Pipeline not going into Playing state when uridecodebin with custom handler is used

Tue Apr 2 11:19:35 PDT 2013

OK, after some debugging I've come across a comment in gsturidecodebin.c
that led me to this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=632782

Looks like instantiating live elements through type-finding either does not
work or at least it's racy.
If this is all true and if there are any ideas of fixing it, I'd be tempted
to have a look and tinker a little bit with it.

Cheers,
Kris

2013/3/28 Krzysztof Konopko <krzysztof.konopko at youview.com>

> Interestingly /decodebin2/ does not propagate instantiated element's
> GstStateChangeReturn return value as it's a type-found signal callback.
> gst-plugin-base/gst/playback/gstdecodebin2.c:connect_pad():
>
> /* Bring the element to the state of the parent */
>     if ((gst_element_set_state (element,
>                 GST_STATE_PAUSED)) == GST_STATE_CHANGE_FAILURE) {
>
> so no way to say there will be no pre-roll.
>
> Does it make any sense to try to instantiate a live element through
> typfinding?
>
> Cheers,
> Kris
>
> On 11/01/13 17:05, Krzysztof Konopko wrote:
> > Hi,
> >
> > I had a closer look into it. The problem can be reduced to something
> > like this (hope you don't mind if I rehash some bits of previous
> > description):
> >
> > gst-launch-1.0 \
> >   uridecodebin uri=file:///tmp/test.sdp caps=video/mpegts \
> >   ! fakesink
> >
> > On my laptop it doesn't matter whether it's a genuine HTTP or filesystem
> > request. It deadlocks.
> >
> >
> > There's a custom vqesdpdemux element which has application/sdp
> > capability on its sink. Here's how the gist of the problem goes:
> >
> > 1. uridecodebin instantiates filesrc, queue2 and vqesdpdemux (typefinder
> > magic)
> >
> > 2. vqesdpdemux receives data (buffers) from filesrc until it gets EOS
> > event on its sink pad (receives SDP content, simple text file)
> >
> > 3. In the same thread were the EOS event was received vqesdpdemux
> > (GstBin) creates a genuine custom vqesrc element which is supposed to
> > receive the RTP traffic
> >
> > 4. The new vqesrc element's state is synchronised with its parent
> > (vqesdpdemux) by calling gst_element_sync_state_with_parent() but this
> > can "trap" it in PAUSED or READY state (depends how far in the
> > transition the pipeline got after sending EOS).
> >
> > Now because vqesrc is a *live* element, it's activated pad thread waits
> > in gst_base_src_wait_playing() for vqesrc to get into PLAYING. But it
> > won't transition to that state if it's "trapped" in pipeline's
> > transition towards READY (depending on timing conditions).
> >
> >
> >
> > I'll be digging into it (*) but if it bells with anyone, please shout.
> >
> > Basically we're looking for (or trying to find/understand) a good
> > pattern to create a new source element somewhere in the *middle* of the
> > pipeline based on some information (buffers) already received and
> > potentially ditch/replace (lop off) the old bit of upstream (if
> > possible) after it's done its job.
> >
> > It works pretty well if the source is explicit (e. g. filesrc). Things
> > get complicated if one wants to use typefind magic and
> > auto-instantiating/connecting (some decodebin element).
> >
> > Cheers,
> > Kris
> >
> > (*) It's a quite involving piece of work to looking into. I'm not doing
> > it because I'm magnanimous but because Mariusz is sitting almost next to
> > me :)
> >
> > On 07/01/13 17:57, Mariusz Buras wrote:
> >> Hi all,
> >>
> >> I have a quite complex problem to describe so first I'll show you my
> >> pipeline setup:
> >>
> >>    uridecodebin uri=http://some_address_somewhere.co.uk/test.sdp
> >> caps=video/mpegts
> >>        ! queue ! tsdemux ! video/x-h264 ! decodebin ! queue !
> xvimagesink
> >>
> >> Where "test.sdp" is an SDP file which refers to a multicast RTP stream.
> >>   I have created an element "vqesrc"[1] which is a live source for this
> >> multicast RTP data.  It takes the contents of an SDP file as a property.
> >>   To get it to be autoplugged by decodebin I have also created
> >> vqesdpdemux which handles "application/sdp" caps much like hlsdemux or
> >> sdpdemux works.
> >>
> >> vqesdpdemux is a bin.  It creates a vqesrc, adds it to itself, sets the
> SDP
> >> file data as a one of the properties of vqesrc and adds a ghost pad on
> >> vqesdpdemux exposing the source pad of the gstvqesrc to outside of the
> >> bin. So when everything works I should be getting something like that on
> >> the diagram[2].  As you can see everything gets autoplugged as expected
> >> and I indeed can see live video on my screen. I have also attached a log
> >> file that shows what's going on when it works [3].
> >>
> >> In vqesdpdemux when I create the vqesrc child element (which is a live
> >> source) I am careful to call gst_element_sync_state_with_parent for the
> >> child.  Also I am careful to return GST_STATE_CHANGE_NO_PREROLL from
> >> vqesdpdemux whenever a request to enter state PAUSED is received as I
> >> know the child I will be adding will be live.
> >>
> >>
> >> The problem starts when uridecodebin is pointed to a locally stored SDP
> >> file, something like this:
> >>
> >>    uridecodebin uri=file:///home/mariusz.buras/tmp/test.sdp
> >> caps=video/mpegts
> >>      ! queue ! tsdemux ! video/x-h264 ! decodebin  ! queue ! xvimagesink
> >>
> >> Basically, what seems to happen is that my pipeline never fully enters
> >> PAUSED state (only vqesdpdemux does) and gets stuck in READY forever.
> >> As shown in [4] pipeline start to preroll but never finishes.  My
> >> experiments showed that in "http case" SDP file is delivered while the
> >> pipline is changing it's state to PLAYING. While in the "broken" case
> >> it's delivered when the pipeline is transitioning to the PAUSED state.
> >> This leads me to believe that something wrong happens (or something good
> >> doesn't happen) when vqesdpdemux receives a sink event callback with a
> >> buffer containing the SDP file.
> >>
> >> What I have tried to fix/mitigate the problem*:
> >>
> >> 1. Forcing vqesrc element state to PLAYING just after it's added to
> >> vqesdpdemux bin with gst_set_state rather than
> >> gst_element_sync_state_with_parent. This makes it work, but I don't
> >> think this is a right thing to do.  It makes me a bit uneasy using  a
> >> half baked "fix" to a problem I don't understand.
> >> 2. Sending a reconfigure event. Doesn't help.
> >> 3. Delaying the creation of vqesrc element - this doesn't work.
> >> 4. Plenty of weird/desperate hacks on vqesdpdemux - same result.
> >>
> >> * when I write that "it doesn't work" I mean that it behaves in the same
> >> or very similar fashion to when the "fix" wasn't applied.
> >>
> >> I've also attached [5] a diagram of the last state the pipeline gets
> >> into when it doesn't work. This is not very helpful though, because
> >> the last state my pipeline fully enters is READY when no auto-plugging
> >> happened yet.
> >>
> >>
> >> I think possibly what is happening is that the pipeline is prerolling in
> >> the PAUSED state so vqesrc doesn't produce any data so the pipeline
> >> never exits the prerolling state so makes it to state PLAYING but then
> >> I'm unsure why it would work with the http case but not with local file.
> >>
> >>
> >> Can someone help me with that?
> >>
> >> Regards,
> >> Mariusz.
> >>
> >>
> >> [1] The code for both of these can be found on github:
> >> https://github.com/sqward/gst-vqe
> >> [2] An example working pipeline attached as
> "example_working_pipeline.jpg"
> >> [3] An example working log attached as "example_working_log.txt"
> >> [4] Log of a broken case attached as "broken_case.txt"
> >> [5] A diagram of "broken" pipeline when it gets stuck in READY state
> >> attached as "broken_case.png"
> >>
> >>
> >>
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >>
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
>
> This transmission contains information that may be confidential and
> contain personal views which are not necessarily those of YouView TV Ltd.
> YouView TV Ltd (Co No:7308805) is a limited liability company registered in
> England and Wales with its registered address at YouView TV Ltd, 3rd Floor,
> 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at
> http://www.youview.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130402/7a9a86f1/attachment-0001.html>