[foms] To DASH or not to DASH
pierre-yves.kerembellec at dailymotion.com
Tue Jan 4 08:27:14 PST 2011
> Speaking for myself, I do think DASH (the XML format) could be pretty useful. It's fairly extensive and can indeed be used as a manifest format for WebM (A/V) + (Web)SRT (captions). We built some basic support for it in JW Player (using H64/AAC though). Hopefully there'll be an "official" baseline version of the format, since a full XML (with all the groupings and namespaces) is pretty overwhelming. It does provide several useful options that M3U8 does not (separate audio/video tracks, single source with ranges, dvr windows).
Sounds fair. What about browsers vendors? Any opinion on the subject?
> DRM is harder. Perhaps there's a way to provision but not implement it? At the other hand, one needs quite a few low-level API's if decryption is not managed by the browser. To date we stayed away from implementing DRM in the JW Players, since it's a lot of work for a few clients (big companies generally build their own players). Isn't there a more or less common decryption algothytm used by all systems, and couldn't this be applied in browsers/players if a decryption key was provided over an API?
The most common encryption algorithm is AES128 (used for instance in Apple HTTP Live Streaming and Adobe Flash Access). The problem is not
with the algorithm itself, but with the way the encryption key is retrieved: usually, there's some obfuscation involved so that this key (and potential IV)
may not be easily extracted (because once you've got the encryption key in the clear, you can actually produce an unencrypted version of the content
outside the player sandbox). DRM key retrieval is by essence a delicate operation to deal with in the open-source world (because no obfuscation/hidden
storage/decoding is really possible in this case).
In Adobe Flash Access, the whole process is performed between the binary Flash player and the Flash Access Server, and the decryption key is not
transmitted in the clear (it's actually re-encrypted with a unique-to-each-client Flash Player local certificate, and signed with global Adobe certificates).
A pre-requisite step called "player individualization" is performed to create a unique private/public keypair for each installation of the Flash Player.
Also, some (usually assembler) steps are being taken to ensure the encryption key will not be accessible in RAM using some debugger and breakpoints.
In Apple HTTP Live Streaming, the key is retrieved using https, so easily accessible by a eyedropper (and since the whole MPEG-TS segment is simply
encrypted with the AES128 CBC algorithm, a clear version may easily be produced).
> Perhaps somebody knows a good read-up on the various DRM systems that are available at present? In the wild, I only seem to encounter Microsoft's PlayReady.
More information about the foms