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]

Hi Nigel,

It may be that this is not a common enough case to warrant a change to the TTML spec, which is why I am willing to close it, if the consensus is that it is not widely useful.   Though Glenn’s comments suggest that others have run into similar problems.

To expand on the rationale for it-  It will probably be less efficient to do require a separate step to re-write the subtitles file.  If there is a way to store the information in the file, it can be handled as part of other transformations to subtitles, such as a transcode to a binary format for playback purposes.

Best Regards,
Courtney

On Aug 15, 2014, at 11:06 AM, Glenn Adams <glenn@skynav.com> wrote:

> 
> 
> 
> On Fri, Aug 15, 2014 at 11:58 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> I think we should keep it open and add support for ttp:mediaTimeOffset which could be negative.
> 
> Can you explain your rationale please?
> 
> At first order, it is a much more simple solution that performing transformation processing to edit times. Think of it as a useful convenience function. I've had requests for both positive and negative media offset expressions from a number of sources.
>  
> 
> 
> On Fri, Aug 15, 2014 at 11:30 AM, Courtney Kennedy <ckennedy@apple.com> wrote:
> Hi Nigel,
> 
> Ok, we can close this then.
> 
> Best Regards,
> Courtney 
> 
> Sent from my iPhone
> 
> On Aug 15, 2014, at 9:03 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> 
>> Hi Courtney,
>> 
>> I agree it’s a real world situation, but I don’t understand why your proposal is better than just putting the TTML file through a transformation processor that adjusts all the times – hence my questions. 
>> 
>> At the point when you know what offset value to put into the document you know what all the correct times should be, don’t you?
>> 
>> If yes, you can already solve this problem with TTML. 
>> If no, how do you assign the offset value?
>> 
>> Am I missing something extra?
>> 
>> Kind regards,
>> 
>> Nigel
>> 
>> 
>> From: Courtney Kennedy <ckennedy@apple.com>
>> Date: Friday, 15 August 2014 16:31
>> To: Nigel Megitt <nigel.megitt@bbc.co.uk>
>> Cc: Timed Text Working Group <public-tt@w3.org>
>> Subject: 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]
>> 
>> 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>
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>