[FFmpeg-devel] 4xm idct computation

[yann.lepetitcorps at free.fr]

> > I have recently make something that use a local
> > wavelet/quantization/rle/zcompression pipeline that can compress/decompress
> a
> > picture and that can be found at
> >
>
http://www.developpez.net/forums/d909172/java/general-java/apis/multimedia/cherche-api-compression-video-wavelet/
> >
> > 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

QuickLZ seem to be the better candidate because it have a "good simple" API (so
can be easily integrated into anothers tools) and seem to have a very good
"compression/decompression vs size/time" ratio.

SR2 seem "not too bad", but on a first look at sources I have see that it work
directely on file
(but the file->memory conversion isn't certainly not too hard to make, so this
can be a good candidate ... if and only if it was more performent than QuickLZ
of course)

I don't find sources of FLZP :(


What I search is an algo that have a very small compression/decompression
time (for to can be used in real time conditions) **but** with a "not too bad"
compression size ratio if possible ...
(cf. that can compress/decompress the more possible "wavelet blocs datas" in a
very short time such as somes milliseconds)


where can I find links about "high performance" compression/decompression tools
?
(something like http://mattmahoney.net/dc but more "real time 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) :

   00 new value    (new value is >> 2 for that the 00 header + the new value can
to fit into a 8 bit value, with a "not too big" loose)

   01 increment the last value    (increment can be 00=+1, 01=+2, 10=+3,
11=stop)

   10 decrement the last value    (decrement can be 00=-1, 01=-2, 10=-3,
11=stop)

   11 #repeat                     (#repeat is the number of the last decoded
value to repeat)

(note that two incremented/decremented values can be stored in only one byte,
and that in this case the 11 in the second "4 bit chunk" indicate that the next
value can't be coded with a simple increment/decrement chunk)

=> I make the implementation of this "extended RLE" and send you the source in
some days
(it's only theoric for now, but I think to finish the implementation of this
algo before the end of the next week)


@+
Yannoo