After doing the sequential image dump, I mentioned that a few things had pricked my interest, and one of those was working with Wave files. By odd coincidence AVI files also use the same container format, so I'm taking the opportunity to write a small standalone program to take these sequential images and sound and convert them to an (uncompressed) AVI.
The format used (RIFF) is an odd beast. I had some fun with it when working on Wave files in the past, and AVI files take that fun and turn the volume up to 11. It's not that it's difficult, it's more the case that it's quite clunky, awkward and poorly documented. Based on an original design from 1984 (which I believe was used for DeluxePaint, Adrian Carmack's weapon of choice) and filtered through the tender loving care of Microsoft and IBM's short-lived alliance, what emerged was something that definitely had four arses instead of a mouth.
Tricksy and messy to work with - oh yeah.
Anyway, the eventual end goal of this is going to be a simple standalone cross-platform C-based AVI writing library with no dependencies that should be usable in any Quake engine (or elsewhere if you wish). Let's see how far we get along the road to that goal!
Wednesday, February 2, 2011
More Fun with AVIs
Posted by
mhquake
at
1:45 AM
Subscribe to:
Post Comments (Atom)
2 comments:
Be aware that by default AVI has a 2GB file size limit which is tiny for uncompressed video. Even 4GB is too small (so goodbye FAT32).
You would be much better of with a modern container like Matroska. That one also supports Ogg Vorbis (which is superior to MP3 in terms of quality/size) and fully supports H264. Alternatively, webm (which basically uses Matroska as container) which would also be a good target for compressed video?
AVI is old, awkward, limited and should not be used anymore for "the things of future".
> Be aware that by default AVI has a 2GB file size limit which is tiny for uncompressed video. Even 4GB is too small (so goodbye FAT32).
That's all accepted; there is an AVIX chunk which allegedly supports larger file sizes but it's one step at a time for now. Another possible option is to use JPG compression on the video data (the format spec allows it) to get sizes down.
A more modern format would certainly be preferable but the problem with that is maintaining cross platform support in a reasonably sane manner. As soon as you need to start messing with external codecs you veer off into OS-dependent land, which is something I'd prefer to avoid here. It's all a matter of balances and selecting the option that - while not necessarily perfect - at least gets the job done without too much extra hassle.
Post a Comment