Pass extra information between elements in a pipeline

Stirling Westrup swestrup at gmail.com
Thu Dec 18 08:09:12 PST 2014 

You don't give much information on what kind of information you want to
pass between your elements, or how timely it needs to be. Some information
gets set once at pipeline formation, and is left. Some gets negotiated when
playing some media, and other gets changed dynamically during play.

In any case, when I was first learning GStreamer I made notes of 8 major
ways that elements can communicate between themselves and the controlling
program. Some should clearly be inappropriate for what you are doing, and
some should be plausible. I recommend looking into the plausible ones.

Those communication methods are:

1) Properties. Normal elements have named properties that either indicate
   or influence their behaviour. Container elements (like bins and
   pipelines) not only have their own properties, but have a mechanism (via
   gst_child_proxy_get() and gst_child_proxy_set() ) of examining and
   changing the properties of enclosed elements. This is done by prefixing
   the name the element was created with, with the name of the
   property. Thus "videovalve::drop" is the name of the "drop" property of
   the valve element named "videovalve" inside a container. These work
   recursively in the case of containers within containers. Properties can
   be changed when an element is active, but the effects are
   element-dependant.

2) Capabilities. Capabilities are how two connected elements negotiate what
   sort of data they will be transferring between their pads. Negotiations
   can be very complex, but they eventually either fail (often leading to
   mysterious pipeline errors) or succeed and result in a shared list of
   specific properties of the data that will be transferred. For video
   media, the negotiated capabilities are one of the few ways to determine
   the frame-height, -width and -aspect-ratios of the playing stream.

3) Metadata. Once two elements are linked and data can flow, it comes in
   the form of Buffers and Events. Buffers can either be raw data like
   video frames, or it can be Metadata. Metadata is information about the
   stream that has been determined by some upstream element. This data is
   another way the height and width of video frames can be determined, but
   its harder for an application to get at, as it needs to install a
   metadata probe on a pad in the video stream, and wait for the Metadata
   to show up.

4) Tags. Tags are a kind-of in-stream metadata that reports what the source
   data has to say about the data (as opposed to what GStreamer elements
   say). Thus this often contains things like track names, album authors
   and other .mp3 metadata.

5) Signals. Signals are a way for an element to asynchronously report
   important state changes to any interested parties. By default, any
   signal that an element produces is ignored. To detect an element's
   signal, a signal handler with a callback must be attached to that
   element, and the callback will be invoked whenever the class of handled
   signals is raised.

6) Messages. Unlike signals, which don't propagate outside their element,
   messages are a long-distance communication method for elements to report
   information to the application program. Provided that the application
   has installed a message watcher on the GstBus of its main pipeline, any
   message issued by an element will 'bubble-up' to the message watcher and
   invoke its callback.

7) Events. Events are, in many ways, the opposite of Messages. Instead of
   'bubbling-up' to the outermost containing element, they percolate
   downward to the lowest contained elements and are either passed upstream
   or downstream (depending on the type of event) from one element to
   another. Bins and Pipelines pass upstream events to each child that is a
   sink and downstream events to each child that is a source. A Bin which
   contains a sink or source (or both) will declare itself to be a sink or
   source (or both) as well, so this scheme works recursively. Thus an
   upstream event sent to the main pipeline will eventually be delivered to
   every elementary sink element to work its way upstream towards the
   sources, and a downstream event will be delivered to every elementary
   source element, to work its way downstream to the sinks.  Any event that
   an element can't deal with itself, will just be passed onward.

8) Queries. Queries are something I haven't much looked into yet, but they
   seem to be a sort of blocking Event that gets responded to, rather than
   asynchronously handled.


On Thu, Dec 4, 2014 at 3:18 AM, frank82 <francescomarino84627 at gmail.com>
wrote:
>
> Hi,
> you can use GstMeta API. You can find reference in GStreamer Plugin
> Writer's
> Manual at par 15.3.
> Basically, after defining the metadata API , you can add extra info to the
> GstBuffer in the my_decoder and get the info in extra_element.
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Pass-extra-information-between-elements-in-a-pipeline-tp4669768p4669798.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>


-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141218/d4f74076/attachment-0001.html>

More information about the gstreamer-devel mailing list