[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