[Ffmpeg-devel] [PATCH] remove drop timecode flag
Mon Apr 16 00:58:30 CEST 2007
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
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
This alternate timecode also will use frame fields that go to :30, instead
of always wrapping at :29.
More information about the ffmpeg-devel