I tried to add ffmpeg support to the vlc ebuild and I had to query for the avi USE flag; it would be nice to have a divx USE flag Reproducible: Always Steps to Reproduce: 1. 2. 3.
isn't DivX just a form of AVI?
nope. DivX is a codec (format for data) and AVI is a multiplex format (roughly, a way to pack one video and a number of audio streams together keeping them in sync). Saying DivX is a form of AVI is more or less as wrong as saying tar is a form of gzip.
I realize this isn't much helpful in gentoo terms :-) the reason why a DivX USE flag is desirable is that it introduces a different and almost orthogonal set of dependencies; if you want divx support in your media player you need a divx codec, and these packages can be either huge, prone to breakage, or non-free.
lalo, I'm just wondering what the "divx" USE flag would satisfy that the current ones in use wouldn't
divx could be used for instance to in/exclude divx support in media players. divx and avi support are quite different. One is a content type, the other is a filetype. DivX can also be included in .mov and .ogm file for instance. It would be like using only an X variable and not making any difference between kde and gnome. ;) btw. i think a mpeg4 (divx is related to the family) is a better choice. for instance what i would like to see is the following USE variables For video: mpeg, mpeg2, mpeg4 (divx, xvid, 3ivx and true mpeg4), real, wmv, quicktime For audio mp3, aac, a52(or perhaps surround ??) For files avi, mov, mp4 Other wanted use variables: wxwindows (for wxGTK and wxPython GUI kits) v4l - Video 4 Linux So, just my 2 cents. BTW. i noticed that several USE variable descriptions name certain libraries. (quicktime for OpenQuicktime for instance). I think this is wrong. there are many other forms for providing quicktime support, which library gets used is irrelevant in my eyes. DJ, VLC media player developer
for Lalo: I miss the point of the enhacement, you want to make ffmpeg (and mplayer) be optional dependences or something else? for Derk-Jan here the current IUSE for vlc-6.2 IUSE="arts qt ncurses dvd gtk nls 3dfx svga fbcon esd kde X alsa ggi oggvorbis gnome xv oss sdl aalib slp truetype v4l xvid lirc wxwindows imlib mozilla dvb debug faad xosd matroska altivec" we'll try to add some of the others requested flags that are already present as global useflag, but I think that setting too many local useflag would be problematic.
Luca, please mind this bug is *old*. When I opened it, the vlc ebuild had no support for ffmpeg. But ffmpeg on vlc is a different bug. This bug is about adding an USE flag for the divx codec (this USE flag could be used for many other packages, as you will notice if you follow the comments).
just added 2 bugs on depend. maybe there are more bugs (packages) which could be configured with IUSE divx marc do you know some packages which could use this flag ?
please notice also that there are more than one decoder supporting mpeg4 and divx! (libavcodec, ffmpeg, divx4linux). I submitted Bug # 30242 because I don't like the divx4linux library (especially as ist binary-only, and the binary additionaly don't works with our clibs (needs complib, which broke my avidemux2, mplayer and all other executables looking for divx4linux even if lavc is installed). Wouldn't it be better to USE those on a per-library base rather than on a per-codec base (like +divx4linux +ffmpeg instead of +mpeg4)? Programs that could use those are nearly all that use video codecs and support different encoding engines, like mplayer, xine (I think), avidemux2. Mostly this is a dependency issue; while most of those packages "require" divx4linux or other codecs, they might also work without. But I'm not sure if we'd end up with to many USE flags, like this :/
Let's see it that way: We have certain methods to decode mpeg4. Usually the configure process scans for required libaries and for optional ones too. The (imho) primary use of a divx USE-flag would be _not_ to implement divx and such, especially for encoding and video processing. The struggle about software patents in mind this could be a good thing(tm) for gentoo. On the other hand a divx flag would mean finding all the packages with divx (and mpeg4 and xvid...) and change the ebuilds accordingly plus enabling divx in make.globals. I must take a look at the number of ebuilds affected by this to state a position. From the user pov I'd say a -divx flag would be useful in maybe one or two ebuilds.
Anything going on with this? Zypher?
I'm stronly for naming such flag mpeg4. DivX might be famous, but it refers to MPEG-4 implementation by DivX Networks (see media-libs/divx4linux) or adjusted Microsoft mpeg4v3 codec dubbed "DivX ;-)". There are other packages that support MPEG-4 encoding and/or decoding (ffmpeg, xvid, mplayer to name few) including its DivX flavor natively. In the addition some players include support divx4linux libraries instead of native MPEG-4 decoder. My proposal: divx flag - include/exclude support for divx4linux mpeg4 flag - include/exclude support for any MPEG-4 implementation (-mpeg4 implies -divx)
Well, I don't think it is possible to build ffmpeg or mplayer without mpeg4 support. It is possible though to build mplayer without the dix4linux libaries. That is the point I see in such a flag, as I stated above. When last time I counted it was about ten ebuilds using the divx4linux libs as a (possible) dependency. Not counted are the packages that depend on the counted ebuilds, for example xine-ui and gxine need xine-lib which could be built with or without divx4linux. So if we choose to introduce such a flag I suggest call it div4linux and it exactly does what it sounds like, enabling/disabling the use of divx4linux. In that case, naturally someone must change the ebuilds according to the new flag and test them. I could do (most of) this work, I don't use divx4linux anyway. Nevertheless if I completely missed Peters point about an mpeg4 flag would someone please explain it to me. ;)
Fine by me. A user had raised the question of creating a Xvid global use flag also... same apps that the divx* affects, Xvid would also. Thoughts?
True, there are not quite as much but I expect the number rising. If there are no objections, I could introduce two new global use-flags "divx4linux" and "xvid" and will have a look at the concerned ebuilds.
Marc, I concure about the xvid and divx4linux USE flags. I have an ebuild for vlc-0.7.1 (bug 37639) that I will probably be submitting into the tree soon, which already has a local xvid flag. And I have an updated mplayer ebuild that is related to the vlc ebuild (bug 43640).
Sorry for the delay, my real life (especially the "end of Q1/04") sucks atm. I'll probably have time at the weekend and will pick up the dev-work again. Thnx for your patience. Cheers, Marc.
media-tv/xawdecode would also be a good candidate for a divx4linux USE flag. It has xvid and ffmpeg support, so disabling this non-free codec would make sense for many users i think. If this flag is accepted, then replacing 'x86' with 'divx4linux' in both RDEPEND and econf options would do the trick (assuming that this flag would be masked for non-x86 profiles).
divx4linux and xvid are global flags now.