On 22.07.2019, at 23:57, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> The dimensions are always 320x200 they are hardcoded in the demuxer. > Hardcode them instead in the decoder. > > Fixes: Timeout (16sec -> 400ms) > Fixes: > 15574/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RL2_fuzzer-5158614072819712 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > --- > libavcodec/rl2.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/rl2.c b/libavcodec/rl2.c > index 6662979c52..2d336a61e5 100644 > --- a/libavcodec/rl2.c > +++ b/libavcodec/rl2.c > @@ -134,10 +134,15 @@ static av_cold int rl2_decode_init(AVCodecContext > *avctx) > Rl2Context *s = avctx->priv_data; > int back_size; > int i; > + int ret; > > s->avctx = avctx; > avctx->pix_fmt = AV_PIX_FMT_PAL8; > > + ret = ff_set_dimensions(avctx, 320, 200); > + if (ret < 0) > + return ret; I really dislike these completely comment-less patches. So it seems this is only based on what our demuxer does. However does the format itself have any inherent size limitations? What was the cause of the slow decoding? Does this actually fix it, or does it just swipe it "under the carpet"? If someone ever found a sample with a different solution, how would they know that they shouldn't just remove this again? Without any kind of comment on the point of this call, people might assume it's pointless nonsense. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
