On 12/22/2012 05:50 PM, Justin Ruggles wrote: > 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.
Looks like it may be ASF packets wrapped in MOV packets... but I can't tell for sure yet. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
