Recently posted on the FFmpeg Developers mailing list was a request for comment from Ronald Bultje regarding the intention to form an FFmpeg Foundation (although not using that name).
Several months ago we posted an article about the Magic Lantern firmware for the Canon 5D Mark II video DSLR. This open source software adds functionality to the 5D that Canon didn’t provide out of the box. There has been quite a lot of progress on Magic Lantern over the last few months. The latest release is version 0.1.6, but even since then further enhancements have been made, including Autoboot.
4. What plans do you have for the new 5d firmware update? Can we expect anything beyond 24p/25p?
You would have to ask Canon about their plans… I’ll update my code to work with their new firmware once it is available. It would really please me if Canon incorporated all of the features from Magic Lantern into their firmware.
On my roadmap for upcoming Magic Lantern releases:
* 1080i HDMI output (still having technical problems)
* SMPTE timecode jamming
* USB control from the Impero remote follow-focus
* Waveforms and vector scope
* Autoboot (now available)
5. On your Wikia Page you describe the Magic Lantern as ” an enhancement atop of Canon’s firmware that makes your 5D Mark II into the 5D Mark Free” What exactly do you mean?
Most equipment is “closed” in that what you buy is what you get. Sure, you can put it on rails, add a follow focus and mattebox, but you can’t really change what is going on inside the box. With Magic Lantern, however, the internals of the camera have been opened up so that it is possible to add new features that the manufacturer might not have ever imagined.
Read the full text of the interview over at Cinema5d.
A potentially useful enhancement to the Magic Lantern firmware would be the ability to change the codec used in the 5D Mark II. Currently, content is stored as H.264 at around 40Mbps. While this provides for some very nice high quality footage, it’d be nice if additional open source options were included, like Lagarith and Dirac Research. The Magic Lantern Wikia Discussion page has a few comments around this idea already.
in effect from November 1st 2009.
It’s been a long time now since I wrote my original How-To for building FFmpeg on Debian. A lot has changed since then, in both the Debian and FFmpeg world, so it’s definitely time for an update.
This tutorial describes how to build x264 and FFmpeg from scratch, on a base Debian Squeeze system. Throughout this tutorial I will be assuming that you are operating as either root or su, or aware of how to use sudo (make sure you’ve added yourself to the /etc/sudoers list).
First, we need to update the sources list. I use pico as my text editor, as I was a long time Pine mail user way back when. Feel free to use vi or emacs if you prefer.
Go to the Debian Multimedia repository site and download the keyring package. Follow the instructions for unpackaging it about half-way down the front page. Now update your sources list:
Add deb http://www.debian-multimedia.org squeeze main on a new line and save the file.
Now you’re using the latest sources and packages.
Next, install all the additional libraries we’ll need:
>aptitude install install build-essential subversion git-core yasm libgpac-dev libdirac-dev libgsm1-dev libschroedinger-dev libspeex-dev libvorbis-dev libopenjpeg-dev libdc1394-dev libsdl1.2-dev zlib1g-dev texi2html libfaac-dev libfaad-dev libmp3lame-dev libtheora-dev libxvidcore4-dev libopencore-amrnb-dev libopencore-amrwb-dev
Once that has successfully completed, it’s time to grab the latest x264 code:
>git clone git://git.videolan.org/x264.git
Hopefully all is still going well and you encountered no errors so far. Great, let’s grab FFmpeg from Subversion:
>svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
Now to configure FFmpeg. There’s so many options, it’s sometimes hard to know which ones to choose. The list below is my personal preference, but do try ./configure –help to assist in choosing your own.
>./configure –enable-gpl –enable-postproc –enable-pthreads –enable-libfaac –enable-libfaad –enable-libmp3lame –enable-libtheora –enable-libx264 –enable-shared –enable-nonfree –enable-libvorbis –enable-libgsm –enable-libspeex –enable-libschroedinger –enable-libdirac –enable-avfilter –enable-avfilter-lavf –enable-libdc1394 –enable-libopenjpeg –enable-libopencore-amrnb –enable-libopencore-amrwb –enable-version3
After a successful configuration, all the enabled decoders, encoders and muxers will be displayed. There are some configuration dependencies here. If you don’t –enable-gpl things like postproc will fail at build time. Next….
“Make” will probably take quite a long time.
Optionally you may like to build qt-faststart as well. If you don’t know what this does, use Google, but in short it arranges atoms in QuickTime header files to allow for progressive download delivery.
If you try to use FFmpeg now, by simply typing “ffmpeg” you are likely to encounter an error regarding shared libraries (we did build FFmpeg with –enable-shared). To fix this we do the following:
Add the line “/usr/local/lib” (without quotes) to this file and then save it. Read more about dynamically linked libraries here, specifically the fourth paragraph to explain what we just did.
That’s it! Finished. Pretty easy, right? Now you just need to learn how to use FFmpeg, but that’s a topic for another day. Very briefly though, here’s a command line for creating a 2-pass H264 file, at 750kbps and 480×360 resolution, in a mov container, with progressive download enabled.
>ffmpeg -y -i inputfile.mpg -pass 1 -vcodec libx264 -vpre fastfirstpass -s 480×360 -b 750k -bt 750k -threads 0 -f mov -an /dev/null && ffmpeg -deinterlace -y -i inputfile.mpg -pass 2 -acodec libfaac -ab 128k -ac 2 -vcodec libx264 -vpre hq -s 480×360 -b 750k -bt 750k -threads 0 -f mov outputfile.mov
>/tools/qt-faststart outputfile.mov outputfilefast.mov
Call me shallow, but in all seriousness the main reason I’ve not tried OpenShot video editor is that I can’t stand the glossy, glassy, bubbly look of their default colour scheme. Dislike KDE? Not that I necessarily do, but OpenShot’s theme was like KDE, but worse, much, much worse.
Just 3 months after the last release, Kdenlive is out with 0.7.6. They even had a pre-release message on their homepage for the last week or so.
The new features are:
- Title module: rewrite, now allows for basic animation (title zoom & scroll)
- Track rename: users can now rename tracks
- Composite transition: keyframes can now be moved
- Clip management: image and audio clips are automatically monitored and updated in the timeline whenever they change on disk
- User interface cleanup: cleaner look for timeline
- Capture monitor improvements: now shows available disk space & timecode, also allows to choose a name for captured files
- Project management: project settings dialog now allows you to clear the thumbnails cache and delete all videoclips that are not used in the project
- Improved clip markers: they are now displayed in the clip monitor ruler, and user can easily go to each marker from the context menu
- Shutdown computer after rendering
Finding a full featured open source video transcoding solution is no easy task. There is of course FFmpeg, which is fantastic and powerful, but one does need to spend a serious amount of time learning the syntax and various options. This is fine if you’re taking one type of input file and creating one type of output file. Easy to script and I’ve seen some really good results, especially using the x264 library. However, trying to find a nice GUI to do the same thing, so far no joy.
I had really hoped HandBrake might be the right tool for the job. It’s been around for a long time now, it’s not just for Mac anymore and there seems to be an active community around it.
The last stable release was almost 10 months ago, but recently an SVN snapshot build was supplied, with some pre-compiled packages to go with it. The usual caveats apply, but the change log provided some tantalising updates, so I decided to try it out.
My home laptop is running Debian Squeeze, but I decided to try the Ubuntu 9.04 GUI package, as I was lazy and didn’t feel like compiling from source. Maybe this was a mistake….. The installation of the deb package went fine. No errors to speak of and a nice little HandBrake icon appeared in my Sound & Video menu. Starting the application also worked flawlessly.
I hadn’t used HandBrake before, so I didn’t know what to expect. On first glance the software appears to be mainly geared towards H.264 transcoding. While this is currently an important video codec, I was hoping for a much wider range of output options. I couldn’t find any.
Fine, let’s stick with H.264. My source file for testing was 4.2GB of DNxHD – a little over 3 minutes of content at 185Mbps. HandBrake uses FFmpeg in the backend to do the transcode heavy lifting. I know FFmpeg supports DNxHD, so I was not expecting any real problems. Unfortunately, my assumption proved to be incorrect.
Selecting the DNxHD file as source, HandBrake scanned the file for a couple of minutes, then stopped. No error message, no warning, just the UI sitting there waiting for the next input. Fortunately, there’s an Activity Window to select and view the command line output. Here’s what I saw…..
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘/home/phillc/Media/South Pacific Avid DNxHD.mov':
Duration: 00:03:11.12, start: 0.000000, bitrate: 189668 kb/s
Stream #0.0(eng): Video: dnxhd, 1920×1080, PAR 1:1 DAR 16:9, 25 tbr, 25 tbn, 25 tbc
Stream #0.1(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.2(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.3(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.4(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.5(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.6(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.7(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
Stream #0.8(eng): Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
[10:14:27] scan: decoding previews for title 1
[10:14:45] scan: could not get a decoded picture
[10:14:58] scan: could not get a decoded picture
[10:15:12] scan: could not get a decoded picture
[10:15:26] scan: could not get a decoded picture
[10:15:40] scan: could not get a decoded picture
[10:15:54] scan: could not get a decoded picture
[10:16:08] scan: could not get a decoded picture
[10:16:23] scan: could not get a decoded picture
[10:16:35] scan: could not get a decoded picture
[10:16:49] scan: could not get a decoded picture
[10:16:49] libhb: scan thread found 0 valid title(s)
What’s it all mean?
It would seem that FFmpeg recognised a valid DNxHD file. It found the video track and 8 tracks of audio, but after this, who knows! Not being able to get a decoded picture is not an error I’ve come across using FFmpeg from the command line before.
EDIT: The root of this problem is actually FFmpeg and not Handbrake. The DNxHD file was 10-bit, but FFmpeg currently only supports 8-bit files of this codec.
That’s as far as I’ve managed to travel in the HandBrake world. I had a look at some of the H.264 file output options, which are comprehensive, but don’t at first glance seem to support the general x264 preset options. HandBrake presets are more geared towards devices – iPod and Apple TV. It appears to be possible to queue multiple jobs using HandBrake, but not set watch folders nor apply rules for output files. E.g Once transcoding is finished, move file to folder X.
HandBrake is probably a good tool for those looking to create web media, from DVD or Camcorder source, but it’s not powerful enough to deal with high end media from the post-production or broadcast domain.