On 06.01.2016 18:32, foo86 wrote: > On Tue, Jan 05, 2016 at 10:46:19PM +0100, Andreas Cadhalpun wrote: >> OK. This decoder seems to be quite robust in handling fuzzed samples, >> so from a security point of view it should be fine to replace the >> old dca decoder with this one. > > Out of interest, did you disable CRC checks in the decoder while fuzzing?
No, I tested it as is. > Otherwise testing coverage will be decreased somewhat. The easiest way to do > this is to modify ff_dca2_check_crc() to always return 0. I tried this (comment out everything in ff_dca2_check_crc except 'return 0') and there doesn't seem to be much difference. >> Out of curiosity: Can you post a few benchmarks comparing the performance >> of the old and the new decoder? > > Here are some benchmarks I did with 3 available decoders on 3 different > systems: (1) x86_64 desktop, (2) ancient i386 laptop, (3) Raspberry Pi Model > B+. > > Measuring how much time it takes to loop 2000 times over a short 5.1 > channel core sample (for a total duration of 00:51:56.22) yields the > following results: > > dca dca2 libdcadec > System 1: 0:11.90 0:11.16 0:19.73 > System 2: 0:57.00 0:55.23 1:21.33 > System 3: 7:41.31 7:00.84 13:16.70 > > The new decoder appears slightly faster than dca even though it doesn't > use any assembly optimized code for dcadsp (besides synth_filter). Thanks for sharing these benchmarks. They look quite nice. ;-) Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel