[Ffmpeg-devel] [PATCH] remove drop timecode flag
Tue Apr 17 00:19:16 CEST 2007
On Mon, 16 Apr 2007, Michael Niedermayer wrote:
> On Sun, Apr 15, 2007 at 03:58:30PM -0700, Trent Piepho wrote:
> > > 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;
> yes minus the floats and rounding
Ok, no floats this time (but 64-bit longs):
long sec30k = i * 1001L; // units of 1/30000th of a second
int secs = (sec30k/30000) % 60;
int mins = (sec30k/(30000*60)) % 60;
int hours= (sec30k/(30000*60*60)) % 24;
int frame= (sec30k%30000) / 1001;
This problem with this is it doesn't follow the SMPTE/EBU/MPEG-2 spec:
Frame 1018, time 00:00:33.967, LTC 00:00:33:28 or 00:00:33;28, alt 00:00:33;28
Frame 1019, time 00:00:34.001, LTC 00:00:33:29 or 00:00:33;29, alt 00:00:34;00
After '00:00:33;28' comes '00:00:33;29', according to the spec. But this
way of creating timecodes has '00:00:34;00' instead.
It this true, this way does give you a SMPTE frame id that is closer to the
true frame time than the official spec's way.
But, suppose skipping Apr 17th 2007 gives us a calendar that is more
accurate than what we get by skipping Feb 29th 2007? If you do that and
call tomorrow Apr 18th, no one else will understand you. Even if your
calendar is better (in some ways) than the Gregorian calendar, it doesn't
matter, you still have to use what everyone else uses.
It is the same with SMPTE/EBU timecodes. You might think your timecode
system is better, and be that as it may, it's not the system everyone else
has been using for over 30 years.
BTW, there is a good reason that SMPTE drops timecodes in pairs. The NTSC
color superframe is two frames (yes frames, not fields) long. The LSB of
the timecode won't say in phase with the superframe. Is it important when
switching from one source to another that the color subcarrier's phase wrt
the horizontal sync pulse be correct. This means, switch from an even time
code in source A to an odd timecode in source B.
More information about the ffmpeg-devel