- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Sun, 12 Apr 2009 21:26:10 +0800
- To: Sean Hayes <Sean.Hayes@microsoft.com>, Public TTWG List <public-tt@w3.org>
- Message-ID: <C6080CF2.A2D3%gadams@xfsi.com>
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