Re: [blink-dev] WebVTT vs TTML Features

On Wed, Dec 11, 2013 at 2:50 AM, David Singer <singer@apple.com> wrote:

>
> On Dec 9, 2013, at 11:31 , Glenn Adams <glenn@chromium.org> wrote:
>
> > The real requirement from TTML, and the major source of disadvantage for
> the current WebVTT approach is that it forces the distribution of
> information that applies to a WebVTT "document". In essence, it prevents a
> WebVTT "document" from being self-contained.
>
> The provision of in-line style sheets in the file header is under active
> discussion and does not seem to be problematic.
>

That's good.


>
> > Another significant design difference between TTML and WebVTT comes into
> play here as well: TTML was designed for smart authoring systems and dumb
> clients, while WebVTT was designed for dumb authoring systems and smart
> clients.
>
> I don’t think this can possibly be true.  The client-side implementation
> of VTT is vastly simpler than TTML, and indeed does not require profiles,
> or complicated specification.
>

This is speculation, since we don't have a reasonable open-source client
implementation of TTML to compare against. I do know that VTT requires a
number of things that TTML does not require, including:

   - a parser
      - TTML would reuse existing an XML or generic HTML markup parser,
      while VTT requires a new parser
   - logic to perform overlap avoidance and other automatic functions
   expected to be performed by VTT
      - TTML assigns this responsibility to the authoring system, not the
      client

A TTML client does not have to process any profile information, e.g., it
can be built to support one or more specific, pre-defined profiles (of
feature sets).

It's too early to say how complicated the VTT specification will be. In
fact, if you review the number of algorithmic steps specified in the
current VTT draft, it vastly exceeds the number of algorithmic steps
specified in TTML.


> > That these design choices are very different will continue to stymy
> efforts to unify the two intentionally different expressions of timed text
> content.
>
> Since TTML’s initial “raison d’etre” was as a flexible authoring system,
> this would seem to be a problem.  I doubt that it’s true.
>

It is certainly true that one could extend TTML by defining new style
extension properties that semantically map to the VTT style semantics that
support automatic region overlap avoidance, etc., but the opposite isn't
true, i.e., VTT doesn't yet support an authoring defined region placement
model, and doesn't support a number of other stylistic, or timing
functions. Over time, it may be possible to add support for some such
functions to VTT, but I tend to doubt the mapping will ever be complete.


>
>
> I also would love to see a report of TTML as *used*, what features are
> actually used, and so on. It would really help, and perhaps help inform the
> profile definitions that are currently underway.
>

Yes, I would like to see that also, however, a more useful compilation
might be an enumeration of the set of all features used with real world
deployed caption/subtitling/teletext systems. When compared with existing
systems (608/708/World Teletext/etc), the current usage of TTML and VTT is
in its infancy.


>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>