Bugzilla Bug 107922

mplayerplug-in can be used in 64-bit firefox/mozilla with 32-bit mplayer-bin. 
All that is required is a symlink of mplayer-bin to mplayer, plus a change to
the mplayerplug-in ebuild to not pull in mplayer.  This works because
mplayerplug-in execs mplayer, rather than loading it or any of it's libraries. 
The attached patch to mplayerplug-in-3.11.ebuild enables this (and moves the
mplayer dep to RDEPEND where it belongs)

Created an attachment (id=69745) [details]
Patch for mplayer-bin

Does mplayer-bin already have the symlink to mplayer.

No, because mplayer could be installed either before or after.  If there's a
decent way to handle this, I'd love to do it.

Why not have a use flag for mplayerplug-in that chooses to launch mplayer-bin
instead when emerged with this flag?

That's quite possible.  I have a patch for mplayerplug-in that causes it to run
mplayer-bin rather than mplayer.  Would such an option be acceptible?

I think that also the firefox depencies can be fixed to avoid emerge mozilla if
firefox-bin is present.

I think that you can try to use mplayerplug-in-bin from
http://www.sh.nu/download/ebuilds/mplayer/

Only needs an ebuild ;)

Wouldn't it be easier to ask the author for a config option for the name of the
mplayer program? Then you can specify mplayer-executable=mplayer or
mplayer-bin.

There's a similar problem with the image and movie viewer gimageview. Since
there's no file called mplayer in $PATH you can't watch movies. One quick
solution would be to create a symlink called mplayer pointing to mplayer-bin as
mentioned before.

Another thing I have thought of is if there's any reason to have both mplayer
and mplayer-bin installed at the same time? If not, I guess you could call
/usr/bin/mplayer-bin mplayer as well and let the two packages block each other.
This would make mplayer-bin compatible with other programs such as gimageview
and mplayerplug-in.

I guess that gimageview could have mplayer or mplayer-bin as a dependancy just
as in the patch posted earlier but that might be a separate bug report...

I tried to copy paste a few parts to get an additional mplayer= option in the
config file. But since i have zero C++ knowledge i did something wrong. Maybe
some one with some basic knowledge in C++ could do a quick patch.

plugin.h: I've added "char *mplayer_binary;"

plugin-setup.cpp: I've copied just another existing block to

if (strncasecmp(buffer, "mplayer", 7) == 0) {
    snprintf(parse, 1000, "%s", strtok(buffer, "="));
    snprintf(parse, 1000, "%s", strtok(NULL, "=\n"));
    if (instance->mplayer_binary != NULL)            
        free(instance->mplayer_binary);
    if (strstr(parse, "`") == NULL)     // don't allow shell commands
        instance->mplayer_binary = strdup(parse);                    
    continue;                                    
}

plugin-threads.cpp:
-      snprintf(buffer, 1024, "mplayer");
-      instance->td->argv[i++] = strdup(buffer);

+      if (instance->mplayer_binary) {
+          snprintf(buffer, 1024, "%s", instance->mplayer_binary);
+          instance->td->argv[i++] = strdup(buffer);
+      } else {
+          snprintf(buffer, 1024, "mplayer");
+          instance->td->argv[i++] = strdup(buffer);
+      }

Ofcourse i failed for some reason and it crashes.

Created an attachment (id=76472) [details]
adds mplayer binary option

I sucked hard and forgot to NULL the string. Theres a quick hack for 3.17.
Worked 2 mins. on my machine with either commented out mplayer= or something
defined.

Created an attachment (id=76487) [details]
Updated mplayer binary config patch

Sigh one hopefully last NULLify (on shutdown)

I have stumbeled across the same issue but with different package:
kmplayer.

I emerged "mplayer-bin" but now "kmplayer" wants to emerge mplayer.

I propose another solution: add the "symlink" flag to mplayer package.

If "symlink" is set, "mplayer-bin" is symlinked to "mplayer".

kmplayer and mplayerplugin could then check for (is this even possible?):

|| (mplayer mplayer-bin-with-symlink)

Originally mplayerplug-in had an option just like this. It was removed because
it allowed people to do dumb things... for example they could set mplayer-bin
to something completely wrong

mplayer-bin=bash

A patch that does this will be rejected into mplayerplug-in

Great, punishing the average user because you want to protect some idiots from
themselfs. 

Created an attachment (id=97846) [details]
Updated mplayerplug-in-3.31-r1.ebuild

Updated ebuild
* New useflag, mplayer-bin: Use mplayer-bin instead of mplayer.

* Change useflag realmedia to real.

* If amd64 it will also compile the 32bit plugins. This make mplayerplug-in
work on both mozilla-firefox and mozilla-firefox-bin at the same time.

* Now depend on either mozilla-firefox or mozilla-firefox-bin

* Fixed bug #148625 mplayerplug-in: Install into
/usr/lib[32,64]/nsbrowser/plugins instead?

* Need mplayer-bin.patch, see below.

Created an attachment (id=97848) [details]
mplayer-bin.patch

Patch to change from mplayer to mplayer-bin.

First of all, the realmedia flag should *not* be changed to real.  There are
other ways to get real-media support besides using the real flag (which is
masked on some arches). Since mplayerplug-in provides stream support, rather
than the codec support, it needs to be different than "real".

I'll look into changing from installing to /opt, but I'm pretty sure that's
like that for browsers that don't have /usr/lib[32,64]/nsbrowser/plugins as a
plugin directory.  I guess we could add symlinks to /opt, but that defeats the
purpose of moving it in the first place.

I have no AMD64 machine, so I can't comment on the AMD64 parts besides siding
with Kevin since he's upstream.  If you can work out the mplayer-bin issues
with Kevin and get them merged upstream, I'd be happy to fix mplayerplug-in's
ebuild to support it.

Sorry for the late reply, the email didn't reach me... *Sigh*

(In reply to comment #18)
> First of all, the realmedia flag should *not* be changed to real.  There are
> other ways to get real-media support besides using the real flag (which is
> masked on some arches). Since mplayerplug-in provides stream support, rather
> than the codec support, it needs to be different than "real".
Ok, didn't know that...

> 
> I'll look into changing from installing to /opt, but I'm pretty sure that's
> like that for browsers that don't have /usr/lib[32,64]/nsbrowser/plugins as a
> plugin directory.  I guess we could add symlinks to /opt, but that defeats the
> purpose of moving it in the first place.
Isn't there any way to change this behavior for the browsers in question, if
there are any? Installing into /opt feels wrong when using a multilib system,
works good on a none multilib system. Or is it just me?

If we choose to install into /usr/lib instead we wouldn't be the only
application to do that, Totem for example install into /usr/lib. So I really
don't see the problem here but it's possible that I'm blind.

> 
> I have no AMD64 machine, so I can't comment on the AMD64 parts besides siding
> with Kevin since he's upstream.  If you can work out the mplayer-bin issues
> with Kevin and get them merged upstream, I'd be happy to fix mplayerplug-in's
> ebuild to support it.
> 

I'm not sure if I follow you on this one, but by using the patch instead of an
option for mplayerplug-in the problem never occurs, right? 

Is it a bad solution to install the plugin for 32-bit and 64-bit browsers?
Mplayerplug-in does in fact have a configure option for this purpose.

Created an attachment (id=104439) [details]
Version bump

Thought I'd version bump this ebuild. It works great for me on amd64 (nocona).

Ebuild works great for me -- at least the building of the 32 bit plugin (which
works great).  I'd like to voice my support for this ebuild (or some other
option) building a 32-bit mplayerplug-in for amd64, since without it, no single
browser can have the necessary plugins on amd64.

Created an attachment (id=116235) [details]
mplayerplug-in-3.40.ebuild

Version bump, you will need the patches from #172328

I've added the mplayer-bin patch and moved to the nsplugin dir instead of opt. 
I still won't change the realmedia flag as real is only for enabling the binary
real codecs, not enabling real support in general.  The main problems that this
bug brought up are now addressed, but feel free to open a new bug if you've got
other changes.