[FFmpeg-devel] FFv1 performance

Michael Niedermayer michaelni
Wed Apr 21 15:08:14 CEST 2010

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>

More information about the ffmpeg-devel mailing list