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

Baptiste Coudurier baptiste.coudurier
Mon Apr 16 11:49:14 CEST 2007

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
> the drop frame timecode calculation end up at 2997/100 instead of 30000/1001
> also what exactly is the problem with just setting the true sec/min/hour
> and frame within that second as mandated by mpeg4 in the mpeg2 case too
> if its really just an abstract ID?

I found this thread in mp4-tech related to mpeg4 timing:


Does lavc encoder use vop_time_increment_resolution, modulo_time_base
and vop_time_increment parameters, as mentioned ?

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

More information about the ffmpeg-devel mailing list