[mythtv] mythtranscode: potential optimization

Mark Steckel mjs at qwsa.com
Tue Nov 27 15:36:44 UTC 2007


Hello All,

I've notice an annoying behavior in mythtranscode that might be a 
bug. Regardless, it is certainly an opportunity to make mythtranscode 
run faster.

I should say up front that any potential improvement will more likely 
be seen when mythtranscode is run with the option --inversecut as 
compared to --honorcutlist.

Given:

   mythtranscode --mpeg2 --infile infile.mpg --inversecut 1-901 -o outfile.mpg

The above cmd creates outfile.mpg from infile.mpg with just frames 1 to 901.

The resulting outfile.mpg is created correctly. However, 
mythtranscode does a lot more work than I think is required.

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?

Does anyone know if this behavior is inherent to mythtranscode or is 
a result of one of the libs (libavformat, libmpeg2, libreplex) than 
mythtranscode utilizes?

Finally, can anyone point me to the appropriate place in the code to 
investigate further?

(I should note that I suspect that mythtranscode does not jump to the 
start frame but instead reads from the beginning of infile.mpg to the 
start frame. I know this is a different and potentially, messier 
problem to optimize.)

Alternatively, if anyone knows of a different utility that produces 
the same sort of results as the cmd above but does so more quickly, 
then I'd love to hear about it. (ffpmeg is actually slower and it 
doesn't use frames but time...)

Thanks
Mark






More information about the mythtv-dev mailing list