[FFmpeg-devel] FFv1 performance

[Peter B.]

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?
>>     
> yes
>   
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
crossed. :)

Thanks,
Peter B.