Fix gaps introduced in video buffer by remuxer work-around

[robwalch]

This PR will...

• Fix estimated DTS timeoffset between segments
• Prevent gaps caused by writing over the previous frame assumed to be a hole

Why is this Pull Request needed?

• Prevent gaps caused by writing over the previous frame assumed to be a hole

Fix gaps in buffer for streams with variable framerate or other PTS/DTS inconsistencies that caused the "Video: PTS/DTS adjusted" workaround to kick in when it should not.

hls.js was shifting the start of the first frame of some segments back about a frame's duration, which cleared the previous frame from the buffer causing buffer gaps. I don't see how we could accurately estimate the last AVC frame duration (lastFrameDuration or mp4SampleDuration) to get the estimated nextAvcDts to be spot on - not sure it can always be. So to prevent these overwrites, ignore assumed AVC DTS "holes" that are smaller than the average frame duration.

https://github.com/video-dev/hls.js/pull/2894/files#diff-14a34ee6c08b15d0e309d10c2c05f3d0R264-R273

• Fix estimated DTS timeoffset between segments

We were using the PTS diff between initial audio and video samples to calculate timeOffset for each segment. This should done using DTS (as outlined in the comments and based on how timeOffset is used in remuxVideo) but was changed to PTS to align the start of buffered media to 0.

With these changes, we'll only use PTS at the very start of a VOD, when the initial time offset is 0, and DTS for the rest. This will prevent false positives when detecting gaps or overlap in AVC DTS in remuxVideo.

https://github.com/video-dev/hls.js/pull/2894/files#diff-14a34ee6c08b15d0e309d10c2c05f3d0R52-R60

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md