docs/design/part-events.txt

   1 Events
   2 ------
   3
   4 Events are objects passed around in parallel to the buffer dataflow to
   5 notify elements of various events.
   6
   7 Events are received on pads using the event function. Some events should
   8 be interleaved with the data stream so they require taking the STREAM_LOCK,
   9 others don't.
  10
  11 Different types of events exist to implement various functionalities.
  12
  13   GST_EVENT_FLUSH_START:   data is to be discarded
  14   GST_EVENT_FLUSH_STOP:    data is allowed again
  15   GST_EVENT_CAPS:          Format information about the following buffers
  16   GST_EVENT_SEGMENT:       Timing information for the following buffers
  17   GST_EVENT_TAG:           Stream metadata.
  18   GST_EVENT_BUFFERSIZE:    Buffer size requirements
  19   GST_EVENT_SINK_MESSAGE:  An event turned into a message by sinks
  20   GST_EVENT_EOS:           no more data is to be expected on a pad.
  21   GST_EVENT_QOS:           A notification of the quality of service of the stream
  22   GST_EVENT_SEEK:          A seek should be performed to a new position in the stream
  23   GST_EVENT_NAVIGATION:    A navigation event.
  24   GST_EVENT_LATENCY:       Configure the latency in a pipeline
  25   GST_EVENT_STEP:          Stepping event
  26   GST_EVENT_RECONFIGURE:   stream reconfigure event
  27
  28   * GST_EVENT_DRAIN:       Play all data downstream before returning.
  29
  30 * not yet implemented, under investigation, might be needed to do still frames
  31   in DVD.
  32
  33
  34 src pads
  35 --------
  36
  37 A gst_pad_push_event() on a srcpad will first store the sticky event in the
  38 sticky array before sending the event to the peer pad. If there is no peer pad
  39 and the event was not stored in the sticky array, FALSE is returned.
  40
  41 Flushing pads will refuse the events and will not store the sticky events.
  42
  43
  44 sink pads
  45 ---------
  46
  47 A gst_pad_send_event() on a sinkpad will call the event function on the pad. If
  48 the event function returns success, the sticky event is stored in the sticky
  49 event array and the event is marked for update.
  50
  51 When the pad is flushing, the _send_event() function returns FALSE immediately.
  52
  53 When the next data item is pushed, the pending events are pushed first.
  54
  55 This ensures that the event function is never called for flushing pads and that
  56 the sticky array only contains events for which the event function returned
  57 success.
  58
  59
  60 pad link
  61 --------
  62
  63 When linking pads, the srcpad sticky events are marked for update when they are
  64 different from the sinkpad events. The next buffer push will push the events to
  65 the sinkpad.
  66
  67
  68 FLUSH_START/STOP
  69 ~~~~~~~~~~~~~~~~
  70
  71 A flush event is sent both downstream and upstream to clear any pending data
  72 from the pipeline. This might be needed to make the graph more responsive
  73 when the normal dataflow gets interrupted by for example a seek event.
  74
  75 Flushing happens in two stages.
  76
  77  1) a source element sends the FLUSH_START event to the downstream peer element.
  78     The downstream element starts rejecting buffers from the upstream elements. It
  79     sends the flush event further downstream and discards any buffers it is
  80     holding as well as return from the chain function as soon as possible.
  81     This makes sure that all upstream elements get unblocked.
  82     This event is not synchronized with the STREAM_LOCK and can be done in the
  83     application thread.
  84
  85  2) a source element sends the FLUSH_STOP event to indicate
  86     that the downstream element can accept buffers again. The downstream
  87     element sends the flush event to its peer elements. After this step dataflow
  88     continues. The FLUSH_STOP call is synchronized with the STREAM_LOCK so any
  89     data used by the chain function can safely freed here if needed. Any
  90     pending EOS events should be discarded too.
  91
  92 After the flush completes the second stage, data is flowing again in the pipeline
  93 and all buffers are more recent than those before the flush.
  94
  95 For elements that use the pullrange function, they send both flush events to
  96 the upstream pads in the same way to make sure that the pullrange function
  97 unlocks and any pending buffers are cleared in the upstream elements.
  98
  99 A FLUSH_START may instruct the pipeline to distribute a new base_time to
 100 elements so that the running_time is reset to 0.
 101 (see part-clocks.txt and part-synchronisation.txt).
 102
 103
 104 EOS
 105 ~~~
 106
 107 The EOS event can only be sent on a sinkpad. It is typically emited by the
 108 source element when it has finished sending data. This event is mainly sent
 109 in the streaming thread but can also be sent from the application thread.
 110
 111 The downstream element should forward the EOS event to its downstream peer
 112 elements. This way the event will eventually reach the sinks which should
 113 then post an EOS message on the bus when in PLAYING.
 114
 115 An element might want to flush its internally queued data before forwarding
 116 the EOS event downstream. This flushing can be done in the same thread as
 117 the one handling the EOS event.
 118
 119 For elements with multiple sink pads it might be possible to wait for EOS on
 120 all the pads before forwarding the event.
 121
 122 The EOS event should always be interleaved with the data flow, therefore the
 123 GStreamer core will take the STREAM_LOCK.
 124
 125 Sometimes the EOS event is generated by another element than the source, for
 126 example a demuxer element can generate an EOS event before the source element.
 127 This is not a problem, the demuxer does not send an EOS event to the upstream
 128 element but returns GST_FLOW_EOS, causing the source element to stop
 129 sending data.
 130
 131 An element that sends EOS on a pad should stop sending data on that pad. Source
 132 elements typically pause() their task for that purpose.
 133
 134 By default, a GstBin collects all EOS messages from all its sinks before
 135 posting the EOS message to its parent.
 136
 137 The EOS is only posted on the bus by the sink elements in the PLAYING state. If
 138 the EOS event is received in the PAUSED state, it is queued until the element
 139 goes to PLAYING.
 140
 141 A FLUSH_STOP event on an element flushes the EOS state and all pending EOS messages.
 142
 143
 144 SEGMENT
 145 ~~~~~~~
 146
 147 A segment event is sent downstream by an element to indicate that the following
 148 group of buffers start and end at the specified positions. The newsegment event
 149 also contains the playback speed and the applied rate of the stream.
 150
 151 Since the stream time is always set to 0 at start and after a seek, a 0
 152 point for all next buffer's timestamps has to be propagated through the
 153 pipeline using the SEGMENT event.
 154
 155 Before sending buffers, an element must send a SEGMENT event. An element is
 156 free to refuse buffers if they were not preceeded by a SEGMENT event.
 157
 158 Elements that sync to the clock should store the SEGMENT start and end values
 159 and subtract the start value from the buffer timestamp before comparing
 160 it against the stream time (see part-clocks.txt).
 161
 162 An element is allowed to send out buffers with the SEGMENT start time already
 163 subtracted from the timestamp. If it does so, it needs to send a corrected
 164 SEGMENT downstream, ie, one with start time 0.
 165
 166 A SEGMENT event should be generated as soon as possible in the pipeline and
 167 is usually generated by a demuxer or source. The event is generated before
 168 pushing the first buffer and after a seek, right before pushing the new buffer.
 169
 170 The SEGMENT event should be sent from the streaming thread and should be
 171 serialized with the buffers.
 172
 173 Buffers should be clipped within the range indicated by the newsegment event
 174 start and stop values. Sinks must drop buffers with timestamps out of the
 175 indicated segment range.
 176
 177
 178 TAG
 179 ~~~
 180
 181 The tag event is sent downstream when an element has discovered metadata
 182 tags in a media file. Encoders can use this event to adjust their tagging
 183 system. A tag is serialized with buffers.
 184
 185
 186 BUFFERSIZE
 187 ~~~~~~~~~~
 188
 189 NOTE: This event is not yet implemented.
 190
 191 An element can suggest a buffersize for downstream elements. This is
 192 typically done by elements that produce data on multiple source pads
 193 such as demuxers.
 194
 195
 196 QOS
 197 ~~~
 198
 199 A QOS, or quality of service message, is generated in an element to report
 200 to the upstream elements about the current quality of real-time performance
 201 of the stream. This is typically done by the sinks that measure the amount
 202 of framedrops they have. (see part-qos.txt)
 203
 204
 205 SEEK
 206 ~~~~
 207
 208 A seek event is issued by the application to configure the playback range
 209 of a stream. It is called form the application thread and travels upstream.
 210
 211 The seek event contains the new start and stop position of playback
 212 after the seek is performed. Optionally the stop position can be left
 213 at -1 to continue playback to the end of the stream. The seek event
 214 also contains the new playback rate of the stream, 1.0 is normal playback,
 215 2.0 double speed and negative values mean backwards playback.
 216
 217 A seek usually flushes the graph to minimize latency after the seek. This
 218 behaviour is triggered by using the SEEK_FLUSH flag on the seek event.
 219
 220 The seek event usually starts from the sink elements and travels upstream
 221 from element to element until it reaches an element that can perform the
 222 seek. No intermediate element is allowed to assume that a seek to this
 223 location will happen. It is allowed to modify the start and stop times if it
 224 needs to do so. this is typically the case if a seek is requested for a
 225 non-time position.
 226
 227 The actual seek is performed in the application thread so that success
 228 or failure can be reported as a return value of the seek event. It is
 229 therefore important that before executing the seek, the element acquires
 230 the STREAM_LOCK so that the streaming thread and the seek get serialized.
 231
 232 The general flow of executing the seek with FLUSH is as follows:
 233
 234  1) unblock the streaming threads, they could be blocked in a chain
 235     function. This is done by sending a FLUSH_START on all srcpads or by pausing
 236     the streaming task, depending on the seek FLUSH flag.
 237     The flush will make sure that all downstream elements unlock and
 238     that control will return to this element chain/loop function.
 239     We cannot lock the STREAM_LOCK before doing this since it might
 240     cause a deadlock.
 241
 242  2) acquire the STREAM_LOCK. This will work since the chain/loop function
 243     was unlocked/paused in step 1).
 244
 245  3) perform the seek. since the STREAM_LOCK is held, the streaming thread
 246     will wait for the seek to complete. Most likely, the stream thread
 247     will pause because the peer elements are flushing.
 248
 249  4) send a FLUSH_STOP event to all peer elements to allow streaming again.
 250
 251  5) create a SEGMENT event to signal the new buffer timestamp base time.
 252     This event must be queued to be sent by the streaming thread.
 253
 254  6) start stopped tasks and unlock the STREAM_LOCK, dataflow will continue
 255     now from the new position.
 256
 257 More information about the different seek types can be found in
 258 part-seeking.txt.
 259
 260
 261 NAVIGATION
 262 ~~~~~~~~~~~
 263
 264 A navigation event is generated by a sink element to signal the elements
 265 of a navigation event such as a mouse movement or button click.
 266 Navigation events travel upstream.
 267
 268
 269 LATENCY
 270 ~~~~~~~
 271
 272 A latency event is used to configure a certain latency in the pipeline. It
 273 contains a single GstClockTime with the required latency. The latency value is
 274 calculated by the pipeline and distributed to all sink elements before they are
 275 set to PLAYING. The sinks will add the configured latency value to the
 276 timestamps of the buffer in order to delay their presentation.
 277 (See also part-latency.txt).
 278
 279
 280 DRAIN
 281 ~~~~~
 282
 283 NOTE: This event is not yet implemented.
 284
 285 Drain event indicates that upstream is about to perform a real-time event, such
 286 as pausing to present an interactive menu or such, and needs to wait for all
 287 data it has sent to be played-out in the sink.
 288
 289 Drain should only be used by live elements, as it may otherwise occur during
 290 prerolling.
 291
 292 Usually after draining the pipeline, an element either needs to modify timestamps,
 293 or FLUSH to prevent subsequent data being discarded at the sinks for arriving
 294 late (only applies during playback scenarios).
 295