Uncompressed 24-bit RGB Video file format specifications

[bobkart]

WANTED. A Google search did not turn up anything useful. I had no problem finding file format specifications for WAV and BMP files, and implementing programs to generate them from scratch, or read existing such files, modify them and write them back out. I would now like to do the same for video, and chose the above format in the hopes that it will be the easiest to understand the file format of, and therefore implement programs to generate such files. If you think there might be an easier format to generate, other than just fewer bits per pixel, I welcome suggestions. I am trying to avoid having to reverse-engineer the file format specifications from examples. Yes I realize such files will be large, I will simply use them as input to rendering applications (TMPGEnc for example) to create useably-sized video files.

And if you think I am nuts for thinking I can find such specifications, understand them, and implement programs to generate video files from scratch, I welcome those opinions as well. But I did exactly that with WAV and BMP files in a matter of hours, admittedly video files are considerably more complex.

Thank you for any information you may be able to provide.

[jagabo]

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/ht...ereference.asp

[bobkart]

That's most of what I need to know, thanks jagabo.

Missing from that specification is the format of each individual uncompressed 24-bit RGB video frame.

[jagabo]

That's easy to figure out. It's just RGB triplets, width * height. I don't remember the order.

If you're working in Windows you don't even need to know. Just pass a 24bit bitmap to VFW or DShow.

[bobkart]

Okay . . . I guess it would be nice to know for sure the format, even simple things like which of the three bytes is red, green, and blue. And whether the first such triplet is the top-left corner or some other corner. Of course I could determine that stuff experimentally.

Seems like I might have enough to go on to at least get a start on this.

Thanks again jagabo.

[jagabo]

It's always left to right as far as I know. Look at rcFrame in AVISTREAMHEADER and dwHeight in AVIMAINHEADER:

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/ht...rstructure.asp

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/ht...rstructure.asp

I suspect if the bottom has a lower value than the top it is upside down, like with bitblt operations.

[bobkart]

Yeah I was going to look at those two header structures next. Finishing up some work now.

As long as it will understand if I just pack the RGB triplets for each frame in the DATA chunk, then I can experimentally determine both the RGB byte order and the top/bottom order. For example, when I was doing the BMP file generation, the byte order for the triplets was BGR instead of RGB, and the first row written to the file was the last (bottom) row displayed in the picture.

Thanks for the help.

[jagabo]

Yeah I was going to look at those two header structures next. Finishing up some work now.

As long as it will understand if I just pack the RGB triplets for each frame in the DATA chunk, then I can experimentally determine both the RGB byte order and the top/bottom order. For example, when I was doing the BMP file generation, the byte order for the triplets was BGR instead of RGB, and the first row written to the file was the last (bottom) row displayed in the picture.

That's what I'd do. Or just make a video with a distinctive pattern and look at a hex dump.

By the way, VirtualDub has a hex editor with a RIFF chunck tree view. Perfect for this. In a little test video I made the data was 3 bytes per pixel: Blue/Green/Red, left to right, bottom to top.

[bobkart]

Ah, very good, just like BMP files then. So each frame is byte-for-byte the same as the data portion of a (say, 720x480) BMP file.

I'm starting code this up, but don't quite understand how this works for files larger than 4GB since only 4 bytes are used for the file size in the second word of the RIFF header. Of course we've all seen AVI files larger than 4GB so there must be a way. Maybe I'll hex-dump (the first part of) one and have a look.

[jagabo]

AI'm starting code this up, but don't quite understand how this works for files larger than 4GB since only 4 bytes are used for the file size in the second word of the RIFF header.

I believe it's a simple as appending a whole new RIFF structure every 4GB. The same as COPY /B FILE1.AVI+FILE2.AVI+FILE3.AVI OUTPUT.AVI

[bobkart]

Aha. Yes that would work.

I coded most of this up last night. I just have to write the actual frames (which will be simple at first, just enough to make sure I'm writing it correctly). And of course there may be debugging in case I've gotten something wrong.

[bobkart]

Well I finished coding it up last night, and generated a short (30 frames), simple (all black frames) AVI file just to test that I am writing the proper format. WMP wouldn't play it ("Windows Media Player cannot play the file. One or more codecs required to play the file could not be found."). So off debugging I went. Started to look at a real AVI file from TMPGEnc, and found some discrepancies compared to what I was generating, corrected those, still no luck with WMP. Finally, after fixing everything I could find to fix, I thought, maybe WMP is the problem. Sure enough, I imported the file into TMPGEnc and it had no problem with it, played back in the Edit window as it should. Who knows how early on I was generating an acceptable format. I guess I can try to back out some of the fixes I make to determine that. And of course I need to generate some more interesting frames now to be sure they come through as intended. So I guess the mystery is why WMP had a problem with what I was generating, especially since it does play the one I generated from TMPGEnc easily enough.

[Cornucopia]

AFA the >4GB stuff:
You are using the OpenDML extension spec, right?

Here's a copy of it: http://www.the-labs.com/Video/odmlff2-avidef.pdf

Scott

[bobkart]

I'm just using the specifications jagabo provided links to. But I'll certainly have a look at the OpenDML extension specs too, thanks.

Tried some differing frames from one to the next and it's all good. Even took out the most recent "fix" I had added to try to get it to work with WMP (12 extra bytes at the end of the strf structure), and it still worked with TMPGEnc. Went ahead and rendered a WMV from the file I generated and everything worked as it should.

For the curious, files sizes come to right around 30MB per second of video (for 720x480, 30 frames/second). That's 1MB per frame by the way. At that size you can get 4142 frames in a 4GB file, that's 138 seconds worth of video. Prior to hearing about the OpenDML extension specs as a way of dealing with the 4GB RIFF file size limit, I proposed to cut over to a new RIFF structure every 4096 frames, as a nice round number.

[Cornucopia]

Yeah, that's what some vendors did prior to OpenDML coming out in the 1st place.

There's "Segmented" AVI's and "Referenced" AVI's, etc. Virtualdub could help you output these variations, just to get a look at what the differences are, and where it occurs in the stream.

I assume you also have a RIFF viewer of some sort...?

Scott

[bobkart]

No RIFF viewer at this point although I did write a specialized file dumper last night to help with the debugging (that I probably didn't need to do as much of). But the effort was not in vain since I got a file dumper out of it. Jagabo has mentioned VirtualDub's hex editor with RIFF chunk tree viewer, so that would be a next step for me if required, notwithstanding better suggestions from you or anyone else that may join this discussion. My main goal was to be able to write video files where I had complete control over what was in each frame, and chose this format as being the most straightforward to generate. So I don't plan to stay in this format, due to the large file sizes involved, I will just feed it to TMPGEnc and render it as I see fit. So I'm not really trying to be a master of the AVI format, I just wanted to get ANY way of representing video in a file that TMPGEnc would understand implemented. With emphasis of course on that way being as straighforward to generate as possible. This format certainly meets that requirement. It's the same reason I chose WAV and BMP file formats to generate in the past, other applications can handle any compression I may want to apply to what I generate, but I don't want to be concerned with it as I generate the data in the first place.

But by all means don't let any of that stop you from sending things my way, documentation links or suggestions. I appreciate any information you may be aware of that is related. I am only just getting started with this endeavour and thus am not at all aware of the various information resources out there.

[jagabo]

AFA the >4GB stuff:
You are using the OpenDML extension spec, right?

Here's a copy of it: http://www.the-labs.com/Video/odmlff2-avidef.pdf

Nice! I added it to my library.

[bobkart]

Ah, having scrolled down a bit further on the main list of subforums, I now see that there is a Programming Forum. So perhaps this Topic deserves to be there instead of here? Apologies for not making it there in the first place.

[bobkart]

Hmmm. I just generated a ~5GB AVI file, creating a new RIFF structure (as jagabo suggested) after 4096 frames (to get around the 32-bit limit on the file size) and TMPGEnc would only import the first 4096 frames. I guess I'd better have a look at that OpenDML extension spec now.

Oh and any chance of getting this Topic moved to the Programming Forum, since I'd likely get more people that know what I'm asking about looking at it there?

[bobkart]

Here's one of the videos I've generated: http://bobkart.gt3times.com/WMV/cmw.wmv

[bobkart]

A little bit better one, same song: http://bobkart.gt3times.com/WMV/cmw2.wmv

[bobkart]

Doing dual traces now (left and right channels), still the same song: http://bobkart.gt3times.com/WMV/cmw-2ch.wmv

I'm noticing what I suppose are compression artifacts, more so on the lower (blue) trace, where some pixels of blue kind of hang about after they should be gone. A bit surprised by that kind of "mistake" in a 1000Kb/s WMV. Anyone else experience something like that with TMPGEnc? I guess I'm kind of wondering if it's a bug or to be expected. I'd think this video material would be easy enough to encode without that kind of artifact.

[bobkart]

And the "filled" version of the dual-trace video: http://bobkart.gt3times.com/WMV/cmw2-2ch.wmv

[bobkart]

Final version although I may render it with more bitrate since TMPGEnc struggled here and there:

http://bobkart.gt3times.com/WMV/CMW6.wmv

There is also an HD version but it's over 200MB:

http://bobkart.gt3times.com/WMV/CMW-HD.wmv