[FFmpeg-devel] FFv1 performance

[Michael Niedermayer]

On Wed, Apr 21, 2010 at 12:44:13PM +0200, Peter B. wrote:
> 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?

doing full frames means additional latency so iam trying to avoid it,
but it is an option worth considering if spliting a frame doesnt work
out as well as i think it should.
Either way improving the initial states is a good idea because it would
improve compression


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

are you sure you used rgb and ffmpeg didnt end up using yuv420 ?
rgb32 is slower here than yuv420 and rgb24 seems unsupported


> 
> 
> > 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. :)

:)

btw, compression performance of ffv1 can likely be improved by finetuneing the
various tables for the source material, the default ones have been tuned to
relatively clean 8bpp yuv420 material.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100421/bf6d74cf/attachment.pgp>