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 attachment 69745 [details, diff] 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 attachment 76472 [details, diff] 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 attachment 76487 [details, diff] 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 attachment 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 attachment 97848 [details, diff] 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 attachment 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 attachment 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.
