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

[foo86]

On Wed, Jan 06, 2016 at 06:55:53PM +0100, Christophe Gisquet wrote:
> Hi,
> 
> 2016-01-06 18:32 GMT+01:00 foo86 <foobaz86 at gmail.com>:
> >             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
> 
> Just to be sure, because I won't check myself: is this an
> apple-to-apple comparison for dca vs dca2? I mean, things like
> favorable/native output format, eg without conversion, etc ?

I've tried to make this a valid comparsion by using each decoder's native
output format. Here is a script I used for benchmarking:

    #!/bin/sh

    export TIME="%E"

    bench(){
        echo "==== $1 ===="
        for i in 1 2 3 ; do
            /usr/bin/time ./ffmpeg -v error -stream_loop 2000 \
                -codec $1 -y -i sample.dtshd -codec $2 -f null /dev/null
        done
        echo ""
    }

    bench dca pcm_f32le
    bench dca2 pcm_f32le
    bench libdcadec pcm_s32le

> synth_filter was in my benchmarks (2? years ago, on a non-avx2 system
> with 5.1 core dts) around 50% of the execution time. It's good that it
> can be reused, but people have "suffered" using dca without it for
> near a decade, so they'll probably handle waiting another decade for
> it to be rewritten if it needs to be.

synth_filter integrates just nicely without any changes, there is no need for
rewrite. There is 64 subband version of it needed though, as well as fixed
point versions for 32 and 64 subbands.

> But the other parts of dcadsp are probably contributing less than 10%,
> so dca2 looks good.

Other parts can't be directly reused unfortunately. They need to be converted
to operate on integer input and process entire frame at once (not just one
subsubframe).

Temporary converting the input to floating point before calling them (what
current dca code does) seems to negate any performance gain from using these
assembly optimized routines in the first place...

> And anyhow, seeing the enthusiastic support for your version,
> performance is probably secondary to a lot of people.