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

[Michael Niedermayer]

Hi

On Mon, Apr 16, 2007 at 03:19:16PM -0700, Trent Piepho wrote:
> 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.

yes i agree that setting mpeg2 timecodes in a spec violating way is a
bad idea ...


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

is the phase of the color subcarrier locked to the sync at all? yes i know
its approximately at the same spot again after 4 fields but exactly?

lets assume it is how does that matter? if you have some non-ntsc recording
it doesnt matter, so we need to have a NTSC (=analog) recording now i have
my doubts that you can switch between 2 such recordings with a time accuracy
better than the wavelength of the color subcarrier
keep in mind digital YUV/RGB isnt affected only recording of the "modulated"
NTSC ...

MPEG != NTSC and the phase even if its locked can start at various differnt
points depending on the mpeg decoder hardware so this isnt going to work
even less so with repeated fields

so while i dont disagree on your reasoning about the 2 frame skip, this
appears to be limited to pre-digital video times and doesnt seem related
to mpeg*

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070417/24808155/attachment.pgp>