[mythtv] mythtranscode: potential optimization

Mark Steckel mjs at qwsa.com
Tue Nov 27 16:36:51 UTC 2007

Hi Chris,

At 11:05 AM 11/27/2007, you wrote:
>* On Tue Nov 27, 2007 at 10:36:44AM -0500, Mark Steckel wrote:
> > For instance, in the above example, if infile.mpg is 902 frames long
> > then mythtranscode runs fairly quickly. On the other hand, if
> > infile.mpg is 54K frames long then it takes much longer.
> >
> > Its as if mythtranscode insists on reading the entire infile even
> > when it is not necessary. Is this actually the case?
>The code should be fast forwarding to skip the sections that are being
>cut out.  That logic is in NuppelVideoPlayer::TranscodeGetNextFrame().
>It should print out some messages like the following when it skips
>forward in the file:
>         Fast-Forwarding from 518 to 48342

I do not see similar messages or anything to do with seek'ing.

I just reran myuthtranscode with the same options in your example. 
See the attached log file for details.

>If the frame that it is trying to skip to is past the end of the
>file, it should stop reading the file.  That is why I set the last
>frame to 999999999 when I build the new cutlist from the --inversecut

I saw this in the code and it made sense.

>It seems to be seeking properly for me.  It skips and starts transcoding
>frames almost immediately when I cut.  Here's a sample command line and
>the relevant corresponding output from the log:
>mythtranscode --infile 
>/taz/video2/mythtv/recordings/1056_20070930000000.mpg --inversecut 
>30000-30100 -v playback -o outfile.mpg -p autodetect
>Cutting from: 0 to: 30000
>Cutting from: 30100 to the end
>2007-11-27 10:59:43.803 Resyncing position map. posmapStarted = 0 
>livetv(0) watchingRec(0)
>2007-11-27 10:59:43.962 Position map filled from DB to: 7428
>2007-11-27 10:59:43.964 SyncPositionMap prerecorded, from DB: 7428 entries
>2007-11-27 10:59:43.964 SyncPositionMap, new totframes: 111420, new 
>length: 3717, posMap size: 7428
>2007-11-27 10:59:43.965 AFD: Position map found
>2007-11-27 10:59:44.053 AFD: DoFastForward(30000 (1), do discard frames)
>2007-11-27 10:59:44.054 Dec: DoFastForward(30000 (1), do discard frames)
>2007-11-27 10:59:44.054 AFD: SeekReset(30000, 0, do flush, do discard)
>2007-11-27 10:59:44.054 AFD: SeekReset() flushing
>2007-11-27 10:59:46.297 ~VideoOutputNull()
>It skipped right to frame 30000 and started transcoding and took
>only 2.25 seconds to transcode those 100 frames out of a 1.6GB file, so
>there is no way it read in the whole file.
>Perhaps your seektable is messed up and it is having to seek manually
>when trying to fast forward.

How can I determine if this is the case? Also, when is the seektable 
set and is there a way to reset it.

>I do notice a longstanding bug where it clears the position map for the
>original file from the DB even if you run mythtranscode using the -o option
>to write to a different file.  Maybe that is affecting you if you are
>trying to cut multiple sections of a file out to different output files.

Any suggestions of how to test for this?


More information about the mythtv-dev mailing list