- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 11 Dec 2013 10:49:00 +1100
- To: Glenn Adams <glenn@chromium.org>
- Cc: David Singer <singer@apple.com>, Victor Carbune <vcarbune@chromium.org>, Silvia Pfeiffer <silviapf@chromium.org>, "public-texttracks@w3.org" <public-texttracks@w3.org>, Nigel Megitt <nigel.megitt@bbc.co.uk>
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. 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 Tuesday, 10 December 2013 23:49:47 UTC