Matthew, My apologies. I know your correct first name; however, for some reason, Mark came out when I typed it! I've read your comic, for goodness sake! :) Thanks for the detailed analysis. Based upon your work and Herman's suggestions, I will poke around too to see if I can help ferret out what is going on.
scott On Mon, 2007-05-28 at 21:37 -0400, [EMAIL PROTECTED] wrote: > On Sun, 22 Apr 2007, Scott C. Frase wrote: > > Mark, > > It's actually Matthew or Matt... > > > Thanks for taking the time to investigate this. It will be a big help > > to get it resolved. > > Okay, after doing more careful tests, I think I've determined that for a > change, it's all the *other* software that's broken, not Cinelerra. Here > are my frame counts for the same file containing an MPEG2 Elementary > Stream extracted from one chapter of a DVD: > > mpeg3toc/mpeg3dump: 18309 > transcode: 17572 > mplayer (default): 18068 > mplayer -fps 29.97: 18314 > > The audio for the same chapter, when extracted and played, takes 610.63 > seconds, which at 29.97 frames per second works out to 18300 frames. > Cinelerra agrees with mpeg3toc/mpeg3dump. So although none of these match > up perfectly, Cinelerra seems to be closest to correct; I think it's the > other packages that are at fault. (There go a couple days' worth of CPU > time I already spent processing the footage with transcode and mencoder, > but sorting this issue out is probably worth it.) > > Before doing the audio test I experimented with modifying the file > libmpeg3/mpeg3vtrack.c, which contains the routine that mpeg3toc uses to > record frames in its index. I was able to get a TOC file with frame count > very close to transcode's (I didn't write down the exact number) by making > it store the previous frame's offset in a static variable and then > silently return without recording a new frame, if it were called a second > time with the same offset. So it definitely appears that most if not all > of the discrepancy comes from some frames being somehow duplicated or read > twice. I've also gotten some messages about duplicate frames from > mencoder when trying to process this file. So all is clearly not well > with the file. Maybe it is at least partly soft-pulldown after all, and > different software has different ways of dealing with that. But based on > the audio length evidence, I think that these duplicate frames are > supposed to be there, and Cinelerra is correctly handling them. > > I made a clip of the start of the file using dd, which was the only > software for clipping it about which I was confident of not changing the > format at all. That clip is here: > http://ansuz.sooke.bc.ca/temporary/ev-clip.m2v > if anyone wants to take a look at it. Grab it soon, because I won't leave > it up indefinitely. It's just barely long enough to show clear > discrepancies among the software packages, and that also is just long > enough to include one of the spots where mplayer complains about > telecining and frame rate changes. I don't know if that's a coincidence, > or critical to what's going on. Frame counts for the sample clip: > > mplayer: 241 > mplayer -fps 29.970: 244 > transcode: 230 > mpeg3toc/mpeg3dump: 245 > cinelerra: 245 > > The content is the start of title 1, chapter 2, of ADV Films's North > American release of Neon Genesis Evangelion Collection 0:3. > > > By the way, what tools are you using to investigate the toc? (Maybe I > > can learn something new)? > > What I did was look at the files with less and try to figure out the > format from that. It seems pretty clear that there's a header and then a > bunch of 8-byte numbers that increment from zero. Then to look for > duplicates I wrote a Perl one-liner. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
