- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Aug 2011 00:09:35 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13544 Summary: Video: <track> element should allow support of more than one format without content sniffing Product: HTML WG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: silviapfeiffer1@gmail.com QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org The <track> element as specified right now is similar to the <img> element for detecting what mime type the resource specified in @src is: browsers have to do content sniffing to identify the mime type of the resource. If all Web browsers only implement support for a single format, we won't have a problem. However, I know that several browser vendors want to support multiple external text track formats, including WebVTT, TTML, and possibly others. The need to content sniff is a problem for this element when on mobile devices and when the list of alternative tracks becomes rather long. This can be the case for videos that have subtitles in many languages, such as e.g. http://www.youtube.com/watch?v=QRS8MkLhQmM&cc=1 . To solve this, the suggestion is to change the content model of the <track> element from being empty to allowing <source> as children. For example: <video controls src="video.webm"> <track label="English Captions" kind="captions" srclang="en-US"> <source src="cap_en.ttml" type="text/ttml"> <source src="cap_en.vtt" type="text/vtt"> <source src="cap_en.srt" type="text/srt"> <source src="cap_en.mpsub" type="text/mpsub"> </track> </video> I'd be curious what people think about this option. -- FYI: MPSub is MPlayer's subtitle format: http://tuxrip.free.fr/MPlayer-DOCS-HTML/en/subosd.html#mpsub -- 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 Wednesday, 3 August 2011 00:09:37 UTC