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 Web browser determines via the @kind attribute on the <track> element for a given WebVTT file the cue payload type [1] and can, as a consequence, go ahead and render the WebVTT file in different manners (e.g. as subtitles, descriptions, or chapters). [1] http://dev.w3.org/html5/webvtt/#cue-payload When the WebVTT file is delieverd together with a video, but without the HTML file that provides the <video> and <track> glue, this cue payload information is lost. This is typically the case for desktop players such as VLC, QuickTime player, Windows Media Player etc. To deliver a default @kind mapping, I suggest we introduce a file-wide metadata header as discussed in bug 15851. A simple name-value metadata field is sufficient such as: Kind=Captions This provides the default cue payload mapping for the WebVTT file. If such a file is delievered to a HTML page through a <track> element, the <track> element's @kind attribute would still be the cue payload interpretation for the Web page. It is possible to make the WebVTT metadata field the default setting for the browser, too, in case no @kind attribute is given. But it's also ok if the browser would just completely ignore this WebVTT metadata field and continue to use "subtitle" as the default @kind value.
Can you give any examples of independent players that use this kind of information in any other format? I don't understand why the user wouldn't say "load this as a chapter file" or "load this as a subtitle file" rather than hoping the file has the right metadata.
The problem is that WebVTT has been built to satisfy several use cases with the different kinds that we have. It is more than just a caption format. Desktop players right now get different file types for the different use case. For example, VLC accepts all of these file formats as caption files: http://www.videolan.org/vlc/features.php?cat=sub . It also deals with SVCD Menus & Chapters and Matroska Chapters[1]. Similarly Subler[1] (a mp4 muxer) deals with subtitle file formats [2] and with chapter files formats [3] differently. [1] http://code.google.com/p/subler/ [2] http://code.google.com/p/suble/wiki/IntroductoryMaterial#What_else_does_it_do? [3] http://code.google.com/p/subler/wiki/ChapterTextFormat If VLC or Subler is fed with a WebVTT file by the user, they won't know how to interpret it. In particular Subler, which is a transcoder and is used by users by just opening a set of files [4]. The user expects Subler to simply know what these files mean. When used with a UI, it is possible to re-interpret what the SW decided the file contains, but that's not easily possible when using it as a command-line tool. [4] http://code.google.com/p/subler/wiki/UsingSubler For other formats, the file extension will already tell the tool how to interpret the content, but for WebVTT that's a piece of information that's just missing.
If I give a WebVTT file to a tool like this, I expect it to use it to show captions. If you want it to show you chapters for those cues, then you should tell the tool that. I don't see what this has to do with the format. Same with command-line tools that convert files from format to format. If you want it to use a cue file as chapters, you tell it to do so. This is exactly equivalent to using a PNG file as a mask, another PNG file as a background, another PNG file as a foreground, and clipping the foreground using the mask and compositing the result to the background. The PNG files don't say "I'm a mask!" "I'm a background!" "I'm a foreground!". You have to tell your tools what to do.
That's a pretty bad analogy. You can't use a PNG file on its own as a mask - it needs to be combined with something else to function as a mask. In your example, several PNG files serving several purposes would be used together and there would likely be a description file that explains what each file's use is. In WebVTT, the file is being used by itself and it can be used for different use cases as is. Therefore, it needs to contain this information, because it's part of how to interpret the file. I now that we are not getting anywhere because we don't need this in HTML. So, I will stop bothering you about it and leave this bug closed.
Silvia, why did you reopen this? I'm also not a fan of a blessed syntax for this, people will think that it actually does something in browsers, but it absolutely shouldn't...
We need to work with the fact that WebVTT is also being used outside browsers and thus outside the track element. VTT files have kind-specific content, so we need to identify it. I can't think of a better way of doing this.
Maybe we could do a separate spec for WebVTT header metadata? Something that is quite obvious that browsers don't implement it, but that would specify how the metadata is specified so that non-browser tools can take advantage of it? Also, maybe as part of this we should re-consider how we're providing region specs and they should become more like comments?
(In reply to Silvia Pfeiffer from comment #7) > Maybe we could do a separate spec for WebVTT header metadata? Something that > is quite obvious that browsers don't implement it, but that would specify > how the metadata is specified so that non-browser tools can take advantage > of it? I think a separate spec for how to interpret the content of a multi-line NOTE with this kind of information would be just fine. > Also, maybe as part of this we should re-consider how we're providing region > specs and they should become more like comments? Yes, I think that WEBVTT Region: id=fred width=50% lines=3 regionanchor=0%,100% viewportanchor=10%,90% scroll=up Region: id=bill width=50% lines=3 regionanchor=100%,100% viewportanchor=90%,90% scroll=up should become WEBVTT REGION id=fred width=50% lines=3 regionanchor=0%,100% viewportanchor=10%,90% scroll=up REGION id=bill width=50% lines=3 regionanchor=100%,100% viewportanchor=90%,90% scroll=up
(In reply to Philip Jägenstedt from comment #8) > (In reply to Silvia Pfeiffer from comment #7) > > Maybe we could do a separate spec for WebVTT header metadata? Something that > > is quite obvious that browsers don't implement it, but that would specify > > how the metadata is specified so that non-browser tools can take advantage > > of it? > > I think a separate spec for how to interpret the content of a multi-line > NOTE with this kind of information would be just fine. Since NOTE can appear anywhere in the spec, I'd prefer keeping kind, lang and similar attributes as the header metadata, as they should not change during the course of the webvtt file. In any case, we should take this discussion back to the list. I will start a wiki page to collect metadata fields. The region issue should be dealt with separately from this bug.
(In reply to Silvia Pfeiffer from comment #9) > (In reply to Philip Jägenstedt from comment #8) > > (In reply to Silvia Pfeiffer from comment #7) > > > Maybe we could do a separate spec for WebVTT header metadata? Something that > > > is quite obvious that browsers don't implement it, but that would specify > > > how the metadata is specified so that non-browser tools can take advantage > > > of it? > > > > I think a separate spec for how to interpret the content of a multi-line > > NOTE with this kind of information would be just fine. > > Since NOTE can appear anywhere in the spec, I'd prefer keeping kind, lang > and similar attributes as the header metadata, as they should not change > during the course of the webvtt file. In any case, we should take this > discussion back to the list. I will start a wiki page to collect metadata > fields. > > The region issue should be dealt with separately from this bug. If regions are moved out of the header there will be nothing left in the header for a browser to care about. But yes, let's discuss this on the list instead.
(In reply to Philip Jägenstedt from comment #10) > If regions are moved out of the header there will be nothing left in the > header for a browser to care about. Yes, that was always the intention.
Was the region header vs block discussion held on the list? I can't find anything.
(In reply to Simon Pieters from comment #12) > Was the region header vs block discussion held on the list? I can't find > anything. Maybe not, I can't remember. There was likely agreement between Philip and I so we didn't go down that track yet.
Yeah, I don't think we every discussed it elsewhere. I think it's pretty clear from the above, but I think a REGION block makes more sense than having it as part of a header.
OK filed https://github.com/w3c/webvtt/issues/231 about the region syntax.
Adding Eric Carlson for feedback on the proposed change.
(In reply to Philip Jägenstedt from comment #14) > Yeah, I don't think we every discussed it elsewhere. I think it's pretty > clear from the above, but I think a REGION block makes more sense than > having it as part of a header. I agree.
Please note, the original intent of the issue was to introduce a content-usage indicating metadata field for WebVTT. While this is moved to v2, there has been further discussion at: https://github.com/w3c/webvtt/issues/363 https://github.com/w3c/webvtt/issues/368