GStreamer Plugin Writer's Guide (0.10.12) | ||
---|---|---|
<<< Previous | Events: Seeking, Navigation and More | Next >>> |
In this chapter follows a list of all defined events that are currently being used, plus how they should be used/interpreted. You can check the what type a certain event is using the GST_EVENT_TYPE macro (or if you need a string for debugging purposes you can use GST_EVENT_TYPE_NAME).
In this chapter, we will discuss the following events:
For more comprehensive information about events and how they should be used correctly in various circumstances please consult the GStreamer design documentation. This section only gives a general overview.
End-of-stream events are sent if the stream that an element sends out is finished. An element receiving this event (from upstream, so it receives it on its sinkpad) will generally just process any buffered data (if there is any) and then forward the event further downstream. The gst_pad_event_default () takes care of all this, so most elements do not need to support this event. Exceptions are elements that explicitly need to close a resource down on EOS, and N-to-1 elements. Note that the stream itself is not a resource that should be closed down on EOS! Applications might seek back to a point before EOS and continue playing again.
The EOS event has no properties, which makes it one of the simplest events in GStreamer. It is created using the gst_event_new_eos() function.
It is important to note that only elements driving the pipeline should ever send an EOS event. If your element is chain-based, it is not driving the pipeline. Chain-based elements should just return GST_FLOW_UNEXPECTED from their chain function at the end of the stream (or the configured segment), the upstream element that is driving the pipeline will then take care of sending the EOS event (or alternatively post a SEGMENT_DONE message on the bus depending on the mode of operation). If you are implementing your own source element, you also do not need to ever manually send an EOS event, you should also just return GST_FLOW_UNEXPECTED in your create function (assuming your element derives from GstBaseSrc or GstPushSrc).
The flush start event is sent downstream if all buffers and caches in the pipeline should be emptied. "Queue" elements will empty their internal list of buffers when they receive this event, for example. File sink elements (e.g. "filesink") will flush the kernel-to-disk cache (fdatasync () or fflush ()) when they receive this event. Normally, elements receiving this event will simply just forward it, since most filter or filter-like elements don't have an internal cache of data. gst_pad_event_default () does just that, so for most elements, it is enough to forward the event using the default event handler.
As a side-effect of flushing all data from the pipeline, this event unblocks the streaming thread by making all pads reject data until they receive a Flush Stop signal (elements trying to push data will get a WRONG_STATE flow return and stop processing data).
The flush-start event is created with the gst_event_new_flush_start (). Like the EOS event, it has no properties. This event is usually only created by elements driving the pipeline, like source elements operating in push-mode or pull-range based demuxers/decoders.
The flush-stop event is sent by an element driving the pipeline after a flush-start and tells pads and elements downstream that they should accept events and buffers again (there will be at least a NEWSEGMENT event before any buffers first though).
If your element keeps temporary caches of stream data, it should clear them when it receives a FLUSH-STOP event (and also whenever its chain function receives a buffer with the DISCONT flag set).
The flush-stop event is created with gst_event_new_flush_stop (). Like the EOS event, it has no properties.
A new segment event is sent downstream to either announce a new segment of data in the data stream or to update the current segment with new values. A new segment event must always be sent before the first buffer of data and after a flush (see above).
The first new segment event is created by the element driving the pipeline, like a source operating in push-mode or a demuxer/decoder operating pull-based. This new segment event then travels down the pipeline and may be transformed on the way (a decoder, for example, might receive a new-segment event in BYTES format and might transform this into a new-segment event in TIMES format based on the average bitrate).
New segment events may also be used to indicate 'gaps' in the stream, like in a subtitle stream for example where there may not be any data at all for a considerable amount of (stream) time. This is done by updating the segment start of the current segment (see the design documentation for more details).
Depending on the element type, the event can simply be forwarded using gst_pad_event_default (), or it should be parsed and a modified event should be sent on. The last is true for demuxers, which generally have a byte-to-time conversion concept. Their input is usually byte-based, so the incoming event will have an offset in byte units (GST_FORMAT_BYTES), too. Elements downstream, however, expect new segment events in time units, so that it can be used to update the pipeline clock. Therefore, demuxers and similar elements should not forward the event, but parse it, free it and send a new newsegment event (in time units, GST_FORMAT_TIME) further downstream.
The newsegment event is created using the function gst_event_new_new_segment (). See the API reference and design document for details about its parameters.
Elements parsing this event can use gst_event_parse_new_segment_full() to extract the event details. Elements may find the GstSegment API useful to keep track of the current segment (if they want to use it for output clipping, for example).
Seek events are meant to request a new stream position to elements. This new position can be set in several formats (time, bytes or "default units" [a term indicating frames for video, channel-independent samples for audio, etc.]). Seeking can be done with respect to the end-of-file, start-of-file or current position, and usually happens in upstream direction (downstream seeking is done by sending a NEWSEGMENT event with the appropriate offsets for elements that support that, like filesink).
Elements receiving seek events should, depending on the element type, either just forward it upstream (filters, decoders), change the format in which the event is given and then forward it (demuxers), or handle the event by changing the file pointer in their internal stream resource (file sources, demuxers/decoders driving the pipeline in pull-mode) or something else.
Seek events are built up using positions in specified formats (time, bytes, units). They are created using the function gst_event_new_seek (). Note that many plugins do not support seeking from the end of the stream or from the current position. An element not driving the pipeline and forwarding a seek request should not assume that the seek succeeded or actually happened, it should operate based on the NEWSEGMENT events it receives.
Elements parsing this event can do this using gst_event_parse_seek().
Navigation events are sent upstream by video sinks to inform upstream elements of where the mouse pointer is, if and where mouse pointer clicks have happened, or if keys have been pressed or released.
All this information is contained in the event structure which can be obtained with gst_event_get_structure ().
Check out the navigationtest element in gst-plugins-good for an idea how to extract navigation information from this event.
Tagging events are being sent downstream to indicate the tags as parsed from the stream data. This is currently used to preserve tags during stream transcoding from one format to the other. Tags are discussed extensively in the chapter called Tagging (Metadata and Streaminfo). Most elements will simply forward the event by calling gst_pad_event_default ().
The tag event is created using the function gst_event_new_tag (), but more often elements will use either the gst_element_found_tags () function or the gst_element_found_tags_for_pad (), which will do both: post a tag message on the bus and send a tag event downstream. All of these functions require a filled-in taglist as argument, which they will take ownership of.
Elements parsing this event can use the function gst_event_parse_tag () to acquire the taglist that the event contains.
<<< Previous | Home | Next >>> |
Upstream events | Up | Creating special element types |