On Tue Jan 10 03:36:41 2023 +0000, Zebediah Figura wrote:
`biBitCount` of 24 apparently means RGB555 in MS-CRAM, and gstreamer
agrees (see the gst-discoverer-1.0 output in the bug report), and the data comes directly from the `strf` header of the AVI file. Okay, I had to look up how Video-1 actually works to understand what this means. For the benefit of anyone else reading this, Video-1 basically works by quantizing 4x4 blocks into a maximum of 8 distinct colors, but the colors themselves retain the full depth of the "decoded" format, which is either 8-bit palettized RGB, or 16-bit RGB 5/5/5. Anyway, are we sure this isn't a bug in the decoder? Should msvidc32 allow bit counts other than 8 and 16? It certainly seems suspicious that it cares in ICM_DECOMPRESS_GET_FORMAT but not any other functions.
There are tests for `ICM_DECOMPRESS_GET_FORMAT`. I tried to get Windows to report success for any `biBitCount` input that is not 8 or 16, to no avail. So I concluded that `ICM_DECOMPRESS_GET_FORMAT` is implemented correctly and I had to fix the caller.
I first implemented some manual fix-ups to the `BITMAPINFOHEADER` in the comctl32 code, but later I found the `ICGetDisplayFormat` function, tried it to see if using it would fix the issue, and it did.