Closed BucherTomas closed 10 months ago
Same issue. What can we do to resolve this issue? Any hotfixes, I can add myself?
Further details worth knowing: the problem here apparently stems from the fact that Edge is now using MediaFoundation renderer when using Playready for higher security. And changeType is not supported for MediaFoundation in Chromium itself yet.
However, both Edge and Chrome now have chrome://flags/#enable-media-foundation-clear flag, which hints that all Chromium browsers will migrate to MediaFoundation on Windows for every type of content, be it clear or encrypted which might make the problem more visible unless fixed. I confirmed that by enabling that flag in Chrome manually. The issue already became present also with regular clear content there.
Even Widevine will not be spared in the future. Also this keysystem is moving towards hardware-backed content processing on Windows so they will most likely need to leverage MediaFoundation as well like PlayReady does.
I have added my feedback to https://bugs.chromium.org/p/chromium/issues/detail?id=1426179 related to the topic.
However, my questions in the original post here still stand about what can be done on player's side to work around this now.
@BucherTomas PR created https://github.com/videojs/http-streaming/pull/1463
I've verified this with the recent http streaming build 3.10 and can confirm that the issue has been resolved with the associated pull request. Thank you.
Description
A couple of days ago Microsoft upgraded their stable Chromium Edge to a new version (most likely 116.0.1938.54 being the culprit) that seems to have an issue with changeType() API when PlayReady DRM is used on Windows OS.
Sources
The following example using Microsoft's own PlayReady stream demonstrates the issue https://videojs-http-streaming.netlify.app/?debug=true&autoplay=false&muted=false&fluid=true&minified=false&sync-workers=false&liveui=false&llhls=true&url=https%3A%2F%2Fprofficialsite.origin.mediaservices.windows.net%2Fc51358ea-9a5e-4322-8951-897d640fdfd7%2Ftearsofsteel_4k.ism%2Fmanifest(format%3Dmpd-time-csf)&type=application%2Fdash%2Bxml&keysystems=%7B%0A%20%20%22com.microsoft.playready%22%3A%20%7B%0A%20%20%20%20%22url%22%3A%20%22https%3A%2F%2Fprofficialsite.keydelivery.mediaservices.windows.net%2FPlayReady%2F%22%0A%20%20%7D%0A%7D&buffer-water=false&exact-manifest-timings=false&pixel-diff-selector=false&network-info=false&dts-offset=false&override-native=false&preload=auto&mirror-source=false&forced-subtitles=false.
Steps to reproduce
Simply load the URL in latest Edge on Windows and either wait for the player to adapt to another representation while using fluid player mode or forcefuly switch representation in its tab.
Results
Expected
Adaption should not cause any issues as all AVC codec variants in the stream are supported by the browser.
Error output
Player reports the following exception in the console and the stream stalls:
Additional Information
Since clear and Widevine content is fine in this regard on Edge, it truly points to PlayReady processing flow being the one to blame for this and we have sent a bug report to Microsoft.
However, just to make sure, can a player based on VHS library attempt to mitigate the situation on its own apart from forcing Widevine keysystem on Edge? Does changeType API need to be used under all circumstances? Can there be a fallback if using it fails without disabling the API itself beforehand? As other players also using changeType API (such as Shaka) do not exhibit the same problem and do not even register any internal browser exception, there appears to be a way.
videojs-http-streaming version
Likely 2.1.0 and newer are affected as that version introduced support for changeType
videojs version
Any
Browsers
Edge 116.0.1938.54 and newer
Platforms
Windows 10 +
Other Plugins
n/a
Other JavaScript
n/a