[FFmpeg-devel] [PATCH v2 1/2] checkasm/rv40dsp: cover more cases
flow gg
hlefthleft at gmail.com
Thu Dec 5 09:25:09 EET 2024
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.gisquet at gmail.com> 于2024年12月5日周四 14:41写道:
> Hello,
>
> Le mer. 4 déc. 2024 à 10:14, <uk7b-at-foxmail.com at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>
More information about the ffmpeg-devel
mailing list