Re: Chapter marks not where specified.

bn <aval57-/[email protected]> Wed, 28 Mar 2012 14:52:49 -0700 (PDT)
Newsgroups gmane.comp.multimedia.dvdauthor.user
Message-ID <[email protected]>
Tom,

Suit yourself, but I would suggest you take your time and actually try it before enumerating at unnecessary length all the reasons (real or imagined) why it mightn't/couldn't/shouldn't work off the top of your head. I'm simply giving you a way to arrive at your intended I-frame, which is presumably what you're asking for help with.

And more power to you if you want to submit a patch.

cheers,
-Bahman


--- 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
> Date: Wednesday, March 28, 2012, 3:07 PM
> Hi Bahman,
> 
> > 
> > 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).
> 
> Quite so. Your computation is exact, and given that the
> 1.001 (represented by 
> 3003 in your code) is the correct number, then *without* the
> fudge factor, you 
> will compute the correct time for any supplied frame
> number.
> 
> > 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 simply isn't true.  In 5 out of 33 cases,
> dvdauthor puts the chapter mark 
> in exactly the specified place; in one out of 33 it puts it
> at the I-frame 
> immediately *after* the specified time.  In the
> remaining 27 case, it put the 
> chapter mark early.  It's more complicated than you
> think.  All times I 
> specified are I-frames. A fix that might work in 82% of
> cases isn't a fix.  In 
> my experience, finding the root cause and fixing it is the
> way to go.
> 
> [small snip]
> 
> > It's not the 29.97 NTSC rounding error that I'm
> referring to.
> 
> I appreciate that.  What I find curious is that you add
> an arbitrary fudge 
> factor to a computation that you know is exact in order to
> fix, and not 
> reliably at that, what looks like a shortcoming in
> dvdauthor.
> 
> The *result* of your computation could conceivably be in
> error because of the 
> rounding of 29.97 (which is accurate to about 20 bits), but
> only if frames 
> numbers greater than 899100 are used, but I don't believe a
> title length of 8 
> hours, 20 minutes is allowed.
> 
> > 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.
> 
> I specified the times as hh:mm:ss.nn to 2 decimal places of
> seconds: dvdauthor 
> and ffmpeg both tell me to enter a time specification, not
> some chimera of 
> seconds and frames, and it would never have occurred to me
> to do so.  I 
> haven't looked closely at the dvdauthor code yet (I have a
> day job to do), but 
> I shall.  Unless I find otherwise, I will not doubt
> that dvdauthor reads the 
> time specifications correctly.  I suspect the problem
> is that, for some 
> reason, but in only in 82% of cases, it doesn't realize that
> the specified 
> time (or frame number) is the same as that of an I-frame in
> the input stream, 
> or if it does, it doesn't act on that knowledge.
> 
> I shall not be deliberately adding systematic errors to my
> time 
> specifications.  My experience is that accuracy, once
> thrown away, can't be 
> recovered.  And, to cap it all, I really can't see how
> adding 1 ms to a 
> chapter mark time specification for either an NTSC or a PAL
> DVD would change 
> the computed frame number (unless doing so crosses the
> half-way point between 
> frames, of course).
> 
> Tom Brock.
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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