[Bug 17673] Define Initialization Data for implementations that choose to support the ISO Base Media File Format

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673

--- Comment #26 from Steven Robertson <strobe@google.com> ---
(In reply to comment #24)
> (In reply to comment #20)
> > A device manufacturer can put a newer browser on a device with an older
> > implementation of a protection system, and that older protection system
> > might require something beyond key ID and URL. For instance, older versions
> > of PlayReady require a checksum of the content key to be present in the
> > initialization data in order to generate a challenge.
> 
> Are there legacy DRM implementations out there whose key exchange messaging
> maps to EME other than PlayReady?

I'm uncertain, I've only had detailed interaction with Widevine and PlayReady
CDMs.

> Even in the PlayReady case, it seems that in order  for the scenario you
> mentioned to actually matter all the following would need to be true:
>  * The old DRM system has API surface for emitting key requests and
> accepting responses in discrete messages that map to the EME API.
>  * Someone who cares can  and will actually deliver a newer browser for the
> device.
>  * The DRM part of the device doesn't support enough software renewability
> to remove the pssh  requirement from the DRM initialization as a software
> update  delivered together with the newer browser.
>  * The old DRM system  has suitable  output capabilities for integrating
> into the composition pipeline of the newer browser.

Apologies for being vague, but check the shelves of your local electronics
store and you will find many devices which implement (older drafts of) the EME
spec in the manner you describe here.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 24 August 2013 01:47:40 UTC