Re: Timed tracks

On Thu, May 6, 2010 at 10:49 AM, Geoff Freed <geoff_freed@wgbh.org> wrote:
> 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.
>
> I don’t mean to sound antagonistic, but “closest to ideal” by what
> standards?

By the standard of solving the majority of use-cases in the problem
space without too much unnecessary complexity.


>  I find it far from ideal:  it isn’t XML,

That's not a benefit.  XML is a potential tool, not a requirement for
everything on the web.


> and it isn’t approved
> by any standards body or anyone.

SRT is used fairly widely.  That's the sort of approval that means
something; it indicates that the format has at least some inherent
merit.


>  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?

Attempting to solve unknown and unknowable future problems has been
repeatedly established to be a rathole from which a technology never
recovers from without a reboot.  The problem of putting captions,
subtitles, and similar on video is not new, and it's had quite a bit
of time to establish an ecosystem of solutions that we can draw wisdom
from.


>> 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.
>
> 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.

XSL:FO is not based on CSS.  It has many similar concepts, but pairs
that with many subtle and incompatible changes.


> 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.

Lightly extending a simple technology is often easier than trying to
remap an existing complex technology that does more than you need.

~TJ

Received on Thursday, 6 May 2010 18:11:05 UTC