[Flac-dev] FLAC support for Android?
dave at dchapman.com
Wed Feb 25 08:25:51 PST 2009
Cristian Adam wrote:
> On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby <brianw at sounds.wa.com>wrote:
>> A better suggestion might be to start with libFLAC, optimize as
>> needed, and then submit the optimizations back to the FLAC project
>> where they will be more widely useful.
>> But that's just my opinion.
> I agree. This way the DirectShow filter for Windows Mobile (based on
> libFLAC) will
> also benefit from those optimizations.
When Rockbox switched from libFLAC to the ffmpeg decoder, FLAC turned
from one of our slowest codecs, to the fastest. The difference was
libFLAC is the _reference_ implementation of FLAC, not one that is
designed to be the ideal decoder everywhere. That's the advantage of
open codecs - the specification is public, and third-party
encoders/decoders should be encouraged, not immediately rejected without
I'm not talking about things that can be achieved by optimising libFLAC.
One of the reasons the Rockbox version of the ffmpeg decoder is so
fast on our target devices is because it is very tightly integrated (no
abstract layers of API). i.e. we created a FLAC codec designed
specifically for the Rockbox codec API.
This involved extracting the FLAC decoder from ffmpeg, using the core
decoding parts of that code, and writing new code just for Rockbox.
Whilst this was a lot more work to do than simply linking libFLAC, the
end result was very worthwhile.
More information about the Flac-dev