Audio tracks switching on Chromecast

[wipawan-zz]

I encountered an issue while casting Shaka Player Demo on the Chromecast. The active audio track is not immediately changed after it is selected. It is only changed after I pause the video for a few seconds. I played "Angel One (multicodec, multilingual)". The same behaviour happens in my implementation.

Here's my code:
this.mediaPlayer.selectTrack(selectedAudioTrack, true); this.mediaPlayer.getConfiguration().abr.enabled = true;

[joeyparrish]

@wipawan, please try to use the issue template we provide. There is much more information we need to investigate this:

• What version of Shaka Player are you using?
• Can you reproduce the issue with our latest release version?
• Can you reproduce the issue with the latest code from master?
• Can you reproduce the issue using our demo app?

[wipawan-zz]

@joeyparrish thanks for quick reply! please see my response below:

• What version of Shaka Player are you using?
  I'm using Shaka Player v2. I installed via npm and run in compiled mode.
• Can you reproduce the issue with our latest release version?
  Yes.
• Can you reproduce the issue with the latest code from master?
  Yes.
• Can you reproduce the issue using our demo app?
  Yes.

Audio tracks switching works perfectly with the player on Chrome browser. The issue seems to appear only when casting on Chromecast.

[joeyparrish]

I can reproduce using "Angel One" and the manual track controls in the "Info" panel of the demo app in uncompiled mode.

• Switching text tracks has an immediate effect.
• Switching audio tracks does have an effect, but it's not immediately obvious. If audio has been buffered until time 30, the audio change takes effect at time 30.
• Switching video tracks behaves the same as audio.

You can make the track switching behavior more obvious by reducing the buffering goals. Run this in the JS console just after clicking "Load":

shakaDemo.player_.configure({streaming: {bufferingGoal: 5, bufferBehind: 5}});

So probably the bug is in clearing the buffer.

[joeyparrish]

So far, this appears to be a Chromecast bug. Shaka Player is calling remove(0, 60) on the audio SourceBuffer, and video.buffered reflects the removal, but the old content still gets rendered and does not get replaced. The same thing happens with video if you manually switch video tracks.

I will reach out to the Chromecast team for further assistance.

[joeyparrish]

Quickest repro:

1. Open Shaka Player demo.
2. Click the cast button on the video controls.
3. Click "Load" to load the "Angel One" clip.
4. Expand the info panel.
5. When the captain starts talking, select a different audio language.

The effect should be immediate because we clear the buffer. We even stop to buffer the new audio, but it doesn't take effect until after the previous data is rendered. If you've buffered the whole 60-second clip, you'll never hear the new audio.

[joeyparrish]

We will need some kind of workaround for Chromecast since clearing the buffer does not flush the pipeline. Chromecast team recommends seeking to flush.

[joeyparrish]

A workaround has been committed, but will not show up in our receiver demo until we deploy a new release to appspot. v2.0.1 is coming soon, though.

[wipawan-zz]

thanks @joeyparrish!

sorry for the late reply. I managed to get to work by force seeking backward by one second (currentTime -= 1) . i'll keep a look out for the new version! 👍

[joeyparrish]

JFYI, this fix was released as part of v2.0.1.

[jyavenard]

This caused regression #569