Bug 23441 - Establish an MSE bytestream format registry
Summary: Establish an MSE bytestream format registry
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: LC
Assignee: Aaron Colwell
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-04 22:42 UTC by Aaron Colwell
Modified: 2013-12-02 19:27 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Colwell 2013-10-04 22:42:03 UTC
During the discussions around Bug 22371 I suggested creating a registry for MSE bytestream formats so that new formats could be defined without blocking progress of the main spec.

This bug covers the following tasks for establishing the registry:
- Find a home for the MSE bytestream format registry.
- Specify guidelines for writing bytestream format registry entries.
- Move existing bytestream format text out of the MSE spec and convert it to proper registry entries.
- Update MSE spec text to reference the registry.
Comment 1 Aaron Colwell 2013-11-05 00:14:52 UTC
Change committed.
https://dvcs.w3.org/hg/html-media/rev/47e74f565722
Comment 2 Pierre Lemieux 2013-11-05 16:33:00 UTC
The statement "the byte stream format registry is the authoritative source for byte stream format specifications that can be accepted by a SourceBuffer" implies that implementations cannot support a byte stream unless it is listed in the registry. Per the call earlier, this does not sound like it is the objective.

Suggest instead: "The byte stream format registry provides a mapping between return values of canPlayType() and byte stream format specifications."
Comment 3 Aaron Colwell 2013-11-13 08:40:59 UTC
(In reply to Pierre Lemieux from comment #2)
> The statement "the byte stream format registry is the authoritative source
> for byte stream format specifications that can be accepted by a
> SourceBuffer" implies that implementations cannot support a byte stream
> unless it is listed in the registry. Per the call earlier, this does not
> sound like it is the objective.
> 
> Suggest instead: "The byte stream format registry provides a mapping between
> return values of canPlayType() and byte stream format specifications."

I don't think the suggested text is quite right. I think the following might be a little better at conveying what you want and perhaps address Adrian's concerns on the call.

"The byte stream format registry provides mappings between a MIME type that may be passed to addSourceBuffer() or isTypeSupported() and the byte stream format expected by a SourceBuffer created with that MIME type. Implementations are encouraged to register mappings for byte stream formats they support to facilitate interoperability. The byte stream format registry is the authoritative source for these mappings. If an implementation claims to support a MIME type listed in the registry, its SourceBuffer implementation must conform to the byte stream format specification listed in the registry entry."

I think this conveys that implementations can include mappings that are not in the registry w/o encouraging such behavior. I want to avoid explicitly saying "implementations may include stuff that is not in the registry" because I think that sends the wrong message.
Comment 4 Aaron Colwell 2013-12-02 19:27:28 UTC
Changes committed.
https://dvcs.w3.org/hg/html-media/rev/79954895a223

Text from comment 3 was applied per F2F conversation.