GNOME Bugzilla – Bug 783075
adaptivedemux: Check live seeking range more often
Last modified: 2017-07-13 12:46:29 UTC
See patch
Created attachment 352556 [details] [review] adaptivedemux: Check live seeking range more often The live seeking range was only checked when doing actual seeks. This was assuming that the rate would always be 1.0 (i.e. the playback would advance in realtime, and therefore fragments would always be available since the seeking window moves at the same rate). With non-1.0 rates, this no longer becomes valid, and therefore we need to check whether we are still within the live seeking range when advancing.
Review of attachment 352556 [details] [review]: ::: gst-libs/gst/adaptivedemux/gstadaptivedemux.c @@ +4145,3 @@ + if (demux->segment.rate != 1.0 && gst_adaptive_demux_is_live (demux)) { + if (!gst_adaptive_demux_stream_in_live_seek_range (demux, stream)) + ret = GST_FLOW_EOS; Instead of EOS, maybe waiting until the segment becomes available is a better behaviour?
Review of attachment 352556 [details] [review]: ::: gst-libs/gst/adaptivedemux/gstadaptivedemux.c @@ +4145,3 @@ + if (demux->segment.rate != 1.0 && gst_adaptive_demux_is_live (demux)) { + if (!gst_adaptive_demux_stream_in_live_seek_range (demux, stream)) + ret = GST_FLOW_EOS; How so ? * If you're doing negative rates it's not going to help (you're already outside of the seek range and it's not going to ever go backwards). * If you're doing positive rates ... you're not playing at the same speed at which the "live" position (and therefore seekable range) moves anyway. Would you want it to constantly buffer/pause ?
That's what I would expect yes. It's also not ideal though, so I guess it doesn't really matter in the end :)
commit f4190a49c04f1d5d174cebba0bc9a03a7ec721c2 Author: Edward Hervey <edward@centricular.com> Date: Thu May 25 09:48:53 2017 +0200 adaptivedemux: Check live seeking range more often The live seeking range was only checked when doing actual seeks. This was assuming that the rate would always be 1.0 (i.e. the playback would advance in realtime, and therefore fragments would always be available since the seeking window moves at the same rate). With non-1.0 rates, this no longer becomes valid, and therefore we need to check whether we are still within the live seeking range when advancing. https://bugzilla.gnome.org/show_bug.cgi?id=783075
This introduces a regression as shown in https://bugzilla.gnome.org/show_bug.cgi?id=784510
I did a wrong assumption with this. I assumed that seek_range for a live stream would be a continuously moving window, which is not always the case (for DASH it is, for HLS it's not).
Created attachment 355502 [details] [review] adaptivedemux: Workaround for live seek ranges when advancing This is a workaround for a regression introduced by f4190a49c04f1d5d174cebba0bc9a03a7ec721c2 ( adaptivedemux: Check live seeking range more often ) The goal of the previous commit was to be able to cope with non-1.0 rates on live streams which have a "seeking window" (i.e. the server keeps around quite a bit of the live stream so you can seek back into it). Without that commit, two different kind of issues would happen: * When doing reverse playback, you would never check whether you are outside of the seekable region. And would then continuously try to download fragments that are no longer present. * When doing fast forward, you would end up requesting fragments which are not present yet. In order to determine whether one was *really* outside of the seekable window, we check whether the current stream position is still within the seekable region. The *problem* though with that commit is that it assumes that subclasses will return continuously updated seeking ranges (i.e. dependent on the current time), which is *NOT* the case. For example: * dashdemux does use the current UTC to determine the seekable region * hlsdemux uses the values from the last updated manifest Therefore if one downloads fragments faster than realtime, for HLS we would end up at the end of the last manifest seekable range, and the previous commit would consider the stream as being ended... which is not the case. In the long run, we need to figure out a way to cope with non-1.0 rates on live streams for all types of stream (including HLS).
Pushed to both master and 1.12 commit 50f92fab89893246f309680bdbdc336cbce38100 Author: Edward Hervey <edward@centricular.com> Date: Thu Jul 13 12:57:12 2017 +0200 adaptivedemux: Workaround for live seek ranges when advancing This is a workaround for a regression introduced by f4190a49c04f1d5d174cebba0bc9a03a7ec721c2 ( adaptivedemux: Check live seeking range more often ) The goal of the previous commit was to be able to cope with non-1.0 rates on live streams which have a "seeking window" (i.e. the server keeps around quite a bit of the live stream so you can seek back into it). Without that commit, two different kind of issues would happen: * When doing reverse playback, you would never check whether you are outside of the seekable region. And would then continuously try to download fragments that are no longer present. * When doing fast forward, you would end up requesting fragments which are not present yet. In order to determine whether one was *really* outside of the seekable window, we check whether the current stream position is still within the seekable region. The *problem* though with that commit is that it assumes that subclasses will return continuously updated seeking ranges (i.e. dependent on the current time), which is *NOT* the case. For example: * dashdemux does use the current UTC to determine the seekable region * hlsdemux uses the values from the last updated manifest Therefore if one downloads fragments faster than realtime, for HLS we would end up at the end of the last manifest seekable range, and the previous commit would consider the stream as being ended... which is not the case. In the long run, we need to figure out a way to cope with non-1.0 rates on live streams for all types of stream (including HLS). https://bugzilla.gnome.org/show_bug.cgi?id=783075