Multiple audio languages with encryption

[ruiposse]

Hi, in my tests I've been trying to get Shaka Player to work with multiple encrypted audio.

In eme_manager.js, chooseEncrypted_ has the following code starting on line 345:

for (var j = 0; j < configs.length; ++j) {
      var cfg = configs[j];
      if (cfg.drmScheme.keySystem == keySystem &&
          cfg.fullMimeType == caps.contentType) {
        chosenCfgs.push(cfg);

        // Accumulate the DRM scheme info from all chosen StreamConfigs.
        if (!this.drmScheme_) {
          this.drmScheme_ = cfg.drmScheme;
        } else {
          var newScheme = /** @type {!shaka.player.DrmSchemeInfo} */(
              cfg.drmScheme);
          shaka.player.DrmSchemeInfo.combine(this.drmScheme_, newScheme);
        }
        break;
      }
    }

Not sure if this is a bug, but what seems to happen is that whenever there's more than one audio in the manifest, Shaka Player loops through them until it finds the first one that matches the supported drmScheme even thought it knows that there's more audio tracks that could be tested.

I've found that removing the break; fixes this issue.
Not sure if that's the proper solution, but I figure this could be a start :)

[sanbornhilland]

+1

I have the same issue and this fixes the problem.

EDIT: It only partially fixes the problem. EX: If you have a manifest that has an english audio track and a french audio track but both of them are protected with Widevine and Playready then by only removing the break statement it ends up listing 4 audio tracks when in fact there are only 2 audio tracks available with the supported encryption.

[joeyparrish]

Thanks for the report. Can either of you supply test content I could use to reproduce and debug the problem? If it's something you can't post in public, an email would be fine.

[ruiposse]

Unfortunately I cannot. All content is behind an authentication system.
Sorry about that. I know it's not very useful, but I'm pretty sure it happens with any manifest with more than one audio.

[sanbornhilland]

I've emailed @joeyparrish with some test content that should reproduce the issue.

[joeyparrish]

I can now reproduce the issue. I'll see what I can do to fix it. Thanks!

[joeyparrish]

@sanbornhnewyyz, I can't reproduce the behavior in your earlier comment, where removing the break statement results in too many tracks.

In the test content you gave me, there are two audio languages, one audio bitrate per language, and three ContentProtections elements. I added a check for PlayReady to app.interpretContentProtection_ in case it was important to have multiple DrmSchemeInfos as well. With this setup, if I remove the break in chooseEncrypted_, I get exactly two audio tracks.

If I edit the manifest and add an additional audio Representation to each AdaptationSet (low bandwidth such that they are not selected by default), I now see four audio tracks as I would expect. I can't seem to get them to duplicate per-ContentProtection or per-DrmSchemeInfo. So for the moment, it seems as if removing the break statement is, in fact, the correct fix.

Is there something I'm missing to reproduce the "too many tracks" problem you described?

[sanbornhilland]

No, as far as I know I just removed that break statement.

[joeyparrish]

Did some archaeology: It seems this bug has always been there, ever since we started using requestMediaKeySystemAccess back in February (a253872).

Removing the break statement seems to me to be the correct fix. You should be able to choose all matches for key system & codec. The content from Sanborn that I've tested seems to be fixed by this.

Are there any objections to this fix? Or counter-examples where it does not work as it should?

[sanbornhilland]

I have no objections.

[sanbornhilland]

I hate to do this but I actually still am having a problem with 1.4.0. When I call player.getAudioTracks() it returns 8 tracks instead of 2. But there are actually only 2 different tracks in the array and each of them is repeated 4 times. Am I failing to specify somewhere that I only want tracks with widevine protection?

[joeyparrish]

No worries! We want to get this solved for you. Does this happen with the last sample you sent me, or will I need a new sample to reproduce?

[sanbornhilland]

It should work with the last sample I sent you but I was going to verify it. I'm having trouble playing the content in the sample app. Can you still play the content that I sent?

[joeyparrish]

Yes, I can play it in the test app. I just paste the URLs you gave me into the test app's manifest and license server fields.

[sanbornhilland]

Okay after some further examination it turns out the problem was caused by our incorrect contentProtection callback (thanks for the tipoff). We were ignoring schemeIdUri and just returning a DrmSchemeInfo instance every time and this caused it to think there were more tracks than there really were. After this change, the fix you put into 1.4.0 works perfectly.

Thanks for the help.

[joeyparrish]

No problem. I'll try to replicate that and see if this is something we should account for somehow when processing the callback's results.

[joeyparrish]

Looks like something we can/should take care of in EmeManager. I've got a fix in review internally that seems to handle duplicate DrmSchemeInfos more gracefully. Thanks for helping me repro it.

[sanbornhilland]

Great, thanks for the fix.