We start with a MPEG-DASH stream that uses CENC DRM (supporting both Modular Widevine and Microsoft PlayReady). The manifest itself contains ContentProtection values though they are not the primary decryption mechanism. Decryption is handled with a license url (Widevine when tested in Chrome browser on macOS) fed to VideoJS. When played out in this manner, the license is requested and there are no issues with playback.
When this stream is passed to Google DAI to be SSAI backed, it comes back with a multi-period manifest where some periods are Clear (bumpers and ads) and some periods are DRM protected (primary content).
The underlying issue is that VideoJS seems to ignore the license url that has been passed in player setup when it sees that the first period of content is not encrypted and fails to ever call the license url to decrypt content when it gets to a period with content. You can see in the network tab that the license url is never requested. videojs-contrib-eme suggests there is a method that could be called initializemediakeys:
https://github.com/videojs/videojs-contrib-eme#initializemediakeys
But using this always results in:
"Unsupported keySystem or supportedConfigurations."
Example urls can only be shared privately due to legal reasons but the VideoJS team should be able to easily replicate this by taking any standard DRM stream (to see successful playback) and then apply SSAI advertising from Google DAI or similar that supports SSAI on MPEG-DASH streams.
I can say that the same streams play fine and we see DRM license url calls in:
Shaka Player
Bitmovin Player
Tizen AVPlay
AVPlayerViewController on iOS/tvOS
ExoPlayer on Android/AndroidTV/FireTV
Roku Player
Hi,
This has been reported in this ticket here: https://github.com/videojs/video.js/issues/7824#issuecomment-1837389916
But have been advised to add this here as well.
videojs-contrib-eme @ 3.11.1 video.js @ 8.5.2 videojs/http-streaming @ 3.5.3
We start with a MPEG-DASH stream that uses CENC DRM (supporting both Modular Widevine and Microsoft PlayReady). The manifest itself contains ContentProtection values though they are not the primary decryption mechanism. Decryption is handled with a license url (Widevine when tested in Chrome browser on macOS) fed to VideoJS. When played out in this manner, the license is requested and there are no issues with playback.
When this stream is passed to Google DAI to be SSAI backed, it comes back with a multi-period manifest where some periods are Clear (bumpers and ads) and some periods are DRM protected (primary content).
The underlying issue is that VideoJS seems to ignore the license url that has been passed in player setup when it sees that the first period of content is not encrypted and fails to ever call the license url to decrypt content when it gets to a period with content. You can see in the network tab that the license url is never requested. videojs-contrib-eme suggests there is a method that could be called initializemediakeys: https://github.com/videojs/videojs-contrib-eme#initializemediakeys
But using this always results in: "Unsupported keySystem or supportedConfigurations."
Example urls can only be shared privately due to legal reasons but the VideoJS team should be able to easily replicate this by taking any standard DRM stream (to see successful playback) and then apply SSAI advertising from Google DAI or similar that supports SSAI on MPEG-DASH streams.
I can say that the same streams play fine and we see DRM license url calls in:
Shaka Player Bitmovin Player Tizen AVPlay AVPlayerViewController on iOS/tvOS ExoPlayer on Android/AndroidTV/FireTV Roku Player
Very much appreciate the help looking in to this.