[FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.
h.leppkes at gmail.com
Sun Jan 3 19:14:28 CET 2016
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
> 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
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
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
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
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
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
> 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? :)
More information about the ffmpeg-devel