image compression algorithms

Converting each frame into a jpeg image is a decent option. You can vary the compression quality to trade off bandwidth vs quality.

Using a more advanced video format of some kind (like say H.264) should give you better quality for the same bandwidth, but it'll have higher CPU costs to encode the video. Latency will probably also be higher.

Also consider changing the resolution of the image before compression - compressing a small image is quicker.

Quote:

Original post by john_q61 Recovery due to transmission errors is not important.

Unfortunately, it is.

Most formats, including h264 and mpeg use concept of GOP (group of pictures) as well as multipass encoding (either over last n pictures or over entire video) for both, improvement in compression as well as error recovery. Depending on settings, forward error correction determines how much such video is delayed and how long it takes to recover from errors. Typically an error will require 0.6seconds to resync, but it may be more.

Even if sending data as JPEG frames, each individual picture is compressed with something like arithmetic encoding which has catastrophic behavior in case of error.

What you are asking is same as OnLive technology, and they had to develop both their own hardware as well as custom compression.

If no motion detection is done assuming fairly rich scenery, then sending individually images at 4:1 compression will have fairly high bit-rate. Assuming 720p this means 1280x720x3 (at 30fps) (at .25%) = 20 Megabytes per second.

Quote:

What would be an ideal compression algorithm to use to maximize the frame rate

Reduce video resolution. 320x200 can stream 30 frames every single 1080p frame.


What it comes down to here are exact requirements. Available hardware and software, latency requirements (is 1-5 second latency acceptable) and error recovery characteristics.

@Antheus -

Thanks. That's informative.

Why can't I use a lossy compression algorithm - similar to those used in video compression? After all I dont care about loss of some information. I am thinking any scalar or vector quantization algorithm. Will it work in this case? Any tutorials or pointers available since I am new in this field.

Quote:

Why can't I use a lossy compression algorithm - similar to those used in video compression?

JPEG is a lossy compression algorithm, that is often used for videos. It may or may not work acceptably for you. See http://en.wikipedia.org/wiki/Motion_JPEG

What will work depends on your exact requirements. For example:

How much network bandwidth is available?
What's the resolution of the video?
What frame rate?
How much latency can you tolerate on top of the network latency?
How much processing power have you got at each end of the connection?

FFMpeg supports encoding and decoding in (almost all?) video formats. You are going to run into two issues: encoding/decoding speed and bandwidth over the network. This means you'll likely have to set the encoding parameters to reduce the video dimensions and drop a lot of information so that it can encode quickly enough. I have zero pointers other than to take a look at that, or some other library that could already take care of some of that for you.

I don't know much about video/image compression so maybe this is a stupid suggestion, but have you considered simple DXT compression with something like FastDXT? It gives 8:1 and you don't have to unpack/decode it on the client machine.

Nothing fancy (doesn't exploit any frame-to-frame coherence, etc) and I don't know if it is fast enough, but maybe it is just 'good enough' for what you want to do.

Original post by Adam_42

Quote:

Why can't I use a lossy compression algorithm - similar to those used in video compression?

Quote:

How much network bandwidth is available?

Varies. For starters lets assume lo-end 100 Mbps office lan.

Quote:

What's the resolution of the video?

Input side - computer screen (say 640x480). Assume same for output.

Quote:

What frame rate?

~30 fps to be received by the ouput

Quote:

How much latency can you tolerate on top of the network latency?

Office lan. For now latency may not be a factor.

Quote:

How much processing power have you got at each end of the connection?

Pentium 2.8GHZ dual core at both ends

Quote:

Original post by john_q61 Quote: How much network bandwidth is available? Varies. For starters lets assume lo-end 100 Mbps office lan.

See, this is why information up front is important - we all thought you wanted to do this across the *internet* [smile]

Chucking 640x480 video across a LAN is (relatively speaking) a piece of cake. JPEG compressed frames should work fine, as long as you have sufficient encoding power at the source.

Quote:

Original post by swiftcoder Quote: Original post by john_q61 Quote: How much network bandwidth is available? Varies. For starters lets assume lo-end 100 Mbps office lan. See, this is why information up front is important - we all thought you wanted to do this across the *internet* [smile] Chucking 640x480 video across a LAN is (relatively speaking) a piece of cake. JPEG compressed frames should work fine, as long as you have sufficient encoding power at the source.

And you thought right. It will be modified to be sent across the internet. That is obviously the core issue. I don't wish to implement JPEG and then change to another algorithm later on. I am thinking H.264 or one of the algorithms suggested above. But I am a novice. There are a zillion compression algorithms. How do I pick the right one for my needs? Help on tutorials/links is much appreciated.