Version of precompiled mplayer that was used, in the past, to play certain medias using w32codecs. These days, FFMPEG itself (which mplayer bundles) plays most of these medias. We also have amd64codecs that is getting filled up with the missing bits as Win64 raises it's ugly head. The version is ancient and likely suffers security issues, which is also the reason we never have marked it stable in the past. For those that wonder "why now?". We need mplayerplug-in-3.55 with Firefox 3.x patch in Portage, and marked stable so it doesn't block Mozilla products from entering stable as USE mplayer-bin is blocking the stabilization for amd64. Please use this bug to track all bugs regarding mplayer-bin. treecleaners, amd64 and media-video, please ACK
Maintainers, please fix your packages not to support mplayer-bin anymore. cardoe, media-plugins/mythvideo-0.20.2_p14684:mplayer media-plugins/mythvideo-0.20.2_p15087:mplayer media-plugins/mythvideo-0.21_p16468:mplayer media-plugins/mythvideo-0.21_p17105:mplayer kde, media-video: media-video/kmplayer-0.10.0:mplayer media-video/kmplayer-0.10.0a:mplayer media-video/kmplayer-0.10.0c:mplayer media-video/kmplayer-0.9.4a-r1:mplayer josejx: net-www/mplayerplug-in-3.45:mplayer-bin net-www/mplayerplug-in-3.50:mplayer-bin
Security, do you have some bugs that I'm unaware of that this bug closes? Or any other input for the issue.
As for security, the latest mplayer-bin version is affected by bugs 208566, 215006 and 231836. I have no idea why we never tracked this, but I second the removal request. This package is not subject to GLSA process since it was never stable.
For clarification: amd64codecs is only RealPlayer codecs, not 64-bit binary codecs in general. My vote (as a member of all three teams: treecleaner, amd64 and media-video) is to dump it, as it's difficult to maintain and build, and the general populous of users will do just fine without it. I've been fighting to hold onto it mostly because WMV and WMA weren't supported in libavcodec, but now they are. And upstream is working on support for more Real codecs, so the "popular" ones are eventually going away. On a related but also separate note, I'd also like to eventually open the idea of dumping support for binary RealPlayer codecs as well, because of the consistent security issues that have cropped up with them. It's the same thing as before -- the recent ones are supported in libavcodec, and the old ones which keep creating security problems are in the binary codecs. I only bring it up because Real codecs are the most popular reason for having an mplayer-bin anyway.
WMA3, WMAPRO, WMV screen codec and similar are not supported without binary codecs. I use a 32 bit chroot anyway, so I am not affected, but how difficult would it be to have an ebuild that builds a 32 bit binary?
(In reply to comment #0) > treecleaners, amd64 and media-video, please ACK ACK, I have no preference in this issue at hand. Let me know if any help is needed.
(In reply to comment #5) > WMA3, WMAPRO, WMV screen codec and similar are not supported without binary > codecs. > I use a 32 bit chroot anyway, so I am not affected, but how difficult would it > be to have an ebuild that builds a 32 bit binary? > It's been a while since I worked on it, but I remember it wasn't easy to build and not really something I'd be interested in maintaining myself. I don't even know if I have the ebuild still to build the binary, I'd have to look. I know I got mine from blubb, and he got his from a user that had contributed it. I don't have anything against having the package in the tree, it just needs to either be maintained or dropped.
kmplayer is done.
mythtvideo is being tracked externally
mplayerplug-in is fixed
Masked now (thanks guys for fixing the rdeps)
How will we amd64 users be able to use win32codecs from now on? I really hope you thought of that.
Also what USE flags for mplayer match what mplayer-bin was compiled with?
Also I hope this will support the J-frames in *.asf, a feature which I need. I strongly hope you won't leave us amd64 users without a working solution.
(In reply to comment #14) > Also I hope this will support the J-frames in *.asf, a feature which I need. I > strongly hope you won't leave us amd64 users without a working solution. (In reply to comment #12) > How will we amd64 users be able to use win32codecs from now on? I really hope > you thought of that. I can see some options.. - One can setup your own 32bit chroot and use it from there. - One can become a gentoo developer, and volunteer to upgrade and *most of all keep maintaining* mplayer-bin in portage. - One can maintain mplayer-bin yourself in Gentoo Sunrise User Overlay. Are you volunteering? (In reply to comment #13) > Also what USE flags for mplayer match what mplayer-bin was compiled with? > On your own here, the configure options have changed many times between these two revisions.
i have been tamping with mplayer all day to see if i could figure out to make the ebuild and the required "pre compiled source". For now mplayer is working here but not gmplayer (which i will look into to the next couple of days). I am considering to commit it to the sunraise-overlay when i got it all figured out. So if you want to help with test or what not. Send me a mail.
Created attachment 162455 [details] a very unsteted ebuild well this is my ebuild and precompiled source and i hope someone would like to test it and send me an email if something do not work. All info will go here http://www.second-order.dk/ and bug can be send to my email.
I need mplayer-bin because that's my only option for playing wmv9dmo videos. Maintaining mplayer-bin in sunrise is not a good option. With every update, you need to upload a new 7MB binary, and sunrise doesn't (AFAIK) handle file hosting. Hosting the binaries from random users' own servers is kinda fishy - I am willing to trust the ebuilds submitted to sunrise, but trusting random binaries compiled and hosted by anonymous sunrise contributors triggers paranoia. What would be the steps to become a gentoo dev and maintain this thing? At a minimum, how much time per week does being a gentoo dev take (I am willing to do this, but I do not have much free time).
(In reply to comment #18) > I need mplayer-bin because that's my only option for playing wmv9dmo videos. You better get someone to maintain and actually update the win32codecs upstream, because those are ancient.
(In reply to comment #17) > Created an attachment (id=162455) [edit] > a very unsteted ebuild > > well this is my ebuild and precompiled source and i hope someone would like to > test it and send me an email if something do not work. All info will go here > http://www.second-order.dk/ and bug can be send to my email. > Can you post the ebuild you used to build the binary somewhere, that's what we really need an updated working fix of. As far as hosting, I'll move the ebuilds into my overlay and host the binaries on my website. The manifest won't change, so you can be sure the packages aren't compromised.
Created attachment 165901 [details] the ebuid that the -bin is build from
Please don't remove this until 64 bit mplayer supports decoding audio in 0x162 codec (which is at the moment possible only in the 32bit version)
[ Adding myself to CC... ] p.s. Any progress with new -bin version? I'd like to test p27120, but host second-order.dk is not responding.
To be honest, I don't understand how the mplayer-bin build ebuild that was posted above is supposed to work. As far as I can tell, it's simply a copy of the in-tree mplayer-1.0_rc2_p27120-r1.ebuild, which means, for example, that you would have lots of file collisions if you install the resulting -bin at the same time as normal mplayer. An ebuild for correctly building the -bin needs to be heavily modified from the original mplayer ebuild.
Created attachment 173324 [details] ebuild for building a p27725 -bin An ebuild for building mplayer-bin-1.0-rc2-p27725. To use it, stick the ebuild in a portage overlay inside an emul-chroot (see http://www.gentoo.org/proj/en/base/amd64/emul/index.xml). To the emul-chroot's /etc/portage/profile/package.use.mask, add media-video/mplayer-bin -sse -sse2 -win32codecs To the emul-chroot's /etc/portage/package.use, add media-video/mplayer-bin bidi cpudetection custom-cflags dv dvd encode gif gtk jpeg opengl oss png quicktime rtc sdl sse sse2 win32codecs xinerama xvid xvmc zlib Finally, to compile mplayer-bin inside the emul-chroot, run CFLAGS="-O2 -march=i686 -pipe -m32" emerge mplayer-bin (the -m32 compiler flag *is* required, without it the build process will terminate with errors)
Created attachment 173327 [details] ebuild for *installing* a p27725 -bin An ebuild for installing the mplayer-bin p27725 package on an end-user's system. I uploaded the mplayer-bin-1.0_rc2_p27725.tbz2 binary package to http://drop.io/tetromino_distfiles where it will hopefully stay for at least a year. Unfortunately, drop.io does not provide stable download URIs, so I can't make the ebuild automatically download the tbz2 file - you will need to download it from the browser.
(In reply to comment #26) > An ebuild for installing the mplayer-bin p27725 package on an end-user's > system. Thanks. After few quick tests seems to work ok. I'll post if any error will show up. Hopefully this build will go to portage, to avoid using drop.io.
Created attachment 174498 [details] ebuild for building a p28058 -bin New ebuild for building mplayer-bin-1.0-rc2-p28058 inside an emul-chroot. Uploaded the resulting package to http://drop.io/tetromino_distfiles To install the package, you can simply copy the *install* ebuild for p27725 with no changes.
Created attachment 177985 [details] ebuild for building a p28288 -bin New ebuild for building mplayer-bin-1.0-rc2-p28288 inside an emul-chroot. Uploaded the resulting package to http://drop.io/tetromino_distfiles To install the package, you can simply copy and rename the *install* ebuild for p27725 with no changes.
(In reply to comment #5) > WMA3, WMAPRO, WMV screen codec and similar are not supported without binary > codecs. Thanks for clarification. Is this situation changed? This package really needs to die as there is no active Gentoo developer to look after it.
We (ssuominen and I) have decided to go ahead and punt this thing. The fact is, WMA and WMV aside, there is always going to be codecs that are not natively ported. I realize, of course, that the rest of them are not as popular, but I don't want to hold back on keeping old, crufty stuff in the tree just because it still works. The fact is, it's unmaintained and unwanted, and should be removed. It's a perfect candidate for an overlay, where someone who wants to give it the TLC it deserves can do so. For archiving it, I've put the ebuilds and the tarballs in my overlay, if someone wants to use them. Also, if someone wants to use my overlay to add any changes, I'll be glad to do so. http://spaceparanoids.org/gentoo/overlay/
punted from tree
(In reply to comment #31) > We (ssuominen and I) have decided to go ahead and punt this thing. > > The fact is, WMA and WMV aside, there is always going to be codecs that are not > natively ported. I realize, of course, that the rest of them are not as > popular, but I don't want to hold back on keeping old, crufty stuff in the tree > just because it still works. > > The fact is, it's unmaintained and unwanted, and should be removed. It's a > perfect candidate for an overlay, where someone who wants to give it the TLC it > deserves can do so. > > For archiving it, I've put the ebuilds and the tarballs in my overlay, if > someone wants to use them. Also, if someone wants to use my overlay to add any > changes, I'll be glad to do so. > > http://spaceparanoids.org/gentoo/overlay/ > I suggest Sunrise instead. ;)
Thanks for keeping it somewhere :) There are still people needing it.
