As we were on holiday last week, in the chilly snows of Austria, we almost missed an important announcement regarding the Schrödinger implementation of the Dirac codec.
From the Kdenlive Release Notes page: Kdenlive 0.7.7 was released on the 17th of february 2010. This release fixes a lot of bugs reported against Kdenlive 0.7.6, including timeline corruption and various crashes. We also fixed a compatibility issue with Qt 4.6. We hope that this new release will make the video editing experience easier and more comfortable for everyone! Kdenlive requires the latest release of the MLT video framework (0.5.0) A complete list of the fixed issues can be found on our bugtracker.
Some of the new features
From the Kdenlive Release Notes page:
Kdenlive 0.7.7 was released on the 17th of february 2010.
This release fixes a lot of bugs reported against Kdenlive 0.7.6, including timeline corruption and various crashes. We also fixed a compatibility issue with Qt 4.6. We hope that this new release will make the video editing experience easier and more comfortable for everyone!
Kdenlive requires the latest release of the MLT video framework (0.5.0)
A complete list of the fixed issues can be found on our bugtracker.
Just days after I first wrote about FFmbc (FFMedia Broadcast) the team have released a new version, marked as 0.3.
- Sync on FFmpeg svn r20539.
- Write Quicktime timecode track.
- Set closed gop flag for first gop when encoding with b frames.
- Search relative path when opening Quicktime reference files.
FFmbc (FFMedia Broadcast) is an off-shoot of the FFmpeg project that is targeted squarely at the broadcast media world. The project while still in its infancy, but available for around 6 months already, is currently at release version 0.2. Launched and managed by Baptiste Coudurier, well known for his work on the FFmpeg project, FFmbc rolls out the following enhancements:
• Creating XDCAM HD422 files in .mov or .mxf
• Creating XDCAM IMX/D-10 files in .mov or .mxf
• Creating AVID DNxHD files in .mov
• ID3v2 complete support.
• Itunes complete support.
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).
As storage space becomes cheaper, there’s a growing trend to save digital music files in a lossless format. Such lossless formats provide an exact replication of the audio quality found in the original content, usually on CD. The resulting files are also much larger, when compared to MP3 or AAC at 128kbps or 256kpbs. A favourite open source lossless audio codec is FLAC, which stands for Free Lossless Audio Codec. Within the possible FLAC settings there are 8 levels of compression to choose from when creating new files.
Lossless codec? Compression? Doesn’t compression result in loss of detail? Not always. There are many lossy codecs, both audio and video, that apply various compression techniques that actually discard some of the original material, to obtain smaller file sizes. The better the codec is at discarding items that don’t impare the listening or viewing experience, the more impressive the end result will be.
FLAC, being lossless, doesn’t discard any of the original content, but still applies compression techniques. View this like compressing a file with Gzip or Bzip perhaps. Smaller files are achieved, but when de-compressed nothing has been lost in the process. Perhaps think of it like folding a piece of paper. Fold it in half once, and the end result is smaller. Keep folding to produce smaller and smaller (or more highly compressed) paper packages. Unfold the paper, and you still have the same original piece of paper. Ignore fold lines and degradation over time! This doesn’t happen in the world of bits and bytes.
We decided to test which of the FLAC compression settings provided the best trade-off between final file size and encoding time. Higher compression will require more time, but should produce smaller file sizes.
Trying to mimic how we would actually go about ripping a whole CD, we decided to use the Ripit utility, and follow instructions posted on the Debian forum. Ripit is a great example of a truly useful utility where a fancy GUI is just not needed. Edit one simple configuration file, then type “ripit” at the command prompt and that’s almost all there is to it. There would be some overhead in using Ripit, as it checks the freedb.org database for each album’s details, but this should be minimal.
Grabbing the nearest un-ripped CD from the shelf, our test file will be U2′s Pride (In the Name of Love) from their Best of 1980-1990 album. This song is 3 minutes and 50 seconds long.
Our exact Ripit command was:
>time ripit 01
“Time” provides feedback on the elapsed time of the process. “01″ tells Ripit to just rip the first track on the CD.
The test machine is a reasonably old Dell Inspiron 6400, which contains a Intel Core2 CPU T5500 @ 1.66GHz and 1GB of RAM.
Here are our results from the 8 different levels of compression
available in FLAC. If no compression level is specified, 5 will always
be the default.
Comression Quality: 0
Size: 30261367 bytes (28.86MB)
Compression Quality: 1
Size: 29643288 bytes (28.27MB)
Compression Quality: 2
Size: 29631732 bytes (28.26MB)
compression Quality: 3
Size: 28596473 bytes (27.27MB)
Compression Quality: 4
Size: 27717767 bytes (26.43MB)
Compression Quality: 5
Size: 27710285 bytes (26.43MB)
Comression Quality: 6
Size: 27710119 bytes (26.43MB)
Compression Quality: 7
Size: 27696835 bytes (26.41MB)
Compression Quality: 8
Size: 27664197 bytes (26.38MB)
Between Compression Quality 0 and Compression Quality 8, there’s approximately 13.5 second and 2.5MB difference. This might not seem like very much, but let’s expand these figures to account for an entire CD.
Assuming all tracks are approximately the same length (3:50) and that there are 12 tracks on the average CD, we have the following figures:
13.5 seconds x 12 = 162 seconds (2 minutes 42 seconds)
2.5MB x 12 = 30MB.
Realistically though, you can see there’s a big jump in time between Compression Quality 6 and Compression Quality 7, while there’s not a lot of difference in time between Compression Quality 5 and Compression Quality 0 (Ignoring Compression Quality 3′s time anomaly which we can’t account for). There’s also not a lot of file size difference between Compression Quality 5 and Compression Quality 8.
Therefore, unless storage space is a really big issue, the average user is probably better off leaving the Compression Quality settings at Default (5) and saving almost 3 minutes for CD rip. Then again, on a newer machine, this time difference is likely to be much less, so you may as well use Compression Quality 8 and save that little bit of space.
In the end, Compression Quality settings in FLAC don’t make that much difference. Leaving the settings at Default is a pretty good choice, but setting them to a maximum of 8 will save some space, without a major time impact.
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.
Stream #0 has now made available our first Amazon Web Services (AWS) AMI. This is based on Eric Hammond’s 64-bit Squeeze AMI: ami-fcf61595.
The first Stream #0 AMI can be found by looking for the following AMI ID in the AWS Management Console: ami-b535d6dc
The following additions have been made over the base Squeeze build:
- Added Debian Multimedia Repository
- Updated and Upgraded to October 22nd 2009 latest packages
- Build x264 from source. r1301
- Build FFmpeg from source. r20350
FFmpeg has been configured as per the options noted in the How-To here
Ultimately we’re planning to build a few different AMI variations. e.g. Lenny with FFmpeg 0.5 build and x264 from Debian Multimedia Repo as a slightly more stable version of the “Squeeze build everything from source” AMI approach.
The AMI has been made public and Stream0 would really appreciate feedback on this, our first time AMI build.
Everything you need to know about Amazon’s Web Services:
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