[Ffmpeg-devel] New Video Codec for low grunt embedded CPU's

Michael Niedermayer michaelni
Wed Mar 22 00:48:31 CET 2006


Hi

On Wed, Mar 22, 2006 at 08:41:01AM +1100, Steven Johnson wrote:
[...]
> > Also, check out the MPEG-like 4xm codec which is sometimes used on
> > Game Boy Advanced games (low-power CPU):
> >
> >   http://wiki.multimedia.cx/index.php?title=4xm_Video
> 
> Lossy, plus I dont think I can afford the IDCT, sometimes i need to play
> a dozen or so animations at once, and while I could probably play 1 and
> perform IDCT, I dont think I could play 12+ animations at the same time,
> and perform IDCT, in real time.

the IDCT is just done for intra/key frames so it shouldnt be a problem


> 
> >
> >     Anyway, there is lots of stuff out there. I encourage you to
> > investigate other codecs which might meet your needs before
> > implementing your own. At the very least, the decoder is probably
> > already available through us so half the effort is already taken care of.
> >
> >     Hope this helps...
> 
> It helps, Thanks for the pointers, unfortunately nothing quite fits the
> bill.  Unfortunatley, because if there was an immediate choice to use, I
> would definately use that rather than think about implementing "Yet
> Another Codec".

maybe you should look at huffyuv, note it supports rgb24 which could be
converted to rgb15 or rgb16 and somehow i belive that the huffyuv
compression would work quite well with palettized data (just dont tell
the codec that what it stored isnt 8bit grayscale ...)
and huffyuv could be extended to code the difference from the last frame
or something like that quite easily if needed

also note that 2D aware compression outperforms generic 1D compression
like LZO

and zigzag scaning like you suggested is completely useless unless you
have a 2d block decorrelation transform like a DCT, if you just code raw
values or differences then raster or hilbert scan is more logic then zigzag

and most important, i also strongly recommand to use an existing codec
or slightly change one, instead of inventing your own

[...]
-- 
Michael





More information about the ffmpeg-devel mailing list