[FFmpeg-devel] [PATCH] ALS decoder

[Justin Ruggles]

Thilo Borgmann wrote:

> Michael Niedermayer schrieb:
>> On Mon, Nov 09, 2009 at 04:55:38PM +0100, Thilo Borgmann wrote:
>>> Michael Niedermayer schrieb:
>>>> On Mon, Nov 09, 2009 at 09:46:18AM +0100, Thilo Borgmann wrote:
>>>>> Revision 26 attached.
>>>>>
>>>>> Regards,
>>>>> Thilo
>>>>>  Changelog              |    1 
>>>>>  doc/general.texi       |    1 
>>>>>  libavcodec/Makefile    |    1 
>>>>>  libavcodec/allcodecs.c |    1 
>>>>>  libavcodec/als_data.h  |   95 ++++
>>>>>  libavcodec/alsdec.c    | 1005 +++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  6 files changed, 1104 insertions(+)
>>>>> c9547bb8ed6d2465083d6185afc860abaaf93a73  als_decoder.rev26.patch
>>>> looks ok assuming its tested (correct files work / randomly damaged files
>>>> see tools/trasher dont crash)
>>>>
>>> My test suite of correct files are all working and I tested with 3
>>> different input files for the trasher using three different trashing
>>> option sets - all decode without crash.
>> 3 different option sets?
>>
>> i would try to increase the amount of errors (x2 in each try) until the file
>> isnt recognized anymore, if by then it didnt crash its probably ok
>>
> 
> What I've done is the following:
> 
>> #!/bin/sh
>>
>> prefix="als_tt"
>> suffix=".mp4"
>>
>> for count in {1..15}
>> do
>>    ./trasher ${prefix}${suffix} ${count} 42
>>    ~/Arbeit/GSoC/ffmpeg/ffmpeg -i ${prefix}${suffix} out.wav
>>    rm out.wav
>> done
> 
> So the same file got trashed several times.
> ffmpeg never crashed, but it ran into infinite loops when the warning
> "Block length is not evenly divisible by the number of subblocks."
> is printed.
> 
> I "analysed" it with the OSX activity tool (whatever it does...) and got
> the following:
> 
>> Sampling process 4858 for 1 seconds with 1 millisecond of run time
>> between samples
>> Sampling completed, processing symbols...
>> Analysis of sampling ffmpeg (pid 4858) every 1 millisecond
>> Call graph:
>>    915 Thread_1165500   DispatchQueue_1: com.apple.main-thread  >(serial)
>>      915 ff_ac3_parse_header_full
>>
>> Total number in stack (recursive counted multiple, when >=5):
>>
>> Sort by top of stack, same collapsed (when >= 5):
>>        ff_ac3_parse_header_full        915
>> Sample analysis of process 4858 written to file /dev/stdout
> 
> So I think it is stuck in ff_ac3_parse_header_full(). The expected
> successive warning "Reading frame data failed. Skipping RA unit." in
> decode_frame() does not appear though...

It must be damaged pretty badly for it trigger AC-3 functions... Can you
upload your trashed sample so I can try to find out what might be
causing the infinite loop in the AC-3 parser?

-Justin