[Lumiera] Which timecode formats do we want?

Brian Rytel tesla.pictures at gmail.com
Thu Jul 8 11:23:12 CEST 2010


>
> Regarding timecodes:
> If I'm not mistaken, all timecode formats can losslessly and trivially
> be converted from/to framecounts, right? So would it make sense to support
> anything but framecounts internally?
>
Not really. 30 DF counts 30 frames a second, but then throws some bits out
from time to time to keep up with the fact that when broadcast 30fps
actually runs at .001 times slower.

You can't "losslessly and trivially" convert say 30 DF TC into 24fps. What
you do is take the 29.97 signal and convert it to 23.976 and the speed that
up to be 24p.


Wikipedia's explanation:

Drop frame timecode dates to a compromise invented when color
NTSC<http://en.wikipedia.org/wiki/NTSC>video was invented. The NTSC
re-designers wanted to retain compatibility
with existing monochrome TVs. Technically, the 3.58 MHz (actually 315/88 MHz
= 3.57954545 MHz) color subcarrier would absorb common-phase noise from the
harmonics of the line scan frequency. Rather than adjusting the audio or
chroma subcarriers, they adjusted *everything else*, including the *frame
rate*, which was set to 30/1.001 Hz.

This meant that an "hour of timecode" at a nominal frame rate of 30 frame/s
was longer than an hour of wall-clock time by 3.59 seconds, leading to an
error of almost a minute and a half over a day. This caused people to make
unnecessary mistakes in broadcasting studios and precious advertising
dollars could be lost.[*citation
needed<http://en.wikipedia.org/wiki/Wikipedia:Citation_needed>
*]

To correct this, drop frame SMPTE timecode was invented. In spite of what
the name implies, NO video frames are dropped (skipped) using drop-frame
timecode. What's actually being dropped are some of the timecode "labels".
In order to make an hour of timecode match an hour on the clock, drop-frame
timecode drops frame numbers 0 and 1 of the first second of every minute,
except when the number of minutes is divisible by ten (i.e. when minutes mod
10 equals zero). This achieves an "easy-to-track" drop frame rate of 18
frames each ten minutes (18,000 frames @ 30frame/s) and almost perfectly
compensates for the difference in rate, leaving a residual timing error of
roughly 86.4 milliseconds per day, an error of only 1.0 ppm.

i.e. - Drop frame TC drops two frames every minute, except every tenth
minute, achieving 29.97frame/s.

Drop frame is usually represented with a semi-colon (;) or period (.)
between the seconds and frames whereas non-drop retains the colon (:). The
period is usually used on VTRs and other devices that don't have the ability
to display a semi-colon.
Example: drop frame = "HH;MM;SS;FF" or "HH.MM.SS.FF", non-drop frame =
"HH:MM:SS:FF"

B.J.M.R.


On Thu, Jul 8, 2010 at 2:14 AM, Burkhard Plaum
<plaum at ipf.uni-stuttgart.de>wrote:

> Hi,
>
> Florian Faber schrieb:
>
>  On 07/08/10 10:47, Edouard Chalaron wrote:
>>
>>  Thanks for the very constructive comment
>>>
>>
>> Well, it is my believe that old crap has to be abandoned at a certain
>> point. Supporting anything else but square pixels and integer frame
>> rates is just a waste of time. We have to move on, people.
>>
>
> Yea, then you can transcode all DVD/DVB/DV streams with lossy scaling and
> framerate conversion (if in NTSC land) before loading them into an editor.
>
> Also, neither nonsquare pixels nor rational framerate take much time
> to support if it's done right.
>
>
>
> Burkhard
>
> _______________________________________________
> Lumiera mailing list
> Lumiera at lists.lumiera.org
> http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
> http://lumiera.org/donations.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lumiera.org/pipermail/lumiera/attachments/20100708/6ab24637/attachment.htm>


More information about the Lumiera mailing list