GNOME Bugzilla – Bug 740867
dashdemux not flushing stream on pipeline stop for live content
Last modified: 2014-12-05 15:10:49 UTC
Created attachment 291732 [details] Condensed log of dashdemux comparing a working case to a failure case. When running a live DASH stream, dashdemux isn't properly ending its session leading to a hang in GStreamer as it waits. I've narrowed the actual cause of the hang down to the call to gst_task_join at around line 1046 in gstdashdemux.c, this never returns as whatever thread it's running never returns as it's trying to continuously download segments. Instead, each thread seems to be waiting in gst_dash_demux_download_wait, and then tries to go off and get more segments. I've attached a file containing two excerpts of the logs taken from a working on-demand stream and a failing live stream, showing the differences in what happens after the stream is stopped. An MPD which recreates the flaw is available here http://rdmedia.bbc.co.uk/dash/testmpds/multiperiod/bbb.php I can't quite figure out why it's broken so I'm posting here just in case anyone else has any ideas. As far as I can see there's no while loops for it to get stuck in and it should reach the end of gst_dash_demux_stream_download_loop at which point it will get picked up by the gst_task_join that's waiting but it never gets there. It's also worth noting that when dashdemux says that it's fetching the next fragment, the upstream http src never actually gets anything (but crucially the httpsrc is still instantiated as it never receives the READY_TO_NULL event to shutdown). Best Regards, Sam
Can you still reproduce this with latest git? On Sunday the adaptive demux baseclass was merged. If so, can you provide updated logs with adaptivedemux and dashdemux log messages for further investigation? Thanks
Hi Thiago, I've been trying to test this but unfortunately your new base class doesn't seem to link/install properly. I've been trying to fix it but I don't know libtool all that well so its pretty slow going. I'm attaching a log showing the error. I'm guessing the install just needs to be run on the uridownloader before the adaptive demux? For reference, I've compiled plugins-bad with "./autogen.sh --prefix=/home/sam/build/gstreamer-new/target --disable-decklink --disable-gtk-doc", and then just "make" and "make install" and it's under the install that I see the failure. I'm disabling decklink and gtk-doc as they're both broken too in my build. My current HEAD commit ID is d0892984bce2ef0d2ac0ff3ef2ced2794ecd27cb, just in case something moves. In case it's useful, my libtool version is 2.4.2. Cheers, Sam
Created attachment 292086 [details] Log for "make install"
Created attachment 292136 [details] [review] adaptivedemux: fix build install order This fixes the build for me but I'm far from being an automake expert so I'd someone else to take a look before I can merge. Meanwhile you can use to proceed with the tests. Thanks
Comment on attachment 292136 [details] [review] adaptivedemux: fix build install order Makes sense. Or you can add an explicit dependency.
Hi Thiago, Thanks for the patch and for the work on the new base class. I can confirm that the reported bug no longer exists with the new base class, as it seems to close everything down correctly as expected when the stream closes. I'll set the status of this bug to resolved now. Cheers, Sam