Open BakurL opened 1 year ago
we are seeing this as well. troubleshooting now
I have weird untested solution. Don't know what changed, but SPC gets SPACES after conversion into Base64 (weird). We tried removing spaces, but this didn't work. We swapped spaces to + symbols and in native implementation (without videojs) were able to playback the content on iOS 16.1.1. Checking videojs+contrib-eme now
Doesn't work with videojs/contrib-eme
@BakurL would you be able to share your "native implementation" that worked in mobile safari with us? (note: it doesn't need real streaming urls, we have those of our own) if we can get DRM working in Safari with raw html / js (i.e. no videojs code) this would help us to see if there is a problem in the contrib-eme implementation.
@rudemateo Sure, it's standard Apple Faiplay implementation that comes with FPS package. But, here's codeshare https://codeshare.io/contib-eme . What we discovered, this implementation generates spaces in SPC somehow (after base64 conversion). Which was working before iOS 16.1.1, but somehow does not work now. So for our License Server (fairplay one), which generates CKC, we had to replace spaces in SPC to plus symbols. This we tested and it works on iOS 16.1.1, as well as older versions of iOS (we tested 15.5). Hope this helps. Please share patch for contrib-eme if you fix it
we used the apple fairplay example code you attached in the codeshare, and confirmed that it works in safari on iOS 16.1.x devices. so this does appear to be an issue with the videojs-contrib-eme implementation.
I was given guidance on the video-dev
slack to downgrade to a 3.x version of this library, and indeed, that fixed this issue :-(
Thanks a lot for the tip! We tested too, works surprisingly
We have tried downgrading to 3.10.1 but it did not fix the FairPlay issues for us on iOS 16.1.x.
Update:- It worked for us too.
We had to change the way getContentId works, some additional transformation was needed.
There was one more bug, we were struggling with - with multi-bitrate/stream manifests (hls), contrib-eme was playing back inconsistently (about 50% of the time issuing MEDIA_ERR_DECODE). This problem got solved with older contrib-eme also
I can confirm that this issue affects us with version 5.0 as well.
While using standard EME seems to work well for iOS 15 and was apparantly in fact required - compare #140 - it breaks iOS 16.
What you are basically doing by downgrading to 3.x is to back out https://github.com/videojs/videojs-contrib-eme/commit/58976556e19bd210a075b0190b0d0d45084b98c6 which prefers standard EME over the vendor specific API.
In our tree, I used https://github.com/PicturePipe/videojs-contrib-eme/commit/49701d3ab71b4d67e0aaed5796ac76079f0db767 to achive the same effect without downgrading the whole plugin and still using standard EME on iOS 15.
This still seems more like a workaround than a proper fix.
The proper fix would be researching why the implementation using standards based EME fails on iOS 16 and fixing it.
Hi @cfra , after we upgrade IOS to 16.1 ++ have the same issue
_VIDEOJS: – "ERROR:" – "(CODE:3 MEDIA_ERRDECODE)" – "The media playback was aborted due to a corruption problem or because the media used features your browser did not support."
Seeing this on iOS 17 as well.
We are seeing MEDIA_ERR_DECODE - this problem on devices with iOS 16.1.1 (recent update). Anyone has any idea on fix/what to do with it?