On Tue, Jul 23, 2019 at 12:13:51AM +0200, Lynne wrote: > Jul 22, 2019, 10:57 PM by mich...@niedermayer.cc: > > > 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; > > + > > /** parse extra data */ > > if (!avctx->extradata || avctx->extradata_size < EXTRADATA1_SIZE) { > > av_log(avctx, AV_LOG_ERROR, "invalid extradata size\n"); > > -- > > 2.22.0 > > > > _______________________________________________ > > 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 <mailto:ffmpeg-devel-requ...@ffmpeg.org>> > > with subject "unsubscribe". > > >
> If the size somehow gets lost between lavf and lavc then the problem is > there, and should be solved by not fudging the decoder. libavcodec is used by many applications which do not use libavformat. for all i know and what is documented in the only reference spec i have. the resolution is a constant its always 320x200 for this codec. So its natural to have the decoder know about its own resolution. > Moreover, if neither the codec, nor container can change the resolution, then > how does that make anything different? > Please, stop it with those patches. It takes energy and some worry to have to > open up the ML and scan it for bad patches from people who really should know > better every time. Please stop with these attacks, this is just making people become mutually more aggressive and filled with hatred. Lets work together to find solutions, not work against each other. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
signature.asc
Description: PGP signature
_______________________________________________ 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".
