Incorrect behavior on large HLS clips

[alexch1311]

Have you read the FAQ and checked for duplicate open issues?
Yes.

What link can we use to reproduce this?
https://shaka-player-demo.appspot.com/demo/#audiolang=ru-RU;textlang=ru-RU;uilang=ru-RU;asset=https://smart-air.tv/media/bruce_ffmpeg/master.m3u8;panel=CUSTOM%20CONTENT;build=uncompiled

What version of Shaka Player are you using?
v3.2.0-uncompiled

What browser and OS are you using?
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

What did you do?
We use Shaka Player for large HLS clips (duration up to 24 hours). It seems that it has some problem dealing with such long clips.
Steps to reproduce are simple:

1. Load clip into the player.
2. Then make some random navigation over the timeline.

What did you expect to happen?
Normal clip seeking and playback at any position on the timeline.

What actually happened?

When navigating over the timeline, Shaka player suddenly stops responding to commands. When it happens, it may even report the incorrect clip duration (see the screenshot, original clip duration is 23:59:56).
In the development console you can see that it tries to load all the segments successively.

P.S. We have tried the same clip with other players (Flowplayer, Akamai, etc.) - it works normally.

[avelad]

@alexch1311 I have tried with 3.2.1 and it no longer happens, can you validate it again?

[alexch1311]

@alexch1311 I have tried with 3.2.1 and it no longer happens, can you validate it again?

Hello. I've checked it on the Shaka Player test page, and the issue still exists.

Url for checking: https://shaka-player-demo.appspot.com/demo/#audiolang=ru-RU;textlang=ru-RU;uilang=ru-RU;asset=https://smart-air.tv/media/bruce_ffmpeg/master.m3u8;panel=CUSTOM%20CONTENT;build=uncompiled

[avelad]

[alexch1311]

It does not happen at once. You should do some random navigation over the timeline, and eventually you will get the error.

[Lubjan]

I've got the same problem, using version 3.2.1, but also tested it with the 3.4.0 branch thinking that maybe #3299 could've fixed it but id didn't.
The problem occurred using the following HLS Playlist, when directly skipping close to the end after the video has started playing. (https://01.cdn.vod.farm/playlist/e7db2f50786dd602eeb08729b885d5d4.m3u8)

The same behavior described by @alexch1311 was observed, with the addition that when the last segment of the playlist loaded, the video source and duration changes to only that last segment.
This behavior does not seem to be triggered when skipping to a time before ~13h30m.

edit it also doesn't seem to happen, if the currentTime is further into the video, so maybe a distance thing?

Hope this helps and can be fixed soon ^^

[Lubjan]

Bug is still present with the latest release 3.3.3 (locally and in the uncompiled demo), can be reproduced in the same way.

[Lubjan]

Bug is still present with the latest release 3.3.3 (locally and in the uncompiled demo), can be reproduced in the same way.

Same for newest 4.0.0 release.

[Lubjan]

Any info on when this could possibly be fixed? I haven't found a workaround to skip to later times yet.

[Lubjan]

@avelad If I'm not mistaken and your PR only fixes something in the shaka UI, it probably likely won't fix this issue, as it also appears when using a custom UI or the browser native video controls.

[Lubjan]

Just to clarify, this issue has two different effects:

1. When skipping over a certain timestamp (from the start, or with a given buffer distance), shaka-player will load all remaining HLS segments and not only the configured amount (e.g. 8). While it's loading the remaining segments, the video element becomes unresponsive.
2. Once the final segment is finished loading, the duration of the video is set to the duration of this segment and only the last segment can be played.

edit I tried implementing the change in our company project, nothing changed, I don't think #4734 fixes any of the problems from this issue.

[Lubjan]

I'm gonna add a video showing the problem 1 (quota exception was thrown before it could show the problem 2, see picture below): https://youtu.be/oqyxkOZcYE4

[avelad]

Can you test with v4.3.4? Thanks!

[Lubjan]

@avelad the issue still persists, tested it in the appspot demo and locally. It still loads all remaining segments at a certain point.

1. When skipping over a certain timestamp (from the start, or with a given buffer distance), shaka-player will load all remaining HLS segments and not only the configured amount (e.g. 8). While it's loading the remaining segments, the video element becomes unresponsive. (Not Fixed)
2. Once the final segment is finished loading, the duration of the video is set to the duration of this segment and only the last segment can be played. (Fixed, with 4.3.2 it was I think)

[Lubjan]

Also still present in 4.3.5.

[avelad]

We've recently fixed a lot of issues with HLS, can you check again against the main branch? Thanks!

[Lubjan]

@avelad Issue still persists, tested it both in the appspot example and in our own integration, no changes.

[avelad]

I tested it again the nightly demo and it works well. https://nightly-dot-shaka-player-demo.appspot.com/demo/#audiolang=es-ES;textlang=es-ES;uilang=es-ES;asset=https://01.cdn.vod.farm/playlist/e7db2f50786dd602eeb08729b885d5d4.m3u8;panel=CUSTOM%20CONTENT;build=uncompiled
Can you try again the nightly demo?

[Lubjan]

I tested it again the nightly demo and it works well. https://nightly-dot-shaka-player-demo.appspot.com/demo/#audiolang=es-ES;textlang=es-ES;uilang=es-ES;asset=https://01.cdn.vod.farm/playlist/e7db2f50786dd602eeb08729b885d5d4.m3u8;panel=CUSTOM%20CONTENT;build=uncompiled Can you try again the nightly demo?

Cannot confirm, tested it via the link, still the same behavior.
Would you like a video showing how I replicate it?

[avelad]

I recorded a small video:

Grabacion.de.pantalla.2023-08-23.a.las.16.05.30.mp4

[Lubjan]

@avelad

Okay, your method of testing works for me as well (I don't think it was every a problem that way), my method skips directly to the end, see comparison video below.

example_4_1.mp4

[avelad]

@Lubjan now I can reproduce the issue. Thanks!

[avelad]

I have been investigating the problem and the error is due to an internal error in the mux.js library when generating the segments that are at the end, but it does not always happen...

[Lubjan]

I have been investigating the problem and the error is due to an internal error in the mux.js library when generating the segments that are at the end, but it does not always happen...

So, what's next? Should I create an Issue over in the mux.js repo (I don't have the slightest clou about the underlying problem, or what to report exactly specifically) or is this still on your todo, but something for a later date?

[joeyparrish]

Am I correct that this is a muxed (audio+video) stream?

We are building our own transmuxer implementations (being released today in v4.4), but they don't yet support muxed streams. For now, we still need mux.js for that case. In v4.5, we anticipate being able to remove all dependence on mux.js.

So @Lubjan, you could create an issue on mux.js, or work with @avelad to do that, or you could contribute to muxed stream support in our native transmuxer, or you could wait for @avelad to finish that work in the next few months. (I think those are the major options. 😄) @avelad knows better than me, though.

[Lubjan]

@joeyparrish It is a muxed stream, as far as I know.

Sadly, my knowledge on that topic is rather limited, so I don't think I could helpfully contribute to the new transmuxer.
I'll most likely wait for V4.5, but wouldn't mind opening an issue over at mux.js with some info from @avelad on the underlaying error (that is if he isn't set on opening one himself).

[avelad]

I have started working on muxed content transmuxer, but there is still a lot of work, you can see the progress at #5571

[avelad]

I tested the stream with the changes of #5571 and the stream works fine :)

[avelad]

I tested in the main branch and now it works fine. The changed will be included in 4.5. Thanks!