[FFmpeg-devel] Behaviour of liba52 decoder

[Justin Ruggles]

Michael Niedermayer wrote:
> On Thu, Jan 10, 2008 at 06:54:13PM +0000, M?ns Rullg?rd wrote:
>>>> On Thu, Jan 10, 2008 at 06:28:52PM +0000, M?ns Rullg?rd wrote:
>>>>> I'm surprised nobody has mentioned the fact that we now have a native
>>>>> AC3 decoder, so there is no longer any need for the liba52 wrapper.
>>>>> Is there some reason I'm missing why it's still there?
>>>> Good question. I'd be happy to see it removed.
>>> if ours is faster sure remove liba52 support ...
>> Is speed the only deciding factor here?  I suppose I could benchmark
>> decoding a DVD or two.
> 
> The question is probably if we have volunteers to do more complete testing
> that is
> * .o size

object sizes (--strip-debug):

aac_ac3_parser.o     1136
ac3dec.o            15784
ac3.o                4688
ac3_parser.o         2164
ac3tab.o             2873
fft.o                2872
mdct.o               2348
-------------------------
                    31865

for apples-to-apples:
ar rc ffac3.a {files above}.o  33170
/usr/lib/liba52.a              42914

It will grow with the addition of E-AC3, but also keep in mind that 6/7
of those files are shared with other codecs.

> * memory requirement

I'm not really sure about the best way to test memory
requirements...valgrind?

> * quality (are there specific tests mandated by the ac3 spec?)

Sadly, no.  The only tests I know of come from Dolby, and they only give
them out to companies who apply to license "Dolby Digital Technology"
for commercial use.  I would love to get my hands on a conformance test,
but after searching around it seems unlikely.  The closest I could find
is a list of the contents of the CD's Dolby gives out for the licensing
process, and all the testing samples and documents are flagged as
confidential information.

> * feature completeness (i assume we are better especially with EAC3 around
>   the corner and liba52 being not very actively developed lately AFAIK)

Yeah, features are pretty much complete for AC3 except for some of the
metadata and more complete downmixing (needs LtRt and everything else
except mono and stereo).  So yeah, 99% feature complete.  And same as
liba52 decoder as-is.

> * error concealment (being mandatory for EAC3 we should be as good or better
>   here as well eventually)

I'll go ahead and work on error concealment on the E-AC3 side of things,
and if everything works okay I can add it to AC3 even if E-AC3 isn't
quite ready for inclusion into FFmpeg SVN. (on that note, I do think
it's getting pretty close)

> Anyway speed tests alone would already be very interresting
> C and SSE of course for both

I'm quite surprised with Mans' speed test results and will try to
duplicate them.  A few months back ffac3 was slower for me than liba52
for 5.1 decoding, but slightly faster for stereo.

-Justin