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

[Steven Johnson]

Mike Melanson wrote:

> Steven Johnson wrote:

>> Do you think I
>> should use a standard codec that already exists, and not re-invent the
>> wheel?
>
>
>     It sounds like you know everything you want (which is everything).
> Have you looked at all the current available technologies?

I dont think I want everything, but in any event, isnt that what
everyone who needs a codec wants?  Yet in the end, they end up with a
compromise, its the nature of the compromise that sets the codecs
apart.  What problems with a particular codec exist, that person A is
happy to live with, while person B isnt. 

For example, in my case I cant live with encoding noise or errors, my
application makes large use of animations with sizes are like 80x48
pixels and 120x16 pixels, etc.  These animations are played on displays
that are many feet across, so with such a low dot density, encoding
errors really stand out, and look horrible.  What you can get away with
when the pixels are tiny, you cant when they are 3-5mm in diameter, and
viewed from a couple of meters.

Ive looked at some, but here are my problems with each of the ones
listed here.

>
>   http://wiki.multimedia.cx/index.php?title=Category:Video_Codecs
>
> Not too many codecs adapt for 8/15/16/24 bit and if they do, they're
> usually lossless (which may not be desirable depending on your
> requirements). QuickTime RLE and the new DosBox codecs both have
> provisions for a range of colorspaces:

Lossless is what im after, I'm willing to sacrifice compression density
for picture quality. (The compromise I can live with.)

>
>   http://wiki.multimedia.cx/index.php?title=Apple_QuickTime_RLE

Wont give me any better result than my FLC/FLX files.  I want to try and
get a better result than that.

>   http://wiki.multimedia.cx/index.php?title=DosBox_Capture_Codec

Uses ZLib, which I know from experience is way to slow on my target
processors to do it in real time.

>
> The venerable Cinepak codec operates in 8-bit palettized mode, as well
> as its primary YUV-like mode which is quick and easy to convert to any
> other colorspace, but it might be tricky to get the quality you want
> out of a vector quantizer:
>
>   http://wiki.multimedia.cx/index.php?title=Cinepak

Lossy, with encoding artifacts.

>
> You may be looking for a combination of codecs, one that handles 8-bit
> well and another that scales to 16- and 24-bit. QPEG is an interesting
> 8-bit codec that provides for variable block size motion compensation:
>
>   http://wiki.multimedia.cx/index.php?title=QPEG

Yes, it is interesting, while not exactly what I need, cause I really
need to be able to do at least 15bpp as well, It has some good
techniques that could be used.  It appears lossless, so that fits the
bill. 

>
> While Duck TrueMotion 1 (full source code available from On2), is a
> lossy DPCM codec that operates on 16- and 24-bit colorspaces, while
> being optimized for running on 32-bit CPUs:
>
>   http://wiki.multimedia.cx/index.php?title=Duck_TrueMotion_1

Lossy and patented.

>
> 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.

>
>     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".

Steven J