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 > >[...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
