[mythtv] mythtranscode: potential optimization

[Chris Pinkham]

* 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

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
argument.

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.

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.

--
Chris