GNOME Bugzilla – Bug 325213
decodebin new-decoded-pad doesn't signal last pad
Last modified: 2008-05-26 11:02:12 UTC
The callback for the new-decoded-pad signal for the decodebin has the following signature: static void cb_newpad (GstElement *decodebin, GstPad *pad, gboolean last, gpointer data); and the last parameter should signal if this is the last pad to be created by the decode bin. unfortunately for me this is always FALSE, even on simple scenarios like decoding mp3 or ogg vorbis.
Created attachment 56505 [details] sample code demonstrating the problem this is a sample code based on the decodebing sample code from the gstreamer manual at http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-components-decodebin.html it prints the value of the last parameter in the decodebin new pad callback. I tried with mp3 and ogg vorbis files, and even though there's only one pad created (naturally) for these, the value of last is 0. one would expect the value to be non-zero.
This is a problem with the way decodebin works currently. Let's take id3demux as an example, it as a source pad template which is of availability 'Sometimes'. When decodebin sees that, it will currently assume they're might be more src pads to be created on that element... and therefore won't set last to TRUE (although there won't be any other pads afterwards).
you have to use the no-more-pads signal. This boolean is useless currently. Keep the bug open for Wim when he will redesign decodebin/playbin for 0.10.
Edward, is this fixed in decodebin2?
This is fixed in decodebin2, since there's internally the notion of groups (of queues/decoders/pads). When a group is exposed, the last pad exposed will always trigger the signal with 'last' set to True. Closing bug, use decodebin2 instead.