[Bug 13544] Video: <track> element should allow support of more than one format without content sniffing

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13544

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #10 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-08-04 00:48:09 UTC ---
(In reply to comment #9)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: The spec is very clear about how multiple formats are to be
> supported. There's no content sniffing unless the MIME type isn't given. The
> premise of the bug is false.

I think you misinterpreted this to be about the video element. This is not
about the video element, but about the <track> element.

There is no attribute to provide the mime type for the <track> element, so
content sniffing is indeed the only way to determine whether the format can be
parsed.

This is even explicitly stated in the download step at:
http://dev.w3.org/html5/spec/the-iframe-element.html#sourcing-out-of-band-text-tracks

"The tasks queued by the fetching algorithm on the networking task source to
process the data as it is being fetched must examine the resource's Content
Type metadata, once it is available, if it ever is."

which links to
http://dev.w3.org/html5/spec/fetching-resources.html#content-type where it
says:

"The Content-Type metadata of a resource must be obtained and interpreted in a
manner consistent with the requirements of the Media Type Sniffing
specification."


There are two particular use cases for supporting multiple formats: one has to
do with legacy content that people don't want to transcode because the
transcoding may lose information. So, they want to be able to provide the
original file to such browsers that will support that format and use the
transcoded file as a "backup".

The second is that some publishers want to provide their captions in two
different formats: a rich caption format with complex formatting and a simple
one that is just text-only for fallback purposes on UAs that only support
simpler formats.

In both these cases, it would be possible to have the <source> elements list
both files and the UA dropping the first one if it can't be interpreted, thus
going to the second one (in WebVTT) as fallback.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 4 August 2011 00:48:12 UTC