After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 634584 - decodebin2 docs should mention that "new-decoded-pad" signal may be emitted after "no-more-pads"
decodebin2 docs should mention that "new-decoded-pad" signal may be emitted a...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal trivial
: 0.10.31
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-11 13:10 UTC by Philip Jägenstedt
Modified: 2010-11-22 00:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log for gst-launch filesrc location=multi2.ogg ! decodebin2 ! fakesink (55.87 KB, application/octet-stream)
2010-11-11 13:10 UTC, Philip Jägenstedt
Details

Description Philip Jägenstedt 2010-11-11 13:10:44 UTC
Created attachment 174243 [details]
log for gst-launch filesrc location=multi2.ogg ! decodebin2 ! fakesink

Input: http://v2v.cc/~j/theora_testsuite/multi2.ogg

To reproduce: GST_DEBUG_NO_COLOR=1 GST_DEBUG=decodebin2:5 gst-launch filesrc location=multi2.ogg ! decodebin2 ! fakesink 2> ~/log

I'm attaching the log, in which you can see that "new-decoded-pad" is emitted after "no-more-pads".

Curiously, "no-more-pads" isn't even mentioned in <http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-decodebin2.html>, is it not supposed to be used? If so, what's the recommended approach to connecting with the pads?
Comment 1 Philip Jägenstedt 2010-11-11 13:11:42 UTC
Also, the same gst-launch command complaints that:

WARNING: from element /GstPipeline:pipeline0: Internal GStreamer error: clock problem.  Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.
Comment 2 Tim-Philipp Müller 2010-11-11 13:27:29 UTC
> I'm attaching the log, in which you can see that "new-decoded-pad" is emitted
> after "no-more-pads".

This is probably not a bug. This may be a 'chained ogg' file. In this case there'd be pads and a no-more-pads for the first chain, and then later you'd get another (set of) "new-decoded-pad" and "no-more-pads" for the second group/chain, etc. Quite common with ogg/vorbis internet radio.

> Curiously, "no-more-pads" isn't even mentioned in
> <http://www.gstreamer.net/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-decodebin2.html>,
> is it not supposed to be used? If so, what's the recommended approach to
> connecting with the pads?

It's a GstElement signal, it is supposed to be used.

Playbin2 handles this right btw.
Comment 3 Philip Jägenstedt 2010-11-11 13:55:46 UTC
Thanks Tim, I guess this is then a bug on the documentation of "no-more-pads", which certainly had me fooled: "This signals that the element will not generate more dynamic pads." I certainly took this to mean that "new-decoded-pad" wouldn't ever be signaled again.
Comment 4 Tim-Philipp Müller 2010-11-22 00:57:17 UTC
commit 1bfefc50af52adc77eeac1021f0dec90153b8819
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Mon Nov 22 00:54:35 2010 +0000

    docs: improve decodebin2 docs a little
    
    Mention that new pads may be created even after no-more-pads.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=634584