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. -- Matthew Skala [EMAIL PROTECTED] Embrace and defend. http://ansuz.sooke.bc.ca/ _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
