ffmpeg: Replace negatively named variants with positively named and changing default variants

[neverpanic (Clemens Lang)]

The state of ffmepg's variants is less than optimal… if you want AAC support you will install ffmpeg -no_nonfree. Now while I could think of a few ways to add yet another negation, maybe we should change those to positively named variants.

The attached patch changes

• no_nonfree to nonfree and makes it the default my removing +non_free from default_variants
• no_gpl to gpl and makes it default by adding +gpl to default_variants
• no_mxx to mmx and makes it default by adding +mmx to default_variants

Notes: The no_gpl variant deleted a "--enable-libfaad" switch from configure.args, which was never there to begin with and breaks the build if added. I've commented it at the moment.

The same patch should probably applied against ffmpeg-devel, and maybe gst-ffmpeg, too.

[neverpanic (Clemens Lang)]

Patch against Portfile

[dbevans (David B. Evans)]

Thanks for your input. Looks like you and I have been thinking about the same things this evening. The -no_nonfree in particular has been bothering me since it became a "default variant".

First, a little philosophy.

To my mind, variants represent an optional change from the default behavior for a port. Hence, the idea of a "default variant" seems like a bit of an oxymoron.

With respect to ffmpeg, the developers philosophy is that it should do any and everything. So the appropriate default is "include everything".

They then allow you to disable things you don't want. First to go is the nonfree stuff, then the GPL if you feel you must have LGPL, etc.

So that's the way the port was originally set up. Everything enabled that MacPorts supports as the default. Then the variants for the optional selections of no nonfree code (libfaac) leaving GPL and LGPL and finally no GPL leaving just LGPL.

I think this makes sense. Start with the whole then make subtractions.

Where things got crazy recently was the introduction of a build server to allow distribution of pre-compiled binaries. Its OK to compile nonfree code for your own use but it shouldn't be redistributed in binary form.

So the quick fix was to make no_nonfree a "default variant". So if you really want to compile the whole thing including the nonfree code then you have to say "no no_nonfree" as you say.

I propose to do the following:

• Make the default configuration just the GPL and LGPL code without any nonfree code so the build server can make a distributable binary by default. No variants, default or otherwise required.

• Add a new variant +nonfree to add back in the nonfree code for those who need it (most?)

• Leave the no_gpl as is. Most people will want it and those that don't can use the variant.

Not optimum but fits within our required constraints. The upstream guys are trying to get everything LGPL so if that happens then this will all be moot.

As to faad2, it was used by ffmpeg many revisions ago but is no longer necessary. References to it were removed along with other cleanup in r83668. Changes in ffmpeg merged into ffmpeg-devel in r83670. ffmpeg updated to 0.7.4 in r83674,

Will work on the variant situation as outlined (in both ffmpeg and ffmpeg-devel) next.

Hope this addresses your concerns.

[dbevans (David B. Evans)]

By the way gst-ffmpeg uses an embedded snapshot with a fixed configuration that meets that port's needs so that's another thing entirely.

[dbevans (David B. Evans)]

I forgot about no_mmx. Again, mmx should certainly be the default if possible and the no_mmx was originally added because it didn't work in some situations. I think that is no longer the case and that the real need for it has gone away. I'm tempted to remove it but there may be someone who needs it for some reason so will probably leave it for now. Maybe just for debugging or benchmarking purposes.

[neverpanic (Clemens Lang)]

Sounds good. I haven't seen variants as diverting from the default, but that sounds reasonable to me. I was under the impression we were trying to drop no_* variants, though. You have a valid point, although one that counts entirely against having the default_variants keyword at all.

The reason I suggested this patch in the first place was -no_nonfree, and this will be fixed, so I'm fine with what you suggested.

[dbevans (David B. Evans)]

Fixed as proposed (both ffmpeg and ffmpeg-devel) in r83708.

Thanks again for your input.