This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
Forgot to mention: the use case is of course to allow people to re-use their existing format without having to transcode (and possibly lose information in the process).
The author should be able to specify a default track per track file type. http://dev.w3.org/html5/spec/Overview.html#dom-track-default The author might have the same content published in (for example) .ttml and .vtt, and may want to set a default in case two user agents don't suppot the same track file types. Also, setting the type on the track itself seems simpler: <video src="v.mp4"> <track kind=captions src=v.en.ttml srclang=en label="English" default> <track kind=captions src=v.de.ttml srclang=de label="German"> <track kind=captions src=v.en.vtt srclang=en label="English" default> <track kind=captions src=v.de.vtt srclang=de label="German"> </video>
I don't really think implementing formats other than WebVTT should be acceptable unless it is clear how that other format is implemented in the same amount of detail as WebVTT. Otherwise minor players end up reverse engineering the market leaders once again.
(In reply to comment #2) > The author should be able to specify a default track per track file type. > http://dev.w3.org/html5/spec/Overview.html#dom-track-default > > The author might have the same content published in (for example) .ttml and > .vtt, and may want to set a default in case two user agents don't suppot the > same track file types. > > Also, setting the type on the track itself seems simpler: > > <video src="v.mp4"> > <track kind=captions src=v.en.ttml srclang=en label="English" default> > <track kind=captions src=v.de.ttml srclang=de label="German"> > <track kind=captions src=v.en.vtt srclang=en label="English" default> > <track kind=captions src=v.de.vtt srclang=de label="German"> > </video> Hmm, if the ttml and vtt english caption tracks are alternatives with essentially the same content, there should only ever one be chosen between them. So, putting them in a <source> would make more sense, don't you think? Also, there can only be a single @default attribute - it would be very confusing to have several. Which one would a browser choose if it supports all of the formats?
(In reply to comment #3) > I don't really think implementing formats other than WebVTT should be > acceptable unless it is clear how that other format is implemented in the same > amount of detail as WebVTT. Otherwise minor players end up reverse engineering > the market leaders once again. I suggest a compromise and we specify WebVTT as the baseline format that all browsers need to support. There will be other formats that browsers will want to accept and there really isn't any way to prevent it.
(In reply to comment #4) > (In reply to comment #2) > > The author should be able to specify a default track per track file type. > > http://dev.w3.org/html5/spec/Overview.html#dom-track-default > > > > The author might have the same content published in (for example) .ttml and > > .vtt, and may want to set a default in case two user agents don't suppot the > > same track file types. > > > > Also, setting the type on the track itself seems simpler: > > > > <video src="v.mp4"> > > <track kind=captions src=v.en.ttml srclang=en label="English" default> > > <track kind=captions src=v.de.ttml srclang=de label="German"> > > <track kind=captions src=v.en.vtt srclang=en label="English" default> > > <track kind=captions src=v.de.vtt srclang=de label="German"> > > </video> > > Hmm, if the ttml and vtt english caption tracks are alternatives with > essentially the same content, there should only ever one be chosen between > them. So, putting them in a <source> would make more sense, don't you think? > > Also, there can only be a single @default attribute - it would be very > confusing to have several. Which one would a browser choose if it supports all > of the formats? Should have added: this is the way in which I would specify your example: <video src="v.mp4"> <track kind=captions srclang=en label="English" default> <source src=v.en.ttml type="text/ttml"> <source src=v.en.vtt type="text/vtt"> </track> <track kind=captions srclang=de label="German"> <source src=v.de.ttml type="text/ttml"> <source src=v.de.vtt type="text/vtt"> </track> </video>
(In reply to comment #5) > I suggest a compromise and we specify WebVTT as the baseline format that all > browsers need to support. There will be other formats that browsers will want > to accept and there really isn't any way to prevent it. We can make pretty clear it would be a proprietary extension instead of endorsing it. I think that would be better.
IMO, content sniffing should be the *only* method for telling formats apart. Let's not repeat the mistake we made with <video>, where lots of authors find it to not work at all until someone points out that they need to configure their server. Also, is anyone *actually* considering supporting anything except WebVTT? Certainly not the legacy SRT?
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.
(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.
You misunderstand the specification. The "requirements of the Media Type Sniffing specification" in terms of how to interpret Content-Type headers do not include actually sniffing, despite the name of the specification. It's just a matter of parsing the Content-Type header and honouring it. There's no sniffing involved here unless the MIME type is absent.
mass-move component to LC1
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: see comment 11.