[FFmpeg-devel] [PATCH] swscale/output: Use av_sat_add32 in yuv2rgba64 templates to avoid underflow

Michael Niedermayer michael at niedermayer.cc
Tue Dec 13 22:32:13 EET 2022


Hi

On Mon, Dec 12, 2022 at 08:08:28PM +0000, Drew Dunne wrote:
> Previously I sent this patch to solve an overflow in these templates. That
> patch wasn't used in favor of one that biased the output calculations to
> avoid the double clipping. Now I've found an underflow case, which I've put
> the command below, and I'll attach an input image in a reply.
> 
> ./ffmpeg \
>   -f rawvideo -video_size 64x64 -pixel_format yuva420p10le \
>   -i yuv2rgb_underflow_w64h64.yuva \
>   -filter_complex \
>   "scale=flags=bicubic+full_chroma_int+full_chroma_inp+bitexact+accurate_rnd:in_color_matrix=bt2020:out_color_matrix=bt2020:in_range=mpeg:out_range=mpeg,format=rgba64[out]" \
>   -f rawvideo -codec:v:0 rawvideo -pixel_format rgba64 -map '[out]' \
>   -y underflow_w64h64.rgba64

can you trigger a under/overflow with real input ?
I mean something where each pixel has a RGB value that can be represented
or is close to such value

Iam asking because if this never happens with real input then a solution
would be to use unsigend ints

If this happens with real input values then input values from
0.0 to 1.0 would have to generate a -1.5 or +2.5 on output
thats quite a overshoot
your example if iam reading it correctly uses white and black pixls
with which have chroma values maxed out. but white and black in reality
would have all R=G=B and thus no color,

the extra cliping takes time and it does not feel like the correct fix for
this
If someone gives me a pixel that has luma only achievable with R=G=B=0 and
then at  the same time chroma only achievable with G=R=MAX B=0 or something
similar. and then the surrounding pixels also add more overshooting during
scaling then iam not sure in which situation the actually color matters
because this is not a "real" color

That said, if you can make a change that handles such odd fuzzed cases
with cliping i dont mind but i think we should not slow down real input
for cases that are not as long as we correct all undefined behavior
and of course ensure this cannot actually occur with real input

Now as you send a 2nd such patch i thought i explain my view a bit better

also does this atually trigger under/overflows in all teh chnaged components
or just some of teh components ?

thx

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20221213/cbd7f553/attachment.sig>


More information about the ffmpeg-devel mailing list