Hi, the original issue I encountered was that FATE failed on RISC-V because
the assembly code didn't handle `rv40_bias` correctly.
I submitted a new patch: "checkasm/rv40dsp: cover more cases for rv40_bias"
to test this situation.
The value of `src` was indeed just copied from `h264_chroma_mc`. Maybe you
or someone more familiar with this can submit a better solution.
Christophe Gisquet <christophe.gisq...@gmail.com> 于2024年12月5日周四 14:41写道：
> Hello,
>
> Le mer. 4 déc. 2024 à 10:14, <uk7b-at-foxmail....@ffmpeg.org> a écrit :
> > @@ -27,7 +27,7 @@
> > #define randomize_buffers() \
> > do { \
> > for (int i = 0; i < 16*18*2; i++) \
> > - src[i] = rnd() & 0x3; \
> > + src[i] = rnd() & 0xff; \
>
> I don't understand why the original code would be correct. It looks to
> be a sample buffer, in which case 8 bits chroma being in [0; 3] sounds
> weird.
> This is in the original h264chroma_mc code.
>
> (and in this case, a UT may also alternating patterns to also check
> overflows, like columns or lines or diagonals alternating between 0
> and 255, but this goes beyond just correct code, and probably impact
> luma MC more)
>
> --
> Christophe
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
