mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-15 04:46:32 +00:00
138 lines
4.3 KiB
Text
138 lines
4.3 KiB
Text
This is a round up from our IRC session on events. It's open for
|
|
discussion of course.
|
|
|
|
Definition
|
|
----------
|
|
|
|
The event system is designed to be a mechanism for _inter_plugin_
|
|
communication. Their scope is therefore limited in a way that they do
|
|
not serve as a way to communicate between plugins and the app (signals
|
|
and properties are still used for plugin-app communication).
|
|
|
|
Events will be generated by either a plugin or the app. It should be
|
|
possible for a plugin to generate an event on one of its pads and it
|
|
should be possible for an app to insert an event on an abitrary pad in
|
|
the pipeline.
|
|
|
|
|
|
Event handling
|
|
--------------
|
|
|
|
Events can both travel upstream or downstream. Some events, by nature,
|
|
only travel in one direction.
|
|
|
|
* downstream events
|
|
|
|
- Travel in the same way buffers do. This includes that they are handled
|
|
by the scheduler. The rationale is that the events should be kept
|
|
as close to the buffers are possible.
|
|
|
|
- plugins should check the type of the GstData passed in the _chain
|
|
or _loop function and act appropriatly. This can be done by either
|
|
doing their own stuff or by calling the default handler.
|
|
|
|
- are handled on the sink pad.
|
|
|
|
* upstream events
|
|
|
|
- are handled with an event handler attached to the srcpad. A default
|
|
handler will be implemented for pads that don't implement their own
|
|
handler.
|
|
|
|
- travel as fast as possible. the rationale is that a seek event should
|
|
get to the src element ASAP.
|
|
|
|
|
|
Possible candidates for events
|
|
------------------------------
|
|
|
|
- QoS
|
|
quality of service. Plugins can notify other plugins about the quality
|
|
of the pipeline. A video element can for example say that it receives
|
|
too much frames and that plugins connected to it need to slow down.
|
|
|
|
- EOS
|
|
A plugin can notify other plugins that it has run out-of-data.
|
|
|
|
- Seek
|
|
Used to notify plugins that they need to seek to a certain byte offset
|
|
or timestamp.
|
|
|
|
- discontinuous
|
|
A plugin has detected a discontinuity in the stream. Other plugins
|
|
might need to resync.
|
|
|
|
- flush
|
|
Plugins need to get rid of any buffered data ASAP.
|
|
|
|
- caps nego??
|
|
- bufferpool get??
|
|
- ...
|
|
|
|
|
|
application generated events
|
|
----------------------------
|
|
|
|
The application can insert events into the pipeline at arbirary
|
|
places. This will be done by calling gst_pad_event() on a pad.
|
|
|
|
A first implementation will only cover inserting events on src pads
|
|
since inserting events on sinkpads needs changes to the scheduler.
|
|
|
|
|
|
Effects of events on plugins
|
|
----------------------------
|
|
|
|
some events are going to change the state of an element. The EOS event
|
|
will for example change the state of an element to the PAUSED state. Not
|
|
sure when or how this will happen.
|
|
|
|
|
|
use cases
|
|
---------
|
|
|
|
1) filesrc ! fakesink
|
|
|
|
filesrc will read until it reaches EOF. It will then create a GstEvent
|
|
of type EOS and return it in the _get function. The event will travel
|
|
downstream and will reach the fakesink element. Fakesink will detect
|
|
the event in the _chain function and will call the default handler. The
|
|
default handler will set the element to the paused state. filesrc will
|
|
eventually change its state to PAUSED, probably before sending out the
|
|
event (TBD)
|
|
|
|
2) filesrc ! fakesink
|
|
|
|
The app wants to perform a seek on filesrc. It'll call the gst_pad_event()
|
|
on filesrcs src pad with the SEEK event type. The event handler will
|
|
react and change filesrcs internal status. filesrc will return a DISCONT
|
|
event before returning the buffer with the new offset.
|
|
|
|
3) filesrc ! mpeg2parse video_0! queue ! { mpeg2dec ! xvideosink }
|
|
|
|
lost of possibilities here: The app can choose to insert a seek event
|
|
on the filesrc element (byte offset), it can insert a byte/time offset
|
|
seek on the video_0 pad of mpeg2parse or it can insert a time seek event
|
|
on mpeg2decs src pad.
|
|
|
|
the event will travel upstream using the handlers and the intermediate
|
|
elements can convert the event from a time to a byte offset (possibly
|
|
using GstTimeCache to speed up things).
|
|
|
|
Filesrc will get a byte seek event on its src pad and will proceed as
|
|
in case 2.
|
|
|
|
As can be seen from this example the app will generate an event in another
|
|
context than those of the plugins, so this will need proper locking.
|
|
|
|
The app can also choose to insert a flush event on one of the src
|
|
pads. The plugins would clear their cached data and forward the event
|
|
to their upstream peer pad(s).
|
|
|
|
4)...
|
|
|
|
Insert impossible case here..
|
|
|
|
|
|
|
|
|