Rockbox mail archiveSubject: Re: ffmpeg coordination effort!
Re: ffmpeg coordination effort!
From: Mohamed Tarek <mtarek16_at_gmail.com>
Date: Mon, 8 Feb 2010 14:18:49 +0200
On Mon, Feb 8, 2010 at 11:10 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> Hey friends,
> After my talk at Fosdem yesterday, I was approached by a guy from the
> ffmpeg team (and I forgot to ask for his name), and he asked me about our
> willingness to cooperate in syncing source code changes between our
> projects. Changes we've done to codecs from them, and changes they've done
> to source codes we use.
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.
> Any particular ideas on how to proceed?
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,
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).
I like the idea of discussing this in an IRC meeting, but I think if the
discussions were on the mailing lists it would be better, more people could
follow and respond later if they weren't able to attend the meeting.
-- MTReceived on 2010-02-08