Playback failing on device when moving from 4.7.15 to 4.8.0

[MikeKav]

Have you read the Tutorials? Yes

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

If the question is related to FairPlay, have you read the tutorial? N/A

What version of Shaka Player are you using? Last working: 4.7.15 Unworking: 4.8.0 and 4.9.0

What browser and OS are you using? EE/YouView TV Box Pro Set Top Box (https://www.bt.com/help/tv/learn-about-tv/bt-tv-boxes), Sagemcom hardware running WPE browser version 2.42.5 (slightly higher versions available soon) YouViewHTML/1.0 AppleWebKit/605.1.15 (Sagemcom; RTIW387; RTIW387.002.X; CDS/0.10.116; API/4.0.0; PS/4.1.144) (+DVR+HTML+IPCMC+UHD+DASH+DRM+MSE)

Please ask your question We've had a issue that playback on this STB has worked from 4.2.10 until 4.7.15, but we are experiencing failure to see/hear video/audio content with DASH/PlayReady material. Clear DASH has continued to work on both 4.8.0 and 4.9.0.

The same code is playing video and audio on Edge on all three of the above versions.

Console output seems to indicate the functionality is semi-working: There is a lot of output on setup, but then the player gets stuck in a loop repeating the below constantly: [Debug] (video:8) – "timeNeeded=10" (shaka-player.compiled.debug.js, line 143) [Debug] (video:8) – "update:" – "presentationTime=0" – "bufferedAhead=10" (shaka-player.compiled.debug.js, line 143) [Debug] (video:8) – "buffering goal met" (shaka-player.compiled.debug.js, line 143) [Debug] (video:8) – "updating in 0.5 seconds" (shaka-player.compiled.debug.js, line 143) [Debug] (audio:2) – "timeNeeded=10.005333333333333" (shaka-player.compiled.debug.js, line 143) [Debug] (audio:2) – "update:" – "presentationTime=0" – "bufferedAhead=10.005333" (shaka-player.compiled.debug.js, line 143) [Debug] (audio:2) – "buffering goal met" (shaka-player.compiled.debug.js, line 143) [Debug] (audio:2) – "updating in 0.5 seconds" (shaka-player.compiled.debug.js, line 143)

We do have AppleWebKit in our user agent string, but have not patched in an is[Device] API as used in platform.js as we have until now been able to use configuration switches to set behavior to a working approach.

Up until 4.7.14 the only changes we've needed have been player.configure('streaming.useNativeHlsOnSafari', false); << This was used originally in 4.2.10 to switch our devices DASH streaming from native engine to MSE/EME and currently for audio track switching where codecs are different we now need to add: player.configure('mediaSource.codecSwitchingStrategy', shaka.config.CodecSwitchingStrategy.RELOAD)

We'd appreciate any ideas for areas to look at to find the problem, we've done a comparison of the new fields in config between 4.7.15 and 4.8.0 and tried a few varying settings with no visible change to behaviours

Results from https://shaka-player-demo.appspot.com/support.html:

YouViewHTML/1.0 AppleWebKit/605.1.15 (Sagemcom; RTIW387; RTIW387.002.X; CDS/0.10.116; API/4.0.0; PS/4.1.144) (+DVR+HTML+IPCMC+UHD+DASH+DRM+MSE) v4.9.5

{ "manifest": { "application/dash+xml": true, "video/vnd.mpeg.dash.mpd": true, "application/x-mpegurl": true, "application/vnd.apple.mpegurl": true, "application/vnd.ms-sstr+xml": true, "application/x-offline-manifest": true }, "media": { "video/mp4; codecs=\"avc1.42E01E\"": true, "video/mp4": true, "video/mp4; codecs=\"avc3.42E01E\"": true, "video/mp4; codecs=\"hev1.1.6.L93.90\"": true, "video/mp4; codecs=\"hvc1.1.6.L93.90\"": true, "video/mp4; codecs=\"hev1.2.4.L153.B0\"; eotf=\"smpte2084\"": true, "video/mp4; codecs=\"hvc1.2.4.L153.B0\"; eotf=\"smpte2084\"": true, "video/mp4; codecs=\"vp9\"": false, "video/mp4; codecs=\"vp09.00.10.08\"": true, "video/mp4; codecs=\"av01.0.01M.08\"": false, "video/mp4; codecs=\"dvh1.20.01\"": false, "audio/mp4; codecs=\"mp4a.40.2\"": true, "audio/mp4": true, "audio/mp4; codecs=\"ac-3\"": true, "audio/mp4; codecs=\"ec-3\"": true, "audio/mp4; codecs=\"ac-4.02.01.01\"": false, "audio/mp4; codecs=\"opus\"": true, "audio/mp4; codecs=\"flac\"": false, "audio/mp4; codecs=\"dtsc\"": false, "audio/mp4; codecs=\"dtse\"": false, "audio/mp4; codecs=\"dtsx\"": false, "video/webm; codecs=\"vp8\"": false, "video/webm": true, "video/webm; codecs=\"vp9\"": false, "video/webm; codecs=\"vp09.00.10.08\"": true, "audio/webm; codecs=\"vorbis\"": false, "audio/webm": true, "audio/webm; codecs=\"opus\"": true, "video/mp2t; codecs=\"avc1.42E01E\"": true, "video/mp2t": true, "video/mp2t; codecs=\"avc3.42E01E\"": true, "video/mp2t; codecs=\"hvc1.1.6.L93.90\"": true, "video/mp2t; codecs=\"mp4a.40.2\"": true, "video/mp2t; codecs=\"ac-3\"": true, "video/mp2t; codecs=\"ec-3\"": true, "text/vtt": true, "application/mp4; codecs=\"wvtt\"": true, "application/mp4": true, "application/ttml+xml": true, "application/mp4; codecs=\"stpp\"": true, "audio/aac": true, "audio/ac3": true, "audio/ec3": true, "audio/mpeg": true }, "drm": { "org.w3.clearkey": null, "com.widevine.alpha": null, "com.microsoft.playready": { "persistentState": false, "encryptionSchemes": [ "cenc", "cbcs" ], "videoRobustnessLevels": [ "150", "2000", "3000" ], "audioRobustnessLevels": [ "150", "2000", "3000" ] }, "com.microsoft.playready.recommendation": null, "com.chromecast.playready": null, "com.apple.fps.1_0": null, "com.apple.fps": null }, "hardwareResolution": { "width": null, "height": null }, "offline": true }

[avelad]

We do not have that device, I recommend that you look at the recent commit history in DrmEngine (https://github.com/shaka-project/shaka-player/commits/main/lib/media/drm_engine.js) and if you find the commit that fails, we will be able to help you... Sorry!

[MikeKav]

Hi, I tried a few versions!

Using: https://github.com/shaka-project/shaka-player/pull/5897 (feat: Add preload system to player) git checkout -b test-branch-489b11a 489b11a python3 build/all.py --force PlayReady Content fails to play

https://github.com/shaka-project/shaka-player/pull/6189 (feat!: Remove com.adobe.primetime keysystem) git checkout -b test-branch-47602c6 47602c6 python3 build/all.py --force PlayReady Content plays

To check I didn't make an error I then: git checkout test-branch-489b11a python3 build/all.py --force PlayReady Content fails to play

The version numbers reported seemed a bit broken, but I assume from this test it's something in the changes in https://github.com/shaka-project/shaka-player/pull/5897 that is causing the issue for me?

[MikeKav]

I'll also add that I had not yet moved to using the player.attach() method, but now I have, with the same results

[avelad]

The PR is huge, but there is no change that affects the drm.

[MikeKav]

I took a look and it did seem quite big. Would you have any further recommendations for narrowing down the issue or to break down the PR changes to test? It seems to be an issue that has been introduced and into new versions moving forward so preventing us from moving off the 4.7 branch

[avelad]

The change is very big, if you can debug more, and find where the error is, we are happy to fix it :)

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.

[MikeKav]

@shaka-bot reopen

I've not had time to work on this until now, today I've tried the newer versions as released since I first posted. 4.17.15 (/) 4.8.0 (x), 4.8.20 (x) 4.9.0 (x), 4.9.19 (x) 4.10.0 (x), 4.10.7 (x)

[avelad]

@MikeKav We do not have that device, we can leave the issue open, but you will have to debug the error yourself, sorry!

[MikeKav]

Hi @avelad , I do understand (as a matter of interest, do you have a UK based lab?). I've re-opened to provide some further details, hopefully someone might see something I'm doing and be able to help advise. I have checked some different content types, and can replicate the issue on public available content and keys, which is: "url": "https://media.axprod.net/TestVectors/v7-MultiDRM-SingleKey/Manifest_1080p.mpd",

                "drm": {
                    "servers": {
                        "com.microsoft.playready":"https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:9eb4050d-e44b-4802-932e-27d75083e266,contentkey:FmY0xnWCPCNaSpRG+tUuTQ==,sl:150)"
                    }
                }, 

[avelad]

@theodab can you help here? Thanks!

[shaka-bot]

@MikeKav Does this answer all your questions? If so, would you please close the issue?

[MikeKav]

Hi, I've looked into the code differences (running uncompiled 4.8.0) and running Edge side by side with my device.

I do see this error: [Warning] Error installing polyfill! (log.js, line 148) ReferenceError: Can't find variable: EncryptionSchemePolyfills install — encryptionscheme.js:26 installAll — all.js:25 (anonymous function) — ui.js:286 scanPageForShakaElements — ui.js:284

This is different on Edge: log.js:148 Error installing polyfill! ReferenceError: EncryptionSchemePolyfills is not defined at Object.install [as callback] (encryption_scheme.js:26:5) at shaka.polyfill.installAll (all.js:25:18) at HTMLDocument.initApp (myapp.js:41:20)

I believe Edge uses native EME, whereas for my device it's probably safe to use the polyfill? (and it is set up this way in media_capabilities.js) so I'm not sure if the error matters as the playback still works on Edge

At this point in the code on my device

const mediaKeys = await mediaKeySystemAccess.createMediaKeys(); mediaKeys has no properties, but on Edge, this seems to be defined and have some functions attached to it:

Does this look like it could be an issue? I think my next step is to see if the working version for my device (4.7.15) has similar code and if that object is correctly defined.

[MikeKav]

On device the code mediaKeySystemAccess.createMediaKeys() appears to be asserting this

// TODO(vaage): Look into the assertion below. If we do not have any drm // info, we create drm info so that content can play if it has drm info // later. // However it is okay if we fail to initialize? If we fail to initialize, // it means we won't be able to play the later-encrypted content, which is // not okay.

// If the content did not originally have any drm info, then it doesn't
// matter if we fail to initialize the drm engine, because we won't need it
// anyway.
return hadDrmInfo ? p : p.catch(() => {});

This is a little out of my experience area, but it seem the polyfill is not doing the right thing, I have tried using native mediaCapabilities but that does not work on my device

[MikeKav]

Part of this currently seems to be a red herring, debugging 4.7.14 I can see that const mediaKeys = await mediaKeySystemAccess.createMediaKeys(); mediaKeys has no properties as per 4.8.0

[MikeKav]

debug log up to just past player.load() looks ok as far as I can tell: debug log from device pretty much matches Edge

[MikeKav]

After further debugging It seems like in 4.8.0 the video element doesn't get beyond loadedmetadata on device. Not sure why this is the case.

I spent some time reviewing: onKeyStatusesChange_ in drm_engine.js as on device the session where simple numbers compared to Edge. However the code looked to be functioning correctly in there

On device: Key status changed for session 2 On Edge: Key status changed for session BzBfqjxFy6Dj1SEQreP9mg==

[MikeKav]

I've not been able to spend too much further time on this, however I have managed to simulate similar behaviour on Edge by commenting out this part of the app code player.getNetworkingEngine().registerRequestFilter((type, request) => { / if (type === window.shaka.net.NetworkingEngine.RequestType.LICENSE) { console.log('[Shaka Player] AX license request'); request.uris[0] += '?cfg=(kid:9eb4050d-e44b-4802-932e-27d75083e266,contentkey:FmY0xnWCPCNaSpRG+tUuTQ==,sl:150)'; } / });

Maybe there is some hint here, in that without the license request Edge won't receive the content keys for decoding the content?

[MikeKav]

Hi @avelad @theodab , sorry to bother you, however is there any UK offices the Shaka team work from that I could bring some hardware for debugging this issue?

[avelad]

Sorry @MikeKav, no one from the maintainers team is in the UK, sorry...

[shaka-bot]

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.

[Iragne]

Look we had to revert back our PS4 and 5 we are checking it. hope we will find the reason

[Iragne]

not in 4.8.20 but in 4.9.0 still work on the sha:20df1a0a88182c6589d2657f8794fa025650cb5e between the previous and this one e0eeb5b77d4887d3fa54ca66236543d7d0df4a57

[MikeKav]

Hi @Iragne I'm not working on PlayStation myself (not since 2021), but it would be interesting to know of any areas to look that might be similar to the issue here.

I have been on holiday but we have had some time to look a little more, I have not found anything at ShakaPlayer level yet, but looking at device firmware logs we can see that the PlayReady license looks to be requested ok, and we can see what seems to be a correct license with the expected content id being stored and made ready for use in the license store.

The device uses gstreamer under the hood, there is a first-pts callback fired which normally results in an event haveEnoughData which should fire the loadedmetadata JavaScript event during loading. when using 4.7.15 this callback does occur, in 4.8.0 it doesn't. At the low level our assumption at the moment is that this means the video buffer is not being injected into the gstreamer pipeline. We don't know what would cause this difference yet

We do have a couple of hosted links that we could PM someone, however the links are geofiltered to the UK.

Unfortunately it will take a little time to have some gstreamer debugging completed, so I am going to look a little more at the ShakaPlayer differences in the preload system in 4.8.0

[Iragne]

On our side we had to set the stream.cleardecodingcache to false @MikeKav it completely solved ps4 and ps4 we have also the or associated to the issue but the or should solved PlayStation issue but in fact it created the issue

FYI we had been able to point to the commit that induce our issue https://github.com/shaka-project/shaka-player/pull/6678

I'm really curious about it, what are the circumstance where the "streaming.clearDecodingCache" should be true or false @tykus160 BTW the issue is maybe not releated to what Mike Kav is facing but error was really similar drm playready crash log quite the same

[Iragne]

@MikeKav let me know if it works

[tykus160]

@Iragne streaming.clearDecodingCache is set to true by default only on PlayStation devices, so probably setting it explicitly to false won't help in the issue @MikeKav is facing (but I encourage experimenting with that). It's been introduced because reusing of MediaKeySystemAccess objects is problematic on those devices and after several playbacks (i.e. due to bingewatching) they are not able to create MediaKeys object anymore (shaka starts to throw 6002 FAILED_TO_CREATE_CDM error). Clearing decoding cache after every session helped us to solve the issue on PlayStation 5.

[Iragne]

@tykus160 I was going to say the same. but we should maybe open a different bug report for PS5 and PS4. The streaming.clearDecodingCache is set to true Clearly break the playback on our stream. ISsue was really similar so we though it was related. We understand the patch but the reality is that it's not working on our stream AWS stream mpv2 dash. we are quite puzzle witht he next steps now happy to talk in private for that

[avelad]

@Iragne any update?

[Iragne]

@avelad we just change the config to use the streaming.clearDecodingCache and it unblock our playback. we will share shortly information about it