On 12/16/2011 05:52 PM, Paul B Mahol wrote: > On 12/16/11, Maans Rullgaard <[email protected]> wrote: >> Paul B Mahol <[email protected]> writes: >> >>> On 12/16/11, Maans Rullgaard <[email protected]> wrote: >>>> Paul B Mahol <[email protected]> writes: >>>> >>>>> On 12/16/11, Maans Rullgaard <[email protected]> wrote: >>>>>> Paul B Mahol <[email protected]> writes: >>>>>> >>>>>>> --- >>>>>>> libavcodec/cljr.c | 6 +++--- >>>>>>> 1 files changed, 3 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/libavcodec/cljr.c b/libavcodec/cljr.c >>>>>>> index a5ee738..199fd98 100644 >>>>>>> --- a/libavcodec/cljr.c >>>>>>> +++ b/libavcodec/cljr.c >>>>>>> @@ -57,9 +57,9 @@ static int decode_frame(AVCodecContext *avctx, >>>>>>> if (p->data[0]) >>>>>>> avctx->release_buffer(avctx, p); >>>>>>> >>>>>>> - if (buf_size / avctx->height < avctx->width) { >>>>>>> - av_log(avctx, AV_LOG_ERROR, >>>>>>> - "Resolution larger than buffer size. Invalid >>>>>>> header?\n"); >>>>>>> + if (buf_size != avctx->height * avctx->width) { >>>>>>> + av_log(avctx, AV_LOG_ERROR, "got a buffer with %d bytes when >>>>>>> %d >>>>>>> were expected\n", >>>>>>> + buf_size, avctx->height * avctx->width); >>>>>> >>>>>> These checks are not equivalent, the old version allowing an oversized >>>>>> input packet. Is this change intentional? >>>>> >>>>> Oversized input packets can not be considered valid packets. >>>> >>>> Of course they can, if they start with a valid packet. >>> >>> Same as undersized, they can still can have valid data >> >> An undersized packet can never have a _complete_ valid frame. An >> oversized one can. The code currently allows junk at the end, and your >> patch changes that. Why? > > I stole check from cyuv decoder. If you prefer to keep compatibility with > previous code I'm fine with it.
Please keep the same behavior. There is no need to error out when the frame can be decoded and any extra bytes at the end skipped. It doesn't really matter whether or not we have samples which require this. Thanks, Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
