[Ffmpeg-devel] [PATCH] remove drop timecode flag

[Trent Piepho]

On Sun, 15 Apr 2007, Roman Shaposhnik wrote:
>   Trent, would you be able to help me out with understanding the
> following, please: here's my problem -- we have a physical objective
> process of capturing frames, in the NTSC world each frame lasts
> exactly 1001/30000 seconds (and again -- this is an objective precise
> number). So, given these facts it'll be fair to say that:
[...]
> BUT when we turn to the frame #1019, which occupies
> an interval of:
>      [1019*1001/30000; 1020*1001/30000) == [34.0006; 34.03)
> and is SUPPOSED to be recorded during the 34th second,
> it still has a timecode of 00:00:33:29 !!!!!!
>
>    Now, from that point on -- timecode LIES to us. Why ?!?!?


I think the key thing to understand about timecode is that it's not for
timing.  It's not used to control playback speed, or synchronize audio, or
control how much time something takes to play.  It is not used at all for
decoding or playback.  It is used externally for editing and cueing.

The name timecode is confusing.  It would be better to call it "SMPTE Frame
ID".

We could give frame 1019 the frame ID "0x3BF", but this would be confusing
to humans.  Maybe the Romans would have used frame ID "MXIX".  Well,
someone at SMPTE decided to use the frame ID "00:00:33:29".  The frame ID
is just an ID.  It doesn't tell us what point in time the frame occupied.

It's like saying each calendar day is 1/365th of a year.  So after 365 days
the Earth should be in the same point in its orbit as it started at.  But
the Earth is not in the same place in its orbit on 01-01-2007 as it is was
01-01-2006!  Our calendar lied to us!  No, not really.  The calendar counts
days, the Earth's rotations.  It tells us that 365 days elapsed between
01-01-2006 and 01-01-2007, and that's right.

The SMPTE frame ID "drop-frame" works the same way as the Gregorian
calendar's leap year "add-day" system.  It does not drop or add frames.  It
doesn't effect playback.  It just assigns different labels to the frames.

After '00:00:33;29' comes '00:00:34;00'.  After '00:00:59;29' comes
'00:01:00;02'.  After '00:09:59;29' comes '00:10:00;00'.  Two frame IDs are
skipped at the beginning of each minute, except for minutes that are
multiples of 10.  It's like how Feb 29th is skipped except when the year is
a multiple of 4, except when it is a multiple of 100, except when it is a
multiple of 400.

This way the SMPTE frame ID will _roughly_ correspond to the
"hours:minutes:seconds:(1/30th seconds)" of the frame's time.  It is not
exact in NTSC, sometimes being off by up to .06 seconds.  But it does not
have an error that accumulates over time, as so is good enough for editing
and cueing, which is what it is used for.