Re: [blink-dev] WebVTT vs TTML Features

On Wed, Dec 11, 2013 at 10:49 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Wed, Dec 11, 2013 at 10:46 AM, Glenn Adams <glenn@chromium.org> wrote:
>>
>>
>>
>> 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.
>>
>
> Correct. TTML is for authoring, VTT for rendering.

Glenn asked me to clarify this. My point on this is that TTML was
created as a format that encapsulates all features of all caption
formats so that anything that is authored anywhere can be transcoded
to TTML without loss. That is a grand goal and has been the driving
force of TTML. In contrast, VTT was created specifically to render
captions and other time-aligned text in browsers. That is what
motivated this statement. It's on this background that the feature
sets of the two formats have been developed, which explains a lot of
the differences and their respective strengths. It also explains why
we are not interested in some things in VTT.

Hope that clarifies that.

Regards,
Silvia.

> At the point in
> time that you are converting a TTML file with SMPTE time code to VTT,
> you have to reference a video file or at minimum the interpretation of
> the SMPTE time code for making the conversion.
>
> Silvia.

Received on Wednesday, 11 December 2013 01:11:59 UTC