views:

980

answers:

5

I was wondering if there are any video codecs out there that are suited for extremely low bitrates, especially for webcam input?

Throwing around some numbers: let's say a 160x120 stream that will result around 32kbps or so.

Quality will be poor, probably. However, the video should be "understandable", and the frame rate should be sufficient for movement perception.

Googling it out, I could only find abstracts. Are there any concrete codecs? Any video examples? And ultimately, any usable libraries?

EDIT: Thanks for the answers. I tried to encode a 160x120 pre-recorded clip with H264 targeting 32kbps, and I must admit that the results were preety good.

The quality was actually susprisingly good, which makes me wonder wether this can be done in real time, and without requiring high cpu load?

Take conferencing for an example, where you have to encode one stream, while decoding multiple streams, all in real time.

+1  A: 

At the end of the day, I think you'll probably be best served by running a high-quality modern codec with a very small target bitrate, and let it work its magic. Give x264 a try; I've seen exceptional performance from it at high bitrates, and it's supposedly designed to degrade very well. The biggest problem with x264 is that it'll have relatively high CPU requirements for encoding and decoding, but I think it will provide the best quality at a given bitrate for currently available codecs. And it's standardized!

kquinn
Do you have any figures for encoding and decoding? In general encoding takes much longer than decoding (something like 4 or 5 times as long).
Lehane
I did a couple tests with 176x112 x264 (and a copyrighted source, so I can't post them). At 32kbps, the quality was terrible, but the video was actually watchable -- it reminded me of 10-year-old QuickTime or RealVideo clips. 64kbps was actually pretty decent, and looked Good Enough to my eyes. On this 2.6GHz Core 2 Duo, I managed 100-120 FPS for encoding (depending on settings). With all the settings on x264 cranked up to "insane" I got about 100 FPS -- so a modern desktop CPU will have no trouble encoding small x264 videos, though an embedded processor probably would.
kquinn
A: 

It's really hard to beat h264, but sadly I think it's about 64kbit for the resolution you mention.

I think there's some stuff in the research world that can do better, typically variations of Matching Pursuits, but I don't think those have made it to real world codecs. This is because firstly, Matching Pursuits is very slow to encode, and second there are some patents covering it.

Jason Watkins
A: 

I think H.264 would be capable of doing that. I seem to remember encoding QCIF(176X220) at around 64 kBit/second and it was reasonable quality, so a smaller resolution at 32kBit/s should be possible (but of course will be very low quality). To be honest I always find it amazing that you can get a watchable video at bitrates so low....

The bitrate achieved will of course depend a lot on the framerate. Also, the content in the video has a large impact on the birate. If there is a lot of movement in the video it will increase bitrate (or decrease quality if the bitrate is fixed).

Intel have a set of free implementations of a number of codecs (H.264, H.263 and others), look here or here. I used them before and they are very good.

Lehane
A: 

remember: framerate is crucial.

what about more quality for less framerate? that way 32kbps is more than possible.

also, GOP size is important, and has a lot to do with compression AND error resilience.

large gop = smaller size/redundancy = small stream corruption becomes fatal small gop = big size/less quality per bitrate = more error-resilient

in x264, I recommend you to turn off variable AQ, Trellis and Psy-RD, and to increase the chroma quantizer offset to say 3, and to increase Beta of inloop deblocker, to about 3, without changing alpha. turn on PSNR everytime you test and look for the best settings. and use MeGUI for testing.

Camilo Martin
A: 

H.264 definitely will have the best quality for the same bitrate. However, it will need the most computational resources. So, encoding or decoding of multiple videos streams my not be feasible in some computers.

There is no way to know a priori the computational resources that H.264 (or video in general) encoding / decoding will need since this depends from the encoding parameters and from the video content. So, you should do some tests yourself in order to see if an average pc can encode/decode H.264 in real time, and if yes how many streams. This is not as hard as it seems. Use mencoder or x264 to H.264 encode with the desired parameters a long video. Take a look at the encoding frame rate. Now, before the first one finishes, start another instance of mencoder and take a look at the frame rate, etc.

If you finally find out that H.264 is not suitable for your needs, try h.263. It is an older protocol and is not able to achieve the compression rates of H.264, however it is specifically designed for video conferences, so it will have good quality in the situation you need it and also, since it is rather old, it is not very demanding on resources.

Serafeim