AC-3 audio configuration for requestMediaKeySystemAccess() is not supported on Tizen, but it is playing

[aluklon]

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

What version of Shaka Player are you using?
2.5.17, 3.0.5

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?
Custom app

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

What browser and OS are you using?
Tizen

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

What are the manifest and license server URIs?
https://support.smartlabs.tv/udrm/wvfta/license
https://support.smartlabs.tv/DTE_DASH_AUTO/TESTCONTENT/TOS_AC3_ENC/playlist.mpd

What did you do?
Start playing

What did you expect to happen?
Playing is started

What actually happened?
Error in log:

The walker saw an error:
Error Code: 6001

But if I remove AC-3 codec from MediaKeySystemConfiguration.audioCapabilities and shaka.media.DrmEngine.willSupport() return is true, then no error occurs and shaka successfully plays this stream.

[aluklon]

Code for test:

var configs = [{
    initDataTypes: ['com.widevine.alpha', 'webm'],
    audioCapabilities: [
        { contentType: 'audio/mp4; codecs="ac-3"' },
    ],
}];
navigator.requestMediaKeySystemAccess('com.widevine.alpha', configs);

Output in console on Tizen:

Uncaught (in promise) DOMException: Unsupported keySystem or supportedConfigurations.

[joeyparrish]

This could be an issue with the MediaKeys implementation in Tizen. (It wouldn't be the first.)

I wrote a quick test to get us some more information from your particular device. Can you please load this URL on your Tizen device and send us a screenshot of the results?

https://storage.googleapis.com/shaka-demo-assets/_bugs/2989/ec3-test.html

Thanks!

[avelad]

@joeyparrish From Tizen 5.5

[aluklon]

[joeyparrish]

If this is the case, I don't see how DrmEngine would have rejected the AC-3 stream or failed to get a CDM instance. The manifest has:

<Representation audioSamplingRate="48000"
    mimeType="audio/mp4" codecs="ac-3"
    id="1" bandwidth="448000">

I'll see if I can test this remotely with the Tizen TV in our lab.

[aluklon]

[joeyparrish]

Using test.py arguments --test-custom-asset 'https://support.smartlabs.tv/DTE_DASH_AUTO/TESTCONTENT/TOS_AC3_ENC/playlist.mpd' --test-custom-license-server 'com.widevine.alpha=https://support.smartlabs.tv/udrm/wvfta/license' and the test launcher for our lab environment (which builds on Tizen WebDriver Server), I can reproduce the failure with error code 6001.

[joeyparrish]

My Tizen 3 device reports slightly different results, so the playback failure actually makes sense here:

{
  "com.widevine.alpha": {
    "audio/mp4; codecs=\"ac-3\"": false,
    "audio/mp4; codecs=\"mp4a.40.2\"": true,
    "audio/mp4; codecs=\"ec-3\"": true,
    "audio/mp4; codecs=\"mp4a.a5\"": true,
    "audio/mp4; codecs=\"mp4a.a6\"": true
  },
  "com.microsoft.playready": {
    "audio/mp4; codecs=\"ac-3\"": false,
    "audio/mp4; codecs=\"mp4a.40.2\"": true,
    "audio/mp4; codecs=\"ec-3\"": true,
    "audio/mp4; codecs=\"mp4a.a5\"": true,
    "audio/mp4; codecs=\"mp4a.a6\"": true
  },
  "clear": {
    "audio/mp4; codecs=\"mp4a.40.2\"": true,
    "audio/mp4; codecs=\"ac-3\"": true,
    "audio/mp4; codecs=\"ec-3\"": true,
    "audio/mp4; codecs=\"mp4a.a5\"": true,
    "audio/mp4; codecs=\"mp4a.a6\"": true
  }
}

Our device claims support for both AC-3 and EC-3 in clear content, but both Widevine and PlayReady reject AC-3 content and permit EC-3 content, which seems strange.

But at least in the case of our device, error 6001 (REQUESTED_KEY_SYSTEM_CONFIG_UNAVAILABLE) makes sense. If the MediaKeys implementation is correct about codec support, then the requested config is truly unavailable.

[avelad]

It is very strange that it supports ec-3 but not ac-3, if you force it to support ac-3 with a pollyfill, does the content work and you can hear it?

[aluklon]

Right, but if you do not pass audioCapabilities with AC-3 to requestMediaKeySystemAccess() and modify shaka.media.DrmEngine.willSupport() follows as:

shaka.media.DrmEngine.prototype.willSupport = function(contentType) {
    return true;
}

then the stream will play successfully.

I want to say that there is some problem in the Tizen platform. Method requestMediaKeySystemAccess() rejects the AC-3 codec, but despite this Tizen plays it successfully.

[joeyparrish]

To verify that AC-3 truly does work (and since my device is Tizen 3, I want to double-check), I tried adding delete config.audioCapabilities before each config is tested in DrmEngine, to see if my device would be willing to play the content as yours does. I also had to comment out the audio section of supportsVariant in DrmEngine, to avoid a failure in filtering later.

I'm not physically present in the lab to verify if audio played. Initially, playback made it to time 13 after 30 seconds of playing. I increased the timeout in that phase of the automated playback test to 60 seconds, and it was able to play all the way 20.

So it's moving slow, and I can't verify that the audio is actually played, but playback doesn't hang. I would assume it's actually playing the encrypted AC-3 audio on this device.

What I don't understand is why either of you see this specific error if MediaKeys does report AC-3 support on your devices. On my device, it does not. And though that report seems to be false, at least the error code is the correct response when the platform claims not to support a necessary codec.

[joeyparrish]

I'm trying to Google whether or not all Tizen TVs support AC-3, because if so, the workaround could be pretty simple. However, the first search result in Google for "tizen ac-3" is this issue. 🤣

[avelad]

You can see the media specifications of each tv model year in:
https://developer.samsung.com/smarttv/develop/specifications/media-specifications/2017-tv-video-specifications.html
https://developer.samsung.com/smarttv/develop/specifications/media-specifications/2018-tv-video-specifications.html
https://developer.samsung.com/smarttv/develop/specifications/media-specifications/2019-tv-video-specifications.html
https://developer.samsung.com/smarttv/develop/specifications/media-specifications/2020-tv-video-specifications.html

Note: all models from 2017 should support ac-3

[joeyparrish]

Perfect, thanks! According to the data from Samsung, Tizen TVs all the way back to 2015 models all support AC-3. None of those tables mention EC-3 support, even the one for my model which reports EC-3 support. So I will assume that EC-3 support implies AC-3, and that Samsung just doesn't mention it in their docs.

That means we should be able to assume AC-3 will work so long as EC-3 will work.

[joeyparrish]

By querying EC-3 every time we query AC-3, and assuming that EC-3 support implies AC-3 support after that, it does seem to play on our Tizen 3 device. I'm going to put my fix up for code review now.

[avelad]

You're only going to do this for Tizen right? I don't want any other platform to break ...

[aluklon]

I have Tizen3, Tizen4, Tizen5 TVs. Test result with 'my workaround':

Tizen3 - no error, stream is playing, no sound (there may be some other error, since earlier on Tizen there were already problems with sound #1610)
Tizen4 - no error, stream is playing, sound is playing
Tizen5 - no error, stream is playing, sound is playing

[joeyparrish]

The workaround will be limited to Tizen, but I am also creating some infrastructure in DrmEngine for doing fallbacks and overrides for this sort of thing. It should be fairly easy to tweak if we make mistakes or if it needs to be adjusted or expanded for other platforms or codecs.

[joeyparrish]

@aluklon, @avelad, the fix has landed in the master branch. Please let us know if you have any concerns with the implementation, and also please let us know if the fix is working for you as it is for me. Thanks!

[avelad]

I will test throughout the week and tell you the results.

[aluklon]

@joeyparrish, I tested the fix ba4763a. The result is the same as here: #2989 (comment). Thanks!