On 12/10/2012 04:12 PM, Janne Grunau wrote: > 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 <[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) > > 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.
Looking at the sample more closely, there appears to be some information inside a 'WMA2' atom. From what I can tell, it is basically the same format as a riff fmt chunk. The block_align value in the WMA2 atom for that sample is 2973, but the packets are actually 3000 bytes. It could be that the extra bytes are just padding though? I'll have to investigate further. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
