parsebin: Not emitting no-more-pads?

[Krzysztof Konopko]

On Sat, 2019-06-22 at 07:49 +0200, Krzysztof Konopko wrote:
> On Fri, 2019-06-21 at 18:43 -0400, Nicolas Dufresne wrote:
> > Le vendredi 21 juin 2019 à 23:04 +0200, Krzysztof Konopko a écrit :
> > > On Fri, 2019-06-21 at 16:23 -0400, Nicolas Dufresne wrote:
> > > > Le vendredi 21 juin 2019 à 19:37 +0200, Krzysztof Konopko a
> > > > écrit
> > > > :
> 
> [...]
> 
> > Yes, it's a replacement. It's not impossible that in the future new
> > elements end up no longer implementing the no-more-pads callback.
> > 
> > > The latter seems like a fundamental part of `GstElement` API so
> > > at
> > > least there's some inconsistency as it's advertised for example
> > > by
> > > `gst-inspect-1.0`?
> > 
> > I'm not sure what gst-inspect-1.0 has to do with that. parsebin is
> > a
> > completely new element, which have never implemented that, so I
> > don't
> > see how this could be an API break. It was written from scratch to
> > support the replacement of playbin2 (called playbin), so it makes
> > no
> > sense to add playbin2 feature into it.
> > 
> 
> `gst-inspect-1.0 parsebin` yields:
> 
>     ...
>     Element Signals:
>     ...
>       "no-more-pads" :  void user_function (GstElement* object,
>                                             gpointer user_data);
>     ...
> 
> > > Are you saying that I should be listening for 'stream-collection'
> > > message instead of 'no-more-pads' signal?
> > 
> > If you want to use this new element called parsebin, yes. If you
> > want
> > to use decodebin instead, no-more-pads will be emited.
> > 
> 
> OK, understood.  Fair enough.
> 

Looking further into this, I don't understand how 'message::stream-
collection' can be a replacement for 'no-more-pads'.  The former is
sent _before_ the pads are exposed while I want for example to know
when it's fine to query for the duration (when all output pads are
exposed to be able to send an upstream query to 'parsebin').

And what is the harm in having 'no-more-pads' emitted after all pads
are exposed?  The documentation of 'parsebin' shows that it supports
this signal which IMO makes sense as it's consistent with `GstElement`
interface.

Basically what I'm trying to do is to use 'parsebin' and handle
typefinding and some of auto-plugging complexity for me.  I just want
to tell it what output caps I'm interested in using 'autoplug-
factories'.  Specifically I'm looking for elementary streams (like
H.264) which I want to set up decoding for in my app (so not interested
in anything like 'decodebin' or 'urisourcebin').  Is this a valid use
case?

Thanks,
Kris