mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-13 21:01:14 +00:00
131 lines
4.7 KiB
Text
131 lines
4.7 KiB
Text
problem
|
|
-------
|
|
|
|
Since gstreamer uses a hierarchical pipeline layout individual elements
|
|
can be inside N levels of containers (bins). Elements can also produce
|
|
interesting information for the user app or for its parent.
|
|
|
|
Consider the mp3parse element that could detect id3 tags in the stream.
|
|
One way to let the app know about those tags is by emitting a signal. The
|
|
problem with this signal is that the app has to perform a g_signal_connect
|
|
on this element. This might not always be possible/feasable because
|
|
the APP might not know about the mp3parse element (eg. an autoplugged
|
|
pipeline or a compound object). The app could instrospect each element
|
|
in the pipeline and look for known properties/signals to connect to,
|
|
but that looks a bit ugly IMO.
|
|
|
|
Signal proxying is also not very feasable because signals are tied to
|
|
class instances.
|
|
|
|
let's take the following use case:
|
|
|
|
- the user autoplugs an mpeg1 pipeline
|
|
|
|
- the autoplugged pipeline most likely contains an mpegdemuxer, an mp3
|
|
decoder, mpegdecoder etc.
|
|
|
|
- the mpegdemuxer knows the (average) bitrate of the stream.
|
|
|
|
- the mpegdecoder knows the framerate of the stream
|
|
|
|
- the mp3 decoder has some neat stuff too (bitrate, layer etc..)
|
|
|
|
how are we going to get all those properties to the app? each element
|
|
could fire a signal with the data. It the app were able to connect to
|
|
every signal in each element this would work somewhat.
|
|
|
|
|
|
Requirements
|
|
------------
|
|
|
|
The application can listen to an abritrary bin in the pipeline to collect
|
|
information about that bins children. The app can listen on the top
|
|
level bin to collect all of the elements messages.
|
|
|
|
The data sent out by the elements must not be limited to a fixed set of
|
|
messages; it must be extensible.
|
|
|
|
|
|
proposed solution
|
|
-----------------
|
|
|
|
We propose another way of propagating these element messages to the
|
|
application.
|
|
|
|
An element can send a message to its parent using a
|
|
gst_element_send_message (element, message). The message would be of type
|
|
GstMessage and would be similar to a GstEvent type (maybe even the same).
|
|
|
|
The message would contain GstProps, which can be anything (a string, an
|
|
int, a range etc..). It would also contain the originator of the message.
|
|
|
|
The parent would just simply accept the message (and do something with it)
|
|
or the default handler would just forward the message to its parent etc..
|
|
|
|
The message would bubble up the pipeline. When an element doesn't have
|
|
a parent, the message is converted to a GSignal. The signal ("message")
|
|
would just forward the message to any listening apps.
|
|
|
|
The app can then use the originator field of the message to find out
|
|
where it came from, possibly using the elementfactories klass field to
|
|
find out what type of plugin created this message.
|
|
|
|
For an autoplugged mpeg1 pipeline the following messages could be
|
|
signalled to the app:
|
|
|
|
element klass element property value
|
|
name
|
|
|
|
stream/mpeg/demuxer: (mpegdemux) "bitrate", GST_PROPS_INT (1000000)
|
|
stream/mpeg/demuxer: (mpegdemux) "type", GST_PROPS_STRING ("mpeg1")
|
|
video/mpeg/decoder: (mpeg2dec) "type", GST_PROPS_STRING ("mpeg1")
|
|
video/mpeg/decoder: (mpeg2dec) "frame_rate",GST_PROPS_INT (25)
|
|
video/mpeg/decoder: (mpeg2dec) "size", GST_PROPS_LIST (
|
|
GST_PROPS_INT (320),
|
|
GST_PROPS_INT (200)
|
|
)
|
|
audio/mp3/decoder: (mad) "layer", GST_PROPS_INT (2)
|
|
audio/mp3/decoder: (mad) "bitrate", GST_PROPS_INT (128000)
|
|
audio/mp3/decoder: (mad) "channels", GST_PROPS_INT (2)
|
|
|
|
other possibilities:
|
|
|
|
video/render/X: (xvideosink) "frames_dropped", GST_PROPS_INT (4)
|
|
video/render/X: (xvideosink) "frames_shown", GST_PROPS_INT (254)
|
|
video/mpeg/decoder: (mpeg2dec) "frames_dropped", GST_PROPS_INT (2)
|
|
video/avi/demuxer: (avidemux) "codec", GST_PROPS_FOURCC ("DIVX")
|
|
|
|
or
|
|
|
|
video/mpeg/decoder: (mpeg2dec) "state_changed", GST_PROPS_INT (GST_STATE_PAUSED)
|
|
|
|
or even
|
|
|
|
audio/render/oss: (osssink) "master_clock", GST_PROPS_OBJECT (osssink_clock)
|
|
....
|
|
|
|
or even even:
|
|
|
|
input/file/filesrc: (filesrc) "here_i_am", GST_PROPS_STRING ("alive and kicking")
|
|
|
|
|
|
With standard naming conventions for the element klass type and the
|
|
messages ids, the player can easily create an info dialog to show various
|
|
properties of the stream.
|
|
|
|
The benefits are that we don't need to define N-thousand methods on
|
|
elements, the messages can be anything and we don't have to use the
|
|
heavyweight GObject signals in the core library.
|
|
|
|
|
|
what about?
|
|
-----------
|
|
|
|
- Threads? do we queue events and let the top half collect the messages
|
|
or do we send them to the app in the thread context?
|
|
|
|
- do we need a similar system for core functionalities (clocks, states,
|
|
...) or do we define methods for those?
|
|
|
|
|
|
|