DASH playback occasionally stucks when switching bitrate using "Video+audio track combinations" for manifest with multiple periods

[chanyk-joseph]

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

What version of Shaka Player are you using?:
Shaka Player v2.4.3-uncompiled

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

Can you reproduce the issue with the latest code from master?:
Yes

Are you using the demo app or your own custom app?:
Demo app

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

What browser and OS are you using?:
Chrome/Windows

What are the manifest and license server URIs?:
https://www.haudosi.com/dash_freq_scte35/manifest.mpd
OR
https://www.haudosi.com/dash_freq_scte35/DASH_freq_scte35.zip

What did you do?

1. Start playback the DASH manifest
2. Wait 10 seconds
3. Switch to another bitrate by selecting the of "Video+audio track combinations"
4. Repeat step 1 until all combinations have been iterated

What did you expect to happen?
I expect the playback could be switched smoothly without getting stuck and browser error

What actually happened?
The playback occasionally stucks with browser error like: "http://127.0.0.1:8005/demo/log_section.js 72:15 "Unable to locate track with id "11225".""

After some investigation, it is found that the track id keeps changing in the options list of "Video+audio track combinations" (due to multiple periods), eg:

Since this DASH manifest has lots of small periods, the track id of each combinations change frequently.
Due to the delay of UI, the track id in the corresponding option value are not updated.
When user click on the option of a combination, the option value reflects the track id of an old period.
However, the internal track id of that combination has already been updated.
Thus, error "Unable to locate track with id "xxx"." is thrown to the browser log, and playback got stuck

[ismena]

Hi, I'm having trouble getting the content (the player seems to thing the segments are not there). Was it a live stream, by any chance? Could you confirm it's still available?

Thanks!

[chanyk-joseph]

Hi @ismena , I have updated the manifest to static VOD format. Please try again:
https://www.haudosi.com/dash_freq_scte35/manifest.mpd

BTW, we need to enable cross-origin using chrome browser plugin in order to playback the manifest on
https://shaka-player-demo.appspot.com/demo/

Sorry for any inconveniences caused!

[joeyparrish]

I can't reproduce, but my guess is that this has to do with the way periods interact with our Tracks API.

There are two periods which are important in today's Shaka Player: the "current" period (where the playhead is) and the "active" period (where streaming/buffering is happening). These can differ if the buffered region spans one or more period boundaries.

Each period has its own tracks, and the Tracks API shows tracks from the current period. That is also what is shown in the UI. When you manually change tracks in the UI, we take the Track ID and look up the corresponding Streams in the manifest.

Your live stream would naturally drop periods that are outside the availability window. So as the stream progresses, older periods go away and newer ones are introduced. If the track you select has since been dropped, this would cause the "Unable to locate track" error you described. (Since you converted to static VOD, I can't reproduce this, since all periods are available and none are ever removed.)

This is essentially a race, which is made worse by the very short periods in your content.

I don't have any easy solutions, unfortunately. One plan I would like to execute is to "flatten" periods in the DASH parser and remove the concept of periods from the rest of the code. This would change the Tracks API so that the list of tracks wouldn't completely change across periods. If your <Period> elements had similar <Representation> elements, you would not see changes in the tracks list during playback. The race that is causing this issue for you would go away. This idea is being discussed in #1339.

In the mean time, you could work around this issue by using longer periods. This would make it less likely that you would run into this issue by reducing the time periods in which it could occur. It may also improve the quality of your stream, since each of your period transitions seems to contain a tiny gap.

You should also make sure you are listening to the trackschanged event from the player and be sure to update any track-selection UI promptly when this happens. A delay in processing this event would increase the odds of triggering this bug.

Does this help?

[chanyk-joseph]

@joeyparrish Thanks for the investigation and your detailed explanations!
I will try to apply workaround util #1339 is resolved.

[joeyparrish]

Okay. May I go ahead and close this issue?

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, you can ask us to reopen or have the bot reopen it by including @shaka-bot reopen in a comment.