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

[Baptiste Coudurier]

Michael Niedermayer wrote:
> Hi
> 
> On Sun, Apr 15, 2007 at 02:28:56PM -0700, Trent Piepho wrote:
>> 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.
> 
> wrong it does have an error which accumulates over time and this is another
> reason why its a very bad idea

You are right, and SMPTE acknowledge it:
Quoting SMPTE 12M:

"When drop-frame compensation is applied to an
NTSC television time code, the total error accumu-
lated after one hour is reduced to --3.6 ms. The total
error accumulated over a 24-hour period is --86 ms."

About time code:

"4.2 Time address of a frame

Each frame shall be identified by a unique and com-
plete address consisting of an hour, minute, second,
and frame number. Refer to ANSI/SMPTE 258M for
standard formats used to display frame-based time.
The hours, minutes, and seconds follow the ascend-
ing progression of a 24-hour clock beginning with 0
hours, 0 minutes, and 0 seconds to 23 hours, 59
minutes, and 59 seconds. The frames shall be num-
bered successively according to the counting mode
(drop frame or nondrop frame) as described below:"

4.2.1 Nondrop frame ---- Uncompensated mode

Frames shall be numbered 0 through 29, succes-
sively, with no omissions.

4.2.2 Drop frame ---- NTSC time compensated mode

Because the vertical field rate of an NTSC television
signal is 60/1.001 fields per second ( 59.94 Hz),
straightforward counting at 30 frames per second will
yield an error of approximately +108 frames (+3.6
secREAL) in one hour of running time.
To minimize the NTSC time error, the first two frame
numbers (00 and 01) shall be omitted from the count
at the start of each minute except minutes 00, 10, 20,
30, 40, and 50."

I don't have IEC 461 though.

I'd like to support both modes for NTSC and mpeg2 encoding.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312