Rebuilding FFmpeg with NVENC and AAC on Ubuntu

This mini guide will show you how to rebuild the exact version of FFmpeg that comes with your version of Ubuntu and just add support for NVidia GPU encoding via the NVENC API and ACC via libfdk_aac.

# Download and unzip the NVIDIA Video Codec SDK from

# Copy the headers files from the SDK so FFmpeg can find them
sudo cp nvidia_video_sdk_6.0.1/Samples/common/inc/*.h /usr/local/include/

# Make sure "Source code" is enabled in System Settings... -> Software & Updates
# Download the build dependencies for FFmpeg
sudo apt-get build-dep ffmpeg

# Install libfdk_aac
sudo apt-get install libfdk-aac-dev

# Download the source for the exact version of FFmpeg you already have installed (not as root)
apt-get source ffmpeg

# Go into the ffmpeg source you just downloaded
cd ffmpeg-2.8.6

# Find out the exact command the ffmpeg was originally built with
ffmpeg -buildconf

# Copy the single line "configuration:" and pass it to ".configure" but add "--enable-nonfree --enable-nvenc --enable-libfdk-aac" on the end
# Mine looks like this:
./configure --prefix=/usr --extra-version=1ubuntu2 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv --enable-nonfree --enable-nvenc --enable-libfdk-aac

# Now build it

# And finally install it over the original
sudo make install

Linking Nvidia GPU temperature with a motherboard PWM fan in Linux

So I have a closed loop water cooler on my GPU and I replaced the stock single speed fan with two Noctua PWM fans (doing push/pull) connected to my motherboard. Even though the fans can be seen by lm_sensors and fancontrol the Nvidia GPU does not appear as it’s proprietary driver.

I knew nvidia-settings could be used to query the temperature (and the pump speed if you care) so I wrote a script to tie it all together:

#!/usr/bin/env bash
set -e

# This is the path to the PWM controlled fan (use lm_sensors/fancontrol to help you identify this)
# Read for your PWM chip to find the correct values (I have a nct6792)
# Temperature at which to run fan at 100% speed

# Re-enable automatic fan control on exit
trap "echo ${automatic} > ${fan}_enable; exit" SIGHUP SIGINT SIGTERM ERR EXIT

# Enable manual fan control
echo ${manual} > ${fan}_enable

function temperature() {
        nvidia-settings -q [gpu:0]/gpucoretemp -t

function fan_speed() {
        echo Setting FAN Speed to $1%
        echo $(((($1 * 255)) / 100)) > ${fan}

while true; do
        echo GPU Temperature: $temp

        if [ "$temp" -ge "$max" ] ; then
                fan_speed 100
                fan_speed $(($temp + ((100 - $max))))

        sleep 1

Then make the script sudoable without password and run on login. Now my fans run at 600rpm at idle and go up to 1100rpm when running a GPU burn in tool.

GitFlow hmmmm

After reading Atlassian worflow comparison and Vincent Driessen original post about GitFlow I have come to realise a couple of worrying things:

  • I incorrectly assumed GitFlow was the same thing as GitHub flow (fork project, do work then pull request)
  • This model appears to be popular but it seems totally archaic to me
    • Requires lots of merging especially if you refactor at lot.
    • Doesn’t do CD
    • Requires lots of manual work
    • Master and develop seem the wrong way around to me
    • How many branches?
  • I use pull requests but don’t use feature branches which the Atlassian article implies requires feature branches
  • Most places I’ve seen, feature branches do live on origin (unlike the original post)

GitHub flow is so nearly right except for the last two steps are the wrong way round (Deploy then Merge!):

Now that your changes have been verified in production, it is time to merge your code into the master branch.

This is my prefered workflow:

  • Master is always trunk or head where all new development happens
  • Every single check-in triggers a build (and tag with auto increment minor version) and is expected to be production code
    • If possible every build is automatically released but if not then a single click by an authorised user would make that release public
  • If old major versions are supported by team they are on branches (but the rest is the same, i.e every check is a release etc)
  • Hot fixes are just another commit to either master or the branch. i.e nothing special
  • Done means in production and you have monitored it with your own eyes! You don’t start new work until you have seen your old work live
  • If you are on the core team:
    • If you pair you can commit to master or branch directly
    • If you solo you should get code review or pull request
  • If you are not on core team you pull request from your fork

Is it just me that thinks GitFlow doesn’t look very “flow” based, more like a lot of manual busy work like the old days. Please report your counter experiences or alternate workflows…

Dan's technical ramblings