Is MPlayer2 A Viable Fork Of MPlayer?

[Viper_Scull]

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

[Ian_M]

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

[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.

[Wyatt]

Wait, you can still build mplayer with gui support? And people USE it? What.

[DanL]

offtopic
"libass" is a pretty funny name btw

liboobs is good too

[evolution]

Well, I don't like this fork very much because of these facts:

1) I've to use a statically linked ffmpeg (if using mplayer2-git), whereas I prefer to compile ffmpeg with my own options and dynamically link mplayer against shared ffmpeg.

2) Doesn't support vaapi, so it's useless for my Desktop with a HD4650AGP card. (I don't want to decode a 720p H264 video in a P4@3.4GHz using 100% of the CPU)

But other than that, I think the project can succeed.

Cheers

[brent]

You can link against your system ffmpeg just fine. The mplayer2-build repository is just meant to provide a self-contained mplayer that doesn't have any special dependencies. You don't have to use it.

[evolution]

You can link against your system ffmpeg just fine. The mplayer2-build repository is just meant to provide a self-contained mplayer that doesn't have any special dependencies. You don't have to use it.

Oh, I see!

How about compatibility with vaapi patches? Has anyone tried so far?

Cheers

[m45t3r]

First FFMpeg got forked, then MPlayer too.

Not really, this project is going for a long time already (I acompany this project for almost a year, it was called mplayer-git or mplayer-uau before). But the originai idea was to create patches that would be merged to upstream MPlayer. Almost no patch was merged and the changes are getting bigger and bigger, so time to fork.

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.

No, uau and verm (two of the main developers of this fork) are not involved with the recent libav issue.

Wait, you can still build mplayer with gui support? And people USE it? What.

Yeah, using ./configure --enable-gui. I remember uau saying that one of the developers of mplayer bitching about removing this piece of crappy, so you can say this is one of the motives of this fork.

Oh, I see!

How about compatibility with vaapi patches? Has anyone tried so far?

Cheers

The best thing you can do is try. I remember to compile mplayer-git with CoreAVC patches and it worked just fine. But the changes on the future version 2.1 will be more agressive, so I believe from this version towards there will be no patch compatibility from mplayer.

You can always send a feature request on their bug tracker too (http://devel.mplayer2.org/wiki/Bugs).