[FFmpeg-devel] [RFC] swscale RGB24->YUV420P

[John Cox]

On Wed, 16 Aug 2023 19:37:02 +0200, you wrote:

>On Wed, Aug 16, 2023 at 05:15:23PM +0100, John Cox wrote:
>> Hi
>> 
>> The Pi has a use for a fast RGB24->YUV420P path for encoding camera
>> video. There is an existing BGR24 converter but if I build a RGB24
>> converter using the same logic (rearrange the conversion matrix and use
>> the same code) I get a fate fail on filter-fps-cfr (and possibly others)
>> which appears to decode a file to RGB24, convert to YUV420P and take the
>> CRC of that so almost any change to the conversion breaks this
>> (unrelated?) test.
>> 
>> My initial assumption was that if the code to conversion in
>> libswscale/rgb2rgb_template:bgr24toyv12_c was good enough for BGR24->YUV
>> then it should be good enough for RGB24->YUV too. However it breaks this
>> fate case - what is an acceptable way to resolve this?
>
>update the checksum (if needed), and put the code under appropriate bitexact flags checks
>(there may be remaining issues but hard to say without seeing and being
>abel to test the code)

Thanks for the prompt answer. The current test invocation goes:

 /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -nostdin -nostats
-noauto_conversion_filters -cpuflags all -auto_conversion_filters
-hwaccel none -threads 1 -thread_type frame+slice -i
/home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov
-r 30 -vsync cfr -pix_fmt yuv420p -bitexact -f framecrc -

Which appears, at first sight, to already have the required bitexact
flag in it, however it doesn't get passed to the swscale context - in
order for that to happen I need something like:

 /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -fflags bitexact -nostdin
-nostats -noauto_conversion_filters -cpuflags all
-auto_conversion_filters -hwaccel none -threads 1 -thread_type
frame+slice -i
/home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov
-r 30 -vsync cfr -vf scale=sws_flags=bitexact -pix_fmt yuv420p -bitexact
-f framecrc -

i.e. adding an explicit "-vf scale=sws_flags=bitexact". Is this the
correct answer or is it a bug that the auto conversion fails to respect
the existing bitexact flag?

>> A further question assuming that the above can be resolved - I have also
>> written aarch64 asm for this (RGB24/BGR24->YUV420P). It costs nothing in
>> the asm to round the output values to nearest rather than just rounding
>> down as the C template does and doing so improves the accuracy reported
>> by tests/swscale - however at that point the asm and the C don't produce
>> identical results. I assume that the x86 asm for BGR24 conversion does
>> match the C. What is the best thing to do here?
>
>The more differences there are between implementations the more annoying
>it is but there is a bitexact flag that allows differences

Thanks

John Cox

>thx
>
>[...]