Switch from VLC_CODEC_BGR555LE to VLC_CODEC_RGB555LE for capture of
16-bit screens. Note that the wingdi video output is already using
VLC_CODEC_RGB555LE for 16-bit output. Documentation also demonstrates
that VLC_CODEC_RGB555LE is correct as VLC_CODEC_RGB555LE is internally
documented as "g3B5 0R5G2" and Microsoft documents 16-bit DIBs as having
the following format [1]:
"The relative intensities of red, green, and blue are represented with
five bits for each color component. The value for blue is in the least
significant five bits, followed by five bits each for green and red. The
most significant bit is not used."
[1] https://learn.microsoft.com/en-us/previous-versions/dd183376(v=vs.85)
On Windows, 256 color bitmaps always have color palettes. Prior to this
change, we captured palette indexes where we expected 8bpp RGB bytes.
Since GDI will happily convert[1] to and from bitmaps of differing
depths, we now write out a 24bpp bitmap for 256 color screen depths and
let GDI convert to the paletted format. Specifically [1], "[i]f the
color formats of the source and destination device contexts do not
match, the BitBlt function converts the source color format to match the
destination format."
[1] https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-bitblt
We can't detect it with BITSPIXEL according to [1]:
> When nIndex is BITSPIXEL and the device has 15bpp or 16bpp, the return value is 16.
And as the comment says, the "bitmap" format is really 15 bits, just as
in BITMAPV5HEADER [2]:
> If the bV5Compression member of the BITMAPV5HEADER structure is BI_RGB,
> the bmiColors member of BITMAPINFO is NULL. Each WORD in the bitmap
> array represents a single pixel. The relative intensities of red, green, and
> blue are represented with five bits for each color component. The value
> for blue is in the least significant five bits, followed by five bits each for
> green and red. The most significant bit is not used.
[1] https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getdevicecaps#return-value
[2] https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv5header
It is not used in POSIX systems. On other system it probably don't make a
difference anymore, only Windows has actual useful values for
VLC_THREAD_PRIORITY_XXX. The synchronization is more important than having some
threads called more often than others.
Steve Lhomme
Jeffrey Knockel
Alexandre Janniaux
Johannes Kauffmann
Marvin Scholz