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

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

[John Cox]

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?

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?

I've tested by hand with libswscale/test/swscale but fate integration
would be obviously better - I'm currently a bit lost in fate, where/how
should I do this?

Many thanks

John Cox
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1985 bytes --]

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)


> 
> 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

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".

Re: [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
>
>[...]
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2814 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 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".