[FFmpeg-devel] [PATCH v2 2/3] avutil: add RGBF16 pix_fmt

[martin schitter]

On 14.10.24 00:45, Michael Niedermayer wrote:
> On Sun, Oct 13, 2024 at 08:03:56PM +0200, Martin Schitter wrote:
>> ---
>>   libavutil/pixdesc.c              | 25 +++++++++++++++++++++++++
>>   libavutil/pixfmt.h               |  4 ++++
>>   libavutil/version.h              |  2 +-
>>   tests/ref/fate/imgutils          |  4 ++++
>>   tests/ref/fate/sws-pixdesc-query | 11 +++++++++++
>>   5 files changed, 45 insertions(+), 1 deletion(-)
>>AV_PIX_FMT_VULKAN
> [...]
>> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
>> index 3caa183..4efc4cb 100644
>> --- a/libavutil/pixfmt.h
>> +++ b/libavutil/pixfmt.h
>> @@ -400,6 +400,9 @@ enum AVPixelFormat {
>>   
>>       AV_PIX_FMT_VUYA,        ///< packed VUYA 4:4:4:4, 32bpp (1 Cr & Cb sample per 1x1 Y & A samples), VUYAVUYA...
>>   
>> +    AV_PIX_FMT_RGBF16BE,    ///< IEEE-754 half precision packed RGB 16:16:16, 48bpp, RGBRGB..., big-endian
>> +    AV_PIX_FMT_RGBF16LE,    ///< IEEE-754 half precision packed RGB 16:16:16, 48bpp, RGBRGB..., little-endian
>> +
>>       AV_PIX_FMT_RGBAF16BE,   ///< IEEE-754 half precision packed RGBA 16:16:16:16, 64bpp, RGBARGBA..., big-endian
>>       AV_PIX_FMT_RGBAF16LE,   ///< IEEE-754 half precision packed RGBA 16:16:16:16, 64bpp, RGBARGBA..., little-endian
> 
> this would change the values of AV_PIX_FMT_RGBAF16BE and later
> which would break ABI

O.k. -- I'll simply move it down to the end of the list without much 
grumbling.

> new values have to be added so nothing changes (that generally means adding them
> before AV_PIX_FMT_NB, but sometimes soms enums have fixed entries before
> which additions are possible)

In fact I can't find any entry with such a fixed enum value resp. useful 
group separator in this list!

This makes it very hard to place new entries into the semantic context 
of one of these hinted hw accel related sections resp. at the end of 
such a group.

And I also don't get, why the section of hw accel independent formats 
isn't placed at the end of the list or another section gets reserved for 
arbitrary new entries to prevent that all additions look like members of 
the last defined hw specific accel group?

But simply accepting the compatibility requirements of this list and 
their unmediated use in multiple libraries is indeed more important.

Martin