On Thu, Aug 17, 2023 at 10:42:13AM +0100, John Cox wrote:
> 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?

It would be ideal that the main "-bitexact" gets passed to sws_flags

a patch fixing that would be welcome! But one needs to still be
able to remove the bitexact flag from sws_flags, only the default should
change when -bitexact is specfied and nothing specific is specified for sws_flags

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle