Codec order preference for Video and Audio tracks

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

Is your feature request related to a problem? Please describe.

For dash manifests with multiple codecs for audio and video, Shaka player currently chooses the lowest bitrate bandwidth codec. I would like to have the ability to override that by sending an array of codecs to the shaka config.

Describe the solution you’d like I would like the ability to pass an array of codecs that I want Shaka player to consider as my preference when choosing a codec. videoCodecPreference: ['hevc', 'avc', etc] audioCodecPreference: ['ac-3', 'mp4a.40.2', etc]

Describe alternatives you’ve considered For audio codec, I considered the preferredAudioChannelCount shaka config but there are times where the manifest does not provide AudioChannelConfiguration channel count so that config property does not work.

For video, I have not able to find an out of the box support in the current Shaka player to let me choose what video codec to use.

Additional context This is to be used on the Chromecast receiver where I will first check the canDisplayType method in the CAF Receiver SDK and then populate the codec preference array that will be passed to the Shaka player to choose.

It allows Chromecast users the ability to have a higher bitrate codec viewing and audio experience.

[michellezhuogg]

Update: the code change is in review now and would be ready for testing soon 😃

[joeyparrish]

Today, you can force a particular resolution or bitrate through the tracks API (getVariantTracks(), selectVariantTrack()), but the list of tracks is fixed once we choose a codec.

We can definitely provide a way to specify a preference. Thank you both for explaining your use cases for me. This will definitely help.

This relates to our adoption of MediaCapabilities (#1391), which will open up additional ways for us to choose a codec (based on bandwidth, on smoothness, or on power efficiency). Having one more option to use an explicit preference list will be relatively simple to add at that stage.

This also relates to our adoption of codec switching (#1528), which will allow us to avoid choosing a specific codec if the platform will allow us to adapt between codecs.