GNOME Bugzilla – Bug 736012
dashdemux hlsdemux mssdemux: playback failing due to pad EOS state
Last modified: 2014-09-18 15:23:54 UTC
Commit 060b16ac75ac227d4cfe1db89ccdc4f4b31545ff seems to have broken DASH playback. If I run the following: gst-launch-1.0 playbin uri=http://rdmedia.bbc.co.uk/dash/ondemand/bbb/avc3/1/client_manifest-separate_init.mpd The client hangs after fetching the video and audio intialisation segments. From the debug output it looks like dashdemux gets stuck in the state of waiting for the initialisation segments to arrive, event though wireshark shows that they are successfully delivered; the last debug before it hangs is this: [...] 0:00:00.090497256 6531 0xb3e025b0 INFO dashdemux gstdashdemux.c:1789:gst_dash_demux_get_next_header:<dashdemux0> Fetching header A2-aud.mp4/IS 0--1 0:00:00.090519885 6531 0xb3e025b0 DEBUG dashdemux gstdashdemux.c:2161:gst_dash_demux_stream_download_uri:<dashdemux0:ghostpad1> Downloading uri: http://rdmedia.bbc.co.uk/dash/ondemand/bbb/avc3/1/A2-aud.mp4/IS, range:0 - -1 0:00:00.091131974 6531 0xb3e025b0 DEBUG dashdemux gstdashdemux.c:2193:gst_dash_demux_stream_download_uri:<dashdemux0:ghostpad1> Waiting for fragment download to finish: http://rdmedia.bbc.co.uk/dash/ondemand/bbb/avc3/1/A2-aud.mp4/IS If I roll back to the previous commit, 63a943aa8215be781b62b77dfdb2d2ad2c534899, playback works as normal.
This commit was added as fix for bug #735357.
Same with: gst-play-1.0 http://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
commit bda4eae1cc0258a918c4ba039f84b29ead0eb049 Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Sep 4 18:21:38 2014 +0300 mssdemux: Don't send flush events to deactivated pads https://bugzilla.gnome.org/show_bug.cgi?id=736012 commit 51a9e13bf23940b9463e27a3d279ee21eb5a9bc1 Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Sep 4 18:21:25 2014 +0300 dashdemux: Don't send flush events to deactivated pads https://bugzilla.gnome.org/show_bug.cgi?id=736012 commit f6c6d9c280f94e66fe29531ac5a38d7add051407 Author: Sebastian Dröge <sebastian@centricular.com> Date: Thu Sep 4 18:20:58 2014 +0300 hlsdemux: Don't send flush events to deactivated pads https://bugzilla.gnome.org/show_bug.cgi?id=736012
Still doesn't work for me with DASH. On different runs it will initially fetch a varying number of video/audio segments and will open an X window, but video playback doesn't start. Very occasionally, playback does start, but it stops a short way into the stream.
I noticed a regression with DASH the other day, which was not related to the flushing/pad stuff, since it happened before Wim pushed that change.
This could be related to https://bugzilla.gnome.org/show_bug.cgi?id=736295
(In reply to comment #4) > Still doesn't work for me with DASH. > > On different runs it will initially fetch a varying number of video/audio > segments and will open an X window, but video playback doesn't start. Very > occasionally, playback does start, but it stops a short way into the stream. Can you get a debug log and also a backtrace of all threads when it stops?
(In reply to comment #7) [...] > Can you get a debug log and also a backtrace of all threads when it stops? Sure: http://dev-iplatforms.kw.bbc.co.uk/~chrisb/dash.log http://dev-iplatforms.kw.bbc.co.uk/~chrisb/dash.backtrace These files were captured on a run in which the first segment of audio & video were presented, but the client seemed to stall when it got to downloading segment 3 of the A/V representations.
0:00:01.662786751 6300 0xb49029b0 WARN GST_PADS gstpad.c:3742:gst_pad_peer_query:<souphttpsrc0:src> could not send sticky events Seems to be caused by the flush-stop change patches. I'm working on a fix.
Created attachment 286420 [details] [review] dashdemux: fix clearing of eos state in pads The internal pad still keeps its EOS flag and event as it can be assigned after the flush-start/stop pair is sent. The EOS is assigned from the streaming thread so this is racy. To be sure to clear it, it has to be done after setting the source to READY to be sure that its streaming thread isn't running.
Comment on attachment 286420 [details] [review] dashdemux: fix clearing of eos state in pads Why not just deactivate/reactivate the internal pad? But seems ok
(In reply to comment #11) > (From update of attachment 286420 [details] [review]) > Why not just deactivate/reactivate the internal pad? > > But seems ok I already told on IRC but just to register it here: the internal pad is a proxy pad and deactivating/reactivating it will also do it on the ghostpad, dropping the stream-start and segment events and we don't want to do that.
commit 01ccac24fa1f69687c42e9ae7b7148174040007b Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed Sep 17 17:27:53 2014 -0300 mssdemux: fix clearing of eos state in pads The internal pad still keeps its EOS flag and event as it can be assigned after the flush-start/stop pair is sent. The EOS is assigned from the streaming thread so this is racy. To be sure to clear it, it has to be done after setting the source to READY to be sure that its streaming thread isn't running. https://bugzilla.gnome.org/show_bug.cgi?id=736012 commit 07b59c93c2f724cbd23d45539847147ec5c21760 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed Sep 17 17:27:25 2014 -0300 hlsdemux: fix clearing of eos state in pads The internal pad still keeps its EOS flag and event as it can be assigned after the flush-start/stop pair is sent. The EOS is assigned from the streaming thread so this is racy. To be sure to clear it, it has to be done after setting the source to READY to be sure that its streaming thread isn't running. https://bugzilla.gnome.org/show_bug.cgi?id=736012 commit 24c99712a87f35688947ede03d5d73cecfe813b5 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Wed Sep 17 14:51:53 2014 -0300 dashdemux: fix clearing of eos state in pads The internal pad still keeps its EOS flag and event as it can be assigned after the flush-start/stop pair is sent. The EOS is assigned from the streaming thread so this is racy. To be sure to clear it, it has to be done after setting the source to READY to be sure that its streaming thread isn't running. https://bugzilla.gnome.org/show_bug.cgi?id=736012