Re: Issue 29 - SMPTE tests

Notwithstanding all that I said previously, I would not object to changing
the attribute name to tts:dropMode.

G.

On 4/12/09 10:01 PM, "Glenn Adams" <gadams@xfsi.com> wrote:

> 
> Since drop frame mode originates from (and is commonly associated with) SMPTE
> frame timing, then smpteMode is a reasonable choice, and no change seems
> necessary. I just reviewed SMPTE 12M (1995), and at that publication, only
> three systems were defined: 24, 25, and 30 frame systems. However, since frame
> rate is (in most video encodings, such as MPEG-[124]) not fixed to these
> values, and since ³SMPTE frame² timing is nevertheless utilized with such
> video encodings irrespective of whether they adhere to the strict set of {24,
> 25, 30}, and since, moreover, frame drop counting is still applied to such
> systems, then it is again appropriate to use the name we have chosen.
> 
> SMPTE 12M (1995) itself defines a ³Linear Time Code² (LTC) application, where
> each 80-bit LTC code word includes time address of frame, flag bits, binary
> groups, biphase mark polarity bit, and a synchronization word, where the
> following bits apply (I list only the subset that pertains to DFXP here):
> 
> Bits
> 
> 0-3   units of frames
> 8-9   tens of frames
> 10    drop flag
> 16-19 units of seconds
> 24-26 tens of seconds
> 32-35 units of minutes
> 40-42 tens of minutes
> 48-51 units of hours
> 56-57 tens of hours
> 
> Even though 12M does state ³Not all flag bits are used by all systems², there
> is no prohibition on the creation or use of some new or non-standard system
> that would use the drop frame flag with other frame rates. Note also that
> SMPTE 258M (1993) defines an ASCII format for SMPTE time codes which permits
> independent values of drop flag regardless of frame rate  (see attached
> excerpt).
> 
> G.
> 
> 
> On 4/12/09 9:35 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
> 
>> OK, if it has a defined meaning that we define but no meaning in SMPTE 12M,
>> then we shouldn¹t use the word smpte in the attribute name; call it dropMode
>> or some such.
>>  
>> 
>> Sean Hayes
>> Media Accessibility Strategist
>> Accessibility Business Unit
>> Microsoft
>>  
>> Office:  +44 118 909 5867,
>> Mobile: +44 7875 091385
>>  
>> 
>> From: Glenn A. Adams [mailto:gadams@xfsi.com]
>> Sent: 12 April 2009 2:26 PM
>> To: Sean Hayes; Public TTWG List
>> Subject: Re: Issue 29 - SMPTE tests
>>  
>> But it does indeed have a well defined meaning, whether it is used anywhere
>> at all (in a deployed system) is not relevant. The definition of
>> ttp:smpteMode clearly defines what dropNTSC, dropPAL, and noDrop mean
>> irrespective of whether they are used in any deployed television system. In
>> particular, you example below (ttp:frameRate=²30² ttp:smpteMode=²dropNTSC²)
>> means that frames are counted as follows:
>> 
>> If second == 0 and minute is not one of { 0, 10, 20, 30, 40, 50 }, then
>> frames in that second are counted from [2 ... 29]; otherwise, frames are
>> counted [0 ... 29].
>> 
>> So it is well defined and does have a meaning. Accordingly, no change to the
>> spec is required.
>> 
>> G.
>> 
>> On 4/12/09 9:20 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
>> True. But what I meant was timebase=²smpte² frameRate=²30²
>> smpteMode=²NTSCDrop², sorry for the confusion. There is afaik no such thing
>> as drop @ 30fps, so unless we mean 29.97 (in which case the frameRate setting
>> is superfluous and confusing), then this has no meaning.
>>  
>> I¹m generally in favor of generality, (and even being able to write things
>> that have no meaning, as long as we are clear that this is the case). I¹m no
>> expert on SMPTE 12M, and I don¹t have the spec to check; but I¹m not sure it
>> is a continuous parameter space.
>>  
>> I will endeavour to find out what 12M actually allows.
>>  
>> 
>> Sean Hayes
>> Media Accessibility Strategist
>> Accessibility Business Unit
>> Microsoft
>>  
>> Office:  +44 118 909 5867,
>> Mobile: +44 7875 091385
>> 
>> 
>> From: Glenn A. Adams [mailto:gadams@xfsi.com]
>> Sent: 12 April 2009 8:43 AM
>> To: Sean Hayes; Public TTWG List
>> Subject: Re: Issue 29 - SMPTE tests
>> 
>> 
>> On 4/11/09 11:10 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
>> 
>> [SH] frameRate=²30² smpteMode=²NTSCDrop² ­ is this to be interpreted as 29.97
>> drop frame or an error?
>> 
>> [GA] I wouldn¹t interpret as an error, but rather as warranting reporing a
>> warning (in a hypothetical Œdfxplint¹ program), for example:
>> 
>> WARNING: ttp:smpteMode parameter is ignored unless the value of ttp:timeBase
>> is specified as ³smpte²
>> 
>> The current text of Section 6.2.8 clearly states this:
>> If the time base, defined by 6.2.11 ttp:timeBase, is designated as smpte,
>> then this parameter applies as follows: ...
>> 
>> Also, the current text of Section 6.2.11 states:
>> If the time base is designated as smpte, then ... In this case, the value of
>> the ttp:markerMode and ttp:smpteMode parameters apply, as defined by 6.2.5
>> ttp:markerMode and 6.2.8 ttp:smpteMode, respectively.
>> 
>> [SH] With these tests, we can consider Issue 29 closed, however I¹m wondering
>> whether we ought to define that tickRate and tickRateMultiplier are only
>> defined in clock mode=²media², and that for clockmode=²smpte² the smpteMode
>> attribute only is defined, with the values :
>> 
>> NTSC_30
>> NTSC_29.97_drop
>> NTSC_29.97_non_drop
>> PAL_25
>> Film_24 
>> IVTC_23.96
>> [GA] I don¹t like enumerations of aggregrate parameter points in a
>> multi-dimensional parameter space, at least for operational parameters, as
>> there is always a corner case you haven¹t accounted for, plus it makes spec
>> maintenance more difficult. However, I would not object to defining these as
>> enumerated (and labeled) optional features in Appendix E, where each
>> definition would specify the set of ttp parameter values for which support is
>> required if the feature is supported.
>> 
>> [GA] Regarding the semantics of ttp:tickRate, it is presently defined as
>> related to ³media time² as follows:
>> The ttp:tickRate attribute is used to specify the tick rate of a related
>> media object or the intrinsic tick rate of content of a document instance in
>> case it is intended to function as an independent media object.
>> 
>> We don¹t discusss in the text whether the use of the Œt¹ metric would be
>> permitted when:
>> * ttp:timeBase=²clock²
>> * ttp:timeBase=²smpte²
>> 
>> It seems to me, that the tick metric is well defined for (1) timeBase=²clock²
>> and (2) timeBase=²smpte² and markerMode=²continuous². If there is no
>> objection, then propose that we elaborate these two cases in the text.
>> 
>> 
>> 
>> 
>> 
>