On 2012-12-10 13:55:57 -0500, Justin Ruggles wrote: > On 12/10/2012 01:32 PM, Måns Rullgård wrote: > > Justin Ruggles <justin.rugg...@gmail.com> writes: > > > >> On 12/10/2012 01:17 PM, Luca Barbato wrote: > >>> On 12/10/2012 05:49 PM, Justin Ruggles wrote: > >>>> From: Michael Niedermayer <michae...@gmx.at> > >>>> > >>>> This avoids a potential infinite loop due to not consuming any packet > >>>> data. > >>>> > >>>> Signed-off-by: Michael Niedermayer <michae...@gmx.at> > >>>> Signed-off-by: Justin Ruggles <justin.rugg...@gmail.com> > >>>> > >>>> CC:libav-sta...@libav.org > >>>> --- > >>>> libavcodec/wmadec.c | 5 +++-- > >>>> 1 files changed, 3 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c > >>>> index e2803bb..8d82ec4 100644 > >>>> --- a/libavcodec/wmadec.c > >>>> +++ b/libavcodec/wmadec.c > >>>> @@ -808,7 +808,8 @@ static int wma_decode_superframe(AVCodecContext > >>>> *avctx, void *data, > >>>> buf_size, avctx->block_align); > >>>> return AVERROR_INVALIDDATA; > >>>> } > >>>> - buf_size = avctx->block_align; > >>>> + if (avctx->block_align) > >>>> + buf_size = avctx->block_align; > >>> > >>> why block_align should be 0 ? > >> > >> It's from the container. > > > > What demuxer is reporting zero? > > Anything that uses ff_get_wav_header() (e.g. asf, avi, wtv, wav)
Huh, at least the fate-wmav* report non-zero block_align. The mov sample in http://avcodec.org/trac/ffmpeg/ticket/286 on the other hand doesn't set block_align and bytes per frame in the stsd is zero. Also note that the other wma* decoder follow the same pattern. Janne _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
