Re: Issue 29 - SMPTE tests

Interestingly there are circumstances where captions are created against 'as run time'... I.e. The captions or subtitles are 'timed' against the playing time of the video.... 1 second per sec (regardless of the real timebase of the media).

These captions are either 're-striped' by automatic sw conversion of the timing into SMPTE timecode before transmission or synchronised against a clock started when the video starts playing. NB I am discussing tv use cases here.

FYI The former use case is to allow captioning to occur before framerate conversion... the latter is used when no timecode is present in the source video (for example a contribution channel that is being subtitled (think of CNN in a foreign country) 

In one instance I am aware of, subtitles are synchronised against station time!! the caption file being 're-striped' just before transmission to match the air time of the program!!

These may not be cases that DFXP needs to cover, but might fall into the 'clock' timebase described by Michael?

Regards,
John

Sent by Blackberry

John Birch | Screen Subtitling Systems Ltd | Strategic Partnerships Manager
Main Line : +44 (0)1473 831700 | Ext : 270 | Office :  
Mobile: +44 (0)7919 558380 | Fax: +44 (0)1473 830078
john.birch@screen.subtitling.com | www.screen.subtitling.com
The Old Rectory, Claydon Church Lane, Claydon,Ipswich,IP6 0EQ,United Kingdom


See us at NAB 2009, Las Vegas, 20th - 23rd April, Hall S4 Stand SU 10009


Before Printing, think about the environment

----- Original Message -----
From: public-tt-request@w3.org <public-tt-request@w3.org>
To: Public TTWG List <public-tt@w3.org>
Sent: Sun Apr 12 17:40:50 2009
Subject: 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
  
 



This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ