Ya, it sounds like your problem and mine are very similar, cause whenever I had transcoded a file without an index, it was always incredibly hard to get the file back into a working state. rebuilding the index didn't always work, and if I was able to get seeking to work again, teh video would break up all over the place, and myth would yell at me saying that when I tried to seek I wasn't seeking to a keyframe. I haven't tried exporting a corrupt file though, so this is all just a theory.
On Sun, 27 Feb 2005 09:10:08 -0500 (EST), Cory Papenfuss <[EMAIL PROTECTED]> wrote: > On Sun, 27 Feb 2005, Jay Merrifield wrote: > > > Ever since upgrading to .17, I've been having problems transcoding > > RTJpeg files into mpeg4. The video is transcoded just fine, but the > > seek table always seems to be screwed up to some degree or another. So > > I finally got the time to tear through the code and what follows is a > > summary of what I found, and how I fixed it (more like how I found the > > change in CVS that broke my setup and backed it out). Hopefully this > > will be useful for others. Investigation into broken files found that > > all files had a perfectly normal/uncorrupt header/seek table but no > > keyframes were being stored. Upon checking the transcoding process, > > NuppelVideoRecorder was never executive the code to write keyframes. > > Further investigation found that inside nuppeldecoder.cpp, keyframes > > were being decoded correctly, but the isLastFrameKey() function was > > always returning false. Appears lastKey and framesPlayed were always > > off by 1 frame, so the keyframes were never being sent to the > > NuppelVideoRecorder. Subsequent patch to correct this problem lead me > > to the CVS change log and where the original change that broke my > > system was made. Revision 1.54 commented out some frame adjustment > > code in favor of alternate frame tracking code. This change broke > > transcoding on my system. Here's the diff -u with the latest CVS and > > the changes I made: The second change in the diff -u was done in the > > hopes of not breaking the original patch. > > > Interesting... I wonder if this is the cause of my mplayer nuv2avi > copying attempt problems. I patched mplayer with a moldy-old patch (that > still applies cleanly) to play transcoded (MPEG4) .nuv files. Trying to > extract a useful .avi out of it with: > > mencoder infile.nuv -oac copy -ovc copy -o outfile.avi -force-avi-aspect 1.33 > > results in these errors while copying: > 1 duplicate frame(s)! > Pos: 100.0s 2973f (18%) 2003fps Trem: 0min 141mb A-V:-0.067 > [2066:128] > 1 duplicate frame(s)! > Pos: 100.4s 2983f (18%) 1999fps Trem: 0min 140mb A-V:-0.067 > [2063:128] > 1 duplicate frame(s)! > Pos: 100.8s 2994f (18%) 2004fps Trem: 0min 140mb A-V:-0.069 > [2059:128] > 1 duplicate frame(s)! > Pos: 110.8s 3295f (20%) 2088fps Trem: 0min 140mb A-V:-0.067 > [2034:128] > > The result plays, but has no keyframes (so seeking is broken). I > don't remember if I was using 0.17 or 0.16 when I transcoded this show, > however. Sound likely? > > -Cory > > ************************************************************************* > * Cory Papenfuss * > * Electrical Engineering candidate Ph.D. graduate student * > * Virginia Polytechnic Institute and State University * > ************************************************************************* > >
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
