[Flac-dev] FLAC support for Android?
brianw at sounds.wa.com
Wed Feb 25 16:22:53 PST 2009
What you've described, Dave, sounds like you ended up doing a
thorough code review of the FFmpeg sources as you re-worked them for
your application. Provided that you also referenced the FLAC
specification while doing all of this, I'm sure you're not quite as
exposed to potential FFmpeg bugs as someone who just used their code
I only offer the possibility that something similar could be done
with the libFLAC code, if you're willing to rip out core code and
write new code. Perhaps there would be more work, but perhaps there
would be a higher likelihood of remaining fully compliant with the spec.
In any event, I appreciate hearing about the Rockbox effort. Sounds
like you guys put in a lot of effort to support my favorite format
for listening on the go. I look forward to some day having the
challenge of squeezing the FLACodec into a small device (and then
I'll have to eat my words).
On Feb 25, 2009, at 08:25, Dave Chapman wrote:
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