parsebin: Not emitting no-more-pads?

[Krzysztof Konopko-3]

Hi,

I don't see 'parsebin' emitting 'no-more-pads' signal ('pad-added' is
fine).  I also do not see `gst_element_no_more_pads()` called anywhere
in its implementation.

Is this intended or am I missing something?

I've tried it with an MP4 file and it correctly instantiates a
'qtdemux' element which itself exposes all pads correctly and emits
'no-more-pads' which is handled internally by 'parsebin'.  I see no
indication of 'parsebin' doing it itself though.

The idea is that I set blocking probes on the pads exposed, and if I
get 'no-more-pads' from 'parsebin', I can for example query it for the
duration etc.  And then decide what to do next with the pads (at this
point I'm fine with stream selection fall-back behaviour).

Thanks,
Kris

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le vendredi 21 juin 2019 à 19:37 +0200, Krzysztof Konopko a écrit :
> Hi,
>
> I don't see 'parsebin' emitting 'no-more-pads' signal ('pad-added' is
> fine).  I also do not see `gst_element_no_more_pads()` called anywhere
> in its implementation.
>
> Is this intended or am I missing something?

This element is meant to be used with playbin3 elements which uses the
new GstStream API and mechanism to notify new streams.

>
> I've tried it with an MP4 file and it correctly instantiates a
> 'qtdemux' element which itself exposes all pads correctly and emits
> 'no-more-pads' which is handled internally by 'parsebin'.  I see no
> indication of 'parsebin' doing it itself though.
>
> The idea is that I set blocking probes on the pads exposed, and if I
> get 'no-more-pads' from 'parsebin', I can for example query it for the
> duration etc.  And then decide what to do next with the pads (at this
> point I'm fine with stream selection fall-back behaviour).
>
> Thanks,
> Kris
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Krzysztof Konopko-3]

On Fri, 2019-06-21 at 16:23 -0400, Nicolas Dufresne wrote:

> Le vendredi 21 juin 2019 à 19:37 +0200, Krzysztof Konopko a écrit :
> > Hi,
> >
> > I don't see 'parsebin' emitting 'no-more-pads' signal ('pad-added'
> > is
> > fine).  I also do not see `gst_element_no_more_pads()` called
> > anywhere
> > in its implementation.
> >
> > Is this intended or am I missing something?
>
> This element is meant to be used with playbin3 elements which uses
> the
> new GstStream API and mechanism to notify new streams.
>

I understand the purpose of GstStream API but does this mean in this
case the 'stream-collection' message is meant to replace 'no-more-pads'
signal?

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`?

Are you saying that I should be listening for 'stream-collection'
message instead of 'no-more-pads' signal?

Kris

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

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 :
> > > Hi,
> > >
> > > I don't see 'parsebin' emitting 'no-more-pads' signal ('pad-added'
> > > is
> > > fine).  I also do not see `gst_element_no_more_pads()` called
> > > anywhere
> > > in its implementation.
> > >
> > > Is this intended or am I missing something?
> >
> > This element is meant to be used with playbin3 elements which uses
> > the
> > new GstStream API and mechanism to notify new streams.
> >
>
> I understand the purpose of GstStream API but does this mean in this
> case the 'stream-collection' message is meant to replace 'no-more-pads'
> signal?

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.

>
> 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.

>
> Kris
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Krzysztof Konopko-3]

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.

Thank you,
Kris

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Krzysztof Konopko-3]

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel