Hi, On Wed, Feb 29, 2012 at 12:41 PM, Vitor Sessak <[email protected]> wrote: > On 02/29/2012 09:08 PM, Ronald S. Bultje wrote: >> On Wed, Feb 29, 2012 at 12:03 PM, Vitor Sessak<[email protected]> >> wrote: >>> >>> --- >>> libavcodec/amrnbdec.c | 7 +++++++ >>> 1 files changed, 7 insertions(+), 0 deletions(-) >>> >>> diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c >>> index fff0e72..d88f5f0 100644 >>> --- a/libavcodec/amrnbdec.c >>> +++ b/libavcodec/amrnbdec.c >>> @@ -946,6 +946,13 @@ static int amrnb_decode_frame(AVCodecContext *avctx, >>> void *data, >>> } >>> buf_out = (float *)p->avframe.data[0]; >>> >>> + if (buf_size< frame_sizes_nb[p->cur_frame_mode] + 1) { >>> + av_log(avctx, AV_LOG_ERROR, >>> + "Frame too small (%d bytes). Truncated file?\n", >>> buf_size); >>> + *got_frame_ptr = 0; >>> + return buf_size; >>> + } >>> + >>> p->cur_frame_mode = unpack_bitstream(p, buf, buf_size); >> >> >> That seems like the wrong place to check it, since p->cur_frame_mode >> isn't set to the current value yet. Shouldn't this be checked inside >> unpack_bitstream, or inside ff_amr_bit_reorder()? I sent a patch >> yesterday that takes that approach. > > > Sorry, I didn't see your patch. At first I was against your patch since I > thought it would slow the code down and could be done with no performance > hit. Then, I did a little profiling and saw that ff_amr_bit_reorder() is not > really speed critical...
I'm all in favour of faster if it does the same, even if it's just 1 cycle. But you'd still have to do the size check in unpack_bitstream() after reading the mode... ;-). Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
