1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2025-08-04 22:03:09 +02:00

avcodec/mpeg4videoenc: Fix data race when using AC prediction

The check for whether we can use the fast path to process
AC coefficients used the qscale value belonging to a different
slice; this worked in practice, because the predicted AC values
are zero in this case, so it does not matter whether we use
the fast or the slow path.

Fix this by checking for first_slice_line instead. This fixes all
the races in the encoding part of the vsynth*-mpeg4-thread tests
(and fixes them if no frame threading is in use for the decoding part).

(The left prediction check may use data from a different slice, too,
but said slice is always processed by the same thread, so that no race
can happen. Given that out-of-slice AC values are zero, it does not
matter whether we use the fast path or the slow path either.)

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit is contained in:
Andreas Rheinhardt
2025-06-14 03:47:00 +02:00
parent 5cdce56a79
commit 34953e195f

View File

@ -205,7 +205,7 @@ static inline int decide_ac_pred(MPVEncContext *const s, int16_t block[6][64],
const int xy = s->c.mb_x + s->c.mb_y * s->c.mb_stride - s->c.mb_stride;
/* top prediction */
ac_val -= s->c.block_wrap[n] * 16;
if (s->c.mb_y == 0 || s->c.qscale == qscale_table[xy] || n == 2 || n == 3) {
if (s->c.first_slice_line || s->c.qscale == qscale_table[xy] || n == 2 || n == 3) {
/* same qscale */
for (i = 1; i < 8; i++) {
const int level = block[n][s->c.idsp.idct_permutation[i]];