W3C home > Mailing lists > Public > public-tt@w3.org > August 2014

Re: ISSUE-335 (Negative times for offsets): In order to handle offsets between start time in TTML docs and start time in video, allow negative times to be used in fragment begin times. [TTML.next]

From: Courtney Kennedy <ckennedy@apple.com>
Date: Fri, 15 Aug 2014 08:31:14 -0700
Cc: Timed Text Working Group <public-tt@w3.org>
Message-id: <ACEDF9D9-D8CB-4C72-9A3E-C841A62AC550@apple.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
HI Nigel,

This is a real world situation that I have encountered with some content.  For whatever reason, the producers of the subtitles cannot use the same start time as the producers of the video and audio.  I think there is a benefit to have all the information within the subtitles file rather than having it in a sideband file which can get lost or separated from the subtitles file.

Best Regards,
Courtney

On Aug 15, 2014, at 5:54 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

> Hi Courtney,
> 
> Iım puzzled by the implied workflow here: if the subtitle file and the
> video have been created, at what point is the subtitle file modified to
> include the new offset? And if someone or some system is making such an
> edit why not simply make the times in the TTML correct against the video,
> rather than adding an offset?
> 
> Iıve seen this issue arise before, when packaging TTML documents in ISO
> BMFF (or some other wrapper). In that case the packaging is likely to
> happen after production of all the media that would be wrapped so it seems
> like the best way to capture any offset is using the facilities provided
> by the wrapper rather than editing the content itself. Certainly ISO BMFF
> appears to offer enough parameters/attributes to support that use case.
> 
> I guess the key structural point is that there is a need to signal
> equivalence of some time reference in the TTML with some other time
> reference in a specific rendition of some related media. At the moment
> this is expected to happen externally to the TTML document: why would we
> bring it inside the document, given that no explicit link exists from
> within a TTML 1 SE document to a related media object?
> 
> Kind regards,
> 
> Nigel
> 
> 
> 
> On 14/08/2014 16:33, "Timed Text Working Group Issue Tracker"
> <sysbot+tracker@w3.org> wrote:
> 
>> ISSUE-335 (Negative times for offsets): In order to handle offsets
>> between start time in TTML docs and start time in video, allow negative
>> times to be used in fragment begin times. [TTML.next]
>> 
>> http://www.w3.org/AudioVideo/TT/tracker/issues/335
>> 
>> Raised by: Courtney Kennedy
>> On product: TTML.next
>> 
>> Use case:  
>> 
>> Subtitles files may be created separately from video and audio for any
>> particular piece of content.  Subtitles may be created in different
>> facilities and at different points in time than the original content.  As
>> a result of this decoupling, sometimes the subtitles file will use a
>> different start time than the video and audio.
>> 
>> Proposal:  
>> 
>> Time expressions in sub-elements are relative to the time expressions in
>> their parent elements, as described in section 10.2.4 of the TTML
>> specification.
>> 
>> When subtitles have non-zero start times relative to the video they are
>> to be synchronized with, the parent div element can have an offset in the
>> begin attribute which, when applied to the times in the samples within
>> the div element, will produce time expressions that synchronize with
>> video.
>> 
>> 
>> The following example uses this offset to indicate that the titles are
>> using start time of 01:00:00:00, and require adjustment before their
>> values express the actual time they should appear in the video.
>> 
>> 
>> <div begin="-01:00:00:00">
>>  <p begin="01:00:05:00" end="01:00:10:00">
>>  This text should appear at 00:00:05:00
>>  </p>
>> </div>
>> 
>> 
>> 
>> 
> 
> 

_____________________________________________
Courtney Kennedy 408.974.3386, mobile: 408.771.8615
Engineering Manager, Media Sharing
Apple, Inc.
Received on Friday, 15 August 2014 15:31:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:17 UTC