RE: Initial value of ttp:markerMode

Right.  To be clear, I wasn’t taking a position on the proposal; just noting the “common” properties of SMPTE timecode.

 

To the proposal, it creates a backwards incompatibility with only a perceptual benefit.  I think this would be better addressed with explanatory text in the Recommendation.

 

Regards,

 

                Mike

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Thursday, May 24, 2012 6:55 AM
To: Michael A Dolan
Cc: public-tt@w3.org
Subject: Re: Initial value of ttp:markerMode

 

as TTML is defined, smpte time base is always marker based, whether the markers are continuous or not;

 

we had defined 'continuous' irrespective of the value of the first marker, and irrespective of use of drop frame, since neither of these result in uncomputable discontinuities that prevent calculating duration; that is, duration is computable with drop frame and arbitrary start time if you know the drop frame mode and have read the first marker;

 

on the other hand, if post production edits result in the insertion or deletion of material that introduces other types of non-linearity, e.g., a jump forward or backward of time codes, or a different rate of time codes with respect to media time (PTS), then those edits would constitute discontinuous mode;

On Thu, May 24, 2012 at 7:47 AM, Michael A Dolan <mdolan@newtbt.com> wrote:

SMPTE timecode is often discontinuous due to post production edits, and (in the US for non-integer framerates) always dropframe mode, and common practice is to start the first frame of the media at 1 hour (not zero), thus making presentation time undefined.  So, SMPTE timecode is nearly always marker mode.  The special case is actually when it is usable as a non-marker timebase.

 

Regards,

 

                Mike

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Wednesday, May 23, 2012 11:45 PM
To: Andreas Tai
Cc: public-tt@w3.org
Subject: Re: Initial value of ttp:markerMode

 

I have never thought that markerMode was intended to primarily express discontinuous markers. When we created this property, the discontinuous mode was thought to be an exception rather than the default. So without considerable further discussion, I would hesitate to accept this proposal.

On Thu, May 24, 2012 at 12:27 AM, Andreas Tai <tai@irt.de> wrote:

I would like to propose to change the initial value of markerMode from contineous to discontineous. As seen in discussions the intended meaning of markermode aligns more with the expressed meaning of markermode "discontineous".

What do you think?

Best regards,

Andreas

-- 
------------------------------------------------
Andreas Tai
Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
Floriansmuehlstrasse 60, D-80939 Munich, Germany

Phone: +49 89 32399-389 <tel:%2B49%2089%2032399-389>  | Fax: +49 89 32399-200 <tel:%2B49%2089%2032399-200> 
http: www.irt.de | Email: tai@irt.de
------------------------------------------------

registration court&   managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------