Re: Issue 29 - SMPTE tests

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.
> 
> 
> 
> 
>