[FFmpeg-devel] ATRAC3+ support

Michael Niedermayer michaelni at gmx.at
Tue Oct 1 17:53:35 CEST 2013


Hi

On Tue, Oct 01, 2013 at 11:34:02AM +0200, Maxim Polijakowski wrote:
> Hi crews,
> 
> I just want to announce that the long-awaited decoder for the
> ATRAC3+ format is finally ready to be released!
> In this mail I want to negotiate how to include the code into the
> FFmpeg codebase. I have to mention that the Libav project is already
> working on integrating my code.
> Taking in account the whole FFmpeg-Libav fork situation, I want to
> stay neutral and would like to contribute to the FFmpeg project as
> well so everyone can benefit from my work.

Its not neutral if one submits patches to one project but
not the other.
Thats pretty much the definition of neutral vs. non neutral.


> 
> Moreover, it is important to have a working ATRAC3+ decoder in
> FFmpeg because several emulation projects like PPSSPP still rely on
> the FFmpeg API.
> 
> Therefore, I wonder how do we proceed.
> 
> 1) I could provide FFmpeg with appropriate patches. Considering

yes, it is a matter of 2 seconds to add ffmpeg-devel to the CC of
your mails.
Seperate patches that are based on ffmpeg and are fully tested
might be a bit more work but then that makes sure they have been
tested and work in ffmpeg, and thats very important!


> Libav is currently working on the same code, this approach has the
> following drawbacks:

> ---> duplicating and possibly controversal reviews on both
> FFmpeg/Libav sides

duplicate review as in "more people reviewing code" doesnt sound like
a bad thing to me.


> ---> duplicated work on fixing things

if 2 sides ask you to fix the same thing its still just one time that
you need to fix it. If only one side asks you to fix an issue then
imagine you didnt sent it to that side, it would have a unfixed bug
in that case.


> ---> both projects will end up having different code

other developers submited patches to both projects and that didnt
happen.

also consider the kernel
https://www.kernel.org/doc/Documentation/SubmittingPatches

"Unless you have a reason NOT to do so, CC linux-kernel at vger.kernel.org."

same applies to ffmpeg pretty much, if you have a patch that makes
sense for ffmpeg, CC it to ffmpeg-devel. Dont just send to libav
debian, gentoo, mplayer, vlc or whatever.


> 
> Taking in consideration the huge patch size of approx. 5000 code
> lines this will cause alot of additional work.

More bugs/issues might be found and it might be thus more work
fixing them but thats what reviews are for, finding and fixing issues.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131001/95e7b00d/attachment.asc>


More information about the ffmpeg-devel mailing list