LL-HLS: Preload hinted fragments is played twice sometimes

[duggaraju]

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

What version of Shaka Player are you using?
4.0.0

Can you reproduce the issue with our latest release version?
yes

Can you reproduce the issue with the latest code from main?
yes

Are you using the demo app or your own custom app?
both

If custom app, can you reproduce the issue using our demo app?
yes

What browser and OS are you using?
Chrome/Edge windwos

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?

What configuration are you using? What is the output of player.getConfiguration()?

What did you do?

Just play a live LL-HLS URL which has preload hint for the latest part.

What did you expect to happen?
Playback works fine.

What actually happened?

You will occasionally see audio/video repeat and if you see the network trace, the same part is downloaded twice.

Since the preload hinted part has no duration (start/end time are the same) and then when it becomes a regular part sometimes instea of merging the part looks like we are adding twice and downloading twice.

[duggaraju]

Sample live URL https://lldemo-usw22.streaming.media.azure.net/7c7bbf89-6a16-4b49-90d3-8bf15477b04f/93634f61-62c8-4f58-a500-ee2c9a6f40f4.ism/manifest(format=m3u8-cmaf).m3u8 but this may go down any time.

[joeyparrish]

Do you get the same behavior for v3.3? Or was this introduced in v4.0?

[avelad]

I can reproduce it in 4.0.0 with https://shaka-player-demo.appspot.com/demo/#audiolang=es-ES;textlang=es-ES;lowLatencyMode=true;uilang=es-ES;asset=https://lldemo-usw22.streaming.media.azure.net/7c7bbf89-6a16-4b49-90d3-8bf15477b04f/93634f61-62c8-4f58-a500-ee2c9a6f40f4.ism/manifest(format=m3u8-cmaf).m3u8;panel=CUSTOM%20CONTENT;build=uncompiled

[duggaraju]

Yes it repros with Shaka 3.3.0 as well. You can clearly see the same video fragment being downloaded twice in the developer tools. I can see it more often with audio parts (but I guess it is more of a timing issue and could happen with video too. But audio being smaller and quicker to download more easier to hit).

[joeyparrish]

Thank you for confirming!

[joeyparrish]

From what I see, the merge logic is actually sound. The problem appears to be in how streaming and buffering operates on these segments. I expect it is caused by the reference having a 0-duration, but I need to spend a little more time debugging to be certain.

[joeyparrish]

I can't get this to play with v3.3 at all. It seems that when we try to fetch the first segment to extract a timestamp, by the time we make the request, it has fallen out of the window and we get a 404. This doesn't happen in v4, since we don't extract timestamps any more.

I believe what is happening is that we would fetch the same partial segment twice, because StreamingEngine would try to look up the next segment to fetch based on the end time of the previous one. Since the last thing we fetched had an apparent duration of zero (according to SegmentReference), we would re-request the duration-having version of the same partial segment reference next.

I expect that if I could get v3.3 to play this at all, it would make duplicate requests, but otherwise play correctly.

In v4, I'm seeing an additional problem caused by this re-request, combined with sequence mode. The re-requested segment gets appended in sequence mode, and some content repeats. If a timing issue causes this to happen asymmetrically between audio and video, you then also get A/V desync.

I'm going to up the priority to P0, because at least for v4, this is quite bad.

[joeyparrish]

I am convinced that the zero-duration partial ref is to blame. On v3, this would result requesting the segment twice, but no other negative consequences, as it would overwrite the buffered frames of the first version. On v4, it also results in stuttering playback and possible A/V desync.

The way StreamingEngine processes a zero-duration reference is at the root of requesting the segment twice. Handling these refs specially in StreamingEngine would solve the issue for both branches, but it's a bit complicated. I have a working version of this here: joeyparrish@adf3b77

After working on that solution, I discovered that there is an attribute in LL-HLS which we are parsing, but not using to compute the hinted segment's duration: PART-TARGET. By using that, we have a simple solution that only touches the HLS parser, and all segment references will always have a duration. And it's a required attribute according to the spec. Here is what that fix looks like: joeyparrish@00a7ac8

I'm going to move forward with a PR for the PART-TARGET solution, but I would love to have feedback on this from @duggaraju and their colleagues before it is released.