Justin Ruggles <[email protected]> writes: > On 12/10/2012 01:32 PM, Måns Rullgård wrote: >> Justin Ruggles <[email protected]> writes: >> >>> On 12/10/2012 01:17 PM, Luca Barbato wrote: >>>> On 12/10/2012 05:49 PM, Justin Ruggles wrote: >>>>> From: Michael Niedermayer <[email protected]> >>>>> >>>>> This avoids a potential infinite loop due to not consuming any packet >>>>> data. >>>>> >>>>> Signed-off-by: Michael Niedermayer <[email protected]> >>>>> Signed-off-by: Justin Ruggles <[email protected]> >>>>> >>>>> CC:[email protected] >>>>> --- >>>>> 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)
I thought those read the block_align value from the file. Does the spec assign a meaning to a value of zero? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
