After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740867 - dashdemux not flushing stream on pipeline stop for live content
dashdemux not flushing stream on pipeline stop for live content
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.3
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-11-28 16:56 UTC by Sam Hurst
Modified: 2014-12-05 15:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Condensed log of dashdemux comparing a working case to a failure case. (8.07 KB, text/plain)
2014-11-28 16:56 UTC, Sam Hurst
  Details
Log for "make install" (3.02 KB, text/plain)
2014-12-03 17:53 UTC, Sam Hurst
  Details
adaptivedemux: fix build install order (1.19 KB, patch)
2014-12-04 16:35 UTC, Thiago Sousa Santos
reviewed Details | Review

Description Sam Hurst 2014-11-28 16:56:30 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
Comment 1 Thiago Sousa Santos 2014-12-02 17:40:57 UTC
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
Comment 2 Sam Hurst 2014-12-03 17:52:57 UTC
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
Comment 3 Sam Hurst 2014-12-03 17:53:42 UTC
Created attachment 292086 [details]
Log for "make install"
Comment 4 Thiago Sousa Santos 2014-12-04 16:35:31 UTC
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 5 Tim-Philipp Müller 2014-12-05 03:12:45 UTC
Comment on attachment 292136 [details] [review]
adaptivedemux: fix build install order

Makes sense. Or you can add an explicit dependency.
Comment 6 Sam Hurst 2014-12-05 11:10:29 UTC
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