[Lumiera] Which timecode formats do we want?

Brian Rytel tesla.pictures at gmail.com
Thu Jul 8 11:33:34 CEST 2010

On the ticket:

> During in-place editing, the separators (colons etc.) should be enforced,
> so that the user only edits the HH:MM:SS:FF values.
1) Colons, semi-colons (and for music decimals) can't be static as they need
to reflect the timecode structure they use.
2) Most NLE's enter from the last frame holder (ie the right-most #)
So if I type 5 it fills in the lowest hour set by the user ##:00:00:05, if I
type 4005 then you get ##:00:40:05
With the exception of frames, the numbers are fixed base, mins & secs are
60, hours 24.
Most critically manual TC entry should start with on the right and 'bump'
the values to the left as new ones are entered.

On Thu, Jul 8, 2010 at 2:23 AM, Brian Rytel <tesla.pictures at gmail.com>wrote:

> 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 =
> 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/431de910/attachment.htm>

More information about the Lumiera mailing list