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

[foo86]

On Sun, Jan 03, 2016 at 07:14:28PM +0100, Hendrik Leppkes wrote:
> 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...

Having both decoders available during development makes things like
comparing their output and performance a bit simpler, but I agree that
keeping both decoders doesn't make much sense in the end. The final
version of the patch should probably replace the old decoder. This will
offer some opportunity to clean up dcadata.c, etc.

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

I did a few manual runs with valgrind/ubsan and zzuf to make sure the
decoder doesn't do anything particularly stupid, but no real stress
testing yet.

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

If someone hinted what parts of code are easily optimizable with SIMD I
could later provide DSP hooks for it.

> 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? :)

I've implemented basically everything I wanted in external library, so I
don't really expect any more substanial development, just the bug fixes.
Regaring the new decoder in FFmpeg, I'll try to be around, assuming
nothing bad happens to me :)