Is MPlayer2 A Viable Fork Of MPlayer?

[XorEaxEax]

I seem to recall that the same guys who were the main driving force in the ffmpeg 'fork' also took over certain administrative parts of the mplayer project earlier. I can't help but wonder if mplayer2 is a fork by them or caused by them or non-related. I'll try digging up the blog posts were I read about this and see if I can get some sort of overview of what (if anything) is going on.

[Ian_M]

All of these things are welcome changes, especially dynamically loading ffmpeg and removing gmplayer.

[Viper_Scull]

Agreed. Excellent work. using AUR package with SMPlayer svn.

[crazycheese]

Michael, its "mplayer2" vs "MPlayer", not "MPlayer2" vs "MPlayer".

Awesome fork btw, definitely better than MPlayer.

[yogi_berra]

Some of the stuff that's come up on ffmpeg-devel has been pretty ugly.

They bring it on themselves with their attitude. Up until recently they didn't bother linking to their bugtracker and they still spend a significant amount of time on their "wall of shame."

[Wyatt]

As far as I'm concerned, forking isn't nearly so big a deal these days because git is neat like that. The ffmpeg/libav thing was unfortunate, and I still don't think it was a great idea, but upon further thought it occurs to me that maybe more development will get done because less friction sparks fewer flame wars. (Some of the stuff that's come up on ffmpeg-devel has been pretty ugly.) Maybe we'll see a similar effect here?

There will be people that cherry-pick patches across party lines, so this may even end up a GOOD thing for the technical state of the art, if not the community/political aspects.

[cl333r]

offtopic
"libass" is a pretty funny name btw

[accumulator]

direction looks sane to me

Runtime-switchable translations with gettext are now supported.

finally!

MPlayer2 does not depend on embedded FFmpeg library copies and uses FFmpeg only through its public API

finally!

Support for gapless playback of audio files (option -gapless-audio)

finally!

Future work will concentrate on improving the interface for external GUI implementations instead.

finally!

All in all it looks like some good architectural choices are made in this fork..

[loonyphoenix]

There's an Arch AUR package, too.

http://aur.archlinux.org/packages.php?ID=46805

I'm currently using it, and it works well with SMPlayer, and it does feel snappier.

[timofonic]

First FFMpeg got forked, then MPlayer too.

This is a sign the FFMpeg ecosystem needs a lot stronger and democratic leadership. The lack of a strong organization behind it is showing the problems lately, but it seems the symptoms were already there in the underground.

I think it's time to make a proper Foundation (name it whatever yoy may want), with a strong look at consensus from different project members and in collaboration with other organizations. Look at Linux Foundation, X.Org Foundation and Document Foundation for examples.

Forking is a good way to experiment different paths and showing different ways. It was quite good with EGCS that showed the technical superiority and got merged back to GCC, Libreoffice forked from OpenOffice and is starting to show the benefits of open government without a very big coporate head behind it.

The most weak point of FOSS is sometimes the lack of a strong organization behind projects. This can be a non-issue in hobbyist or small projects for some time, but not when your project gains lots of importance and grow in terms of complexity. I believe that's the main reason FFMpeg and other related projects are having organizational problems so they are forking...

At a long time, I think an Open Source Confederation must be done someday. I'm not talking about some geeky utopian idea taken from Star Trek, but looking at non-tech organizations out there that did something similar to that. This can make the community stronger and also put more pressure both in media and governments.