On Thu, Jul 28, 2022 at 01:18:07AM +0300, Mohammad AlSaleh wrote: > Don't give up on the whole frame just because a block failed to > decode correctly. > > Try to continue decoding if the AV_EF_EXPLODE flag is not set. > > Signed-off-by: Mohammad AlSaleh > --- > libavcodec/mjpegdec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c > index 816eb1ce5d..edefc35cb3 100644 > --- a/libavcodec/mjpegdec.c > +++ b/libavcodec/mjpegdec.c > @@ -1504,7 +1504,8 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int nb_components, int Ah, > s->quant_matrixes[s->quant_sindex[i]]) < 0) { > av_log(s->avctx, AV_LOG_ERROR, > "error y=%d x=%d\n", mb_y, mb_x); > - return AVERROR_INVALIDDATA; > + if (s->avctx->err_recognition & AV_EF_EXPLODE) > + return AVERROR_INVALIDDATA; > } > if (ptr) { > s->idsp.idct_put(ptr, linesize[c], s->block); decoding should stop at an error and resume at a reset marker or some other marker where resync is possible otherwise chances are there will be alot of random trash. If there are no reset markers, it may be possible to match the end of decoding up to the frame end, this would be difficult but could allow a bit extra recovery of image data. also bit errors tend to be uncommon so if you encounter something looking like a bit error, consider that may be a encoder or decoder bug. I dont know what your case is but if it is a encoder bug or some odd quirk of some encoder it may be possible to add some special case and decode that better than just handling it like an error If you really have a file that benefits still after all above from continued blind decoding after an error then something like your patch can be considered iam not against it. Can you share the jpeg this helps ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus