Fix Safari backwards seek bug

[robertbryer]

There's a bug in Safari on macOS, where appending a segment to the start of a buffered range causes a portion of the original start of the buffer to be removed.

To reproduce this bug:
Seek to a point in the video, buffer for a few seconds.
Seek back 15-20 seconds, play the video forward to the first seek point.
The video stops for lack of buffer at the point first downloaded segment. Dash.js believes it has already downloaded this segment, so will fetch later ones instead.

This fixes it by watching the onSeeked event, and then removing any buffered ranges ahead of the currentTime(for macOS user agents only). There's no point just re-fetching and replacing the missing segment because the problem occurs again filling in that gap.

[epiclabsDASH]

Hi @robertbryer. Thanks for the contribution, I could reproduce the issue very easily following your instructions.

Fix looks fine to me but I need to spend more time with it to ensure there is no regression.

Thanks!

[nicosang]

Hi,

in my opinion, this PR is a workaround. The main question is why dash.js doesn't download the missing segment(s). Delete already downloaded segments in order to download them again is not optimal. I agree we can merge this PR to solve the problem temporarily in Safari, but keep in mind, we have to really solve it for good.

Nico

[robertbryer]

There is no choice in this case except to clear all the segments ahead because appending to fill a gap at index n makes a new gap at index n+1, and so on for the entire buffer ahead.

But yes, I did look at using .buffered to see if a fragment had been downloaded, instead of using the fragmentModel class. - the issue in this case is that Safari can leave gaps in the buffer that are smaller than the tolerance that we use to grab chunks:

dash.js/src/dash/DashHandler.js

Line 311 in 2451c6b

epsilon = (timeThreshold === undefined || timeThreshold === null) ? fd / 2 : timeThreshold;

If verifying against .buffered is wanted, I did prototype it in this commit:
bbc@d441341
But since it doesn't fix the Safari bug, and I don't know of any user agents that are clearing the buffer silently, I didn't carry on with it.

[epiclabsDASH]

@robertbryer, do you have a reference to this issue in https://bugs.webkit.org?

[robertbryer]

https://bugs.webkit.org/show_bug.cgi?id=177483

[epiclabsDASH]

Thanks!