On Tue, Jan 26, 2016 at 12:05 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Fri, Jan 22, 2016 at 11:25 PM, Michael Niedermayer > <mich...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
