[FFmpeg-devel] [PATCH v2 00/16] Replace native DCA decoder with libdcadec based one

[Hendrik Leppkes]

On Tue, Jan 26, 2016 at 12:05 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Fri, Jan 22, 2016 at 11:25 PM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
>> On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote:
>>> Updated version of the patch. I choose to split it into even smaller commits to
>>> make reviewing easier; you may prefer to squash it as needed.
>>>
>>> Changes since the first version:
>>>
>>> * Removed checkasm test for dcadsp
>>> * Removed FATE test for dca-xll (didn't check if this works)
>>> * Core decoder now uses butterflies_fixed() for sumdiff decoding
>>> * avpriv_request_sample() is now used for reporting missing features
>>> * Core decoder now stays in fixed point mode during intermittent XLL decoding errors
>>> * X96 extension is no longer parsed (and left unused) when decoding XLL
>>> * Minor code refactoring
>>>
>>> foo86 (16):
>>>   avcodec/dca: remove old decoder
>>>   avcodec/dca: remove unused assembly
>>>   avcodec/dca: remove unused data
>>>   tests/fate/audio: remove dca-xll test
>>>   tests/checkasm: remove dcadsp test
>>>   avcodec/dca: add REV1AUX sync word
>>>   avcodec/dca: add more tables
>>>   avcodec/dca: add math helpers and fixed point DCT
>>>   avcodec/synth_filter: fix whitespace
>>>   avcodec/synth_filter: add more filters
>>>   avcodec/dca: add DSP implementation
>>>   avcodec/dca: add generic defines
>>>   avcodec/dca: add core decoder
>>>   avcodec/dca: add EXSS parser
>>>   avcodec/dca: add XLL decoder
>>>   avcodec/dca: add new decoder based on libdcadec
>>
>> This breaks decoding https://trac.ffmpeg.org/raw-attachment/ticket/3550/WorstCase.wav
>> didnt investgate what or why
>>
>
> That file seems rather funky. The dts parser outputs DTS frames of
> 16384 bytes, while the frame headers say 4097 bytes.
> Seems like a parser problem to start with.

So I did some further checking, and that file is just crazy, and the
parser behaves like it should.
The frames are actually 16384 bytes in size, padded with a bunch of
zeroes. One theory was that a spdif encoder spit this out.

So on to the error -
The decoder complains about overreading the dca frame, and yes, its
reading more than the designated frame size in the core header -
however, its not actually overreading the input buffer.

Maybe the check can be "relaxed" a bit, since it doesn't actually
overread the input, and the frame size in the header is just bogus?
The header says 4096+1, but looking at the bitstream I can clearly see
it just going on with seemingly meaningful data after.

An "explode" type check might make sense here? If the input buffer is
this large, and the core header is just lying, do we really need to
error out?

- Hendrik