the so called "for those taking the higher ground and declaring it a soap opera" if nothing to do with taking the higher ground as you put it , and this whole thread is nothing more than Michael coming in to the Mplayer thread totally unprepared and lacking any background....
the simple fact is Mplayer is today an almost unmaintained project with very little active input, the reason is simple , they are all in FFmpeg/libav and on IRC now and are actively transferring many of the filter's to these codebases etc...
this whole Attila Leaving the project comes from and leads directly from this ffmpeg thread outlining the facts as relates to the services provided for instance
http://ffmpeg.org/pipermail/ffmpeg-d...ch/108249.html
Wed Mar 2 18:07:14 CET 2011
and Michael's ( no not phoronix Michael, but rather ffmpeg Michael) continued dig's at different core developers and service providers etc....
now Michael seems to like Michael, and indeed Michael is a very good assembly and C programmer, so Michael seems to favour Michael at the expense of the other assembly programmers in the other team , confused yet![]()
it seems now Michael has reconsidered his position , and replied again adding his offer to resign (from this almost unmaintained project remember)
http://lists.mplayerhq.hu/pipermail/...il/068020.html
as several IRC chats have obviously taken place etc since that Attila post that started this phoronix thread/news item and yet there are very few posts to their mailing list.....
the simple fact is, there are a very few active assembly dev's and their in the ffmpeg or libav camps, and Michael said he will cherry pick all the libav and other patches as they appear, cant blame him as there are more assembly devs writing and porting x264 code in libav than ffmpeg now.... so as you can see its all very simpleits all good for getting clicks for the commercial Phoronix Test Suite OC
Isn't it kind of obvious that the project leader in question is Michael Niedermayer? He is after all answering in a way that leads not much doubt about that. I have no knowledge about this two guys, but sadly, intuitively, I believe this is just happening because Michael Niedermayer got a bit pissed of by the fact that ffmpeg.mplayerhq.hu is pointing to libav.org. He probably wrote or said some exaggerated things, and he has every right to be pissed of. Regardless of the reasons for forking ffmpeg, is really bad idea (read: stupid idea) to do such a thing. It leads to the believe that ffmpeg has just changes name to libav, and the fact that both ffmpeg.org and libav.org looks pretty much the same does not help at all. Also, libav.org don't actually call it a fork, but
We, as a group of FFmpeg developers, have decided to continue developing FFmpeg under the name Libav. All existing infrastructure will be transferred to the libav.org domain.
Yes, I agree with that, somewhat. However, I can see where these developers are coming from. Comparing the volume of libav and ffmpeg lists, it is obvious that more active development is going on in the libav team. Meaning that those 8 developers are 8 core developers of ffmpeg/libav, and should, in their opinion, be considered the majority of developers. I can even see how they thought they had the right to take over the project completely instead of forking it, even though they are not technically the majority -- and they might have succeeded, if the ffmpeg trademark owner hadn't sided with Michael. And if the majority of development is happening in libav camp, it seems to me that libav might, by some standards, be considered the main fork, at least from libav developers' point of view. In their opinion, it is only a technicality that Michael's fork continues under the name of ffmpeg, while theirs bears a different name.
You are basing this on the 'volume' of mailing lists? I mean I could understand if you based it on examination of svn entries, but mailing lists? I've seen project mailing lists with tons of chatter but absolutely no development and vice versa. I hope I am misunderstanding this.
Hey, that was a cursory glance. I didn't do any in-depth analysis of git commits or anything. That seemed like a lot of effort
All right, I was pretty curious too, so I made a small investigation.
This is the ffmpeg git tree, which merges most changes from the libav team now. I don't know all the members of the libav team, but I think it includes Anton Khirnov, Mans Rullgard, Justin Ruggles, Ronald S. Bultje, Jason Garrett-Glaser, Janne Grunau, Luca Barbato and, I think, Alexander Strange. That is a pretty impressive list, isn't it?Code:$ git log --since '1 jan' --pretty=short | git shortlog -s -n 228 Anton Khirnov 220 Mans Rullgard 174 Michael Niedermayer 155 Justin Ruggles 147 Stefano Sabatini 100 Peter Ross 87 Ronald S. Bultje 83 Martin Storsjö 62 Diego Elio Pettenò 55 Reimar Döffinger 53 Anssi Hannula 50 Jason Garrett-Glaser 40 Baptiste Coudurier 37 Carl Eugen Hoyos 37 Janne Grunau 24 Luca Barbato 22 Alexander Strange 22 Daniel Kang 19 Philip Langdale 18 Alex Converse 18 Nicolas George 14 Georgi Chorbadzhiyski 14 Young Han Lee 12 Clément Bœsch 11 Maksym Veremeyenko 11 Vitor Sessak 10 Aurelien Jacobs 10 Sascha Sommer
now compare that ffmpeg list above to the http://patchwork.libav.org/project/libav-devel/list/ and the people on the libav-devel and x264-dev IRC channel's etc, clearly there's a very high proportion of active developer's there and contributing patches to libav right now including the so called Mplayer dev's.
clearly most average people dont realise just how small a team the core patch developers are in the video related app's you use every day, for instance the ever massively popular VLC core devs are in reality 2 people, and in need of more windows devs to contribute patches directly to that platform... they take their core code from FFmpeg/libav and x264 just like #handbrake-dev and most other 3rd party app's devs do today
Heh, I know the feeling!
Yes, some names even I recognize, like garret-glaser, rullgard from x264 project and Bultje. Anyway, best scenario is that the projects merge again and bad blood be put away. And if that doesn't happen we'll just have to wait and see which one emerges as the project of 'choice', as in which lib applications will link to.