The event class provides factory methods to construct events for sending and functions to query (parse) received events. Events are
usually created with gst_event_new_*() which takes event-type specific parameters as arguments. To send an event application will usually
use send_event and elements will use
send_event or push_event. The
event should be unreffed with unref if it has not been sent. Events that have been
received can be parsed with their respective gst_event_parse_*() functions. It is valid to pass null for unwanted details.
Events are passed between elements in parallel to the data stream. Some events are serialized with buffers, others are not. Some events
only travel downstream, others only upstream. Some events can travel both upstream and downstream. The events are used to signal special
conditions in the datastream such as EOS (end of stream) or the start of a new stream-segment. Events are also used to flush the pipeline
of any pending data. Most of the event API is used inside plugins. Applications usually only construct and use seek events. To do that
Event.seek is used to create a seek event. It takes the needed parameters
to specity seeking time and mode.
performing a seek on a pipeline:
GstEvent *event;
gboolean result;
...
// construct a seek event to play the media from second 2 to 5, flush
// the pipeline to decrease latency.
event = gst_event_new_seek (1.0,
GST_FORMAT_TIME,
GST_SEEK_FLAG_FLUSH,
GST_SEEK_TYPE_SET, 2 * GST_SECOND,
GST_SEEK_TYPE_SET, 5 * GST_SECOND);
...
result = gst_element_send_event (pipeline, event);
if (!result)
g_warning ("seek failed");
...
Last reviewed on 2006-09-6 (0.10.10)
async flag is set, a thread boundary is prefered.
GST_EVENT_MAKE_TYPE macro,
assigning a free number and filling in the correct direction and serialization flags. New custom events can also be created by
subclassing the event type if needed.
false
immediately. Elements should unlock any blocking functions and exit their streaming functions as fast as possible when this event is
received. This event is typically generated after a seek to flush out all queued data in the pipeline so that the new media is played
as soon as possible.
latency to the running time before synchronising against the clock. The latency is mostly used
in live sinks and is always expressed in the time format.
start and
stop values. The position value of the segment is used in conjunction with the start value to convert the buffer timestamps
into the stream time. This is usually done in sinks to report the current stream_time. is a valid stop given, it must be
greater or equal the start, including when the indicated playback rate is < 0. The applied_rate
value provides information about any rate adjustment that has already been made to the timestamps and content on the buffers
of the stream. (@rate * applied_rate) should always equal the rate that has been requested for playback. For example, if
an element has an input segment with intended playback rate of 2.0 and applied_rate of 1.0, it can adjust incoming
timestamps and buffer content by half and output a newsegment event with rate of 1.0 and applied_rate of 2.0
After a newsegment event, the buffer stream time is calculated with: position + (TIMESTAMP(buf) - start) * ABS (rate * applied_rate)
diff is positive (buffers are late).
proportion value. The proportion value can safely be used to lower or increase the quality
of the element. buffer that caused the element to generate the QOS event. A negative value means that the buffer with timestamp
arrived in time. A positive value indicates how late the buffer with timestamp was. When throttling is enabled,
diff will be set to the requested throttling interval. to generate the QOS event. It is expressed in running time and
thus an ever increasing value. The upstream element can use the diff and timestamp values to decide whether
to process more buffers. For possitive diff, all buffers with timestamp <= timestamp + diff
will certainly arrive late in the sink as well. A (negative) diff value so that timestamp + diff
would yield a result smaller than 0 is not allowed. The application can use general event probes to intercept the QoS event
and implement custom application specific QoS handling.
start to stop at the speed given in rate, also called a playback segment. The
start and stop values are expressed in format. A rate of 1.0 means normal playback
rate, 2.0 means double speed. Negatives values means backwards playback. A value of 0.0 for the rate is not allowed and should be
accomplished instead by PAUSING the pipeline. A pipeline has a default playback segment configured with a start position of 0, a stop
position of -1 and a rate of 1.0. The currently configured playback segment can be queried with
SEGMENT. start and stop fields in playback segment. Adjustments can be made
relative or absolute to the last configured values. A type of NONE means that
the position should not be updated. When the rate is positive and start has been updated, playback will start from the
newly configured start position. For negative rates, playback will start from the newly configured stop position (if any). If the stop
position if updated, it must be different from -1 for negative rates. It is not possible to seek relative to the current playback
position, to do this, PAUSE the pipeline, query the current playback position with
POSITION and update the playback segment current position with a
SET to the desired position.
amount
(expressed in format) of media. It can be used to implement stepping through the video frame by frame or for doing fast
trick modes. A rate of <= 0.0 is not allowed, pause the pipeline or reverse the playback direction of the pipeline to get the same
effect. The flush flag will clear any pending data in the pipeline before starting the step operation. The
intermediate flag instructs the pipeline that this step operation is part of a larger step operation.
taglist.
event has the given name. This function is usually used to check the
name of a custom event.
event and stores the results in the given result locations.
msg after usage.
event and stores the results in the given taglist location. No
reference to the taglist will be returned, it remains valid only until the event is freed. Don't modify or free the
taglist, make a copy if you want to modify it or store it for later use.
