On Wed, Jan 06, 2016 at 12:28:00AM +0100, Hendrik Leppkes wrote: > So that leaves us with a bunch of positive comments, on this side > anyway, and noone opposed yet. > > Arguments for a switch include: > - Nearly complete coverage of all DTS features, well tested and > confirmed bit-exact (only DTS Express is missing, which is technically > its own little codec using DTS EXSS headers) > - Slightly faster (~5%) > - Active maintainer > - Andreas seal of security approval ;) > > If anyone thinks we should not replace our decoder, speak now or > forever hold your peace (and bring proper arguments). > I will try to do a code review to the best of my abilities in the upcoming > days. > > foo86, could you work on changing the patch to replace the original instead? > > After it is merged, we could think about integrating your test-suite > into the FATE system, but all in good time.
OK, I'll start changing the patch. Some questions so far: 1. Should I remove old decoder files in separate commit first or should I simply proceed with replacing entire content of certain files (e.g., dcadec.c, dca_exss.c, dca_xll.c)? 2. Is it OK to leave arch-specific dca code as well as dcadsp.c untouched for now? I'd really like to postpone dealing with that until I'm done with generic code, especially since the new decoder is not slower already. This means some assembly functions (ff_dca_lfe_fir32_*, ff_dca_qmf_32_subbands_*) will still be compiled in but unused. libavcodec/dcadsp.c will be still around but not compiled. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel