Discontinuity strategy breaks seeking when using delta updates

[davidspura]

Description

My use case:
Im recording 10 second long videos with MediaRecorder which then get run through ffmpeg.wasm to create .m3u8, .mp4
and .m4s files. So every 10 seconds the player gets 10 seconds of new video. That is achieved with the hls delta updates.

Example of initial playlist:
#EXTM3U
#EXT-X-TARGETDURATION:2
#EXT-X-VERSION:9
#EXT-X-SERVER-CONTROL:CAN-SKIP-UNTIL=12.0
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PROGRAM-DATE-TIME:2023-07-11T05:25:39.306Z
#EXT-X-MAP:URI="i0.mp4"
#EXT-X-PROGRAM-DATE-TIME:2023-07-11T05:25:39.306Z
#EXT-X-DISCONTINUITY
#EXTINF:2.036101
s0.m4s
#EXTINF:1.992780
s1.m4s
#EXTINF:1.992780
s2.m4s
#EXTINF:1.992780
s3.m4s
#EXTINF:1.992780
s4.m4s
#EXT-X-PROGRAM-DATE-TIME:2023-07-11T05:25:49.310Z
#EXT-X-DISCONTINUITY
#EXTINF:2.036101
s5.m4s
#EXTINF:1.992780
s6.m4s
#EXTINF:1.992780
...

example of delta update (with gaps):
#EXTM3U
#EXT-X-TARGETDURATION:2
#EXT-X-VERSION:9
#EXT-X-SERVER-CONTROL:CAN-SKIP-UNTIL=12.0
#EXT-X-DISCONTINUITY-SEQUENCE:26890
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-SKIP:SKIPPED-SEGMENTS=14093
#EXT-X-PROGRAM-DATE-TIME:2023-07-11T13:09:55.554Z
#EXT-X-MAP:URI="g21.mp4"
#EXT-X-PROGRAM-DATE-TIME:2023-07-11T13:12:57.554Z
#EXT-X-DISCONTINUITY
#EXTINF:2.000000
g14093.m4s
#EXT-X-PROGRAM-DATE-TIME:2023-07-11T13:12:59.554Z
#EXT-X-DISCONTINUITY
#EXTINF:2.000000
g14094.m4s
...

The new segments get added to the stream with no problem but seeking the video AFTER an delta update eventually breaks the player. From what I found, when seeking, either the Segment or the Discontinuity strategy will be used.
If the Segment strategy is used, seeking never breaks and works mostly as expected, with the exception that every once in a while the seeking will be off by 10 seconds.
But when the Discontinuity strategy gets used, the player starts playing from the beginning of the stream and shows different time.
After that, since the time is completely out of sync with the segment that is actually playing, trying to seek a few more times eventually crashes the player.

Upon a bit of a research of the player I found that the player keeps discontinuityStarts which gets used in the Discontinuity strategy.
When new delta update comes, the player tries to merge the new playlist with the old playlist, but this merge completely ignores the old discontinuityStarts, they just get replaced by the ones from the new playlist.
(also indexing inside of discontinuityStarts array starts from 0 again, despite the delta update starting for example at segment 123.m4s)

When having a video that doesn't get updated (no delta updates) the Discontinuity strategy works fine, since I suppose the discontinuityStarts array never gets overwritten.

My temporary solution was to add a few lines of code to the 'selectSyncPoint_' method, where it now checks if the Segment strategy is available and if it is, it always uses it. Outside of the 10 second inconsistency mention earlier, it works fine and the player never breaks while seeking.

On unrelated note, you might notice that my discontinuity sequence in the delta update is very high. That is because Im increasing the sequence whenever Im writing a new discontinuity into a playlist. This is NOT how it should be done based on HLS specifications.
Based on the specifications, the discontinuity sequence should get updated only when an segment in a playlist gets deleted on the server.

But when doing that, the player breaks. From what I remember it was in the 'timestampOffsetForSegment' method, where current timeline and timeline of new segments get compared.
If the initial playlist had smaller number of segments then what gets send in the delta update (for example the initial playlist had 5 segments and the delta had 7) eventually these timelines would match (which returns null from the method) and since the discontinuity sequence didn't get updated, the timelines would continue to match and the player would never play the new segments from delta updates.

So at first glance it kinda feels like the player is not really ready for delta updates or Im doing something wrong. Can someone please help?

Reduced test case

https://github.com/davidspura/vite-video-test

Steps to reproduce

The test case is my repo where I encountered the issue. Im testing the whole process of creating and playing video there, to eventually merge this repo into separate project.

1. Press start. Recorder will start getting recorded and transcoded to hls files. After 20 seconds the player will start and should have 20 seconds of video.
2. After the video has some duration, try seeking the video, eventually the player will jump back to first segment but the seek bar of the player will either disappear or wont be in sync with what segment is actually playing.
3. Trying to seek after that will eventually crash the player

How does the project work:
Media recorder is creating 10 second long videos that then get run through ffmpeg.wasm to create hls files. These files are then saved to IndexedDB.
ServiceWorker is registered to listen for requests of the player. When the player makes a request to any file, the serviceWorker catches that request and sends a message to client.
The client retrieves requested file from IndexedDB and send the file back to the serviceWorker. The serviceWorker sends the file back to the player.

Errors

No response

What version of Video.js are you using?

8.3

Video.js plugins used.

http-streaming

What browser(s) including version(s) does this occur with?

Microsoft Edge Version 112.0.1722.54 (Official build) (arm64)

What OS(es) and version(s) does this occur with?

MacOS Ventura 13.0

[welcome]

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.