NemanjaSRB
NemanjaSRB

Reputation: 396

MPEG-DASH CENC encoder produces MEDIA_ERR_DECODE issue in browser

I have a MPEG-DASH encoder that is fully functional. Now I'm trying to extend it so that streaming content is DRM protected. I have two issues that I'm unable to understand quite easily so I decided to ask you here :)

  1. In full sample encryption (audio track) can I just encrypt each sample in "mdata" box with AES128/CTR/NoPadding and 8byte long IVs which are later stored in "senc" box?

  2. If "senc" box is the container for IVs - do I still need "saiz" and "saio" boxes in "traf" (fragment)?

  3. If I do - offset/size of what should I store there? Of "senc" box or ...?

I have verified that stream is working perfectly without DRM, DRM session is successfully created using "pssh" boxes and ClearKey DRM support in dash.js. Only thing that bothers me for three days is how should a fragment boxes looks like so that browser is capable of decoding it successfully? I'm guessing I did something wrong related to previous three questions.

Upvotes: 1

Views: 939

Answers (1)

NemanjaSRB
NemanjaSRB

Reputation: 396

Ok so let me answer myself - maybe someone will have similar issues.

  1. Yes and no. MP4A contains frames which are serialized into mdata. Each frame is a sample. This means that frame by frame should be passed through AES128/CTR/NoPadding cipher and ciphertext should than stored into mdata instead of a plain frame. Each frame has it's associated IV.

  2. Yes! Although senc box is detected in Mp4 explorer it will not be used by CENC compliant decryptor unles there are saio/saiz boxes that points to senc. Senc should not be stored in mdat box. Saio should point to the begining of IVs in senc - not the senc box itself.

  3. Saiz contains sizes of a single senc entry not the whole box. Saio has only 1 record and it points to senc box first IV position.

Hope it'll help - I've tested my stream with dash.js and bitmovin player - works in both.

Upvotes: 3

Related Questions