Re: [FFmpeg-devel] [PATCH] tests/fate/image: add a test for half-float dwab compressed stream

[James Almer <jamrial@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3940 bytes --]

On 5/6/2025 6:39 PM, James Almer wrote:
> On 5/6/2025 6:26 PM, Michael Niedermayer wrote:
>> On Tue, May 06, 2025 at 06:10:22PM -0300, James Almer wrote:
>>> On 5/6/2025 5:44 PM, Michael Niedermayer wrote:
>>>> On Mon, May 05, 2025 at 04:44:06PM -0300, James Almer wrote:
>>>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>>>> ---
>>>>>    tests/fate/image.mak                        | 3 +++
>>>>>    tests/ref/fate/rgb-scanline-dwab-half-float | 6 ++++++
>>>>>    2 files changed, 9 insertions(+)
>>>>>    create mode 100644 tests/ref/fate/rgb-scanline-dwab-half-float
>>>>>
>>>>> diff --git a/tests/fate/image.mak b/tests/fate/image.mak
>>>>> index 042cf6438f..abf204f69f 100644
>>>>> --- a/tests/fate/image.mak
>>>>> +++ b/tests/fate/image.mak
>>>>> @@ -124,6 +124,9 @@ fate-exr-rgb-scanline-pxr24-float-12x8: CMD = 
>>>>> framecrc -i $(TARGET_SAMPLES)/exr/
>>>>>    FATE_EXR += fate-exr-rgba-multiscanline-half-b44
>>>>>    fate-exr-rgba-multiscanline-half-b44: CMD = framecrc -i 
>>>>> $(TARGET_SAMPLES)/exr/rgba_multiscanline_half_b44.exr -vf scale - 
>>>>> pix_fmt gbrapf32le
>>>>> +FATE_EXR += fate-rgb-scanline-dwab-half-float
>>>>> +fate-rgb-scanline-dwab-half-float: CMD = framecrc -i 
>>>>> $(TARGET_SAMPLES)/exr/rgb_scanline_dwab_half_float.exr -vf scale - 
>>>>> pix_fmt gbrpf32le
>>>>> +
>>>>>    FATE_EXR += fate-exr-rgb-scanline-float-b44
>>>>>    fate-exr-rgb-scanline-float-b44: CMD = framecrc -i 
>>>>> $(TARGET_SAMPLES)/exr/rgb_scanline_float_b44.exr -vf scale -pix_fmt 
>>>>> gbrpf32le
>>>>> diff --git a/tests/ref/fate/rgb-scanline-dwab-half-float b/tests/ 
>>>>> ref/fate/rgb-scanline-dwab-half-float
>>>>> new file mode 100644
>>>>> index 0000000000..a5a1997785
>>>>> --- /dev/null
>>>>> +++ b/tests/ref/fate/rgb-scanline-dwab-half-float
>>>>> @@ -0,0 +1,6 @@
>>>>> +#tb 0: 1/25
>>>>> +#media_type 0: video
>>>>> +#codec_id 0: rawvideo
>>>>> +#dimensions 0: 512x512
>>>>> +#sar 0: 1/1
>>>>> +0,          0,          0,        1,  3145728, 0xbb11b00a
>>>>
>>>> differnt result here: (on linux x86-64)
>>>>
>>>> --- ./tests/ref/fate/rgb-scanline-dwab-half-float    2025-05-06 
>>>> 22:40:40.017406113 +0200
>>>> +++ tests/data/fate/rgb-scanline-dwab-half-float    2025-05-06 
>>>> 22:40:53.297513198 +0200
>>>> @@ -3,4 +3,4 @@
>>>>    #codec_id 0: rawvideo
>>>>    #dimensions 0: 512x512
>>>>    #sar 0: 1/1
>>>> -0,          0,          0,        1,  3145728, 0xbb11b00a
>>>> +0,          0,          0,        1,  3145728, 0x2a15f7aa
>>>> Test rgb-scanline-dwab-half-float failed. Look at tests/data/fate/ 
>>>> rgb-scanline-dwab-half-float.err for details.
>>>
>>> Yeah, I can reproduce it, and even if i add "sws_flags
>>> +accurate_rnd+bitexact" i get the same results (0xbb11b00a on Win64,
>>> 0x2a15f7aa on Linux x86-64). I also get a different hash in both 
>>> targets if
>>> i don't rescale to gbrpf32, so the problem is not in swscale.
>>>
>>> Neither Valgrind or gcc-usan complain, so I'm not sure what could be
>>> producing this difference.
>>
>> float is not bitexact in C, and float on x86 might use old x87 style 
>> while
>> x86-64 might be SSE*/AVX, so if theres any float in the code slight 
>> differences
>> can happen, no idea if half float in this case is affected by this or not
> x87 float instructions are not used in x86_64, which is both these 
> targets. For float16 it will either use CPU instructions if available, 
> or the fallback we have using a lookup table (through float2half and 
> half2float).

Ok, turns out the Win64 target had the F16C instruction set enabled, 
which surprisingly results in that difference (Many other tests also use 
half float samples and the lookup table fallback matches the F16C output).
Might have to look further to find out why.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".