[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