-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ffmpeg: refactor to generic #6602
Conversation
I was just about to point out that having 15+ ffmpeg versions seems pointless. As before, I'd just keep the latest branch and any with an explicit reference (typically due to particular packages not ported to newer ffmpeg branches). |
Is there a particular reason why the particular build inputs are no longer supplied based on configuration? It's probably not much difference in most cases when most features are enabled, but still... |
Btw cross builds work, they just needs a few minor changes like moving perl and texinfo to nativeBuildInputs, but i can do that after this will be merged. |
On Sat, Feb 28, 2015 at 02:48:07AM -0800, Vladimír Čunát wrote:
I agree. |
@vcunat I also changed it so that even though the build inputs are passed by default if you override them to null it will disable the features that depend on the build input (it passes the inverse flag e.g. --disable-, otherwise if the build input is detected is passes --enable-). @offlinehacker @vcunat @viric |
Ah, I forgot you use that |
longDescription = '' | ||
FFmpeg is the leading multimedia framework, able to decode, encode, transcode, | ||
mux, demux, stream, filter and play pretty much anything that humans and machines | ||
have created. It s the most obscure ancient formats up to the cutting edge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is suppose to say 'supports' not 's'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, Thanks, I'll change it when I update the commit to remove the extra branches.
* migrate some branches from ffmpeg.config.<optional>, now allows version specific configuration * Added optionals for most features * Added qt-faststart executable * Licensing corrections * Added dependencies + celt + faad2 + flite + frei0r-plugins + fribidi + game-music-emu + gsm + jack2 + ladspa-sdk + libavc1394 + libbluray + libbs2b + libcaca + libmodplug + libogg + libraw1394 + libssh + libwebp + libxcb + lzma + openal + opencl + opengl + openh264 + openjpeg + openssl + pulseaudio + rtmpdump + samba + soxr + v4l-utils + vid.stab + wavpack + libX11 + libXv + wavpack + x265 + xavs + xvidcore + zeromq * Outlines support for: (unpackaged/broken dependencies) + aacplus + avisynth + crystalhd + blackmagic-design-desktop-video + flite + ilbc + libavc1394 + libcdio-paranoia + libiec61883 + libmfx + libnut + nvenc (nvidia) + opencl + opencore-amr + openh264 + oss + libquvi + schroedinger + shine + twolame + utvideo + vo-aacenc + vo-amrwbenc + zvbi
@Fuuzetsu I only replaced 0.6 with 0.5 on builds that are already broken and I can't test further to see if they compile against newer versions. 0.6 contains build errors with vappi & ffserver and 0.5 on the other hand has had a lot of support and fixes back ported because a few of the major distros (debian & ubuntu in lts releases) continued to use it up until a couple of years ago. 0.6 would be OK if you are only linking against libav, but if anyone actually uses it, it is missing ffserver (despite the fact that it may not be of use to most people). |
ffmpeg: refactor to generic
In order to make this generic I had to add a way to handle differences between version. FFmpeg has always used the same configure script since its first release (0.5), and typically options are only added, but in a few rare cases may be changed or removed. Being as consistent as it has, I used the branch that the change was added in as a minimum version to know whether it should pass the configure flag or not (in most, but not all cases). I am not particularly fond of doing it this way, but the alternative is having a separate builds for each version. To date maintaining branches independent of one another hasn't worked out well in the sense that each branch is currently setup in very different manners, have different feature sets (not because they aren't available in the version) and it becomes much harder to maintain. This generic method is a bit complicated, but it clearly lays out all options and the versions in which they apply. I have already laid out the ground work for all past options, so maintenance should only involve future changes.
Optionals no longer use global settings (e.g.
config.ffmpeg.<optional>
) as this does not allow for having configuration settings specific to versions.All features are enabled by default, with exception to large dependencies like samba, some legacy features, and anything that would conflict with the GPL/LGPL.
I have added a number of asserts to help ensure that enabling and disabling features does not produce unintended results. FFmpeg's configure script is flawed in a few ways because you can explicitly enable the ffmpeg executable and also disable a feature required to build the executable, but the build will succeed without error even though the executable was never built. I still need to add additional tests to prevent these scenarios further.
Platforms such as Cygwin and Darwin may pose problems for some version and might take a bit of work to make sure everything builds correctly, but should be doable. I want to make sure that all features that can build for a given platform do work rather than just disabling them as a work around unless absolutely necessary (such as how libass is currently disabled for darwin).
Currently I added all possible branches, however I don't intend for them to be added. Let me know what versions should be kept. Currently (after my changes) we build against 0.10, 1.2, 2.2, 2.5, and some broken packages that were using 0.6.90 I changed to use 0.5 in case they are ever fixed since 0.6.90 is not an official release.
There are maintainer notes in the comments in which I detailed anything that doesn't work on a given branch with a brief explanation in case anyone wants to add a fix in the future, or if fixes are ever back ported.
Any dependencies that have not been packaged or are packaged but cause build failures are detailed in the maintainer notes. Most missing dependencies I have already started working on and I will add them as I get to them.
@Fuuzetsu @vcunat @edolstra @viric @bluescreen303 (anyone who has dealt with FFmpeg)