[FFmpeg-devel] 4xm idct computation

[Michael Niedermayer]

On Thu, Dec 29, 2011 at 12:06:26AM +0100, yann.lepetitcorps at free.fr wrote:
> > > > > This is my problem, I search something that is "only partially block
> > based"
> > > > :)
> > > > > (cf. that work on fixed 8x8 blocs, but where the blocs are dynamically
> > > > > constructed from a "mipmapped" picture)
> > >
> > >
> > > > indeo4 uses block based haar transform amongth other things
> > > > see http://wiki.multimedia.cx/index.php?title=Indeo_4
> > > >
> > > > the haar transform does not perform very well though.
> > > >
> > > >
> > > > and there are fraktal coders that work by downscaling a simple trivial
> > > > image and then using blocks from it to construct a new image repeatly
> > > > to build up the image one wants.
> > > > These are too slow for practical use though.
> > >
> > > Thanks,
> > >
> > > This seem a good scheme, but what is the scale of the "too slow" ?
> >
> > the problem with fraktal coders is the encoding step. It is VERY slow
> > so they are not used in practice anywhere AFAIK (someone will probably
> > reply and point out some real world useage if there is one)
> >
> 
> It's why I think :
> 
>  1) make only one iteration of the wavelet transform on patch of 8x8 pixels
>     (this can work on very littles caches of 8x8=64 bytes and this use only
> bytes, not floats ... so this is really very speed)
> 
>  2) reorder this picture into something like a "mipmap picture" where the
> horizontal and  vertical coefficients replace the red and blue parts, and where
> the average coefficients replace the green part
> (cf. look similar to a real wavelet picture, but only with the first 8 levels)
> 
>  3) remake a second iteration of the wavelet trnasform into this "mipmapped
> picture"
> 
>  4) reorder the resultant picture for to have always in output something that is
> "mipmapped"
> 
> A limitation of this scheme  is that the width and height are to be always
> multiples of 64
> 
> => I think that this "only two recursions wavelet transform" can be computed
> very quickly (because the only one recursion version is **really** very speed ..
> but OK without the [x%8,y%8] reordering)
> 
> 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111229/65d2c965/attachment.asc>