DRM Playback Failure on Long Form MPEG-DASH Content

[jamescahall]

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

What version of Shaka Player are you using?
Tested on 3.0.0-npm-dirty (latest master) and v2.5.12-master-25-ge63813c

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?
Both

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

What browser and OS are you using?
Chrome 84 and LG WebOS 3.X

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
WebOS 3.X

What are the manifest and license server URIs?

URLs will be sent via email.

What did you do?

Attempt to play long form DRM protected content (videos over 1 hour or so).

What did you expect to happen?

Videos should play fine.

What actually happened?

Video playback fails with { code: 3 } error. No other errors in logs.

Short form content with DRM (tested with 45 minute videos and shorter) plays fine.

[jamescahall]

Has this issue been re-created or investigated by the Shaka Player team? Not being able to play long form video is a major limitation.

[TheModMaker]

Unfortunately we don't have a WebOS device, so we have no way to test or provide support ourselves. My guess is this is a decoder error and the device is having some trouble playing your content. This is probably a device limitation. The content plays fine on desktop Chrome. You should try only setting a Widevine or PlayReady license server URL; if you only provide one, then we'll only use that. If it works with one key system, then it is a limitation of the DRM system on the device.

I do notice there is a large gap at the start, so what is probably happening is this used to be a live stream and you converted it to live and you got the timeline wrong (e.g. an incorrect presentationTimeOffset value).

[jamescahall]

I’m seeing the exact same issue in Chrome and the test app with the example URLs I provided to you by email. These are not live nor were ever live streams.

[TheModMaker]

What version of Chrome and what platform? The examples you provided work fine for me on both Windows and Mac with Chrome 84. I tried using both https://shaka-player-demo.appspot.com and https://nightly-dot-shaka-player-demo.appspot.com.

[jamescahall]

I'm using Chrome 84 but oddly they are playing fine in Chrome now. I have no idea why they didn't play the other day. However, they are still not playing in webOS. The part that is most confusing is that shorter content (under an hour) is playing fine with DRM on webOS. The strange thing is that when we turn off DRM temporarily for the content, it plays fine. I wouldn't think it would be DRM specific since other shorter DRM content plays fine with the same key structure and these play fine on other devices. The main difference is we use MPEG-DASH when using DRM but unclear why these specific MPEG-DASH manifests are throwing the error.

Can you please provide more details on the presentationTimeOffset as to what you think we should try? Again, these were not previously "Live" videos so not sure why it would affect anything but open to trying things.

[joeyparrish]

What we have seen on older Tizen devices, for example, is that there are sometimes bugs in the integration between the device's hardware decoders and the CDM. We've also seen non-DRM bugs triggered by long content on Tizen. For example, if an audio stream's timestamps are larger than 2⁴⁸ milliseconds (if I recall the exact number correctly), then it just fails to play audio on certain versions of Tizen. Clearly bugs in the firmware in those cases, and it's hard to develop a workaround for those sorts of things. Sometimes the trigger for such bugs can only be avoided by changing something in the encoder.

All of that is to illustrate that the same could be true on some versions of WebOS, such that a decoder error is triggered with long DRM content. It's very hard to say, and we don't have a WebOS device integrated into our lab environment yet.

Anyway, sorry to distract from the productive talk of potential workarounds. @TheModMaker, is there a workaround you want @jamescahall to try?

[TheModMaker]

I figured out why there's a large gap at the start, I noticed this bug as part of #2709 but we closed it and didn't fix the bug. You can work around this by setting the manifest.dash.initialSegmentLimit to a large value (e.g. 1e9); this can be changed in the top-left menu of the demo under the "Manifest" tab. I'll put up a fix now.

Could you try with just one DRM system configured? You can't do this with the demo as-is, but I think if you edit this: https://github.com/google/shaka-player/blob/master/demo/main.js#L1704 to only have one entry, it should only use that. You can't just do this in DevTools since this is used during startup and won't have an affect once the demo is loaded. Alternatively, if you have a custom app, just configure only one license server. If you try only PlayReady or only Widevine, we may see one of them work if this is caused by DRM-protected content.

[jamescahall]

Hi Jacob,

I attempted to set the initialSegmentLength to 1e9 as you suggested but had no affect. I also tried widevine and playready one by one. Neither adjustment helped. As mentioned, shorted videos (under an hour or so) play fine with DRM. Longer videos do not. Here is my setup (NOTE Ignore the 4K switch as this content is not 4K):

        var configuration = { 'abr': { 'defaultBandwidthEstimate' : 500000 }, 'streaming': { 'bufferingGoal' : 10, 'rebufferingGoal': 4 }, 'manifest' : { 'initialSegmentLength' : 1e9 } };
        var features = [];
        if (source != "" && Content.currentContent.mpdURL != null && Content.currentContent.licenseURLs != null && Object.keys(Content.currentContent.licenseURLs).length > 0) {
            source = Content.currentContent.mpdURL;
            var servers = {};
            if (Content.currentContent.licenseURLs["widevine"] != null) {
                servers["com.widevine.alpha"] = Content.currentContent.licenseURLs["widevine"];
            }
            if (Content.currentContent.licenseURLs["playready"] != null) {
                servers["com.microsoft.playready"] = Content.currentContent.licenseURLs["playready"];
            }
            configuration["drm"] = { servers: servers, advanced: { 'com.widevine.alpha': { 'videoRobustness': 'SW_SECURE_CRYPTO', 'audioRobustness': 'SW_SECURE_CRYPTO' } } };
        }
        if (this.is4KContent == true) {
            features.push("ultra-high definition");
        }
        if (features.length > 0) {
            configuration["features"] = features;
        }
        this.drmPlayer.configure(configuration);

Do you have any further suggestions? Is there any settings I should enable to get you additional logs that could help identify the issue? Long form content works without DRM and works in other apps such as Amazon, Hulu, Netflix, etc. (of course I don't know what player they use).

Thanks
James

[jamescahall]

NOTE: I'm actually getting this in Chrome and my note above about Chrome wasn't with Shaka enabled and will send a link for you to test by email.

Additionally, I turned on V2 logging and the browser is reporting:
Invalid config, unrecognized key .manifest.initialSegmentLength
shaka.util.ConfigUtils.mergeConfigObjects @ config_utils.js:45

I'm not seeing initialSegmentLength in the configuration tutorial either so wondering if that is some new parameter that requires a specific version.

Here are some more detailed logs from Chrome on the failure:
No Period ID given for Period with start time 0, Assigning a default
player.js:2355 Found variant with audio and video content, so filtering out audio-only content.
drm_engine.js:858 Created MediaKeys object for key system com.widevine.alpha
23drm_engine.js:548 Ignoring duplicate init data.
stream_utils.js:79 codecs avc1-mp4a avg bandwidth 1295978.5
streaming_engine.js:185 init: completed initial Stream setup
24drm_engine.js:548 Ignoring duplicate init data.
player.js:1888 No preferred audio language set. We have chosen an arbitrary language initially
simple_abr_manager.js:278 Calling switch_(), bandwidth=172245 kbps
player.js:4427 switch_

No further logs.

When a DRM video DOES play, it also shows lines such as:
switch: switching to Stream (video:8)
switch: Stream (audio:9) already active

[jamescahall]

Sent additional sensitive testing details by email.

[joeyparrish]

Sorry for the confusion. The correct config is manifest.dash.initialSegmentLimit, not manifest.initialSegmentLength. Please try correcting that key and see if it helps.

[joeyparrish]

Also, the latest code in the master branch has a fix from @TheModMaker which should fix segment limit issues for all VOD content. So you could either try correcting the config key you're using for the recommended workaround, or you could update to the latest source, where no additional config should be needed.

Does this help?

[TheModMaker]

Also, I loaded your app and transferred the manifest and license server URL to the Shaka demo and the asset plays fine. So it is probably a problem with your app. Without access to the app's code, this can be hard to tell what this is.

[TheModMaker]

It looks like it doesn't start on Chrome due to the issue I described above. If I seek to 6000, it plays fine. If you use the latest master or the updated config value the asset should start fine. I am still not seeing any decoder errors on Chrome so I can't be much help with that. Maybe with that fix WebOS will handle it better?

[jamescahall]

Thank you. I pulled the latest master branch code with your change and seems to have fixed the issue and all non-DRM and DRM content is now playing (including the linear stream).

One note, and not sure if it is related, but when changing videos this error keeps repeating in console:
failed to get buffered range for video DOMException: Failed to read the 'buffered' property from 'SourceBuffer': This SourceBuffer has been removed from the parent media source.
at shaka.media.MediaSourceEngine.getBuffered_ (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:374:100)
at shaka.media.MediaSourceEngine.bufferStart (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:370:502)
at $jscomp.generator.Engine_.program_ (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:606:381)
at $jscomp.generator.Engine_.nextStep_ (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:36:105)
at $jscomp.generator.Engine_.next_ (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:32:234)
at $jscomp.generator.Generator_.next (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:37:73)
at https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:45:230
at new Promise ()
at Object.$jscomp.asyncExecutePromiseGenerator (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:45:123)
at Object.$jscomp.asyncExecutePromiseGeneratorProgram (https://html5-dev.ottera.tv/vizio/js/helpers/shaka-player.compiled.debug.js?_=1596664843071:45:419)

For reference, to destroy the player we are:
a) Removing the raw video tag from the DOM
b) Calling:

                this.drmPlayer.unload().then(function() {
                    _this.drmPlayer.destroy().then(function() {
                    }).catch(function(error) {
                        log("DRM Destroy Error: " + error);
                    });
                });

[joeyparrish]

I think the error is caused by removing the video element from the DOM while the player is still holding a reference to it. Instead, I would suggest calling await player.destroy() first, then removing the element. There is no need to call unload() or detach() immediately before destroy(), as destroying the player implies both unloading the content and detaching from the video element.

Does this help?

[joeyparrish]

BTW, I'm marking this as a duplicate of #2677 since the fix for that issue also fixes this one.

[jamescahall]

OK thanks. I'll review code changes to prevent the error. It doesn't affect app usage so appears to be non-critical.

[joeyparrish]

This issue and #2677 were fixed in c403dec.