Re: [blink-dev] WebVTT vs TTML Features

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

>
> On Dec 10, 2013, at 15:33 , Glenn Adams <glenn@chromium.org> wrote:
>
> > I should have been more specific. VTT does not presently support pixel
> addressing for region placement.
>
> What is a pixel?  OK, so that sounds flip, but text does not have pixels
> in it.  They are ephemeral aspects of the encoding, or (increasingly
> irrelevant) aspects of the client device.
>
> On Dec 10, 2013, at 15:33 , Glenn Adams <glenn@chromium.org> wrote:
>
> > Here I was referring to support for:
> >       • SMPTE code time expressions
> >       • wall clock time expressions
> >       • frame addressing in time expressions
> >       • sub-frame addressing in time expressions
> > VTT supports only a media time base model with time expressions that map
> to NPT.
>
> SMPTE time-code is useful for addressing specific sub-sections of a video
> that is labeled with them, and being frame accurate with it. However, since
> they are labels, they can be discontinuous, and this is problematic.
>
> Wall-clock times are useful if you want something done at, or recorded as
> having been done at, a specific date/time.  This rarely, if ever, arises,
> in captioning; one is more interested in having the content express “<this>
> caption should be shown for <this> time interval over <that> video” than
> “show this caption at 2pm on Thursday”
>
> Frame addressing is relevant if you need to extract a specific frame, but
> the temporal sampling structure of video is sometimes an artifact of its
> delivery environment.  If video is re-sampled from 60i to 30p, or from 60p
> to 120p, or 3:2 pulldown is introduced or reversed, frame expressions
> become fragile.
>
> I am not sure what you mean by sub-frame, unless you mean the ability to
> time something at other than a frame time, which clearly can be done.
>
> On Dec 10, 2013, at 15:33 , Glenn Adams <glenn@chromium.org> wrote:
>
> > Are you saying we should not even try coming up with a mapping?
> >
> > No. I think various folks (including me) are already working on such a
> mapping. The question is to what extent it will be complete and remain
> complete.
> >
>
> TTML is supposed to be an authoring language.  If there are aspects of VTT
> that cannot be represented in TTML, we may need to look at extending TTML.
>  But just as it covers aspects of 3GPP Timed Text, SMIL text, SAMI, and
> other systems that we looked at way back, as well as x08, full TTML is and
> should be a superset of almost any delivery format.
>
> David Singer
> Multimedia and Software Standards, Apple Inc.
>
>
Whether or not pixels, SMPTE time codes, frames etc are useful are not is
irrelevant to this discussion. TTML supports them. So any discussion of
mapping TTML to VTT or HTML or anything else for that matter has to deal
with these at some level.

This thread is not about second guessing or redesigning TTML.