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

[Rich Felker]

On Sun, Apr 15, 2007 at 03:58:30PM -0700, Trent Piepho wrote:
> On Sun, 15 Apr 2007, Michael Niedermayer wrote:
> > >
> > > 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
> 
> Ok, you're right, it gains 1 frame every 9 1/4 hours.  Usually video tape or
> film reels aren't > 9 1/4 hours so this doesn't cause a problem.

How broken and disgusting...

> > 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'm not sure what you mean by "frame within that second".
> 
> In your method, what is the formula for the timecode values for frame i at
> 30000/1001?
> 
> Do you mean:
> double t = i * 1001 / 30000;
> int hours = (int)(t/3600) % 60;
> int mins = (int)(t/60) % 60;
> int secs = (int)(t) % 60;
> int frame = (t - (int)t)*30000.0/1001.0 + 0.5;

Timebase conversion is precisely defined with exact integer
arithmetic. Trying to perform the floating point analysis to determine
if it's the same is disgusting and I don't feel like doing it...

> This has two problems.  One, it doesn't follow the SMPTE spec.  Frame
> 510 should have frame id '00:00:17;00', but this method gives it
> frame id '00:00:17;01'

I suspect it gives the identical results for the full interval up to
9? hours (or maybe only halfway there) if you use the correct integer
timebase conversion. Anyone care to check? I don't know the SMPTE
stuff myself.

> This makes a difference!  How many frames are there between '00:00:16;00'
> and '00:00:17;10'?  In SMPTE timecode, there are exactly 40 frames.  In
> this alternate timecode, there are a 39 frames.  The interval is different
> because it's not following the SMPTE spec.  It's not following the MPEG-2
> spec either.
> 
> This alternate timecode also will use frame fields that go to :30, instead
> of always wrapping at :29.

Only because you defined it nonsensically... The correct way is to
convert first from a 1001/30000 timebase to a 1/30 timebase exactly
(rtfs lavc source or rtfm nut spec), then do the standard hh:mm:ss:ff
arithmetic for 30 fps. Obviously the 'ff' field will always be in the
interval 00 to 29 if you do this.

If you work out the arithmetic and this does not give identical
results to 'drop timecode' algorithm, AND if there's a serious reason
the believe that the exact 'drop timecode' semantics are needed for
users, then maybe it's time to talk about hacks to support them. But
otherwise it's senseless special-casing.

Rich