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

[Hendrik Leppkes]

On Sun, Jan 3, 2016 at 6:49 PM, foo86 <foobaz86 at gmail.com> wrote:
> This is initial version of libdcadec DCA decoder port I hacked together over
> the last week. This patch is of RFC/inquiry type and not meant for immediate
> inclusion.
>
> Any comments about the code are appreciated, as well as suggestions concerning
> how should I proceed with this patch. Should I aim for including it as a
> separate decoder or a replacement for existing DCA decoder? Or it might be that
> you prefer to continue improving existing decoder instead and not merge this at
> all.

Having two dca decoders with varying degrees of features is no
advantages, and considering the native decoder lacks a long list of
features and fails decoding a bunch of XLL streams, the aim should be
to replace.
I'm not aware of a single advantage of the old decoder, so...

>
> Attached decoder is feature complete enough to fully decode any practically
> available DTS stream configuration. It supports any possible combinations of
> XCH, XXCH, XBR and X96 core extensions to deliver up to 7.1 ch, 96 kHz floating
> point output. It also implements lossless decoding of XLL extension to deliver
> up to 7.1 ch, 192 kHz fixed point output. Bit rate managed XLL streams are
> supported. Downmixing to 5.1 and stereo using embedded coefficients is
> supported.

I have been using libdcadec through the library wrapper in ffmpeg for
a while now, and I am not aware of any file that doesn't decode
properly today, so yes, I tend to agree.
Other people will probably want to apply fuzz testing, I'm not sure
how much you have done to this degree.

>
> Performance wise, this decoder used to be around 10% slower than pure floating
> point version of existing native DCA decoder. However, after native DCA decoder
> has been partially converted to fixed point, this decoder became 5% faster than
> native one. Measurements were done looping over 5.1 core only stream in
> floating point mode on a x86_64 system. Of course, decoding extensions like X96
> and XLL makes the decoder much slower. These can be ignored with -core_only
> option.

Trying to get some extra functionality into SIMD-able functions would
be a good goal for later, but even the previous decoder doesn't have
that much.
So something for later.

>
> The libdcadec code this decoder is based on has been rather well tested and
> stable, thus I don't expect any fundamental issues with this new decoder. I
> might have introduced some bugs during porting; these should be hopefully found
> by regression tests and fixed. Note that I've not run this decoder through any
> serious regression testing yet, I just checked that it works on several select
> samples.
>
> This decoder depends on assembly versions of existing native dcadsp, however it
> only uses assembly optimized version of synth_filter currently. Because
> synth_filter implicitly depends on dcadsp this is required to allow decoder to
> build when existing DCA decoder is disabled. I plan to overhaul this area
> (interacting with existing dcadsp) later.
>

Out of curiousity, do you plan to continue developing the external
library, or would you abandon it if its merged?
And more directly, I would hope we can also count on basic maintenance
of the new decoder in ffmpeg? :)

- Hendrik