Some HLS streams only start on second time

[Robloche]

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

If the problem is related to FairPlay, have you read the tutorial? Not FairPlay-related.

What version of Shaka Player are you using? I'm usind v4.11.17

Can you reproduce the issue with our latest release version? Yes.

Can you reproduce the issue with the latest code from main? I reproduced it on the nightly version.

Are you using the demo app or your own custom app? Both.

What browser and OS are you using? Chrome and Windows 11, both up-to-date.

What are the manifest and license server URIs? https://hls-od-gratuit-canalplus.akamaized.net/wholesale/clair/20241012/d8_1217108_2_D8/54345/d8_1217108_2_D8.m3u8 https://hls-od-gratuit-canalplus.akamaized.net/wholesale/clair/20241016/d8_1276089_3_D8/54464/d8_1276089_3_D8.m3u8 https://hls-od-gratuit-canalplus.akamaized.net/wholesale/clair/20241014/d8_1276089_1_D8/54379/d8_1276089_1_D8.m3u8 https://hls-od-gratuit-canalplus.akamaized.net/wholesale/clair/20241012/d8_1280697_1_D8/54340/d8_1280697_1_D8.m3u8 No DRM.

What did you do? My app plays HLS streams from different sources. But for 2 of these sources, here's what happens when I try to play a stream:

1. The URL loads.
2. The play() promise never ends (no resolve and no reject).
3. If I try again, this time, the play() succeeds and the stream plays as expected.

Here's the related code:

try {
  await shakaPlayer.load(url);
  await videoElement.play();
} catch (error) {
  console.log(`Error: ${error.message}`);
  throw error;
}

I tried it in different version on https://shaka-player-demo.appspot.com and here are the results:

✅v4.9.29 ❌v4.10.21 ❌v4.11.7 ❌nightly

✅ means that the stream plays the first time I press the PLAY button. ❌ means that the stream plays the second time I press the PLAY button.

So, it seems that something happened between v4.9 and v4.10.

[avelad]

@Robloche I can reproduce the error but rarely, when it fails, if I then call load again or reload the page, it works correctly, for it to fail again I have to restart the mac, it is very rare....

[Robloche]

My colleagues and I systematically experience it. First try: failure. Second try: success.

But even if it's rare for you, do you think it's a bug in Shaka's code or something on the streaming server?

[avelad]

I don't know, these streams use TS, could you change to using MP4 and see if the same thing happens? With this we could rule out a bug in Shaka's transmuxer.

[Robloche]

I'm sorry but I can't change the streams to mp4 because they're hosted by a third-party provider.

But I edit my first post and put 4 new streams (the first ones having expired since I posted). Alors, could you try on a PC in private navigation?

I just try these 4 new streams on https://shaka-player-demo.appspot.com/ and the issue was there every time.

Thanks for your time.

[joeyparrish]

The good news is that v4.9.x is our current LTS branch. We will continue cherry-picking fixes there, so you can rely on that branch for the time being.

We will see if we can reproduce this consistently enough to bisect between v4.9 and v4.10 to find the root cause.

[Robloche]

Thanks a lot.

[avelad]

@Robloche Can you confirm that you see the same issue as in the video?

https://github.com/user-attachments/assets/6e38ac49-3a2d-4550-af45-777fd86dbabb

[Robloche]

Yes. This exact same one. I'm glad you were able to reproduce it.

[avelad]

I have looked deeper, it is a problem with the TS segment, specifically with the MP4 that we generate from Audio.

It seems that in HLS.js it doesn't fail because they remove the first two audio samples from the first segment, why? (https://github.com/video-dev/hls.js/blob/master/src/remux/mp4-remuxer.ts#L866) I don't know yet... @robwalch

Stream used to test it: https://hls-od-gratuit-canalplus.akamaized.net/wholesale/clair/20241012/d8_1217108_2_D8/54345/d8_1217108_2_D8.m3u8

[avelad]

@Robloche , if you can find the exact commit where it stops working that would be a great help!

[Robloche]

I'm gonna give it a try.

[Robloche]

OK, I don't have enough time to pinpoint the exact commit where it broke but I found the version.

Here are the results of my tests: ✅ ... ✅ v4.9.9-main ✅ v4.10.0 ✅ v4.10.1 ✅ v4.10.2 ❌ v4.10.3 ❌ v4.10.4 ❌ v4.10.5 ❌ ...

[Robloche]

This lead me to these potential culprits:

$ git log --pretty=oneline v4.10.2...v4.10.3
30ce8b64dcd462ce19d4e57625db6c1e94bdbf06 (HEAD, tag: v4.10.3) chore(v4.10.x): release 4.10.3 (#7001)
3cc460f3df57ceee10d172bfe96cfb49e32e65ac docs: Add documentation about screen resolution detection (#6997)
5ce03542efd2fddaef4c1e12957567fff86dbab6 fix(HLS): Fix parsing of width and height when using media playlist (#6989)
8791368541cdb48b49913822473ab220d45d0acb fix(HLS): A/V sync regression for HLS live (#6987)
3e20d5e6c8ec2113c01cab828a43dbe70affa9b2 fix: Offset text regions that are out of viewport (#6986)
5ea77b1a5147205f4282498af59d01b870e0d04c fix(Xbox): Fix screen resolution detection (#6988)
0dd6435c971583f04970ab8299d4e18bde939a93 fix(UI): Show the ad marker in the seek bar when there are some intersections (#6990)
4b4571228a99a1113f4a6c48944e3e714ccf4569 chore: Move CueRegion to its own file (#6993)

Reading the commit messages, I'd go for this one: 8791368541cdb48b49913822473ab220d45d0acb fix(HLS): A/V sync regression for HLS live (#6987)

Can I let you finish the investigation, please?

[avelad]

Yes! it's true, the PR that introduces the bug is https://github.com/shaka-project/shaka-player/pull/6987

I won't be able to work on this until next week... Sorry!

[avelad]

It seems that const compensation = await this.audioCompensation_; never gets resolved with your stream

[Robloche]

Yes! it's true, the PR that introduces the bug is #6987

I won't be able to work on this until next week... Sorry!

Don't be sorry, you're working freely for the community. That's a huge thing and your work is greatly appreciated.

[Robloche]

It seems that const compensation = await this.audioCompensation_; never gets resolved with your stream

But what changes between the first try (not resolved) versus the following tries (resolved)?

[avelad]

It seems that const compensation = await this.audioCompensation_; never gets resolved with your stream

But what changes between the first try (not resolved) versus the following tries (resolved)?

I don't know yet, I posted it here because I saw it but I can't look any further until next week. Sorry!

[Robloche]

Got it. It's a note for yourself.