Skip to content
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

Merged
merged 1 commit into from
Mar 8, 2015
Merged

ffmpeg: refactor to generic #6602

merged 1 commit into from
Mar 8, 2015

Conversation

codyopel
Copy link
Member

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)

@vcunat
Copy link
Member

vcunat commented Feb 28, 2015

Currently I added all possible branches, however I don't intend for them to be added.

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).

@vcunat
Copy link
Member

vcunat commented Feb 28, 2015

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...

@offlinehacker
Copy link
Contributor

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.

@viric
Copy link
Member

viric commented Feb 28, 2015

On Sat, Feb 28, 2015 at 02:48:07AM -0800, Vladimír Čunát wrote:

Currently I added all possible branches, however I don't intend for them to be added.

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).

I agree.

@codyopel
Copy link
Member Author

@vcunat
I migrated the build away from using variables specified true/false it now relies on whether the build input is null or not (except in the case where features/build inputs are disabled by default). The only thing that would make sense is adding optionals for build inputs that are disabled by default and for specifying versions that build inputs apply to so that you aren't downloading additional dependencies older version.

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
I wasn't sure what needs to be done since I haven't dealt with cross compilation in relation to nix. I have already setup native build inputs so it should be ok there. I am not sure how ever if the way I have os/platform specific portions will work or not (currently only multithreading has anything explicitly platform specific). The other part I wasn't sure of is determining the OS that you are cross compiling for, since it needs to be specified for FFmpeg, in the past the target OS was just explicitly set to linux, I added a section to return the target OS, but I don't know that it will work or not.

@vcunat @viric
I planned on only adding the necessary versions, but wanted input incase anyone felt differently and as a proof of concept that all branches work.

@vcunat
Copy link
Member

vcunat commented Feb 28, 2015

Ah, I forgot you use that null-style switching. It's probably not much worth investing time into detailing the deps more.

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.
Copy link
Contributor

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'

Copy link
Member Author

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
@codyopel
Copy link
Member Author

codyopel commented Mar 1, 2015

@Fuuzetsu
No, I used ffmpeg_0_10 instead since it is branch 0.10.x and not version 10. I changed it so that branches uses the following format ffmpeg_<version>_<branch>.

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).

wkennington added a commit that referenced this pull request Mar 8, 2015
ffmpeg: refactor to generic
@wkennington wkennington merged commit b452bd4 into NixOS:master Mar 8, 2015
@codyopel codyopel deleted the ffmpegbr branch March 28, 2015 14:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants