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

Sorry, yes... I was using the wrong terminology in there...

For media timebase (continuous) that should be ORIGIN [Document] = BEGIN[Media].

And for SMPTE timebase continuous then Origin [Document] = Begin [Media] would work if timevalues in the document are expressed as SMPTE12M. This is basically media timebase but just using times expressed in a SMPTE12M format.

The continuous flag permits calculations, so it can have an impact on a how a processor makes a presentation implementation (e.g. using a duration based timer)... So yes, I accept it may have utility... But a discontinuous implementation could handle a continuous document equally... It's just a special case of discontinuity (I.e there are none).

So I was wrong! :-) but I think we are actually on the same page? I need more thought before commenting on your table though...

Best regards,
John


From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: Friday, September 26, 2014 05:11 PM
To: John Birch; Glenn Adams <glenn@skynav.com>
Cc: Timed Text Working Group <public-tt@w3.org>
Subject: Re: ISSUE-346: Need ttp:mediaDuration parameter [TTML2]

From: John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> Date: Friday, 26 September 2014 18:00
Ok, I’ve read and think I understand the draft – thanks for the link.
I understand the need to formalise ISD production.

This is how it seems to me….

For media timebase (which must be continuous) I can see that BEGIN [Document] = BEGIN[Media]. That’s an easy one! ;-)

Really? That means that you have no way of expressing "the first appearance of text is 5 seconds into the media" because you've equated BEGIN(document) = 5s with BEGIN(media) = 0s. The only way I can see to express that is to say ORIGIN(document) = BEGIN(media), so that the first <p begin="5s"> really means 5s into the media.


For SMPTE timebase continuous then BEGIN [Document] = BEGIN[Media] would work if timevalues in the document are expressed as SMPTE12M and if the media context emits SMPTE12M synchronisation events that start at 0.
This is basically media timebase but just using times expressed in a SMPTE12M format.

I've been expressing this as ORIGIN(document) = ORIGIN(media) = BEGIN(media).

For SMPTE timebase discontinuous the media context emits synchronisation events for every frame (extracted from the media). There is no ‘equivalence’ between media begin and document begin, however the document becomes active at BEGIN [media] and inactive at END [media].

Agreed. And since the root temporal extent is the interval during which a document is active, that's also defined the root temporal extent.

In this case the SMPTE12m format synchronisation events emitted into the document may or may not start at 0, and may or may not be contiguous. In effect SMPTE timebase continuous could be handled as a special case of a discontinuous implementation.

The existence of SMPTE timecode within the media is only of relevance to SMPTE timebase discontinuous.

I don't follow this. If you know that the media's timecode is continuous then it seems reasonable to be able to use that information.


For clock mode the media object is irrelevant.

Where am I going wrong? ;-)

Please could you check that your interpretation of ORIGIN and BEGIN match what we've been using in this and the related threads? (or maybe I've got it wrong :-( )

Kind regards,

Nigel


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<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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

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<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 25 September 2014 17:13
To: John Birch
Cc: Timed Text Working Group
Subject: Re: ISSUE-346: Need ttp:mediaDuration parameter [TTML2]



On Thu, Sep 25, 2014 at 8:36 AM, John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> wrote:
I cannot see how mediaduration can always be known… it certainly cannot be ‘a priori’ knowledge in the streaming live video scenario.

Please read the drafted text at [1].

[1] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#parameter-attribute-mediaDuration


Consequently I do not see how TTML to ISD conversion can be normatively dependent on a parameter that is potentially unavailable.

It just means that in such a case, it a duration must be approximated at some point in time or that everything must be explicitly timed (i.e., no reliance on indefinite duration containers) or that conversion is not possible.


Am I misunderstanding and it is proposed that media duration is mandatory? (only when using media timebase?)

No. Read the draft text.


Re: SMIL assumes they are relative to beginning of related media.

Whilst I am certainly no expert on SMIL, I was under the impression that SMIL supports the concept of a sync-base that allows the origin point of timed events to be offset from a specific time point in the ‘host document’.

True, but we didn't support in TTML the full generality of SMIL timing options. Let's just say that, at least for media time base, it is assumed by TTML1 that document times are related to BEGIN(media), not ORIGIN(media). This is no different from assuming that the origin of the root container extent (in TTML1) is aligned with the origin of the related media object (video).

TTML does not explicitly form a timing relationship with a related media within the TTML document, that relationship is established by normative prose in the specification – and thus could be elaborated upon.

Let's just say that in TTML1 this relationship is only discussed in the Note in Appendix N.2, but it has been widely assumed and used in other contexts, e.g., VTT, translation to HTML, etc.:

The above formalisms assumes that the Root Temporal Extent corresponds with the beginning of a related media object. If this assumption doesn't hold, then an additional offset that accounts for the difference may be introduced when computing media time M.


Re: However, apparently SMPTE time base authors have been using the origin of the time line of related media.

I am not sure what you mean by ‘origin of the time line of related media’. The use of SMPTE timebase with ‘continuous’ is (rightly IMHO) deprecated.

Granted that for discontinuous mode my comment doesn't apply. Consider my comment to apply only to smpte continuous mode *and* in the case that a discontinuous mode document has been converted to smpte continuous or media time base.

To effectively use SMPTE timebase you must be in discontinuous mode to engage the *reading of timecode values from the frames of the related media* - rather than use the play time of the related media – even if expressed as SMPTE12M. Timecode is and always has been a labelling scheme (that can – if certain constraints are met – also be used to calculate durations).

Yes, this is true for "SMPTE timecode" usage in the normal discontinuous based interpretation, but not for SMIL clock-time expressions.

Since these constraints cannot be guaranteed in the TTML context (i.e. it has no knowledge of external media timecode contiguity) then ‘discontinuous’ must be used.

I don't want to turn this thread into a discussion of the utility of smpte continuous mode, but I should say that I don't discount its utility as you appear to do.

Further, if continuous was used with smpte timebase in a TTML document, then the time values in the TTML would have to be relative to the first frame of the media – even while being expressed in SMPTE12M… and consequently would typically be significantly offset from the timecode labels that might exist within the media itself (e.g. by 10 hours or 3 hours etc.).

I am not making that assumption: that time values in a smpte continuous mode TTML document are relative to the first frame of the media. In fact, I'm assuming that there may be an arbitrary offset between the two, just as I'm assuming there may be an arbitrary (positive or negative) offset in the media time base scenario.

Yet further, those values would also have to take into account a potentially variable length slate that might be added, extended or truncated during the processing of media files, necessitating a change of the TTML document every time the related media object was processed (which is of course undesirable). This is of course all very broadcast media centric – but of course that is the domain of smpte timecode!

I'm not following this, since I don't know the meaning of "variable length slate".


Since SMPTE must be discontinuous,

Nope, we have smpte continuous mode in TTML1 and just today decided to keep it in TTML2. [1]

[1] http://www.w3.org/AudioVideo/TT/tracker/issues/349


the ‘origin of a timeline’ is irrelevant? (as the Document Processing Context emits labelled synchronisation events).

It is definitely not irrelevant in media time base, in smpte continuous mode, or in conversion of smpte discontinuous mode to media or smpte continuous time base.


Best regards,
John



John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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

From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: 25 September 2014 14:15
To: John Birch
Cc: Timed Text Working Group
Subject: Re: ISSUE-346: Need ttp:mediaDuration parameter [TTML2]



On Thu, Sep 25, 2014 at 3:38 AM, John Birch <John.Birch@screensystems.tv<mailto: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?

The TTML to ISD conversion process will normatively use this parameter. It is also used by the proposed CP5 for conversion to HTML.


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.

We have an interesting issue here: what are authors using for the origin of document times. SMIL assumes they are relative to beginning of related media. However, apparently SMPTE time base authors have been using the origin of the time line of related meda. But this is unrelated to ttp:mediaDuration.


Best regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://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<mailto:sysbot%2Btracker@w3.org>]
Sent: 21 September 2014 13:35
To: public-tt@w3.org<mailto: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
  ­­