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

RE: ISSUE-346: Need ttp:mediaDuration parameter [TTML2]

From: John Birch <John.Birch@screensystems.tv>
Date: Thu, 25 Sep 2014 13:56:30 +0000
To: Nigel Megitt <nigel.megitt@bbc.co.uk>, Timed Text Working Group <public-tt@w3.org>
Message-ID: <0981DC6F684DE44FBE8E2602C456E8AB016C0DB1DB@SS-IP-EXMB-01.screensystems.tv>
Yes, I believe you have correctly understood what I was trying to say.

Yes point 2 is *implicitly* occurring when using SMPTE discontinuous... but is impossible with media timebase.

A SMPTE discontinuous document does not need re-work if a slate is removed, providing the timecodes in the original (truncated) media are unaltered and can be used as markers. In fact this applies even if internal sections of the media are removed.

A media timebase document will require ALL time values to be adjusted if the slate is removed...

I am uncertain as to where the "ORIGIN(document) in the document's timebase is defined as being coincident with BEGIN(media) in the media's timebase" rule comes from - is that SMIL or TTML1 ?

I would suggest that an (optional!) offset to apply to this (currently coincident) relationship would be a 'nice to have'. Such an offset might also have application in easily facilitating alignment of captions and subtitles to video in playback (perhaps to compensate for rendering latencies) - it being easier to change just one value to compensate rather than all timing values in a document.

If this is deemed out of scope as an attribute then a) to my mind the same applies to media begin and end b) a non normative note that processors might consider the 'coincident' relationship to be subject to external adjustment might be justifiable.

Best regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv | www.screensystems.tv | https://twitter.com/screensystems


Visit us at
SMPTE Annual Technical Conference, Loews Hollywood Hotel, Stand 107, October 21-23
Languages & the Media, Hotel Radission Blu, Berlin, November 5-7

P Before printing, think about the environment-----Original Message-----
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 25 September 2014 11:42
To: John Birch; Timed Text Working Group
Subject: Re: ISSUE-346: Need ttp:mediaDuration parameter [TTML2]

Thanks John,

So to be even more coarse, what is needed is to temporally position subtitles in a subtitle document against media where the beginning of the period for which subtitles may apply doesn't fall at the beginning of the media, but may fall some time later to skip past any slate etc.

Have I understood your last point correctly as follows?:

1. Using timebase="media" all document times are relative to the start of media, i.e. ORIGIN(document) in the document's timebase is defined as being coincident with BEGIN(media) in the media's timebase.

2. To translate from document time to media time one must add an offset value that positions ORIGIN(document) somewhere on the media's timebase.

If I've got this right, then the next question is: should this offset be defined within a TTML2 document or externally? It seems to me that
ORIGIN(document) is well defined but that BEGIN(media) is out of scope of TTML and must be defined externally. Other views are available!


Kind regards,

Nigel



On 25/09/2014 11:29, "John Birch" <John.Birch@screensystems.tv> wrote:

>Thanks, good info there...
>
>RE: I'm interested in the requirement/use case though: when you say
>"allows time values within a document to be 'offset' relative to the
>start of associated media", what calculations are you envisaging that a
>processor should perform, exactly, and in what circumstances might they
>be useful?
>
>I have in mind the easy re-purposing of subtitle documents that were
>originally created to match 'tape' style video clips (i.e. clips that
>include a pre-roll slate). This is still very common for distribution
>of media, e.g. commercials.
>Subtitle documents are currently created against the full media
>duration (and in effect use SMPTE timecode in discontinuous modality to
>achieve correct subtitle synchronisation) - note these are not
>necessarily TTML format subtitle documents.
>
>Use of an offsets for timing from the beginning of media would allow
>easy removal of the pre-roll (which is typical when such media migrate
>to a media file representation) by simply changing one value.
>
>Admittedly a 'fringe' use case....
>
>I have a tendency to view SMPTE / discontinuous as legacy, and media
>time as file-based... and of course using media-time timing requires
>more information about the related media timing.
>For me, for media time documents) moving to a completely offset based
>approach (i.e. from start of media) is more logical than establishing a
>specific range of timecode values within a continuous media timebase
>(by using start and end or start and duration values). YMMV.
>[Additionally, as discussed briefly at EBU F2F I believe there is
>utility in a nested timing model with 'soft / sticky' boundaries. This
>for me would all be 'offset' based.]
>
>Best,
>John
>
>John Birch | Strategic Partnerships Manager | Screen Main Line : +44
>1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile : +44
>7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv |
>www.screensystems.tv | https://twitter.com/screensystems

>
>Visit us at
>SMPTE Annual Technical Conference, Loews Hollywood Hotel, Stand 107,
>October 21-23 Languages & the Media, Hotel Radission Blu, Berlin,
>November 5-7
>
>P Before printing, think about the environment-----Original
>Message-----
>From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>Sent: 25 September 2014 11:11
>To: John Birch; Timed Text Working Group
>Subject: Re: ISSUE-346: Need ttp:mediaDuration parameter [TTML2]
>
>No processing requirements that use ttp:mediaDuration are stated either
>in the ttp:mediaDuration section at [1]  or anywhere else in the
>document, right now. Taken in isolation this would suggest that it is
>metadata and should not be in the parameter namespace, however I think
>it is merely a reflection of work in progress.
>
>[1]
>https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#para

>met
>e
>r-attribute-mediaDuration
>
>My expectation is that, regardless of how they are calculated, the
>effective media begin time and media end time will be used to define
>the temporal period within which any ISDs should be created for display
>alongside the related media, and that mediaDuration would therefore be
>referenced in the Intermediate Synchronic Document Construction process
>at [2]. There's an editorial note on that section - possibly when that
>note has been resolved into spec text this will become clearer.
>
>[2]
>https://dvcs.w3.org/hg/ttml/raw-file/default/ttml2/spec/ttml2.html#sema

>nti
>c
>s-region-layout-step-1
>
>I've proposed in the "Issue-270 and Issue-335" thread that starts at
>[3] that this period might better be defined explicitly in terms of
>mediaBegin and mediaEnd parameters expressed in the time base of the
>document. If mediaDuration is needed and the time base and marker modes
>permit time calculations (e.g. it is not SMPTE - discontinuous) then it
>can be calculated as (mediaEnd - mediaBegin).
>
>[3] http://lists.w3.org/Archives/Public/public-tt/2014Sep/0065.html

>
>
>I'm interested in the requirement/use case though: when you say "allows
>time values within a document to be 'offset' relative to the start of
>associated media", what calculations are you envisaging that a
>processor should perform, exactly, and in what circumstances might they be useful?
>
>
>Kind regards,
>
>Nigel
>
>
>On 25/09/2014 10:38, "John Birch" <John.Birch@screensystems.tv> wrote:
>
>>I am uncertain about the 'requirement' for a duration parameter?
>>What is the current situation... does TTML1 work as if the media
>>duration is 'indefinite' ?
>>In which case what additional benefit does having a defined duration
>>bring?
>>
>>Of far more importance (IMHO) is a media start value - that allows
>>time values within a document to be 'offset' relative to the start of
>>associated media.
>>
>>Best regards,
>>John
>>
>>John Birch | Strategic Partnerships Manager | Screen Main Line : +44
>>1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532 Mobile : +44
>>7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv |
>>www.screensystems.tv | https://twitter.com/screensystems

>>
>>Visit us at
>>SMPTE Annual Technical Conference, Loews Hollywood Hotel, Stand 107,
>>October 21-23 Languages & the Media, Hotel Radission Blu, Berlin,
>>November 5-7
>>
>>P Before printing, think about the environment-----Original
>>Message-----
>>From: Timed Text Working Group Issue Tracker
>>[mailto:sysbot+tracker@w3.org]
>>Sent: 21 September 2014 13:35
>>To: public-tt@w3.org
>>Subject: ISSUE-346: Need ttp:mediaDuration parameter [TTML2]
>>
>>ISSUE-346: Need ttp:mediaDuration parameter [TTML2]
>>
>>http://www.w3.org/AudioVideo/TT/tracker/issues/346

>>
>>Raised by: Glenn Adams
>>On product: TTML2
>>
>>In order to perform ISD processing, it is necessary to know the
>>duration of root external extent. When associate with a related media
>>object, this is the simple duration of the related media object. If
>>this is known at authoring time, then it is an important parameter
>>that should be specified. I propose defining a ttp:mediaDuration
>>parameter attribute that takes either an offset-time form of a time
>>expression or the keyword "indefinite", where the latter is used (or
>>implied) when no related media object exists or its simple duration is
>>unknown or indefinite. If this parameter is not specified, then it
>>would be treated as if indefinite were specified.
>>
>>
>>
>>
>>This message may contain confidential and/or privileged information.
>>If you are not the intended recipient you must not use, copy, disclose
>>or take any action based on this message or any information herein. If
>>you have received this message in error, please advise the sender
>>immediately by reply e-mail and delete this message. Thank you for
>>your cooperation.
>>Screen Subtitling Systems Ltd. Registered in England No. 2596832.
>>Registered Office: The Old Rectory, Claydon Church Lane, Claydon,
>>Ipswich, Suffolk, IP6 0EQ
>
>
>This message may contain confidential and/or privileged information. If
>you are not the intended recipient you must not use, copy, disclose or
>take any action based on this message or any information herein. If you
>have received this message in error, please advise the sender
>immediately by reply e-mail and delete this message. Thank you for your cooperation.
>Screen Subtitling Systems Ltd. Registered in England No. 2596832.
>Registered Office: The Old Rectory, Claydon Church Lane, Claydon,
>Ipswich, Suffolk, IP6 0EQ


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
Received on Thursday, 25 September 2014 13:57:05 UTC

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