GNOME Bugzilla – Bug 759333
hlsdemux/others: Bad drift compensation for live streams
Last modified: 2018-11-03 13:44:13 UTC
Currently with live streams we will just fall behind more and more based on clock drift and also because of rebuffering due to BUFFERING messages. The only time when we resync (in hls to the 3rd newest fragment, no idea for the others) is when we fall off the Manifest completely. If the Manifest is huge (I have one here that has about 1 hour of fragments), we would get up to one hour behind. Instead we should probably start resyncing earlier. Like once we are 3 or 6 or $number fragments behind the one we would resync to, or 1 minute or whatever worth of fragments behind the fragment that we would resync to. It doesn't seem a good idea to have live streams go that far away from being live. I'll provide a patch for HLS later, but unfortunately the same work has to be redone for DASH and the others individually. DASH fortunately has an optional extension that allows to compensate for this based on the server clock, but if that is not available we should also do something like I proposed above.
OTOH we need to distinguish this case from the one where the user seeked inside the available range of a live stream. How?
(In reply to Sebastian Dröge (slomo) from comment #1) > OTOH we need to distinguish this case from the one where the user seeked > inside the available range of a live stream. How? We could have a 'target-offset' that would default to 0 which means as close to live as possible and it would be adjusted backwards if the user seeked to some other position. Perhaps, on some applications it seems possible that the user would prefer to watch it as continuously as possible. But this could be added if requested with a property, let's leave more complication to later.
And when seeking in a live stream, this target offset would be the offset between the newest fragment and the seek target? And whenever we get too far away from that we would resync accordingly? How would you define too far away? I gave some options above :)
(In reply to Sebastian Dröge (slomo) from comment #3) > And when seeking in a live stream, this target offset would be the offset > between the newest fragment and the seek target? And whenever we get too far > away from that we would resync accordingly? Yes, that's what I'd suggest. > > How would you define too far away? I gave some options above :) I don't know, do we want to do it in absolute value? Or relative to the server buffer size? I can't think of a sane default anyway. I'd start with something large as right now we only resync when falling out of range. We can make it shorter if needed later.
We already resync to 3 fragments below the top of the playlist when we fall off the playlist (for HLS).
Unfortunately I don't have a good idea of what would be a decent maximum allowed drift for resyncing. Perhaps the people working with DASH/HLS streaming clients would have a better view of the use cases.
-- 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/335.