GNOME Bugzilla – Bug 740009
dashdemux: gst_dash_demux_download_wait causes abort for dynamic MPD
Last modified: 2014-12-11 12:19:07 UTC
Testing with DASH stream [1] that has MPD@type="dynamic" causes GStreamer to abort. Using a stream that has MPD@type set to "static" [2] does not exhibit this problem. Both streams use the same media fragments, the only difference is the contents of the MPD. Command line: [GST] gst-plugins-bad> gst-launch-1.0 --gst-debug=dashdemux:5,3 playbin uri='http://dash-live-streams.appspot.com/dash/manifest_e.mpd' The console output prior to the abort: 0:00:00.398173450 17369 0x9b79bb0 DEBUG dashdemux gstmpdparser.c:3544:gst_mpd_client_get_next_fragment_timestamp: Looking for fragment sequence chunk 4 0:00:00.398210606 17369 0x9b79bb0 DEBUG dashdemux gstdashdemux.c:1969:gst_dash_demux_wait_for_fragment_to_be_available:<dashdemux0> Selected fragment has end timestamp > now (4718913000), delaying download 0:00:00.398236044 17369 0x9b79bb0 DEBUG dashdemux gstdashdemux.c:2539:gst_dash_demux_download_wait:<dashdemux0:ghostpad0> Download waiting for 0:00:04.718913000 Attempt to unlock mutex that was not locked Abort (core dumped) Looking at the stack trace in the core file: (gdb) bt
+ Trace 234325
It appears that gst_dash_demux_download_wait issues a call to g_cond_wait_until with a mutex that it does not hold. Searching the dashdemux code, I can't see anywhere where that mutex is locked. These tests were done with the current head of master from git: [GST] gst-plugins-bad> git describe 1.4.0-643-g5e8624e [GST] gst-plugins-bad> git log commit 92796446a23bae05cf3fd70cfe161f04e0dac980 Author: Julien Isorce <j.isorce@samsung.com> Date: Wed Nov 12 09:41:53 2014 +0000 [1] http://dash-live-streams.appspot.com/dash/manifest_e.mpd [2] http://dash-live-streams.appspot.com/dash/manifest_b.mpd
Created attachment 290513 [details] [review] claim mutex in gst_dash_demux_download_wait I had a quick attempt to fix the bug by simply adding a g_mutex_lock in to gst_dash_demux_download_wait. This stops the abort, but when trying the problematic test stream, it now blocks waiting to preroll. Not sure if the preroll problem is another bug, or if this patch does not solve the problem.
Can you test again with latest git master? I think this problem was addressed at the base class.
I agree, I'm not seeing the problem when using the refactored version of dashdemux.
Thanks for re-testing. Let's declare this fixed then :)