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

[Michael Niedermayer]

Hi

On Mon, Apr 16, 2007 at 11:49:14AM +0200, Baptiste Coudurier 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
> > 
> > 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 found this thread in mp4-tech related to mpeg4 timing:
> 
> http://lists.mpegif.org/pipermail/mp4-tech/2001-October/000268.html
> 
> Does lavc encoder use vop_time_increment_resolution, modulo_time_base
> and vop_time_increment parameters, as mentioned ?

your question makes no sense, the author of the mail to which you refer
is confused, there is no drop frame, no compensation,
no random update and no inexactness in mpeg4s timecode and timestamps

the previous mail from gary, explains the whole very well and it just
repeats what i already said, hours/minutes/seconds are exactly 
hours/minute/seconds there is no round to interger fps in mpeg4

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

Democracy is the form of government in which you can choose your dictator
-------------- 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/20070416/bd5be941/attachment.pgp>