[FFmpeg-devel] 4xm idct computation

[yann.lepetitcorps at free.fr]

> > > Note that 99% of the CPU time is used by the zlib compression stage
> > > => without the zlib stage this can already work on real time ...
> >
> > replacing zlib by a static huffman coder storing zero run length +
> > value of the following non zero value in one symbol should be quite
> > fast and efficient.
> > A better compressing variant would be using a context adaptive
> > arithmetic coder
> >
>
> I have found somes fast compression tools on the Net such as :
>
>     QuickLZ
>     SR2
>     FLZP
>
[...]

LZO seem a good candidate too :)

And FLZP seem to be too text file specific :(


> Note that I think to extend the RLE scheme for to handle successives values
> that
> are very near the last decoded value too (this work on a byte per byte basis)
[...]

My first tests/experiments show a very good compression/time ratio improvement
with the use of this (new) extended RLE stage instead the (very fast) RLE + the
(very slow) Zlib stages :)

Ok, I have to reorder my locals 8x8 blocs of wavelets to a global width*height
picture "that look like a mimmap" **AND** the final compressed data is about 2x
more big than before **BUT** the entire pipeline is now about 10x more speed
than before
=> for me, this look like a 5x improvement :)
(10x more speed but 2x more data)

This seem logic when you see that the Zlib compression spend 99% of the entire
pipeline time ...
=> delete this stage and you can multiply by 10x the time spend in alls others
stages ... with a 10x decrease of the total time spend in the entire pipeline :)
(100%-99%=1% , so only 1% of the time is used  for alls stages except the ZLIB
stage => even with a 10X increase in alls stages except the Zlib stage, this is
always only 10% of the time needed to the (very very slow) Zlib stage ... which
is now no longer used in the pipeline ...)


@+
Yannoo