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

Received on Sunday, 12 April 2009 13:26:57 UTC