>IMO this should replace the current dca decoder. Based on what i saw from libdcadec >yours is cleaner, more feature complete, you're a knowledgeable maintainer, and >since the current developer for ffdca over at libav is porting code from yours to >get bitexact xll working the code duplication would be considerable if we keep both.
I agree. On 3 January 2016 at 18:24, James Almer <jamr...@gmail.com> wrote: > On 1/3/2016 2:49 PM, foo86 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. > > IMO this should replace the current dca decoder. Based on what i saw from > libdcadec > yours is cleaner, more feature complete, you're a knowledgeable > maintainer, and > since the current developer for ffdca over at libav is porting code from > yours to > get bitexact xll working the code duplication would be considerable if we > keep both. > > > > > 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. > > > > 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 > > Another reason to have this replace the current one, then. > > Thanks. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel