This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
(In reply to comment #0) > > 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. Common Encryption is one encryption scheme which can be used with ISO BMFF. The use of Common Encryption is signalled by the "cenc" value appearing in the Scheme Type. In theory there could be other encryption schemes for ISO BMFF, though it is to be hoped that people will standardize on CENC. Other schemes could have a different format for the InitData. In the absence of actual examples of other schemes, though, I think we could reasonably require that all ISO BMFF encryption schemes provide initData in the form of a sequence of ISO BFMM boxes. An application that supports both CENC and some other hypothetical ISO BMFF encryption scheme can then parse the initData to see if it contains PSSH boxes or whatever boxes the other (hypothetical) scheme provides.
This assumes that it is not possible to determine the content type being used by the media element. Perhaps this is feedback for the HTML5 media element - it should be possible to ask the media element what the content type of the playing content is regardless of the purpose (i.e. not just for needkey).
Are there other use cases where type would be useful? (It might be useful for debugging since MSE and some sites use URLs where the type is not in a filename, but that's probably not convincing.) What are the chances of successfully getting this added to HTMLMediaElement? It may not be possible to specify a single type for a given element (see below). In theory, MSE supports multiple types on the same media element. This might prevent addition of type to HTMLMediaElement. Regardless, there is some symmetry in providing type and initData in the event when we expect those same parameters to then be provided to createSession().
Assigned to adrianba - ACTION-26
Changeset -> https://dvcs.w3.org/hg/html-media/rev/da3ae92ecee2
More changesets related to this bug: * Example updates: https://dvcs.w3.org/hg/html-media/rev/e2673ee7ed4f * Added 'type' in a couple more locations: https://dvcs.w3.org/hg/html-media/rev/5a818f7084c3