[FFmpeg-devel] Behaviour of liba52 decoder

[Justin Ruggles]

Baptiste Coudurier wrote:
> Hi Justin,
> 
> Justin Ruggles wrote:
>> 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.
>>
> 
> Btw, what's still left to change license to LGPL ?

E-AC3.  Although the E-AC3 decoder is far from feature complete, it now
works for all samples I have been able to get my hands on.  The code is
also looking much cleaner now.

-Justin