I’ve got an idea I’ve started playing around with, to cleanup the mess that is the binary codecs in Gentoo. Right now, the whole situation is confusing. I always get mixed up on what the status is, and if it’s bad for me, I can only assume it’s confusing a few users as well.
Currently, we have three packages just for binary codecs to be used with media players in the tree: win32codecs, amd64codecs and realcodecs. I’m not gonna go into the difference of the three, because I’ve done that so many times, and that’s one thing I’m actually trying to avoid here. Suffice it to say that a lot of users think they need them, when they don’t. They see “win32” and think, “Oh, I want to be able to playback WMA and WMV and DivX so I must need these, right?” Wrong. Support is already native in libavcodec (the backend library for playback in about every multimedia app in the tree) for, well, most everything. I won’t get into the details of specifically what’s missing, but 90% of the time, a user won’t need the binary ones.
Anyway, that aside, what I’d like to do is roll all three into one ebuild. I can’t come up with a real original name, so media-libs/binary-codecs seems to suffice. As long as it doesn’t have “win” in there, I’ll be happy. The idea seems simple enough, and it makes sense on paper, and I already have a base ebuild that does everything, but I thought I better throw the idea out there to see if I can get any feedback.
For what it’s worth, here’s a link to the unfinished ebuild so you can see what I have in mind. I’m tossing the idea around in my head of adding a use flag for every binary codec that it installs. That could help with any future security issues where we’d have to mask the use flag.
That sound like a good idea if you include all the formats as USE flags. Then, users like me will actually know what’s included in those packages 🙂
I’d suggest _against_ going toward this. First the Real binary codecs can be used in situations where the rest really cannot (64-bit xine can load 64-bit Real codecs, but not 32-bit indeo codecs!); second, win32codecs is what upstream calls most of the pack.
What do you mean about Xine and Real? They’re both in there.
Upstream actually already has three packs, one for x86, one for ppc and one for amd64.
er, wow, I was off … there’s more than that. x86, amd64, ppc, alpha, osx x86 & ppc.
And nobody calls them win32codecs except for us. They just package them as essential-arch.
I just looked and I have win32codecs installed. I looked into removing it but got the following:
$ emerge –pretend –depclean win32codecs
Calculating dependencies… done!
media-libs/win32codecs-20071007-r2 pulled in by:
media-video/mplayer-1.0_rc2_p28450
media-video/vlc-0.9.8a
>>> No packages selected for removal by depclean
$ equery depends win32codecs
[ Searching for packages depending on win32codecs… ]
media-video/mplayer-1.0_rc2_p28450 (!bindist & x86 & real? media-libs/win32codecs)
(!bindist&x86&win32codecs? media-libs/win32codecs)
media-video/vlc-0.9.8a (win32codecs? media-libs/win32codecs)
$ euse –active bindist x86 real win32codecs
x86 [+ ]
win32codecs [+ D ]
$ eselect profile show
Current make.profile symlink:
default/linux/x86/2008.0/desktop
Somewhere the win32codecs flag is enabled by default, but I can’t find where. Any ideas?
I don’t mind if those three packages are merged together to a mega package. I do agree that people usually won’t need these, but I have encountered some media files which I have had to reencode in a 32bit environment before I can play in my 64bit environment.
Yeah, you’re very right there.
What do you think of adding some short description of cases where user really need to install these codecs and where he doesn’t somewhere to the fore? E.g. ebuild can be masked by default, or message can be shown after installation.
Excellent idea
But please add lots of einfo explaining it
I always thought the codecs were additional ones that weren’t part of ffmpeg
Mike
i never really got the details about the current state of the codecs packages.
on my amd64 machine i experience the following:
the win32codecs useflag of mplayer is masked for my arch, the package itself is not, it’s ~.
media-libs/amd64codecs is masked.
so, win32codecs is “more” available than amd64codecs on amd64, but also win32codecs cannot be pulled in by mplayer.
a little bit strange, isn’t it?
so, on amd64, how do i get binary codecs? e.g. for watching an indeo video.
This is an issue I’ve run into over the last 10 months or so. I use to be able to view dvd movies, but due to conflicting codecs, I think, any movie simply stops part way into it. I note that mplayer’s log says the cracking of the key is the problem.
>They see “win32” and think, “Oh, I want to be able to playback WMA and WMV and DivX so I must need these, right?”
Most users probably don’t think anything b/c the win32 is a default use flag for x86 desktops, isn’t it ?