GNOME Bugzilla – Bug 780181
DASH Live playback stops with 404 error when requested chunks move out of the timeShiftBufferDepth window due to buffering.
Last modified: 2018-11-03 14:06:05 UTC
DASH Live playback stops with 404 error as the requested chunks move out of the timeShiftBufferWindow (buffer window) due to buffering. If dashdemux should consider the timeShiftBufferWindow while advancing to the next fragment. The indexes should be readjusted to be within the window if they are moving out of the window. The URLs used for this testing are: 1) http://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestARD.mpd 2) http://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestBR.mpd
Hi, Can someone please have a look at this issue.
Have you tried recently? Edward made some changes recently to when dashdemux checks the live range. https://bugzilla.gnome.org/show_bug.cgi?id=783075
Hello Ashley, I tried this on 1.12.0 version. Now 404 error is not thrown at all even if the chunk download fails. The next chunk download requests keep coming for download & they keep failing. As a result nothing plays & no error is seen as well. As far as I had analysed, gst_adaptive_demux_eos_handling() & gst_adaptive_demux_stream_update_fragment_info() are called after 404 as the start time of the fragment is lesser than the live range_start. But this moves the download request to the next fragment & I have noticed there can be a difference of hundreds of fragments between present request & the next available fragment. This is very easy to reproduce if we pause the live for some time & unpause it later on.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/536.