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

[Michael Niedermayer]

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?

[...]

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070415/e6b1fc7a/attachment.pgp>