mvidmoviemaker 24 vs 32 bpp detection renders 24bpp images with 0xFF as alpha value

[mdejong]

Currently, the mvidmoviemaker command line app needs to render at 32bpp and then mark the video as 24bpp post rendering when no pixels with alpha or partial alpha values were found. The result of this logic is that black pixels are represented as 0xFF000000 instead of 0x0. This may or may not be optimal WRT data compression. It is handy for the case where 24bpp pixels are converted to 32bpp pixels, because the values can remain the same, but that is not clearly needed at runtime.

What is more of a concern is that if black pixels are 0x0, then a large number of black pixels can be represented as a run of 0x0 bytes, as opposed to pixels at binary data compression time. Previously, all black pixels were always explicitly marked as 0x0 in a 24BPP file. If this logic is changed, then new code that will rewrite each pixel and then calculate the adler again after all frames have been written will be needed to support detection and explicit setting of the bpp. At 32BPP, the 0xFF will always be needed for a fully opaque pixel.

The complication is that once the pixels are rendered and written, then it is too late to go back and rewrite them because the delta logic is already done and delta pixels are more complex to deal with than keyframes. One approach would be to scan the input but not actually write it in one loop, then do the actual write. Another approach would be to emit keyframes into an .mvid and then when all that was done, actually write the keyframe data as deletas with the proper modifications (0xFF alpha set to 0x0) done before passing the data to be written. After a first attempt, it seems like a scan would be the most simple to implement, then do the actual write.