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

[Roman Shaposhnik]

Hi,

I'm almost tempted to change the subject, since I would like to
ask for a help to understand the LTC drop-frame better and it
has nothing to do with the original thread...

On Sun, 2007-04-15 at 10:49 -0700, Trent Piepho wrote:
> Think of the timecode as the frame number.  Not the frame PTS time, but
> just the ordinal number of the frame.  Instead of writing it in base 10,
> it's written in a weird base 30/base 60 numeric format.  It is convenient
> for humans to look at, since we keep time in base 60.
> 
> 107892 == 0x1a574 == 00:59:56:12, it's all the same, just an integer
> written in different formats.
> 
> The problem is that a broadcast of 107892 frames will last one hour, not 59
> minutes 56 seconds and 12 frames.  A broadcaster would like it if he could
> cue his tape to end after an hour by using a timecode of '01:00:00:00' in
> his automatic cueing equipment.

  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:

  actual frame 0 occupies an interval of -- [0; 1001/30000)
  actual frame 1 occupies an interval of -- [1001/30000; 2*1001/30000)
  ....
  actual frame X occupies an interval of -- [X*1001/30000; 
                                            (X+1)*1001/30000)]

and again -- these are objective physical data points that *precisely*
describes a physical experiment of capturing a particular phenomenon.

Now, we also know that the convention is for timecode of 00:00:00:00
to correspond to frame 0 and for timecode of 00:00:00:29 to correspond
to an actual physical frame #29. Given that physical frame #29
has a timecode of 00:00:00:29 occupies an interval of 
    [29*1001/30000; 30*1001/30000) 
which equals to 
    [0.96; 1.001) 
it would be reasonable to assume that:
   ---------------------------------------------------------------
   the way timecode works is -- the value of seconds in a timecode   
   corresponding to a physical frame X (which occupies an interval
   of [X*1001/30000; (X+1)*1001/30000)) is a trunc(X*1001/30000)
   ---------------------------------------------------------------

Now, this rule seems to work reasonably well, all the way till we
get to a frame #1018 which occupies an interval of:
     [1018*1001/30000; 1019*1001/30000)
and thus is counted as a frame recorded during the 33d second,
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 ?!?!?

Thanks,
Roman.