[FFmpeg-trac] #4002(undetermined:new): reconciliate & merge with libav
trac at avcodec.org
Fri Oct 3 23:01:07 CEST 2014
#4002: reconciliate & merge with libav
Reporter: calestyo | Type:
Status: new | enhancement
Component: | Priority: wish
undetermined | Version: git-
Keywords: | master
Blocking: | Blocked By:
Analyzed by developer: 0 | Reproduced by developer: 0
Not sure if anyone has tried this before in the form of a bug (discussions
about this topic are of course going on), but I think it should be
actually handled as just this:
btw: Apart from the fact that I think security should come first followed
by functionality - I personally have basically no preference on either of
the two projects, neither the people behind them.
The only exceptions are perhaps that I hate trac (used by ffmpeg) and that
I think libav is a better name for what both projects do, at least a
better name than ffmpeg.
In the following I will name ffmpeg before libav, simply for alphabetical
1) about forks
Having the possibility to fork is often a good thing and one of the
strengths of open source. We've seen many cases in the past, where a fork
revived development, solved political problems or greatly improved on the
code itself (just take xfree86/xorg, gcc/egcs, openoffice/libreoffice as
It seems that the fork between ffmpeg/libav has either failed such goals
or already succeeded with them for both projects, especially from a purely
technical POV since ffmpeg seems to more or less simply merge all commits
from libav, AFAIK.
2) most other people are simply sick with the current situation
Just google for ffmpeg vs. libav and you'll find dozens of blogs and other
commentries, where people write about the forking, it's background, a
small comparison about the differences of ffmpeg/libav... basically always
concluding that the whole thing is just annoying and at least as of now,
not leading to any further benefits for developers (using either of the
two) or end-users.
Also, a lot of manpower is wasted because of the fork, be it on an
organisational level (when other communities, like recently Debian, argue
about ffmpeg vs. libav), a technical level (when developers of other
products try to be compatible to both or developers/end-users have to
handle bugs/bug-reporting in both).
3) duplicate of development works & security issues
Both projects surely also waste some manpower when they do similar/same
Manpower that could be invested much better - after all, what the people
from both projects want to do is the development of some all-round
Having two very similar forks, probably doesn't improve the security
4) it distracts developers/users
I guess it's quite clear that developers (of 3rd party programs) and
prospective users of ffmpeg/libav are rather distracted from using either
of the two because of these issues.
The same possibly applies to developers, that directly want to contribute
to ffmpeg/libav but who are not inclined to take part in both and/or the
"war" between them.
For sure there are more reasons which speak against the forking...
Let people try toreconciliate and merge the projects,
and perhaps to not step on anyone's toes, explictly stating: that this is
not a victory of one over the other.
Outstanding issues and possible solutions:
Well I guess if the project is called either ffmpeg or libav, than either
of the two parties may felt upset and external people may conceive it, as
if this project would have "won".
I personally would say:
- "ffmpeg" is imperfect, since the code is about much more than (Fast
- "libav" is IMHO already better, at least it av stands for audio/video,
but still not optimal since both projects also support e.g. image formats.
So maybe just think about another name? libiav (images/audio/video)?
libmultimedia? Well I guess someone else can surely come up with less
stupid proposals than these two of mine.
Of course it's a lot of work, but it shouldn't be impossible to merge the
infrastructure (repo, bugtracker, website, wiki, domains) of the two
Especially if a new name would be chosen.
The old ones could link to the new ones.
3) Project leadership/maintainers
If there's still open issues about the leadership / maintainer position -
simply do what other projects did, e.g. establish a steering committe,
which makes binding decisions if necessary.
Such comitte could have e.g. 5 members, 2 from ffmpeg, 2 from libav and
maybe a 3rd neutral person (from some other multimedia project?).
Or one could kindly ask an existing similar committe (e.g. Debian's tech-
ctte whether it may give it's vote), basically taking the 5th seat ex
4) Security / code quality
If security and/or code quality is a concern (like some of the bloggers
basically write, that ffmpeg would support more formats but sometimes on
the cost of taking hacky code), simply do what e.g. Linux does:
Make a kind of a staging area of codecs/drivers, which are only activated
by compile time options or runtime parameters.
 It's not that I would be so smart to come up with solutions no one
else would have been able to find - actually all of these have been done
before by other projects.
Ticket URL: <https://trac.ffmpeg.org/ticket/4002>
FFmpeg issue tracker
More information about the FFmpeg-trac