On Sun, Jan 3, 2016 at 6:49 PM, foo86 <fooba...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
