Re: Chapter marks not where specified.

Hi Tom,

I think If you follow the logic of the example function I provided you'll see that I'm converting frames to dvd clock ticks (see below) and then to a correctly rounded fraction (no fudge factors, just whole clock ticks which are completely accurate for NTSC as well as PAL).  Even so, dvdauthor will pick the previous GOP over the intended I-frame unless you nudge the fraction number up a tiny bit (I use .001).  This is the same whether we're at minute three or hour 3.

It's not the 29.97 NTSC rounding error that I'm referring to.  Dvdauthor misses the intended I-frame even if your fraction is perfectly accurate, as in the case of PAL.  What I'm saying is that you need to use fractions not frames and also be deliberately inaccurate, i.e. inflate your perfectly accurate fraction a tiny bit, then your chapter point will end up exactly where you want it.

-Bahman

One second = 90000 PTS ticks
One NTSC video frame = 3003 PTS ticks
One PAL  video frame = 3600 PTS ticks
One lpcm audio frame = 150 PTS ticks


--- On Wed, 3/28/12, Tom Brock <tomb-yZYHXxUkMT10YYv+nEap2lpr/1R2p/[email protected]> wrote:

> From: Tom Brock <tomb-yZYHXxUkMT10YYv+nEap2lpr/1R2p/[email protected]>
> Subject: Re: [Dvdauthor-users] Chapter marks not where specified.
> To: dvdauthor-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, "bn" <aval57-/[email protected]>
> Date: Wednesday, March 28, 2012, 11:25 AM
> Hi Bahman,
> 
> > 
> > Hi Tom,
> > 
> > This may have some bearing on your problem: Dvdauthor
> uses a fractional time
> > string in the form hh:mm:ss.frac as opposed to the
> usual hh:mm:ss.frame.
> > So to convert from frames to frac I use the function
> below with a "boost"
> > of .001 to the fractional component, (without which the
> chapter point ends
> > up back at the start of the previous GOP rather than
> the intended frame,
> > as you describe):
> 
> This is certainly clueful information, but really a bit
> worrying in its 
> implications.
> 
> I can almost see why you might want to do that for NTSC, but
> why on earth for 
> PAL, when each frame is worth exactly 40 ms?  Getting
> from the string in the 
> XML file to frames might involve rounding, but if the user
> is daft enough to 
> specify his chapter marks half-way between frames, say
> 0:15:14.06, then he 
> must expect it to be rounded to the nearest frame and he
> might miss his 
> carefully placed I-frame by one, but that's his problem.
> 
> Even with NTSC, I've often wondered which is right, the
> 29.97 fps figure or 
> the 1.001 fudge factor that is supposed "correct" for its
> not being exactly 30 
> fps.  If 29.97 fps is exact, then you should use
> 3003.003003... for the 
> multiplier, not 3003.  If the oft-quoted 1.001 is
> correct, (and I suspect it 
> is because the 90 kHz is pretty fundamental to DVDs) then
> NTSC is 
> 29.97002997002997... fps, and that is the number that should
> be used when 
> computing frames from times.
> 
> Whichever number is exact, you can throw your fudge factor
> out the window, and 
> just correctly rounded arithmetic.  In any case, 1 ms
> will correct only in a 
> region around 20 minutes, at 3 hours you need 10 ms.
> 
> Tom.
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Dvdauthor-users mailing list
> Dvdauthor-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dvdauthor-users
>


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure