> I'm not really aware of what code of ours that they used, but we'd definitely benefit a lot - in codecs of course - from such an idea.

IIRC that would be linuxstb's APE codec.  Its now in ffmpeg.

> As for our side of it, I think we could have a branch specific to ffmpeg-related stuff. Porting codecs to rockbox generally entails isolation of the codecs, converting them to fixed point math and removing dynamic allocations, and up until this stage, the code is easily usable outside rockbox. i.e, the ffmpeg people could benefit from having the fixed-point, memory-optimized codecs.
> Briefly, the idea is that the process of porting codecs to rockbox should first start in the said branch, until the codec is ready to be optimized for rockbox, then work continues in the trunk.
>
>
>
> For ffmpeg, I don't know exactly sure of the workflow of adding a new codec, but it seems to me that they could follow nearly the same process, and have a branch for ffmpeg-independent codecs, i.e, when a codec is still early in the development process, all the work is done in this branch, until it's ready for integration with ffmpeg, then work continues in their main trunk.
>
>
>
> And since it seems that my idea entails both sides having a new branch for code-syncing between them, why not make this branch common to both projects ? Just one branch containing floating point codecs (ffmpeg work) and fixed point codecs (rockbox work).

The problem I see is that we do fixed point, while ffmpeg does floating point (except their MP3 decoder and lossless codecs).  Its not clear to me that they're all that interested in fixed point.  So we'd have to try and write codecs in a way thats generic about being number representation.  The codecs that I have seen try and do this have not been particularly fun to work with (libfaad).  Readability suffers and optimization gets harder because the whole codec is a mess of preprocessor code.  
What exactly is ffmpeg's interest?  Do they want fixed point codecs, or just for us to stop being jerks about back porting our optimizations?  If the latter, ffmpeg may need to get in line, I think we owe Tremor a lot more then them.  Our version is something like 2x as fast as upstream at the moment on ARM.  And theres a lot of people out there using libTremor on ARM (sandisk, iRiver, Samsung , etc).  

                                               
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/
Received on 2010-02-08