[mythtv] [PATCH] Missing keyframes on mpeg4 transcode

[Jay Merrifield]

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
<papenfuss at juneau.me.vt.edu> 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                   *
> *************************************************************************
> 
>