adaptivedemux: stream can pause for a long time when server errors encountered
Submitted by David Waring
Link to original bug (#760930)
Description
During testing dashdemux/adaptivedemux with live streams we noticed the
playback cease and wait for a long time before attempting to carry on.
This was caused by an unexpected 503 error from the DASH server, which
caused the adaptivedemux element to immediately wait for the next MPD
update. The MPD used had a 1 hour update period, meaning that the stream
could remain frozen for up to 1 hour after encountering an HTTP server
error. We believe that this a less than ideal situation for playback of
a live stream.
We propose that the error recovery logic in
gst_adaptive_demux_download_fragment and
gst_adaptive_demux_download_loop be changed. We believe, for a live
stream, a better error recovery scenario would be achieved by:
- retry the current media fragment first, up to the retry limit.
- once the retry limit is reached for the current media fragment it
should be abandoned and the stream resynchronised to the fragment that should
be at the current running time (i.e. bring back up to date with what
should be playing out had the stream continued and not encountered an
error). - if there is no new fragment to resynchronise to, only then wait for a
manifest update.
Step 2 could also just skip to the next fragment should one be available.
If this logic seems sound I'll try and produce a patch to implement it.
Can any of the maintainers foresee any problems with these proposed changes
to adaptivedemux?