[gst-devel] why is 'islast' parameter in "new-decoded-pad" signal on decodebin/decodebin2 deprecated?

Alberto Vigata alberto at nelalabs.com
Fri Mar 19 02:57:50 CET 2010


I highly suspected that mpeg systems may have something to do with
this. Having worked on those quite a bit it is true that their lack of
an 'stream index' complicates the implementation of something like the
'islast' flag.

Here is one suggestion though. For those containers that this
information is available from the start, think AVI, MP4.., 'islast'
could be made available reliably and it would be useful.

I was originally looking for a way to have GStreamer provide me a map
of the streams inside a container on startup so I could make pipeline
building decisions based on the streams of the source but without
something like 'islast' is difficult to achieve.

Alberto

On Wed, Mar 17, 2010 at 8:50 PM, Michael Smith <msmith at xiph.org> wrote:
> On Mon, Mar 15, 2010 at 10:25 PM, Alberto Vigata <alberto at nelalabs.com> wrote:
>> Hello gstreamer devs,
>>
>> I was playing around with decodebin and decodebin2 and the docs say
>> that the 'islast' parameter is now deprecated. The prototype for the
>> "new-decoded-pad" singal handler is as follows:
>>
>> void                user_function                      (GstDecodeBin *bin,
>>                                                        GstPad       *pad,
>>                                                        gboolean      islast,
>>                                                        gpointer
>> user_data)
>>
>> The docs state that islast is deprecated for both decodebin and
>> decodebin2. Certainly, there is the need of knowing when no more pads
>> are going to become available so I'm assuming there is now a
>> new/better way to get that information outside the "new-decoded-pad"
>> signal. Which one is it?
>
> The main reason for deprecating that is that it isn't reliable - you
> have to implement your code as if this might never be called with it
> set to true anyway. As such, there's not so much use in having it at
> all.
>
> This is because for some formats (including very common ones like
> mpeg-{ps,ts}), new streams can actually start at any arbitrary time -
> there's no way to know if there might be more pads added in the
> future.
>
> Mike
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>




More information about the gstreamer-devel mailing list