[FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

[James Almer]

On 1/6/2016 2:32 PM, foo86 wrote:
> 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)?

Yeah, send it as separate patches to make reviewing easier. Whoever commits it
can then squash it into a single patch (Like it was done in commit b08569a2) if
necessary.

Also, while at it, try to split the main header into separate headers for some
of the modules (xll, exss, dsp which already exists for the old decoder, etc).

> 
> 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.

Try to disable or remove code that will not be used. Git will easily let you
recover any of it in the future if needed.
Better than keeping dead code in the tree, IMO, but do what you think will make
your work easier.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>