Re: Issue 29 - SMPTE tests

Sean and all-

The SMPTE timebase was meant for providing labels 
on blocks of text such that one could translate 
from US and DVB captioning into and out of DFXP 
without loss of timing information and sync.  It 
was not meant as a particularly useful of 
friendly authoring timebase.  That is, if the 
block of captions were encoding on frame X of a 
clip, in an automated translation into DFXP the 
12M fields were tagged as such in DFXP, and then 
when it was converted back to captions and 
re-inserted into the video clip, the captions 
could be restored to the precise video frame they came from.

The drop/non-drop comes from fields in the SMPTE 
12M timecode - again more to preserve the 
transformation than enable a useful authoring 
timebase.   It does not infer more than that.

DFXP native authoring in SMPTE timebase would be 
odd.  Anyone natively authoring in DFXP would 
naturally use the media clock.  When authored in 
the media timebase, a conversion downstream into 
a 12M television caption system would be a best 
effort conversion of exactly which video frame to 
put the captions on.  A transformation would 
occasionally be "off" by one frame.

Also, there is no such thing in real life as 
"NTSC 30". "NTSC" is only 29.97, by 
definition.  I think the fields and semantics 
need to remain as they were defined.  However, 
perhaps more clarifications are needed about the 
purpose for this timebase and its limitations?

Also since DFXP was drafted, 12M has been revised 
to support more values.  Although backwards 
compatible, someone should probably see if the 
new 12M is supported fully in DFXP and update the reference as appropriate.

Regarding Sync007, I don't offhand recall 
discussions about transformations in and out of 
the MPEG-2 TS time model, but this seems like a 
good example of how it could work.

Missing are examples of the "clock" timebase, 
which could theoretically be used to map into and 
out of the popular NTP/RTP based systems.

Regards,

         Mike

At 04:10 PM 4/11/2009 +0100, Sean Hayes wrote:
>In respect of issue 29 regarding SMPTE mode.
>
>Rather than try and work from David’s tests, I 
>took an approach of starting from scratch. Short 
>summary, new tests are attached; to replace existing tests:
>frameRate00n
>frameRateMultiplier00n
>smpteMode00n
>subFrameRate00n
>tickRate00n
>timeBase00n
>
>
>The longer discussion now follows:
>
>Rather than try and test each attribute 
>individually, these tests are designed to work 
>for the range of expected scenarios, as the 
>attributes are not fully independent.
>
>The following SMPTE time codes are in standard use:
>30fps
>29.97 fps drop frame
>29.97 fps non-drop frame
>25 fps (EBU derived from SMPTE).
>24 fps and 23.96 (IVTC) for film work.
>
>I have created one test for each of these 6. The 
>mechanics of clockMode, smpteMode, frameRate and 
>frameRateMultiplier are somewhat confusing and 
>we should probably have simply defined the 6 
>modes as an enumeration; as it means that 
>certain things we can express in Timed text 
>don’t seem to make much sense in a SMPTE world, 
>or at least are not adequately documented.
>For example:
>frameRate=”30” smpteMode=”NTSCDrop” – is this to 
>be interpreted as 29.97 drop frame or an error?
>
>The tickrate and tick rate multiplier mechanics 
>are perhaps useful in the media clock mode, 
>where you are trying to match an unknown video 
>rate; and clock mode expressions don’t make much 
>sense without knowing the exact frame rate, 
>however in such a case milliseconds or ticks may be more useful.
>
>Sync007 is an example of how one might sync to 
>MPEG-2 PCR using ticks. I’m not sure this is 
>what tick rate was intended for, but it’s an 
>important use case which otherwise might be  missed.
>
>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
>
>Thoughts?
>
>Sean Hayes
>Media Accessibility Strategist
>Accessibility Business Unit
>Microsoft
>