[gst-devel] How can I get full information about a media file?
lrn1986 at gmail.com
Thu Apr 1 17:29:06 CEST 2010
On 01.04.2010 13:17, wl2776 wrote:
> lrn-2 wrote:
>> while (TRUE)
>> GstMessage *msg = gst_bus_pop(mBus);
>> if (msg)
>> if (!OnBusMessage(mBus,msg))
>> OnBusMessage() here doesn't call gst_message_unref() either. I don't
>> know, maybe it's a bug on my part.
> The documentation:
> Returns :
> The GstMessage that is on the bus, or NULL if the bus is empty. The message
> is taken from the bus and needs to be unreffed with gst_message_unref()
> after usage. MT safe.
> So, one gst_message_unref() should be.
Thanks, i'll remember that.
> Now, when the pipeline is built, how can I get an information about the
> I see only one way - gst_bin_iterate_... elements then, for each element
> iterate its pads and gst_pad_get_negotiated_caps().
> By the way, gst_pad_get_negotiated_caps() returns null, when called right
> after gst_element_link_pads()
> from the no-more-pads handler.
In no-more-pads i've used gst_element_iterate_src_pads() on decodebin
element (with gst_iterator_next() and a standard gstiterator spell). For
each pad it returns you can gst_pad_get_caps(),
> I'd like to somewhat shorten the procedure - for example, iterate sinks and
> iterate sink pads.
srcs, not sinks. Src pads of decodebin are the output pads of decodebin.
Sink pads are the input pads. With filesrc ! decodebin pipeline you
should see only one sinkpad of decodebin - the one that gets raw data
from filesrc. Obviously, it is not interesting at all (sink pads never are).
> From what I've seen on the pictures, built by GST_DEBUG_BIN_TO_DOT_FILE, I
> need only decoder elements.
> There is a function gst_bin_iterate_all_by_interface().
> Is there any interface, that all decoders support?
It is enough to iterate source pads of the bin as a whole, without
digging into its internal organs. By doing this you'll get all
decodeable streams of the source file, and 'unknown' handler will
provide some info on undecodeable streams.
> However, this method also doesn't give a full information, if there is more
> than 2 streams in a file. As far as I understand, uridecodebin will not
> render more than two streams.
uridecodebin (or decodebin) will have one src pad for each decodeable
stream (regardless of how many streams there are).
P.S. GStreamer devs, am i explaining this wrong, or have i missed
something important in my explanation? I expected that by now someone
would comment on this discussion.
More information about the gstreamer-devel