FFmpeg is changing its name to libav!
Today, FFmpeg developers decided to continue developing FFmpeg under the name Libav.
Source of the news: Libav.org website: click here
This is apparently not a simple name change, but a fork arising from a dispute over management of the project (server policy, commit permissions, patch review standards), which would explain why ffmpeg.org is still up and has no mention of this.
IMHO it's a dumb move. It's just going to cause confusion with now having libva and libav and both being video libraries. I wish these projects would get over trying to keep their library names within a 8.3 format. It's 2011 and not 1983.
Oh, so the coup turned into a full-on fork? Stupid.
So, which group owns which fork?
given what you've posted in the past, and the number of times I've had to step in and correct you, your opinion carries about as much weight as a sheet of collage rule paper.
Originally Posted by deanjo
Okay, fine, it's 2011. Mind telling me exactly how many projects out there use FFMpeg?
If you don't know, go here: http://ffmpeg.org/projects.html
Okay. Next question. How many of those projects are supported across more processing architectures than x86?
How many of those projects are used in computer systems where memory space is at a premium?
how many of those projects are used in computer systems where the only user interface is a command prompt?
how many of those projects are used in computer systems where the only user interface is a command prompt over SSH or telnet?
You might not like the 8.3 format, but it's really convenient for the developers doing the actual programming. It's also really convenient for the developers using that library in their own applications.
Now, is it confusing with LibVA?
Well, let me ask you this. When was the last time you actually looked at the number of Lib files installed on your Linux. Never? Don't run Linux?
Well, drop by Debian's package list sometime. It's located here: http://packages.debian.org/stable/libs/
Scroll there and tell me how many of the library files YOU could identify if only given their short names.
Saying that forking a given project was a dumb idea isn't smart unless one has managed to identify the actual reasons behind the fork - reasons which are mostly and only known to those who actually write the code and try to contribute to the given project - which is one of the most obvious yet underrated reasons to fork a project. Yes, in the short term such moves (only) cause hysteria, speculations and confusions but in the long run they could very well justify the move.
In some projects contributing is often one of the most difficult (and frustrating) tasks, which, among others, Mark Shuttleworth compared to "like a frontal assault on a machine gun post".
Btw, how's the crappy 1 minute rule doing? No decision yet? sry 4 offtopic
I would also like to know. In particular to which group Michael Niedermayer belongs.
Originally Posted by curaga
I would like to see more information. Why the fork, who is involved, what are the differences, etc pp.
That said, a fork can be a good thing. Competition, new blood, new energy. Just look at Xfree86/X.org, gcc/egcs or the 'fight' between nptl and ngpt.
Tags for this Thread