<div dir="ltr">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.<br><div><br></div><div>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.<br><br></div><div>Those communication methods are:<br></div><div><br>1) Properties. Normal elements have named properties that either indicate<br>   or influence their behaviour. Container elements (like bins and<br>   pipelines) not only have their own properties, but have a mechanism (via<br>   gst_child_proxy_get() and gst_child_proxy_set() ) of examining and<br>   changing the properties of enclosed elements. This is done by prefixing<br>   the name the element was created with, with the name of the<br>   property. Thus "videovalve::drop" is the name of the "drop" property of<br>   the valve element named "videovalve" inside a container. These work<br>   recursively in the case of containers within containers. Properties can<br>   be changed when an element is active, but the effects are<br>   element-dependant.<br><br>2) Capabilities. Capabilities are how two connected elements negotiate what<br>   sort of data they will be transferring between their pads. Negotiations<br>   can be very complex, but they eventually either fail (often leading to<br>   mysterious pipeline errors) or succeed and result in a shared list of<br>   specific properties of the data that will be transferred. For video<br>   media, the negotiated capabilities are one of the few ways to determine<br>   the frame-height, -width and -aspect-ratios of the playing stream.<br><br>3) Metadata. Once two elements are linked and data can flow, it comes in<br>   the form of Buffers and Events. Buffers can either be raw data like<br>   video frames, or it can be Metadata. Metadata is information about the<br>   stream that has been determined by some upstream element. This data is<br>   another way the height and width of video frames can be determined, but<br>   its harder for an application to get at, as it needs to install a<br>   metadata probe on a pad in the video stream, and wait for the Metadata<br>   to show up.<br><br>4) Tags. Tags are a kind-of in-stream metadata that reports what the source<br>   data has to say about the data (as opposed to what GStreamer elements<br>   say). Thus this often contains things like track names, album authors<br>   and other .mp3 metadata.<br><br>5) Signals. Signals are a way for an element to asynchronously report<br>   important state changes to any interested parties. By default, any<br>   signal that an element produces is ignored. To detect an element's<br>   signal, a signal handler with a callback must be attached to that<br>   element, and the callback will be invoked whenever the class of handled<br>   signals is raised.<br><br>6) Messages. Unlike signals, which don't propagate outside their element,<br>   messages are a long-distance communication method for elements to report<br>   information to the application program. Provided that the application<br>   has installed a message watcher on the GstBus of its main pipeline, any<br>   message issued by an element will 'bubble-up' to the message watcher and<br>   invoke its callback.<br><br>7) Events. Events are, in many ways, the opposite of Messages. Instead of<br>   'bubbling-up' to the outermost containing element, they percolate<br>   downward to the lowest contained elements and are either passed upstream<br>   or downstream (depending on the type of event) from one element to<br>   another. Bins and Pipelines pass upstream events to each child that is a<br>   sink and downstream events to each child that is a source. A Bin which<br>   contains a sink or source (or both) will declare itself to be a sink or<br>   source (or both) as well, so this scheme works recursively. Thus an<br>   upstream event sent to the main pipeline will eventually be delivered to<br>   every elementary sink element to work its way upstream towards the<br>   sources, and a downstream event will be delivered to every elementary<br>   source element, to work its way downstream to the sinks.  Any event that<br>   an element can't deal with itself, will just be passed onward.<br><br>8) Queries. Queries are something I haven't much looked into yet, but they<br>   seem to be a sort of blocking Event that gets responded to, rather than<br>   asynchronously handled.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 3:18 AM, frank82 <span dir="ltr"><<a href="mailto:francescomarino84627@gmail.com" target="_blank">francescomarino84627@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
you can use GstMeta API. You can find reference in GStreamer Plugin Writer's<br>
Manual at par 15.3.<br>
Basically, after defining the metadata API , you can add extra info to the<br>
GstBuffer in the my_decoder and get the info in extra_element.<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/Pass-extra-information-between-elements-in-a-pipeline-tp4669768p4669798.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Pass-extra-information-between-elements-in-a-pipeline-tp4669768p4669798.html</a><br>
<div class="HOEnZb"><div class="h5">Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature">Stirling Westrup<br>Programmer, Entrepreneur.<br><a href="https://www.linkedin.com/e/fpf/77228" target="_blank">https://www.linkedin.com/e/fpf/77228</a><br><a href="http://www.linkedin.com/in/swestrup" target="_blank">http://www.linkedin.com/in/swestrup</a><br><a href="http://technaut.livejournal.com" target="_blank">http://technaut.livejournal.com</a><br><a href="http://sourceforge.net/users/stirlingwestrup" target="_blank">http://sourceforge.net/users/stirlingwestrup</a></div>
</div>