[Ffmpeg-devel] [PATCH] remove drop timecode flag
Mon Apr 16 11:49:14 CEST 2007
Michael Niedermayer wrote:
> 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
>> 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