[Bug 19096] New: Add 'type' attribute to MediaKeyNeededEvent

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

           Summary: Add 'type' attribute to MediaKeyNeededEvent
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encrypted Media Extensions
        AssignedTo: adrianba@microsoft.com
        ReportedBy: strobe@google.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org


CDMs which support multiple media types may support different formats for
'initData' depending on the 'type' parameter in a call to 'createSession()'.
When using Media Source with EME, it is possible that a single element is
simultaneously parsing media from multiple container formats. In this case,
'needkey' events may fire for multiple streams in different formats, and it is
not always possible to resolve which stream caused the 'needkey' event to be
fired, and therefore the correct value of the 'type' parameter to
'createSession()'.

I propose adding a 'type' parameter to the 'MediaKeyNeededEvent', with a value
representing the MIME type of the media which caused this event to be fired. 


A detail which may require further analysis is the inference of the correct
MIME type value in the case where the MIME type is not supplied to the browser.
For a hypothetical container and codec, 'initData' may have a format which
depends on the actual codec, rather than just the container, and thus codec
information would be needed in the MIME type passed to 'createSession()'.

For this reason, I propose that the Container Guidelines section be expanded
for each container to enumerate the valid MIME types which may be returned in
the value of the 'type' parameter to 'MediaKeyNeededEvent'. 

Since ISO BMFF + CENC is a container-level encryption specification, it should
be sufficient to identify the container format in the call to 'createSession()'
without regard to the codecs or media types contained, and therefore I propose
that the ISO BMFF Container Guidelines indicate that the value of the 'type'
parameter will always be the string "video/mp4", regardless of what codecs may
be used by the container.

I believe that the current WebM encryption specification is similarly defined
at the container rather than the codec level, and tentatively propose that the
value for the WebM guidelines always be "video/webm" regardless of codecs.

Note that this relates only to inference of MIME type for the purposes of
'MediaKeyNeededEvent'. The semantics of 'canPlayType()' should not be affected
by this proposal, nor should the ability to provide MIME types to
'createSession()' that include a codec component even if it is not needed for
that format and key system.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 27 September 2012 18:07:29 UTC