[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 #16 from Mark Watson <watsonm@netflix.com> ---
(In reply to comment #15)
> (In reply to comment #14)
> > It appears that trying to support any scheme type (not just CENC) has led us
> > to include the entire |sinf| box along with |pssh| boxes. This may be adding
> > complexity and overhead that are otherwise unnecessary.
> 
> What's the use case for non-CENC schemes? Since the interoperability story
> of EME hinges on CENC, supporting non-CENC schemes looks like an avenue for
> vendor lock-in.

I would not be opposed to including only CENC schemes.

> 
> > If we returned to just reporting |pssh| boxes, we could always fire a
> > needkey event with the |pssh|
> 
> What's the use case for exposing even pssh? It, too, looks like an avenue
> for defeating the interop story of EME by introducing vendor lock-in.

Common encryption arose originally from work by Microsoft in DECE in which
context several DRM vendors agreed to a common encryption format. This was then
brought, with minor adjustments, to MPEG to define CENC, but there was no
discussion of a common header format.

A common header format would clearly be desirable, but its absence is not the
same problem that a lack of a common encryption format would be. The headers
are small and it is not difficult to include headers for multiple keysystems.
Since the creator of the file needs to support the keysystems on their servers
anyway, its not a huge deal to add the additional headers to the files [It is
something of a pain, though, since new files must be created and distributed.].

As I understand it, the various DRMs include different things in their headers,
not just the key id in different format. I'm told their choices of what to
include are tightly tied to their design and specifically their use or not of
certain IPR.

So, the prospects of a common header format look weak.

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

Received on Wednesday, 14 August 2013 17:02:15 UTC