Re: Metadata in the VTT file header (bug 15851), use cases (and a need to close this)

On Wed, Aug 29, 2012 at 5:21 PM, David Singer <singer@apple.com> wrote:

> 1) Authoring.  Quite often caption files are authored/written in a
> different workflow from the media, and must be re-united later. We'd like
> to keep track of attributes of the files in-band, so that they don't get
> lost (e.g. the language of the captions), and indeed, of the proposed
> values for the <track> element attributes when the file is referenced from
> HTML. It can also be useful to include a link-back to the content that was
> captioned, using an identifier (e.g. URL).
>

To give an example, when you mux audio, video and caption files into a
.WebM file, you currently need to supply metadata to the muxing software,
eg.:

mkvmerge -o example.mkv video.avi audio.ogg --language 2:ger german.vtt
--language 3:eng english.vtt

By including this inline, muxers can find this out directly:

mkvmerge -o example.mkv video.avi audio.ogg *.vtt

This causes users (me) headaches, and can greatly simplify this very common
case.

 key: |
> valueline
> valueline
> …
> .
>

Also, &escapes; need to be allowed, so that "-->" can be escaped to
"--&gt;".  This is needed for single-line headers, too.  Other than that
one oddity, however, this format requiers no escaping except for prefixing
backslashes, and unescaping can be as simple as "if the line begins with a
backslash, remove it".

We have implementation of the single-line case in hand and would prefer it
> not change; we can probably be more flexible on the multi-line case, but
> the above seems fine to us and covers all the cases while retaining
> simplicity.
>

Including &gt; (etc.) handling, by the way?


On Wed, Aug 29, 2012 at 6:53 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 29 Aug 2012, David Singer wrote:
> >
> > 1) Authoring.  Quite often caption files are authored/written in a
> > different workflow from the media, and must be re-united later. We'd
> > like to keep track of attributes of the files in-band, so that they
> > don't get lost (e.g. the language of the captions), and indeed, of the
> > proposed values for the <track> element attributes when the file is
> > referenced from HTML. It can also be useful to include a link-back to
> > the content that was captioned, using an identifier (e.g. URL).
>
> This would be entirely addressed by in-file comments, and doesn't need
> name-value pairs.


Muxing software shouldn't be storing data in proprietary magic headers and
then parsing them out.  That's nuts--it means the format *will* have
key/val headers, just in an ad hoc, nonstandardized, uninteroperable way.

In fact name-value pairs wouldn't address the problem
> sufficiently, since some people have data that isn't name-value pairs
> (e.g. an author might want to include name,language,value tuples, or
> binary data, or structured data). In addition, author-specific workflow
> data doesn't need to follow a standard, since it only needs to be
> interoperable within the application the user uses.
>

The person authoring subtitles is often not the same person muxing the
result.  There isn't just one author, or one toolset in use for creating a
single final muxed file.

"Language" is already included in this proposal.  While there may be other
information that authors might want to include; this standardizes the stuff
that you almost always *need* (the stuff <track> needs is usually all you
need for muxing), and gives a framework for future data if needed.

This should be at the container level, not in VTT, IMHO. It is trivial for
> a container format to define how to include such information; even in the
> case of a format that can only embed data directly, the payload format can
> always be defined as being the data from the <track> element followed by
> the WebVTT data itself.
>

How does this data get into the container?  That happens at muxing time,
and it has to come from somewhere.  With no metadata format within VTT,
everyone is going to make up their own incompatible places to put this data
before muxing, or make the user specify it all manually (the aforementioned
headaches).

 > 4) Style-sheets.  Maybe it's satisfactory to define that WebVTT inherits
> > styling from its container (e.g. HTML5), but in the case where the
> > container doesn't carry styling (e.g. HTTP streaming, MP4), or in the
> > case where specific styling is needed for the WebVTT, we need to be able
> > to reference or include style sheets in the WebVTT layer itself. As an
> > example, a style-sheet giving 608/708 appearance is being worked on as
> > part of the 608/708 conversion.
>
> This is handled by the proposal(s) in:
>    https://www.w3.org/Bugs/Public/show_bug.cgi?id=15023
>
> This is not a use case for a name-value pair metadata header.
>

The proposals in that bug *are* name-value pairs; the name is "style" (or
"STYLE", or whatever).

Additionally, https://www.w3.org/Bugs/Public/show_bug.cgi?id=18530(external
stylesheets) is another use case (eg. "External-Stylesheet:
captions.css").

-- 
Glenn Maynard