Okay, it has been modified in this reply.

Martin Storsjö <martin@martin.st> 于2023年12月29日周五 22:35写道：

> On Fri, 29 Dec 2023, James Almer wrote:
>
> > On 12/29/2023 9:16 AM, Martin Storsjö wrote:
> >> On Fri, 29 Dec 2023, flow gg wrote:
> >>
> >>> Tests on x86 might fail, possibly due to a 16-bit sub overflow
> >>
> >> If this only happens in checkasm but not in real life use, it means
> > that
> >> the checkasm test input is out of range, and we should try to mimic the
> >> real input data.
> >>
> >> If the issue is off-by-one due to rounding, we could allow it by making
> >> a comparison per element, and tolerate a certain diff (maybe only on
> > x86).
> >>
> >> But if it is an actual overflow on valid input data, the x86 asm
> >> definitely needs to be fixed, by someone... Worst case, we might want
> > to
> >> disable that checkasm test on x86 temporarily.
> >
> > The function subtracts an int16 from an int8, whose result may not fit
> > on an int16. The x86 asm expects it to do, hence the failures.
> >
> > I don't know if such cases exist in real world files, so like you said,
> > if they don't then the test should generate in-range input. But if they
> > do, i'll fix the x86 asm (sadly, this means sse4 will be required
> > instead of sse2).
>
> I think it's probably best to limit the checkasm inputs that don't
> overflow, for now.
>
> // Martin
> _______________________________________________
> 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".
>