[FFmpeg-devel] [PATCH] libavcodec/mjpeg: keep last_dc value unclipped
Andreas Rheinhardt
andreas.rheinhardt at outlook.com
Fri Jun 7 22:34:48 EEST 2024
Ramiro Polla:
> Do av_clip_int16(val) _after_ copying the value to last_dc.
>
> Related commits: c28f648b19d and dffae122d0f
> Related ticket: 4683
> ---
> libavcodec/mjpegdec.c | 3 +--
> tests/ref/fate/jpg-12bpp | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> index 1481a7f285..7daec649bc 100644
> --- a/libavcodec/mjpegdec.c
> +++ b/libavcodec/mjpegdec.c
> @@ -843,9 +843,8 @@ static int decode_block(MJpegDecodeContext *s, int16_t *block, int component,
> return AVERROR_INVALIDDATA;
> }
> val = val * (unsigned)quant_matrix[0] + s->last_dc[component];
> - val = av_clip_int16(val);
> s->last_dc[component] = val;
> - block[0] = val;
> + block[0] = av_clip_int16(val);
> /* AC coefs */
> i = 0;
> {OPEN_READER(re, &s->gb);
> diff --git a/tests/ref/fate/jpg-12bpp b/tests/ref/fate/jpg-12bpp
> index b3c662d587..9b039a92c6 100644
> --- a/tests/ref/fate/jpg-12bpp
> +++ b/tests/ref/fate/jpg-12bpp
> @@ -3,4 +3,4 @@
> #codec_id 0: rawvideo
> #dimensions 0: 999x749
> #sar 0: 1/1
> -0, 0, 0, 1, 1496502, 0xd91deb4b
> +0, 0, 0, 1, 1496502, 0x44efc0af
Is the change for the fate-sample supposed to be an improvement or what
is the rationale for this? (Is this change mandated by the spec?)
- Andreas
More information about the ffmpeg-devel
mailing list