Re: Timed tracks

Hi, Tab:

A few comments inline.
Geoff/NCAM


On 5/6/10 12:41 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

On Wed, May 5, 2010 at 5:49 PM, Geoff Freed <geoff_freed@wgbh.org> wrote:
> So WebSRT will be different from SRT, which is different from TTML... speaking from a broadcaster/content producer point of view, I find this very discouraging.  We already have a plethora of formats to deal with, each with its own limitations.  WebSRT, too, will have its own limitations.  Is the goal now to extend SRT into WebSRT in order to cover basic features already available in TTML, simply in order to eliminate the need for TTML?  Correct me if I'm wrong, but this is what seems is happening.

In essence, yes, though you can replace "TTML" with most existing
captioning formats, since the majority of them are substantially more
complex to author and parse/display than is necessary for the vast
majority of content.  SRT is the closest-to-ideal existing format,
it's just missing a few relatively small things that turned out to be
widely necessary.

GF:
I don't mean to sound antagonistic, but "closest to ideal" by what standards?  I find it far from ideal:  it isn't XML, and it isn't approved by any standards body or anyone.  Extending it now to cover a few missing elements might make it prettier for the moment, but what about adding to it in the future?


The alternative to defining one format is to support all formats above
some baseline usage number.  There are a lot of formats, though,
without any substantially dominant ones, so this potentially means
supporting a lot of different formats.  Further, these will all
require substantial work to map them into the layout framework the web
uses, so they can be interoperably implemented.  Even if were to just
say "All right, we're just doing TTML", it would require us to still
produce a spec explaining how TTML's layout primitives should be
interpreted.  Potentially, of course, browsers could just implement
XSL:FO directly, but initial feedback indicates that that's not an
option they're willing to support.  So we'd have to define how all of
that maps into CSS, which would be as much or more work.

GF:
But since XSL:FO is based on CSS, would it be such a large amount of work to define mappings of the former to the latter?  In the TTML spec, links are provided to the XSL:FO elements, which themselves are linked to the appropriate CSS references.

It just seems odd to me that the group is willing to put the work into extending SRT rather than working with TTML, which already provides for many of the needs of the caption- and subtitle-viewing audiences.