1759936 - Playback of CBCS encrypted stream is failing

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Spinning this off from a comment on bug 1492377

---

For example I just sted this asset on firefox, and can see that clearly CBCS decryption isn't handled:

https://shaka-player-demo.appspot.com/demo/#audiolang=en-US;textlang=en-US;uilang=en-US;asset=https://content.uplynk.com/e5e23a51daca4f679ee29d173aa66ce2.mpd?m4fenctype=cbcs;panel=CUSTOM%20CONTENT;build=uncompiled

License URL is https://content.uplynk.com/wv, but shaka takes care of it, just try playing the above link in Chrome and then in firefox.

Additionally I can play it back in edge on windows, I can also play it back in safari if I create an HLS manifest using the same segments (which I just tested but won't demo for you now).

It plays back on roku and in exoplayer. Basically we are getting really close to being able to just use this one set of segments everywhere, but Firefox appears to be a holdout. You are the only prominent browser not supporting it as of now from what I can tell.

Comment 1

[john.bowers]

CBCS is a new encoding be added to the edgecast (formerly verizon digital media) slicer / encoder system. You would use the slicer to generate assets, but CBCS encoding has to be turned on for your account, and you have to create an account.
Here is the documentation link for the slicer:

https://docs.edgecast.com/video/index.html#Ingestion/MI-OD.htm

If you really want to use the system to generate new content we could work through it I am sure, but I figure a test asset like the one above is probably enough to work through any issues. Especially since it seems to play basically everywhere else.

Comment 2

[Whome]

Firefox(win10) CBCS still not working, CENC works ok. See dashjs tests below.
Chrome(win10, widevine) = cbcs1:9+cbcs0:0+cenc ok
Edge(win10, widevine, playready) = cbcs1:9+cbcs0:0+cenc ok
Chrome(android, widevine) = cbcs1:9+cbcs0:0+cenc ok
Chrome(macOS, widevine) = cbcs1:9+cbcs0:0+cenc ok
Firefox(win10, widevine) = cenc ok
Firefox(macOS, widevine) = cenc ok

CBCS_1:9 pattern (10% encrypt, 90% nocrypt)
https://refapp.hbbtv.org/dash/test_dashjs_wv.html?video=llamacbcswv
https://refapp.hbbtv.org/dash/test_dashjs_wv.html?video=llamacbcs

CBCS_0:0 pattern
https://refapp.hbbtv.org/dash/test_dashjs_wv.html?video=llamacbcs2wv
https://refapp.hbbtv.org/dash/test_dashjs_wv.html?video=llamacbcs2

CENC normal scheme
https://refapp.hbbtv.org/dash/test_dashjs_wv.html?video=llamacencwv
https://refapp.hbbtv.org/dash/test_dashjs_wv.html?video=llamacenc

Comment 3

[Whome]

Firefox(win10, widevine) started to work once "tenc" encryption box in an init.mp4 segment is using "default_constant_IV, default_constant_IV_size" fields instead of "default_per_sample_IV_size" field.
https://refapp.hbbtv.org/dash/test_dashjs_wv.html?video=springcbcs2wv

Comment 4

[m.schloesser]

I am working as an external consultant for a VoD project for a national rail service, where this bug unfortunately has made it to the top of customer complaints.
We're using vp9/aac with widevine cbcs and this works fine for chromium and also Firefox on windows and osx, but not FF on android.
We would be potentially interested in sponsoring someone to fix this bug.
Hopefully this is OK to post here?
If interested, please do contact me 😊

Comment 5

[Luca Niccoli]

I have found the cause for this bug: ISO/IEC 23001-7/2016 §10.4 specifies that non-video assets protected with CBCS encryption use whole-block full-sample encryption; in this case there won't be any subsample ecryption information for the samples.
MediaCodec.queueSecureInputBuffer will throw an IllegalArgumentException if we submit a CryptoInfo that has no subsamples though; we need to specify one subsample which is just as big as the whole sample, with 0 clear bytes and all encrypted bytes.

I have requested Level 1 commit access to submit a patch fixing this bug; take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1914063 if you want to vouch for me.

Comment 6

[Alastor Wu [:alwu]]

(In reply to Luca Niccoli from comment #5)

I have requested Level 1 commit access to submit a patch fixing this bug; take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1914063 if you want to vouch for me.

I've vouched you, and feel free to set me as reviewer when you submit a patch. Thanks!

Comment 7

[Luca Niccoli]

Attachment: Bug 1759936 - Fix playback of non-video CBCS encrypted assets on Android r=alwu

ISO/IEC 23001-7/2016 §10.4 specifies that non-video assets protected
with CBCS encryption use whole-block full-sample encryption; in this
case there won't be any subsample ecryption information for the samples.
MediaCodec.queueSecureInputBuffer will throw an IllegalArgumentException
if we submit a CryptoInfo that has no subsamples though; we need to
specify one subsample which is just as big as the whole sample, with 0
clear bytes and all encrypted bytes.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/36862cadc13f
Fix playback of non-video CBCS encrypted assets on Android r=alwu

Comment 9

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/36862cadc13f