[FFmpeg-devel] FFv1 performance
Wed Apr 21 12:44:13 CEST 2010
Michael Niedermayer wrote:
> On Wed, Apr 21, 2010 at 10:51:44AM +0200, Peter B. wrote:Hello again,
>> - Is it possible to change FFv1 to support multithreading?
Excellent. That's good news!
>> - If "yes", how much effort would that be?
> Its not trivial but neither overly complex. The multithreading itself should
> be easy but we need some changes to how the AC & VLC coder is initialized,
> because multithreading requires more independant chunks and thus
> initialization becomes more critical in terms of compression performance
I must admit that my math-foo is weak, and my understanding of AC and
VLC coding is only rudimentary. Would it make it easier if a thread was
processing a full frame, instead of parallelizing the processing of
parts of a frame (chunks?) - or won't that matter?
> 444 and 422 will always be slower than 420 because for them the encoder must
> encode more samples.
Clear. What puzzled me is that RGB24 was possible, though.
If I'm not mistaken, YUV444 (8bit) and RGB24 have the same number of
samples (24bit per Pixel).
> general optimizations that make all faster should be
> possible though its hard to say how much faster it can be made before
> actually trying/doing it.
Makes total sense.
>> If it would be possible to use FFv1, I might be able to get proper
>> budget in order to finance the implementation of these improvements.
> This would be great
We're still evaluating the performance of different lossless codecs on
"dirty" archive material (noisy, etc). If FFv1 is able to compress them
without failing (like Huffyuv), I might be able to use the argument of
reduced storage costs to fuel these code changes. I'll keep my fingers
More information about the ffmpeg-devel