Need to find a lossless video *or* image format with certain features...

[slugg]

I need to be able to store video data. This can be done as a video (preferred) or as a series of images. Either is fine.

The format must be lossless. Compression is not required, but would be nice.

The format must also have a readily available, easy to use library for manipulating the video/image files in C, C++, or Objective-C. C is strongly preferred.

Here's where it gets weird. The video information is your typical 8 bit rgb image, plus one more 16 bit field from a separate sensor. So this could be stored as a 5 channel image, where the 4th and 5th channels are just the upper and lower bits of the 16 bit field. Or, alternatively (preferred), the format could support a 4th channel that's 16 bits wide.

So far, what I have in mind is a custom variant of PPM/PGM image files, stored as a sequence (each file is a video frame). It's a large file format and terribly naive, but hard drive space or even "user friendliness" isn't really a concern. The problem with this approach, however, is that we'd now be performing 30 fopen's and fclose's per second, which I have a feeling will cause problems when the operating system's scheduler decides to stop being nice to my software.

Any thoughts, insight, etc. are greatly appreciated

 

[Ken g6]

So, you say you want to store a sequence of files? And to avoid multiple file opens and closes, you'd like to store them linearly in one file, as if they were archived on a tape? :sneaky:

Sorry, I don't know enough real video formats to suggest one of those.

 

[degibson]

Out of band to Ken:
1. I think the ASM comment was better
2. That Yuck! is totally out of context.

 

[esun]

Does it need to be written to the final format in real-time? If not, then just dump the video data (compress it first if you want) to a binary file, then post-process it into the format that you want.

 

[DaveSimmons]

You could store any number of frames to a single file by opening the file once then for each frame:

1. compress frame to memory buffer
2. write buffer size to file
3. write buffer to file

To read the file later you (read the size, read the buffer, decode the buffer back to a bitmap) for each frame. Use a buffer size of -0- as a marker to stop reading.

You'll want to close the file and start a new one every so often to keep sizes reasonable.

 

[slugg]

Dave, I like that. Do you have any suggestions for cheap compression/decode?

 

[slugg]

Does it need to be written to the final format in real-time?

This would be ideal... Any ideas?

 

[Cogman]

http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html
Huffyuv is going to be your best bet, though, you'll probably have to write something special for yourself as this is a unique problem.

The link above is an implementation of Huffyuv, you'll probably want to tweak things so it will spit out and consume your data correctly (you will have to do this with pretty much any storage method.)

The problem you'll have is that better compression methods are going to result in much higher CPU utilization. Not only that, but there are very few codecs specifically designed for an RGB color space. H.264 via x264 will probably give you the best lossless compression ratio (yep, it does that), but you would have to switch your data to a YUV color space. That, and any changes to the way x264 works are going to be difficult to say the least.

So yeah, some implementation of an adaptive huffman tree is probably going to be your best bet. Especially if the data is something like a computer screen shot (lots of repeated colors). For camera footage, the adaptive huffman tree is only slightly better sometimes than just doing things uncompressed.

The advantage to the adaptive huffman tree is that it is extremely quick.