[FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
u at pkh.me
Sat Aug 1 11:18:34 CEST 2015
Since Michael decided to step down as a leader, the question of
reunification with Libav came up once more naturally. Before negotiations
start again, I think it's important if we can all individually start
thinking about what are our conditions or expectations from a potential
reunification, and what we are willing to concede in the process.
The purpose of the operation is to start a debate with a very good
overview for everyone about what is still going wrong and what are the
priorities in solving the matter. The Libav project has been encouraged to
do the same by Jean-Baptiste Kempf and myself, and at least some of the
developers seem to be willing to play the game.
The VDD are coming soon¹, and while I personally hate these real life
meetings more than probably most of the people here on this mailing list,
I think with recent the events (Michael leadership, but also stuff like
FFmpeg being back as default in all the distributions) and the help of
this "mental preparation" (or whatever you want to call it), we finally
have a great opportunity to put an end to this extremely toxic environment
for our common users and developers from both projects. So I'd call for
everyone to come, even though I have many doubts about this.
In order to illustrate what I'm selfishly expecting from this operation,
I'll start here with my own list. Keep in mind that it's not so much for
discussing it right now, and certain points are meant to be very personal
and in disagreement with probably a number of current FFmpeg developers.
We are just setting up pieces on the board for a future discussion.
- Using the current FFmpeg source code as the code base for the common
This is the most important point. There are many arguments toward this,
but I think the main one is that we do not want to loose anything of the
last years of development from many FFmpeg developers. The amount of
work done by everyone is surreal, and it would be a huge mistake to
think that we can re-do all of this based on a old code base or on Libav
code without losing code history, gaining regressions, and losing people
because they won't work on an incomplete codebase for a very long time.
Which leads me to my next point:
- After we come to an agreement, both FFmpeg and Libav must freeze their
That way, everyone is forced to work on a common project, or has to fork
properly in case of a disagreement (by changing not only the project
name but also the library names etc). This will prevent losing something
from the past years for both projects.
- While I have no real opinion on whether a leader is needed, I think it
really helps when you don't have a process that prevent any development
dead lock. The decision machine must not stop.
Since we all agree there is no one currently that can take the position
of a leader in FFmpeg, and there isn't really any on Libav, creating a
working development process looks like a priority to me.
I do not believe at all in review blocking in the current Libav state
for several reasons, and I don't think FFmpeg is perfect in that regard,
especially with no more decision maker. So there is room for discussion
A middle ground between the two would involve talking about
maintainership areas, and common sense about trust and power on these
areas. Typically, I would like to avoid having to wait for a meaningless
review on a patch for code only I know. Again, I'm fine doing
concessions here but I think the terms need to be discussed.
- 2011 is our Godwin point. It needs to stop being mentioned for the
sanity of everyone, so developers of the new project would need to stand
against other developers and users to stop the discussion ASAP when it
- One of the main collateral damage for the FFmpeg codebase is the
duplicated features (prores, avr/swr, and more), and I'm willing to make
this a priority on my TODO list for the sake of the new project, but I
would like to see more people standing here, especially when they are
concerned by these areas.
- Redefine how we make evolution on the API: while there are indeed very
different approaches to how API evolve in both projects, I think it is
really mainly a consequence of politics (for compatibility FFmpeg had
many trouble engaging in API evolution for instance), and I think we can
come up with new methods and how to deal with that. So basically, this
is a touchy topic, but it is because even our users disagree with this
(some want to trash many stuff, and some want to keep them forever) more
than a disagreement between FFmpeg and Libav developers. I'm looking
forward many benefits in this reunification, such as finally being able
to end my long struggle with the subtitles API that I couldn't really
change for years.
- We should probably keep our bug tracker since it reflects bugs on the
FFmpeg code base. Processing every bugs from the Libav tracker and
importing them might require some work, but I think Carl has done most
of that already. I'm fine if we migrate to something else than Trac as
long as the current DB is properly imported (I don't really like
bugzilla but I'm fine with it).
- I think keeping the FFmpeg name is important from at least a
"marketting" PoV, but in all honestly if it is renamed to
FFmpegAndLibav, FFmpeg-NG, or MultimediaDrama I don't really care as
long as the communication around the new project is done properly and
2nd point of my highest expectations is met. But note that while I think
"FFmpeg" as a name is fine, I don't think using "Libav" name is going to
do any good due to bad image and butthurt developers.
Anyway, this is a call for other FFmpeg developers, please share your own
feelings about this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 473 bytes
Desc: not available
More information about the ffmpeg-devel