[Ffmpeg-devel] [PATCH] remove drop timecode flag
Sun Apr 15 23:46:07 CEST 2007
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?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel