Do not adjust initPTS without accurate playlist time offset

[robwalch]

This PR will...

• Do not adjust initPTS without accurate playlist time offset (when live playlist is out of sync).
• Do not re-emit AUDIO_TRACK_LOADED for track sync as it reruns playlist merge logic.
• Keep audio-stream-controller startPosition within playlist bounds.
• Fix audio-only main <-> track switching buffer flushing issues
• Do not treat live playlists as expired after three "misses" (static responses -> archived live / load segments anyway)

Why is this Pull Request needed?

Adjusting initPTS should only be performed for contiguous operations or on switch when expected timestamps differ enough from playlist times that the only way forward is to remap them (these are malformed HLS but we support them since #5235 and #5471).

In this case, when live playlist updates are unable to be delivered frequently enough to stay in sync, media timestamps are used to realign them, but this remapping of initPTS prevented that adding permanent misalignment.

Re-emitting AUDIO_TRACK_LOADED when cachedTrackLoadedData caused mergeDetails to be called on the audio playlist details a second time shifting it forward.

Are there any points in the code the reviewer needs to double check?

accurateTimeOffset is false because the playlist time should not be trusted for segments from live playlists which are being loaded out of sequence. In this state, initPTS should not be readjusted.

Resolves issues:

Resolves #6920

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

[kakao-wise-kim]

@robwalch
hi. robwalch
Testing with the this submitted PR code appears to have resolved the audio synchronization issue.
However, the audio segment download behavior seems suspicious.
As shown in the attached image, it first fetches an earlier audio segment.
For example, assuming the current segment index is 165666, it downloads audio index 165667 first, and then proceeds to download video and audio index 165666.

[kakao-wise-kim]

I attached Chrome Media Event and Message

[robwalch]

Testing with the this submitted PR code appears to have resolved the audio synchronization issue.

👍

However, the audio segment download behavior seems suspicious.

I attached Chrome Media Event and Message

This has nothing to do with Chrome's decoder. If playlists become desynced because of insufficient bandwidth, you can expect segments to be loaded out of sequence. Debug logs would include information about hls.js behavior in that case.

[robwalch]

However, the audio segment download behavior seems suspicious.

@kakao-wise-kim please give it another try with changes 5ca9822. The audio playlist was drifting ahead. Hopefully selection is less suspicious now. 🕺 💃

[kakao-wise-kim]

@robwalch
The issue of audio drifting forward slightly seems to have been alleviated, but it hasn’t completely disappeared.
Since the video also follows closely, it seems to be acceptable to a certain extent.

[kakao-wise-kim]

Occasionally, the audio is received, but instead of the video at the same timeline, an earlier video is received.
This sometimes results in playback with 2 to 3 previous audio-video segments.

[robwalch]

Occasionally, the audio is received, but instead of the video at the same timeline, an earlier video is received.

That is unrelated to these changes. Please file a new issue.

[kakao-wise-kim]

Occasionally, the audio is received, but instead of the video at the same timeline, an earlier video is received.

That is unrelated to these changes. Please file a new issue.

I think it’s problematic if the playback position moves forward and skips downloaded segments. However, since the current system waits for the download to complete before starting playback, it does not skip the switched segments. Therefore, I do not consider this issue a problem.

If the system is modified to download starting from the earliest available index, it would be an improvement in terms of optimization.