Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=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] [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.
> 

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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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.