[FFmpeg-devel] 4xm idct computation
michaelni at gmx.at
Thu Dec 29 02:19:30 CET 2011
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
> 4) reorder the resultant picture for to have always in output something that is
> 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
> 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
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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel