[Bug 760930] adaptivedemux: stream can pause for a long time when server errors encountered

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=760930

--- Comment #15 from David Waring <david.waring at rd.bbc.co.uk> ---
Yes, I'd thought of that, but quickly realised skipping forward one segment at
a time wouldn't work.

I then tried to figure out how far the viewer was from live and use that as an
offset to recalculate, but I couldn't figure out how to find out how far behind
live the viewer is at (due to pause/skip). That figure doesn't seem to be
easily available and there doesn't seem to be any way to derive it from
absolute time, running time, stream time and/or segment information (my first
patch had incorrectly tried to use the segment base as this offset, due to me
misreading the GstSegment documentation).

The problem with just trying to skip forward one segment at a time is that, due
to the retry logic, each fragment will take a fragment duration plus a little
extra to retry. So simply skipping to next fragment will never catch up the
stream. It needs to be a jump forward, sometimes 2 or 3 fragments to get back
to the streaming point. As pointed out above, calculating that skip doesn't
seem to be an easy task.

I'm open to suggestions to improve this, but I was spending way too much time
trying all sorts of combinations of clocks, bases and offsets. I had to make a
decision to just drop that behaviour and just assume that most viewers would be
watching a live stream at the live point. For those not viewing live, there
would be a disruption to playback anyway, during retry of the current fragment,
followed by a jump back to live. I realise this is not ideal, but I also
believe that it is better than the current master branch behaviour which can
freeze playback for long periods of time waiting for a manifest update.

After posting this latest patch I did have a thought to try remembering the
difference between current playback stream time and live stream time upon seek
event or transition to PLAYING, and use that as an offset. But I'm not sure how
well this would work and I haven't had chance to try it yet.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.