[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