[media] CP relating to bug 11207

When the specific format references were taken out of the spec in fulfillment of bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=11207 with the intention that more than one format could be supported by browsers, no provision was put in place to actually handle multiple formats; therefore while bug 11207 is marked as "resolved fixed" the media accessibility sub-team don't believe that it is (see http://www.w3.org/2011/04/13-media-minutes.html for discussion). 

On behalf of the sub-team the following change proposal is made to address the gap.

SUMMARY

In order for authors to take advantage of multiple track formats, a selection mechanism is proposed based on making <track> a non-void element with possible <source> element children, like that defined for <audio> and <video>.

RATIONALE

There has been discussion and general agreement on supporting more than one file format in <track> elements. Even if a single baseline format is implemented across browsers, it is clear that additional formats are likely to be supported, for example  SRT (SubRip), WebVTT, TTML (former DFXP), SUB (SubViewer), SSA (substation alpha), YouTube XML, and others as they develop in the future. 

The requirement for supporting more than one format comes from the drive to re-use existing content without transcoding. It seems that some browser vendors are open to this idea and are indeed planning to implement support for more than one format. It is also important that the specification be future proof to new developments in this area.

DETAILS

The proposal is to reuse the same mechanism for <track> elements as is defined for <audio> and <video> elements: namely to use the <source> element for format selection.
 Example: 
 <video controls>
   <source src="video.webm" type="video/webm">
   <source src="video.mp4" type="video/mp4">

   <track label="English Captions" kind="captions" srclang="en-US">
     <source src="cap_en.ttml" type="text/ttml">
     <source src="cap_en.srt" type="text/srt">
     <source src="cap_en.vtt" type="text/vtt">
   </track>
 </video>
 
Specific specification changes.

In section http://dev.w3.org/html5/spec/Overview.html#the-source-element 

Change contexts in which this element can be used as follows:

Contexts in which this element can be used: 
As a child of a media element, before any flow content or track elements.

Change:
The source element allows authors to specify multiple alternative media resources for media elements. It does not represent anything on its own.
To:
The source element allows authors to specify multiple alternative media resources for media elements, or multiple alternative external timed text tracks for track elements. It does not represent anything on its own.

Changes to expand media references to media and text track references.

In section http://dev.w3.org/html5/spec/Overview.html#the-track-element

Change to content model:
Content model: 
If the element has a src attribute: zero or more track elements. If the element does not have a src attribute: zero or more source elements.

Extend canPlayType to also query supported text track formats

IMPACT

1. Positive Effects

It is possible to provide alternative formats for a single track (label, kind, lang)-combination, while still relying on a common baseline.

Obviates content sniffing on the @src attribute of track when we support several formats (note that content sniffing can become costly in particular in a mobile environment and when many languages are supported).

Having track not be a void element means it will parse better in legacy browsers.

2. Negative Effects

Requires rewording of the specification to allow <source> elements to reference both media content and text track content

Need to implement a source selection algorithm for text tracks.

3. Conformance Classes Changes

None.

4. Risks

None.

REFERENCES

None.

Received on Wednesday, 20 April 2011 12:33:24 UTC