From: Tom B. <to...@ba...> - 2012-03-28 19:07:56
|
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. |