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 unchanged.
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). Brian Willoughby Sound Consulting On Feb 25, 2009, at 08:25, Dave Chapman wrote: Cristian Adam wrote: > On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby > <bri...@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 extremely dramatic. 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 consideration. 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. _______________________________________________ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev