[foms] To DASH or not to DASH
watsonm at netflix.com
Tue Jan 4 10:44:06 PST 2011
On Jan 4, 2011, at 7:36 AM, Jeroen Wijering wrote:
> 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).
There definitely needs to be a "baseline" profile of the DASH specification. I'll be working on that with others in the DASH group.
> 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?
Here's our approach: firstly, the encryption used and signalling of Initialization Vectors needs to be common across different DRM technologies. Different devices will support different DRM technologies due to commercial and other issues and I don't want to provide a separate encrypted file for each device type. Some of the main DRM vendors have agreed a common encryption method in DECE using the Microsoft PIFF specification. We've been trying to get this into the ISO Base Media File Format in MPEG, but there is one company strongly opposing this.
Secure delivery of the keys to the "trusted" DRM component on the device is the tricky (and IPR-laden) part. This involves the DRM component itself being authenticated with the DRM server. Ultimately, there must be some tight integration between the key exchange, decryption, the downstream media pipeline on the client. The level of difficulty of "breaking into" this chain determines the kind of content that content owners will allow to be delivered to the device (people analyze this in terms of the types of tools, expertise and time commitment that would be needed to break it and what information you'd get access to).
Another thing that must happen, though, is authorization. The various DRM systems do support this as part of their DRM-system-specific exchange with the DRM server, but really it is something that you want to be done by the service (i.e. Netflix in my case) in a service-specific, rather than DRM-technology-specific, way.
We'd like to see a model in which the service can be in control of user authentication and authorization, the encryption is independent of the DRM technology and just the key exchange is done in a DRM-specific manner.
> 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.
> Kind regards,
> On Jan 3, 2011, at 5:59 AM, Pierre-Yves KEREMBELLEC wrote:
>> Reading this blogpost: http://techblog.netflix.com/2010/12/html5-and-video-streaming.html, I wondered what
>> was the FOMS list members position on DASH (esp. browsers vendors)? Is this something that anyone would
>> be willing to implement? What about DRM: how could it be rolled-out in open-source software?
>> Happy new year to everyone on the list,
>> foms mailing list
>> foms at lists.annodex.net
> foms mailing list
> foms at lists.annodex.net
More information about the foms