- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Sun, 12 Apr 2009 15:43:19 +0800
- To: Sean Hayes <Sean.Hayes@microsoft.com>, Public TTWG List <public-tt@w3.org>
- Message-ID: <C607BC97.A2CB%gadams@xfsi.com>
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 07:44:15 UTC