This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24951 - Use a simple string to identify the initData format instead of a MIME/content type
Summary: Use a simple string to identify the initData format instead of a MIME/content...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 17673 24673 24873
  Show dependency treegraph
 
Reported: 2014-03-05 23:46 UTC by David Dorwin
Modified: 2014-04-03 00:16 UTC (History)
3 users (show)

See Also:


Attachments

Description David Dorwin 2014-03-05 23:46:51 UTC
The spec currently uses a |contentType| parameter and attribute to tell the CDM and application, respectively, how to interpret the corresponding |initData|. The spec says, "The contentType attribute contains the MIME type of the media data specific to the event."

The proposal is to replace |contentType| and the MIME type string it contains with something like |initDataFormat| or |initDataType|, which would contain a simple string that exactly defines the format of the Initialization Data contained in |initData|.

Examples include "webm" and "cenc". These strings would be documented in the existing Container Guidelines.

The new value would directly replace the createSession() parameter and MediaKeyNeededEvent (needkey event) attribute. We would need to discuss changes to isTypeSupported() further since both the format/protection system and contentType are useful. (The isTypeSupported() signature is already being discussed in bug 24873.)

Benefits of this change include:
* Eliminate ambiguity in the meaning of isTypeSupported() responses for "mp4" MIME types - this provides no indication of the protection scheme (see bug 17673).
* Allows simplification of the definition of Initialization Data for CENC (see bug 17673).
* Eliminates the superfluous "audio/" and "video/" and additional checks in clients and applications.
* No ambiguity around whether codecs, etc. may also be included in |contentType|.


This bug tracks the proposal in http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0037.html (originall http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0008.html). There has also been some discussion starting with https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c37.
Comment 1 David Dorwin 2014-03-05 23:51:55 UTC
I propose that comparisons of this string be case sensitive (matching the definitions in Container Guidelines).

I increased the priority since this blocks at least 3 bugs.
Comment 2 David Dorwin 2014-03-08 01:46:28 UTC
https://dvcs.w3.org/hg/html-media/rev/9e9a5189294e makes the use of contentType in determining the format of initData more explicit as has always been intended.
Comment 3 Adrian Bateman [MSFT] 2014-04-01 14:48:56 UTC
https://dvcs.w3.org/hg/html-media/rev/c92afe8aac93 replaces the use of contentType with initDataType. It doesn't update the isTypeSupported call, which is also discussed in Bug 24873.

The next part of implementing this bug is to add the registry files that define what strings should be used. E.g. 'cenc' and 'webm'.
Comment 4 Adrian Bateman [MSFT] 2014-04-01 15:59:43 UTC
I've made a number of changes to create a registry of stream/initdata formats and moved the container guidelines into these documents.

This doesn't resolve the isTypeSupported question. The CENC specification should now be able to change with bug 17673.
Comment 5 David Dorwin 2014-04-03 00:16:22 UTC
The changes look good to me. I made some minor tweaks to a couple algorithms in https://dvcs.w3.org/hg/html-media/rev/3d45b0dfdb81.

We can close this and address the other issues Adrian mentioned in those bugs.