This is the equivalent of VLC_CODEC_ARGB used below, without the alpha.
The TODO on RGB mask in ce0db74040 means
they not have been known when it was written. The new code is not the
code that could have been assume (BGRX on Little Endian).
The documentation [1] for CAIRO_FORMAT_ARGB32 says:
"alpha in the upper 8 bits, then red, then green, then blue. The 32-bit
quantities are stored native-endian."
So this is ARGB on Big-Endian and BGRA on Little-Endian.
[1] https://www.cairographics.org/manual-1.0.2/cairo-Image-Surfaces.html
Those functions can be useful in other places.
One useful case will be to attach color properties properly in the cvpx converter's output image buffers in a future fix without duplicating this mapping code.
The libavutil formats will always be mapped to the VLC chromas without
a mask. VLC_CODEC_RGB32 will still be masked to libavutil chromas when
the mask matches or loosely if no mask matches.
The original format may be using a chroma that relies on the RGB masks.
Since we change the chroma we should not reuse the mask from the previous
chroma.
Fix the -Wstringop-truncation warning by setting a correct size to the
line being read:
../../modules/codec/telx.c: In function ‘Decode’:
../../modules/codec/telx.c:583:9: warning: ‘__builtin_strncpy’ output may be truncated copying 127 bytes from a string of length 255 [-Wstringop-truncation]
583 | strncpy( p_sys->ppsz_lines[0], psz_line,
| ^
../../modules/codec/telx.c:535:9: warning: ‘__builtin_strncpy’ output may be truncated copying 127 bytes from a string of length 255 [-Wstringop-truncation]
535 | strncpy( p_sys->ppsz_lines[row], t,
| ^
../../modules/codec/telx.c:501:9: warning: ‘__builtin_strncpy’ output may be truncated copying 127 bytes from a string of length 255 [-Wstringop-truncation]
501 | strncpy( p_sys->ppsz_lines[0], psz_line,
| ^
Since at most `len` characters are read from the input, and an utf-8
caracter is written in the output for each character from the input,
and since the to_utf8 function only supports utf-8 characters with at
most 3 characters, then it's not possible to write more than 3 times len
into the output buffer, without accounting the terminating character.
Additional related changes are made to:
- Move the creation of psz_line close to decode_string, since that's
the main first user and it needs the size of the buffer, helping
readability.
- Add assertion checking that we don't extend utf-8 to 4 bytes, which
is mainly for development, since the function will not outreach the
bounds of psz_line anyway.
- Add some documentation for `decode_string` so it's clearer how the
length of the buffer should be assigned.
VideoToolbox decoder doesn't attach all color properties to image buffers.
Current display modules handle tonemap without them.
Attaching additional color properties to image buffers is mandatory for native image buffer display on macOS in order to have proper colors tonemap when AVFoundation APIs are used to render them and prevent flickering while using multiple displays with different colorsync profiles
If the mask corresponds exactly, we have an exact match. If the RGB source
has a mask but none of the RGB mapping uses the same mask, we map to
a close RGB format with a different mask.
It's better than using the first VLC_CODEC_RGBxx in the list if there's
one corresponding to the exact match.
Another option would be to move the VLC_RGB_ES() calls at the end of the
list.
The macros can not handle alpha channel properly,
as it does not only requires reassigning channels
but shifting.
Mapping to/from RGB32 also loses alpha information.
We can not rely on AV native macros for this and
need to declare chroma with fixed alpha position
Could also modify the macro to add left or right
shifts parameters and even less readable for 2 chromas.
Steve Lhomme
Alexandre Janniaux
Francois Cartegnie
Maxime Chapelet
Marvin Scholz
Alaric Senat