can both be installed on the same machine ?

CC: (none) => dmorganec

honestly i preferred to remove mplayer 1 from my linux box in order to avoid any issue....

If not both of them I would prefer to keep mplayer1 for this reason (written on the website) : 

"Dropped features
MEncoder is no longer available

The MEncoder codebase was thoroughly rotten and has been deleted. A different solution to provide some encoding functionality will be added in a future version."



Mplayer2 is strictly a videoplayer (better, certainly) but no more a swissknife as mplayer1 used by other apps  ! uninstalling mplayer1 implies you no longer use 2mandvd nor acidrip which need mencoder

CC: (none) => philippedidier

it's a temporary features until a new api or solution is implemented mplayer2 is now a video player only. you can still use gstreamer enconding capabilities or ffmpeg api. I only use mplayer as video player so i don't care much about MEnconder.

I use acidrip so i pretty much care and probably many other users do as well. If mplayer2 can't replace the current one fully then we should wait until it does.

CC: (none) => sander.lepik

From the official website : "Currently mplayer2 uses the same binary and directory names as MPlayer"

So mplayer and mplayer2 can't cohabit.
As mplayer2 doesn't provide mencoder (used by many apps), this blocks the inclusion in Mageia.

The only solution is that mplayer2 be renamed to make the cohabitation possible.

CC: (none) => olivier

dod anyone check whether it acutally is impossible to just keep using the mencoder package?

have the existing mplayer package build "mplayer1" and "mencoder" packages, and make mplayer2 the new mplayer (or add "Conflicts (or even Obsolets): mplayer" and keep it as mplayer2)

CC: (none) => lohmaier+mageia

Created attachment 984 [details]
specfile to build mplayer2 as mplayer2, to be installed alongside mplayer

it's pretty easy to make the two not conflict with each other.

The attached specfile builds mplayer2 as mplayer2, so it can be installed alongside mplayer.

Only the installname is changed, it will still use mplayer's configuration files.

I didn't bother setting up all the buildrequires right and deal with tainted vs non-tainted and with the target-cpu (mplayer as well as mplayer2 default to optimizing for the build host's CPU, so a nogo for a RPM meant for distribution, but fine for personal use) this is left as an exercise for the actual packager.

To build it, just install mplayer's builddependencies, or look at configure's output and install the missing bits

Created attachment 985 [details]
simple patch needed to also install the manpages as mplayer2

as with the spec itself, only the installname is changed, not the contents of the manpage.

add --confdir=/etc/mplayer/ to the configure line, otherwise it will look for the default config in /usr/etc/mplayer/mplayer.conf (same for systemwide codecs.conf)

*** Bug 3273 has been marked as a duplicate of this bug. ***

CC: (none) => lda.thedevil.dark

Setting version to cauldron, because package requests will usually be done for cauldron first and are then expected to be available in the first stable release that follows.

Keywords: (none) => PATCH
CC: (none) => marja11
Version: 1 => Cauldron
Summary: replace mplayer with mplayer2 (fork of the first mplayer) => mplayer2, an advanced general-purpose video player, can be installed alongside mplayer
Source RPM: (none) => mplayer2

*** Bug 7492 has been marked as a duplicate of this bug. ***

CC: (none) => xpris

What about mplayer2 pack for Mageia?
Please make rpm mplayer2 without conflict mplayer.

Created attachment 4201 [details]
spec file to build current (as of now) git master of mplayer2

as with the previous version, this spec is mean to be compiled on the target-computer, as it doesn't use the runtime-cpu detection, but optimizes for the host-cpu. It also doesn't list the requries for vdpau, quicktime and similar. If you want full set of features, you should also install buildrequires of mplayer package.

Attachment 984 is obsolete: 0 => 1

Created attachment 4202 [details]
patch to install manpages as "mplayer2"

note that while it installs as mplayer2, no string replacement has been done, so manpages, etc will continue to call it mplayer in most places, but it can be installed alongside mplayer package without problem.

Attachment 985 is obsolete: 0 => 1

I tried to test the build of a RPM for mplayer2, but I didn't find the sources....
How can I get the sources at the correct revision from their website?
Is it possible to ask the mplayer2 team for a simple tar.gz release?

The spec contains the pointer to the source:
Source0:	http://git.mplayer2.org/mplayer2/snapshot/mplayer2-6c87a98.tar.bz2


so do a "wget http://git.mplayer2.org/mplayer2/snapshot/mplayer2-6c87a98.tar.bz" or download with your browser or curl, or whatever... and put it into 
~/rpmbuild/SOURCES/

It is unlikely that mplayer2 team will provide official release tarballs themselves. They're basically in the same situation that mplayer was critisized for: "You don't do releases, thus distributions have outdated versions." So the solution for distros/user is to build from current sources themselves.

BTW: If you're like me and like your audio to have priority over video when switching playback-speed for example, you might want to revert http://git.mplayer2.org/mplayer2/commit/?id=213a224eec05cbd86b06abbdd843f2e252658b37

I'll also look into http://mpv.io/ - another fork (based on mplayer2 this time) - that for example did not include that change.

Ok, sorry, I should have looked.

But the spec in this ticket doesn't work properly.
The %prep section is broken (should be: %setup -q -n %{name}-%{gitver}).
The build breaks on the manpages generation ("rst2man not found").

If there is another fork (with a DIFFERENT name, thanks guys!), let's wait to know on which we should really spend packaging time.

well, apparently they updated their webfrontend to include the version info - so yes, you're right, setup should now include the version.

And getting the buildrequires right: that's why I didn't bother becoming a packager :-)
And finding out where rst2man comes from is not a problem (urpmf for example) 

I have quite a bit of stuff installed from other projects, so getting the requirements 100% correct was of no priority for me.

So Stick a "BuildRequires: python-docutils" in there and try again :-)

Quoting myself:
"I didn't bother setting up all the buildrequires right and deal with tainted vs non-tainted and with the target-cpu (mplayer as well as mplayer2 default to optimizing for the build host's CPU, so a nogo for a RPM meant for distribution, but fine for personal use) this is left as an exercise for the actual packager."

So if you want to actually package mplayer2, you need to configure it for using runtime cpu detection at least.

The spec was initially meant as a proof that they can both be installed alongside with very little effort. 

problem with a package with another name is that it has another name. Users don't know about it. you could do stuff and have it provide "mplayer2" and make mplayer2 only a virtual thing - but again that's something for the real packagers to decide. mplayer2 didn't receive new commits since april, while mpv still receives commits regularily.

I think we can close this bug, now that mpv aka ex-mplayer2 is in cauldron and in 5 backports.

Status: NEW => RESOLVED
CC: (none) => lists.jjorge
Resolution: (none) => OLD

yes, kill it, mpv is even better.