From 4af36c2ac6108bb953fab663afeceed197ade279 Mon Sep 17 00:00:00 2001 From: Wim Taymans Date: Wed, 5 Dec 2001 21:01:43 +0000 Subject: [PATCH] Added some ramblings about a messaging system idea.. Original commit message from CVS: Added some ramblings about a messaging system idea.. --- docs/random/wtay/messages | 131 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 docs/random/wtay/messages diff --git a/docs/random/wtay/messages b/docs/random/wtay/messages new file mode 100644 index 0000000000..9b12c3c3b5 --- /dev/null +++ b/docs/random/wtay/messages @@ -0,0 +1,131 @@ +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? + + +