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

[Trent Piepho]

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.

> 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;

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'

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.