Hi, (apologies for losing the link before ;-) That bug report seems to point out the right places. Here's some more thoughts about making OpenMAX components for free codecs (also thinking about other codecs like Theora and Speex): http://blog.kfish.org/2009/02/is-openmax-important-for-free-software.html After some discussions at FOMS last month, we might be able to get a few people together and co-ordinate this through Xiph.org. Conrad. 2009/2/24 Ben McCann <ben at benmccann.com>:> I envisioned this being implemented as a patch to Android at the OS level. > It looks like Android has native decoders which the media player and Java > APIs call.? My understanding is that T-Mobile pushes out over the air > updates of the operating system every so often.? For example, there's a new > version of the Android OS called Cupcake in the works.? Patching the OS > would allow the default media player and third party media players to play > FLAC files on updated versions of the OS. > Conrad, you mentioned the OpenMax IL components.? I've posted links in the > bug report to existing places in the code base that we'd have to hook into. > Perhaps you could peek at those links and point to a place in the code where > there's an existing OpenMax component implementation to use as an example? > I'm pretty strong with Java, but since it turns out this needs to be done > natively, I'm not sure whether I would have the ability to patch Android > myself.? I at least wanted to find out if anyone else was working on it and > help come up with a design documented on the bug report, so that when > someone eventually does tackle it there will be a game plan in place.? As a > side note, if someone already involved in FLAC development were willing to > work on the feature, I'm pretty optimistic I could connect you to somone on > the Android side of things for design feedback, code reviews, etc. > > -Ben > > > _______________________________________________ > Flac-dev mailing list > Flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > >
Hi, I'm a developer with the Rockbox project - http://www.rockbox.org - which is a written-from-scratch operating system and application suite designed for portable audio players. We of course support FLAC, and have a small, well-optimised (for embedded targets, including ARM) decoder which I think would be perfect for the devices Android runs on. It is based on the decoder from ffmpeg, and hence is licensed under the LGPL, with Rockbox specific code licensed under the GPL. I don't know if the GPL will be a problem with this part of Android. If the LGPL is compatible, then I'm sure the relevant Rockbox developers (including myself) would be happy to donate their code under that license. We initially implemented FLAC playback in Rockbox using libFLAC, but achieved significant speed gains (and reduced code size) when switching to the smaller ffmpeg decoder. I'm afraid I don't have exact figures to hand, but can try and dig them out if people are interested. Our current decoder can decode a typical FLAC file using about 13MHz of an arm7tdmi core. On portable (battery-powered) devices, performance is very important. The Rockbox source code can be browsed here: http://svn.rockbox.org/viewvc.cgi/trunk/ See apps/codecs/ for our codecs. If I was going to attempt to implement this, I would definitely go for the ffmpeg decoder, rather than libFLAC, assuming the license is OK. Regards, Dave.
Thanks for the info, Dave. Speed is a very important feature, but there might be some risk choosing the FFmpeg decoder. They've had trouble with their encoder in the past, which tells me it's possible your users might one day run into a valid FLAC that the FFmpeg decoder won't handle correctly. 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. Brian Willoughby Sound Consulting On Feb 25, 2009, at 03:10, Dave Chapman wrote: I'm a developer with the Rockbox project - http://www.rockbox.org - which is a written-from-scratch operating system and application suite designed for portable audio players. We of course support FLAC, and have a small, well-optimised (for embedded targets, including ARM) decoder which I think would be perfect for the devices Android runs on. It is based on the decoder from ffmpeg, and hence is licensed under the LGPL, with Rockbox specific code licensed under the GPL. I don't know if the GPL will be a problem with this part of Android. If the LGPL is compatible, then I'm sure the relevant Rockbox developers (including myself) would be happy to donate their code under that license. We initially implemented FLAC playback in Rockbox using libFLAC, but achieved significant speed gains (and reduced code size) when switching to the smaller ffmpeg decoder. I'm afraid I don't have exact figures to hand, but can try and dig them out if people are interested. Our current decoder can decode a typical FLAC file using about 13MHz of an arm7tdmi core. On portable (battery-powered) devices, performance is very important. The Rockbox source code can be browsed here: http://svn.rockbox.org/viewvc.cgi/trunk/ See apps/codecs/ for our codecs. If I was going to attempt to implement this, I would definitely go for the ffmpeg decoder, rather than libFLAC, assuming the license is OK. Regards, Dave.