Results tagged “FFmpeg” from Stream #0

A little over one month since the release candidate was made available, FFMBC has officially rolled our version 0.4. Lots of useful and interesting updates for our favourite open source video transcoding tool:

As could probably be predicted, there's been a lot more press around WebM over the last ten days or so. A few articles are worth noting.

In August 2009, Google acquired codec developer On2 Technologies for a rumoured $106 million. The flagship On2 codec was VP8 and it was also rumoured at the time that Google may open source this technology in the future, although a number of challenges lay ahead.

Just days after I first wrote about FFmbc (FFMedia Broadcast) the team have released a new version, marked as 0.3.

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

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:

Amazon Web Services
AWS Elastic Compute Cloud (EC2)
AWS Developer Guide
Alestic - listing Debian and Ubuntu AMIs
ec2debian Google Group

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:

>pico /etc/apt/sources.list

Add deb http://www.debian-multimedia.org squeeze main on a new line and save the file.

>aptitude update
>aptitude full-upgrade

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
>cd x264
>./configure --enable-shared
>make
>make install

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
>cd 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
>make install

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

>make tools/qt-faststart

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:

>pico /etc/ls.so.conf

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.

>ldconfig

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 480x360 resolution, in a mov container, with progressive download enabled.

>ffmpeg -y -i inputfile.mpg -pass 1 -vcodec libx264 -vpre fastfirstpass -s 480x360 -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 480x360 -b 750k -bt 750k -threads 0 -f mov outputfile.mov

>/tools/qt-faststart outputfile.mov outputfilefast.mov

Finally, something actually useful on this blog......

In an interesting, and to be applauded, move from the BBC, they are now releasing a technology based television programme under a Creative Commons non-commercial attribution licence. R&DTV's first episode is now available for free download in a number of file formats. There is a full 30 minute version available, a shorter 5 minute highlight version, as well as a complete Asset Bundle, which includes rushes that may not have made it into the final programme versions.

The BBC's RAD blog has a launch announcement about this, followed up by another post 24 hours later outlining some small fixes.

The programme is PAL 720x576. The aspect appears to be 14:9 anamorphic. The little person inside me who wants the greatest and the best all the time, wonders why the filming wasn't done in HD, even HDV would do.

I thought the "formats" described on the R&DTV website were a bit vague. What does QuickTime format and Matroska format really mean? Sure, I know about QuickTime and Matroska containers, but this doesn't say anything about the video and audio essence contained therein. The best way to find out about this is to download each video and let FFmpeg take a look.

QuickTime Format (461.3MB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'RDTV_ep1_5mins.mov':
Duration: 00:05:59.08, start: 0.000000, bitrate: 10777 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: h264, yuv420p, 720x576, 25 tbr, 25 tbn, 50 tbc

That's H.264 video with PCM audio. Strange they didn't use AAC audio in a QuickTime file. Looking at that 10Mbps bitrate though, I'm guessing perhaps the BBC is expecting people to use this version for editing. But then why use H.264, rather than something that's I-Frame only like IMX50? There's also an Uncompressed version and another QuickTime version, which we'll come to later.
 
Matroska Format (28.4MB):

Input #0, matroska, from 'RDTV_ep1_5mins.mkv':
Duration: 00:05:59.04, start: 0.000000, bitrate: N/A
Stream #0.0(eng): Video: mpeg4, yuv420p, 720x576 [PAR 1:1 DAR 5:4], 25 tbr, 1k tbn, 25 tbc
Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16

Generic mpeg4 video this time (Xvid perhaps) and here's our AAC audio!

MP4 Format (65.4MB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'RDTV_ep1_5mins.mp4':
Duration: 00:05:59.10, start: 0.000000, bitrate: 1526 kb/s
Stream #0.0(eng): Video: h264, yuv420p, 720x576 [PAR 1:1 DAR 5:4], 25 tbr, 48k tbn, 50 tbc
Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16

H.264 video again and AAC audio again. When opening this file with Totem to view, the Comments section says "HandBrake 0.9.3 2008121800". Nice to know the BBC is using Open Source software for at least some of their video transcoding.

AVI Format (63MB):

Input #0, avi, from 'RDTV_ep1_5mins.avi':
Duration: 00:05:59.04, start: 0.000000, bitrate: 1470 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720x576 [PAR 1:1 DAR 5:4], 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 160 kb/s

Generic mpeg4 video again, but this time with mp3 audio.

FLV Format (37.4MB)

Input #0, flv, from 'RDTV_ep1_5mins.flv':
Duration: 00:05:59.07, start: 0.000000, bitrate: 844 kb/s
Stream #0.0: Video: vp6f, yuv420p, 1024x576, 716 kb/s, 25 tbr, 1k tbn, 1k tbc
Stream #0.1: Audio: mp3, 44100 Hz, stereo, s16, 128 kb/s

VP6 for the video codec and mp3 for the audio. No surprises there then. The bitrate is quite low though for VP6 content, quality will suffer.

Ogg Format:

Input #0, ogg, from 'RDTV_ep1_5mins.ogg':
Duration: 00:05:59.08, start: 0.000000, bitrate: 683 kb/s
Stream #0.0: Video: theora, yuv420p, 720x576, PAR 1:1 DAR 5:4, 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: vorbis, 48000 Hz, 5.1, s16, 516 kb/s

Theora for the video and vorbis for the audio, again no surprises there. 5.1 audio is a nice touch though. However, again, the bitrate is very low. Why would the BBC do this? The MP4 version, with H.264 video at a higher bitrate, is going to look far superior.

QuickTime 2 Format (155MB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'RDTV_ep1_5mins_2.mov':
Duration: 00:05:59.08, start: 0.000000, bitrate: 3627 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: h264, yuv420p, 720x576, 25 tbr, 25 tbn, 50 tbc

H.264 video and PCM audio. This second QuickTime file is found only on the FTP site and not linked to directly from the main page. The bitrate is much lower than the previous QuickTime file.

QuickTime Uncompressed Format (7GB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'RDTV_ep1_5mins_uncompressed.mov':
Duration: 00:05:59.08, start: 0.000000, bitrate: 167428 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: rawvideo, uyvy422, 720x576, 25 tbr, 25 tbn, 25 tbc

There we go, raw video in the 4:2:2 colour space at 165Mbps, with PCM audio again. I wonder whether the content was filmed at anywhere near this resolution. Given that the programme is only SD, I'm guessing that the highest quality recording would have been done direct to Digital Betacam, which is only the equivalent of 90Mbps, unless of course the whole thing was done tapeless, which I must admit to doubting.

One last puzzlement is why a Dirac version wasn't supplied, given that this is the BBC's own R&D developed codec.
 

Two posts in two days after such a long silence, who'd have thought it...... And again it's about FFmpeg.

This time Phoronix has posted an interesting interview summary with Diego Biurrun, Baptiste Coudurier, and Robert Swain, three of the many, but very key, developers working on the FFmpeg project. The interview covers some interesting topics about the future of FFmpeg, the difficulties of maintaining such a large project, managing developer motivation for writing codecs and the limited corporate sponsorship the project has so far received.

I've known Baptiste for a year or so, having met at the National Association of Broadcasters (NAB) convention in Las Vegas in April 2008. I'd like to personally thank him for the work he has done on implementing DNxHD in FFmpeg.

Anyway, read the interview and learn something about behind the scenes at FFmpeg.

Also worth a read, which I just found today, is the Phoronix tests on NVIDIAs VDPAU drivers on a cheap chipset and graphics card.

It's been a long while since I've posted on this blog, but finally today something has spurned me into action. 

Recently, and it's hard to say exactly which SVN snapshot this occured in, the FFMpeg project changed the location of a number of its header files. This has caused soem havoc with other applications that use FFmpeg for video decoding or encoding.

Amongst other things, Open Movie Editor complained that certain libraries were not installed, which they plainly were. This could be seen from running a simple "ffmpeg -i" command to see what which libraries FFmpeg had been configured again.

Trying to re-compile Open Movie Editor from source struck some problems, in that OME was looking for FFmpeg headers in the wrong place. To overcome this issue, so that OME would compile and then install correctly, I made the following changes.

The first crash will be with regards to avformat.h in the file nle_main.cxx

nle_main.cxx and the other two files you need to make some small edits to can be found in the "src" directory created when OME is unpacked.

There are three files you'll need to edit in the text editor of your choice:

nle_main.cxx
VideoFileFfmpeg.H
AudioFileFfmepg.H

Open each of those files and near the beginning (around line 35) will be references that look something like this:

#include <ffmpeg/avformat.h>

You'll need to find where avformat.h, avcodec.h and swscale.h are residing on your machine.

You can do this by using the following command:

>sudo find / avformat.h

On my machine, a build of Debian Lenny, these files can all be found in /usr/local/include

I edited the files so the code looks like this (example from VideoFileFfmpeg.H):

#include </usr/local/include/libavcodec/avcodec.h>
#include </usr/local/include/libavformat/avformat.h>
#ifdef SWSCALE
    #include </usr/local/include/libswscale/swscale.h>

Once you've saved those files, OME should now be able to find the FFmpeg header files and build correctly.

Hopefully a new version of Open Movie Editor will soon be available where these issues have been rectified in the source.

Having recently installed Xubuntu Hardy Heron on a laptop, I also needed to install FFmpeg. This post is really just a couple of notes for myself, updating my earlier How-To post regarding installation of FFmpeg on Ubuntu Gutsy.

New apt-get install line:

sudo apt-get install liblame-dev libfaad2-dev libfaac-dev libxvidcore4-dev liba52-0.7.4 liba52-0.7.4-dev libx264-dev libdts-dev libswscale-dev checkinstall build-essential subversion

Here I've added the swscale development libraries. Swscale is used for scaling videos.

If you are ever stuck behind a firewall or proxy, especially one that you have no control over and which does not understand certain SVN commands, there is a nightly Subversion snapshot available for download from the FFmpeg website. This alleviates the need to checkout the source with SVN.

New configure line:

./configure --enable-gpl --enable-libvorbis --enable-libtheora --enable-liba52 --enable-libdc1394 --enable-libgsm --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-libxvid --enable-pthreads --enable-libx264 --enable-shared --enable-swscale --enable-avfilter --enable-postproc --enable-avfilter-lavf

Here I've removed --enable-pp as it is no longer recognised. And I've added --enable-swscale, --enable-avfilter, --enable-avfilter-lavf and --enable-postproc

Avfilter is the new FFmpeg library that replaces the deprecated vhook functionality.

One last note to self is to investigate the possibilities of AVIsynth scripting and FFmpeg.

A short while ago I wrote a review about Open Movie Editor. Essentially this review was written after a couple of hours testing various video clips and assessing the functionality within OME. Now, I can write about what OME is like on a real editing assignment.

Recently I was given a DVD full of PAL DV material and asked to create a compilation from the individual clips. A fun little project that should only take a day or two. Open Movie Editor was the obvious tool for the job.

The good news I can report is that even after 10 to 12 hours of constant video editing, OME is still a very stable piece of software. I only managed to induce two crashes - once when trying to undo multiple edits in a row and once when vigorously moving clips around on the timeline. Other than that, Open Movie Editor was easily up to the task.

I'm not an advanced video editor, happy within my comfort zone using something like Adobe Premiere, but also not using all the intricate features. However, Open Movie Editor does still lack a few basic features, that would have greatly increased my productivity. Changing playback speed of a clip is not possible within OME. I needed to change the framerate of target clips using FFmpeg and mjpeg tools to achieve this effect. While fade transitions are easy enough, I'm sure they could have been even quicker if such a function was built into OME. Precise frame editing, for splitting clips for example, would also make life easier.

There are some really nice features in Open Movie Editor though. Audio automations are a breeze, the media browser window provides easy access to your video library and the list of render options is quite vast - dependent on FFMpeg, Libquicktime and other shared video libraries.

So what did I produce in my 12 hours of work? A fun 4 minute clip, which is still a little rough around the edges, but generally a good laugh. Here's a link for your viewing pleasure:

http://kapitalmototv.co.uk/play-183-0.html

Edited in Open Movie Editor, with some clip transformations using FFmpeg and mjpeg tools. Follow this with final transcoding to x264, again with FFmpeg for more finite control, and you have an Open Source Editing project.

The Kapital Moto TV site uses open source products where possible. The server runs on Debian Etch, the site is served with Apache, built largely with PHP and data is stored in a MySQL database. Content is a mix of QuickTime generated H.264 and FFmpeg generate x264 video files. The Flash player is not open source, but is free as in beer.

Unfortunately my Linux based non-linear editing tool of choice, Open Movie Editor, doesn't currently support directly altering video playback speed. For example, if you wanted a portion of your new compilation to run at 200% of original recorded speed, it can't be done within OME. This exact functionality was something I needed for an existing editing project.

After some thought and investigation, such changes can be achieved through using a combination of FFmpeg and yuvfps, which is part of mjpeg tools, to alter the framerate of the desired footage. If your original file is PAL based, with a framerate of 25fps, changing the framerate to 50fps will result in the video running twice as fast, for half as long.

I didn't initially have mjpegtools installed, but on my Debian based system this was easy enough with

sudo apt-get install mjpegtools

Next, the input video needs to be converted to yuv4mpegpipe format, passed through yuvfps and output to a new avi file. Here's the command line I used to create a clip at 50fps:

ffmpeg -i input.dv -f yuv4mpegpipe - | yuvfps -s 50:1
-r 50:1  | ffmpeg -f yuv4mpegpipe -i - -b 28800k -y output.avi

Change the 50:1 ratios to whatever framerate you require. e.g. 100:1 for 100fps. Be sure to set the output file bitrate to a relevant quality level. Omitting this flag will result in a poor quality AVI output file by default.

The resulting AVI file was easily played back with Totem, and handled on the timeline admirably by OME.

Thanks to Victor Paesa on the FFmpeg mailing list for pointing me in the right direction.

Some other options to investigate include the new Libavfilter for FFmpeg and converting the original footage to a raw data file, which will lost the audio.

Extracting all frames from a video file is easily achieved with FFmpeg.

Here's a simple command line that will create 25 PNG images from every second of footage in the input DV file. The images will be saved in the current directory.

ffmpeg -i input.dv -r 25 -f image2 images%05d.png

The newly created files will all start with the word "images" and be numbered consecutively, including five pre-appended zeros. e.g. images000001.png.

From a video that was 104 seconds long, for a random example, this command would create 2600 PNG files! Quite messy in the current directory, so instead use this command to save the files in a sub-directory called extracted_images:

ffmpeg -i input.dv -r 25 -f image2 extracted_images/images%05d.png

Moving on, let's say you just wanted 25 frames from the first 1 second, then this line will work:

ffmpeg -i input.dv -r 25 -t 00:00:01 -f image2 images%05d.png

The -t flag in FFmpeg specifies the length of time to transcode. This can either be in whole seconds or hh:mm:ss format.

Making things a little more complex we can create images from all frames, beginning at the tenth second, and continuing for 5 seconds, with this line:

ffmpeg -i input.dv -r 25 -ss 00:00:10 -t 00:00:05 -f image2 images%05d.png

The -ss flag is used to denote start position, again in whole seconds or hh:mm:ss format.

Maybe extracting an image from every single frame in a video, resulting in a large number of output files, is not what you need. Here's how to create a single indicative poster frame, of the video clip, from the first second of footage:

ffmpeg -i input.dv -r 1  -t 00:00:01 -f image2 images%05d.png

Notice that the -r flag is now set to 1.

If you want the poster frame from a different part of the clip, then specify which second to take it from using the -ss tag, in conjunction with the line above.

Lastly, if you wanted to create a thumbnail story board, showing action throughout the entire length of the video clip, you'll need to specify the output image dimensions. Use the following line:

ffmpeg -i input.dv -r 1 -f image2 -s 120x96 images%05d.png

My original file was 720x576, so the image dimensions are a whole division of this.

After my previous overview of Open Movie Editor (OME), I decided to create a small How-To regarding an easily obtainable piece of functionality that's not yet standard within OME.

Open Movie Editor natively contains only one transition between clips - a simple cross fade. However, one of the most used transitions in video editing is a fade to black. By adding a black still image, between two clips on a single video track in OME, it is possible to generate exactly what you need.

Here's how by following the steps below:

1. Open your favourite image editor, in this example we've used the GIMP.
2. Create a new image with a solid black background, at the same size as your video clips. We've used PAL 720x576.
3. Save the image as a PNG, although JPG will also work.
4. Switch to Open Movie Editor and navigate to your footage in the Media Browser window. We've previously downloaded two QuickTime clips from stock footage supplier BBC Motion Gallery, to use in this example.
5. Add the first clip to video track one.
6. Add the black still image to the same video track.
7. Add the second video clip to the same video track.
8. Now, overlap the beginning of the black still image with the end of the first clip. A blue area with a red cross through it should appear - this is the length of time that the fade will occur.
9. Adjust the length of the black still image to suit the speed of the fade to black required.
10. Now, drag the beginning of the second video clip over the end of the still image, so that another blue box and red cross appears.
11. Move the timeline marker before the first blue box and test your fade out to and in from black.

Easy! Move the clips, and adjust the length of the black still image until you are happy with the fade.

To make is even easier, we've created a screen cast for you to watch, complete with a couple of extra fades created in OME. Don't adjust your volume, there is no sound.

Get Flash Player 9 to see this movie.

This screen cast was created with RecordMyDesktop, edited with Open Movie Editor, and transcoded into an x264 file, using a custom Perl script to control FFmpeg.

Despite some commentators deploring the state of Linux video editing tools, I continue to believe that somewhere out there is a non-linear editing program that is feature rich, intuitive and stable for the Linux platform. Maybe I'm deluded, but I would settle for a nice tool in its current state, that has an active community, a development road map and doesn't crash all the time!

Yesterday, I decided to give Open Movie Editor a chance. I thought this project was largely dead, but a new release was made on January 2nd 2008, so it looks to be still very much alive. I was also somewhat put off by the screenshots on the website. The GUI looks poor and clunky. After installation I am pleased to say that this isn't entirely the case.

Unfortunately, the packages in the Ubuntu repository are only for older versions. Installing Open Movie Editor (OME) from source was reasonably straight forward, but there are some tips and tricks worth following. To maximise the number of video formats that OME can decode, be sure to have a reasonably new version of FFmpeg installed. For rendering (encoding) output, OME uses Libquicktime. I already had FFmpeg installed, with a lot of extra libraries to cater for x264 and FAAC encoding, amongst others. I also decided to install Libquicktime from source, rather than the Ubuntu package, as configuring with --enable-shared will pickup additional libraries, like libmp3lame, libx264 and libfaac if they're present.

Configuring OME also meant adding some new libraries to the default Ubuntu set, these included Gmerlin, libsndfile and the Alsa dev libraries. I sourced all of these from Ubuntu's repositories and installed through Synaptic. Building OME went smoothly, although it should be noted that at the end of the process, there will not be a nice icon in the application menus. OME needs to be launched from the command line, which is actually quite handy for viewing error messages.

Once up and running, I was surprised by the GUI. It's not nearly as bad as I feared from the screenshots, although there is still plenty of room for improvement. There are also two other skins to choose from, but unfortunately these and any other layout changes made are not remembered by OME between sessions, meaning everything needs to be setup again at startup.

My aim with OME was to perform some simple editing tasks and here's what I found:

• Adding clips to a project is very simple, just navigate to the folder on your local hard drive where the clip is stored, then drag it to the timline. There's no time consuming re-factoring of clips when adding them to a new project.
• OME supports a wide range of formats. I threw MPEG2 (m2t and vob), MOV (MJPEG and x264) and AVI (xVid and x264) files at it. They were all handled correctly. Although, it should be noted that the range of formats is dictated by your FFmpeg setup.
• Adding new video and audio tracks is easy and straightforward
• Splitting clips is possible using mouse clicks, but could be better with keystrokes for more accuracy.  Splitting should be performed at the exact current frame of the marker position.
• Merging two clips together on the timeline creates a nice video crossfade, but this is the only transition available by default. To create a fade out to black, and in for the next clip, a black image must be added to the timeline between existing clips. The two existing clips then crossfade to the black image. The length of the fade is determined by the amount of clip overlap and the length of the black "image". A little clunky, but it works well.
• If a video clip has original audio, this can either be entirely muted, or the volume adjusted using the "Automator" tool.
• If you just want to edit the audio of an existing video, drag and drop the file to an audio track on the timeline, rather than a video track.
• Various effects are supported by the Frei0r video plugins. I have installed them, but not really used them, although there appears to be a wide range available.
  
• There is currently no video preview available, unless the clip is already on the timeline. This means that viewing clips not already on the timeline, needs to be done outside of OME. This is a productivity loss.
• Arbitrary clip padding, cropping and rotation is not available.
• HD support currently not available.
  
• It is not possible to move along the timeline one frame at a time with keystrokes. This can only be achieved by dragging the timeline marker with a mouse, which is not very accurate.
• Rendering a project is straightforward with many options to choose from. This is a major strength of OME. Render options, as mentioned before, are handled through Libquicktime and so far I have no complaints.

However, the one biggest positive of OME for me is stability. I have had only two segfault crashes so far, and this was when zooming in and out, or moving left/right on the timeline very quickly. Other Linux NLEs I have tried - say KDEnlive or PiTiVi - crash very regularly. It is a real plus that OME is so stable.

I've also had some interesting conversations with OME's lead (and currently only) developer Richard Spindler. He's been very helpful and patient with my inquiries. When asked about a future roadmap for OME, Richard said that it revolved around the following two points:

• Improve the User-Interface and Editing-Feature-Set to cover most of the Basic Use Cases that an Amateur/Indie Movie Artist and Home Video Producer needs. This includes basic Compositing. 
• Improve the Technical Backends, to RELIABLE deal with "legacy" Video Technology that is available to the general public. Compatibility to Camcorders, Video-Files and Formats, DVD-Players, etc. There remains a lot of stuff to do in that Field, for Open Movie Editor, as well as for the Linux and the Open Source/Free Software Community as a whole.

When asked if there was a desire for OME to become a Professional level video editing tool, or always aim at the Amateur/Indie/Home User, Richard felt that, "The Lines between Professional/Amateur are blurring, you can do quite amazing stuff with "cheap" HDV Camcorders today.

With Open Movie Editor I will try to do both, provide a level of quality in Image Processing and Format support that is good enough for the "Professional", while keeping the Interface User friendly enough for Newbie users. Of course, I am not yet finished with those requirements.

As for the Interface: Ideally, the default will be simple and plain, but the more complex tools would live in Plugins and Extensions. So the Goal is definitly having both: iMovie and Final Cut Pro in one  Application. I think it is possible, the question is only how long it will take."

I was surprised by the stability of Open Movie Editor. The interface is easy enough to use, although still with plenty of room for improvement. The addition of some extra productivity features and shortcuts will really enhance the power of Open Movie Editor. Give it a try, you might just be surprised.

A request on the Ubuntu forums asked for some assistance creating x264 files from footage originating on DVD. The following FFmpeg command represents input from a couple of users regarding what might be the best options:

ffmpeg -y -i input_file -an -v 1 -threads auto -vcodec libx264 -deinterlace -b 5000k -bt 175k -flags +loop -coder ac -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me epzs -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 3 -b_strategy 1 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 5000k -bufsize 2M -cmp 1 -s 720x480 -f mp4 -pass 1 /dev/null

ffmpeg -y -i input_file -v 1 -threads auto -vcodec libx264 -deinterlace -b 5000k -bt 175k -flags +loop -coder ac -refs 5 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 6 -me_range 21 -chroma 1 -slice 2 -bf 3 -b_strategy 1 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 5000k -bufsize 2M -cmp 1 -s 720x480 -acodec libfaac -ab 256k -ar 48000 -ac 2 -f mp4 -pass 2 new_file.mp4

This command, as an overview does the following:

• Uses libx264 as the output video codec
• Uses libfaac as the output audio codec
• Deinterlaces the original DVD sourced footage
• Allows FFmpeg to choose the number of threads to use for multi-core systems
• Sets the output video bitrate at 5000kbps (or roughly 5Mbps)
• Sets the output audio bitrate at 256kbps
  
• Deblocks the output footage
• Uses CABAC encoding
• Uses .mp4 as the output file container
• Uses B-Frames
• Uses 2 pass encoding - directing the first output to /dev/null and the second pass to a new file

There are of course many other options included in this command. Further useful reading can be found on the FFmpeg documentation page:

http://ffmpeg.mplayerhq.hu/ffmpeg-doc.html

Also, this Mencoder specific page has some useful information regarding encoding using x264:

http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html

Recently I took the time to run a quick comparison test using FFmpeg for producing content with the x264 and xVid codecs. x264 produces H.264 content, while xVid encodes in MPEG4. I was a little surprised with the results.

The input file was sourced from BBC Motion Gallery. It was an MPEG2 Program Stream with I-Frames, encoded at approximately 50Mbps. It also contained a single MP2 audio track at approximately 356kbps. To see the clip on BBC Motion Gallery, click here. The clip was chosen because it is only 2 seconds long, so I could transcode it quickly, and there is also lots of movement, so I expected artifacts.

The output file container is QuickTime MOV, the video bitrate around 2Mbps, the audio codec aac (through libfaac) at 128kbps. I performed a 1 pass and 2 pass encode with x264 and xVid. The output file was to be 720x404 in size, this is 16:9 aspect ratio. All files were played back on a Windows XP machine using QuickTime Player 7.1.3. Some cropping of the original MPEG2 was required to remove VITC at the top and some black padding left and right. An example FFmpeg command line I used is outlined below. As you can see, there are very few optimisations other than the base settings.

FFMPEG command for the second pass x264 encode:

ffmpeg -i 2573-9.mpg -vcodec libx264 -f mov -b 2000k -acodec libfaac -ab 128k -s 736x442 -croptop 34 -cropbottom 4 -cropleft 8 -cropright 8 -deinterlace -pass 2 2573-9_h264.mov

The final output file sizes are as follows:

• x264 1 pass: 599.558 kilobytes
• x264 2 pass: 553.767 kilobytes
• xVid 1 pass: 577.232 kilobytes
• xVid 2 pass: 559.947 kilobytes

So, while xVid one pass produced smaller file sizes than x264 one pass, the x264 2 pass file is smaller than the xVid 2 pass file. Due to the short duration of the input file, no comparison of encoder speed could really be made. However, anecdotally from other ad hoc encoding jobs, xVid does seem to be quicker.

Now, to the real proof of the pudding, what was the quality like. Have a look at the following image file, click the thumbnail for a larger version:

This is where I was surprised. The x264 files are on the left. 1 pass is bottom left. 2 pass is top left. The xVid files are on the right. 1 pass bottom right. 2 pass top right. Clearly, the 1 pass xVid file is superior to the 1 pass x264 file. I also believe that the 2 pass xVid file is slightly better quality then the 2 pass x264 file. Areas for close inspection (we're looking at the two top files here):

• Bottom right corner. There is more blocking and artifacts on the x264 file.
• Top right wing tip. The xVid file has better definition here.
• The underside of the wings and tail. Again the xVid file has better definition.
• The background fire. I think the xVid file has less artifacts and better definition in general.
• As there aren't a lot of colours in the example video, it's hard to say which codec handles colour better, but there is obviously more depth in each of the 2 pass samples, compared to the 1 pass output.

I was surprised that to my eye the xVid content appeared to be superior to the x264 output. Perhaps with a more complext FFmpeg command and options this would have changed.

Using FFMpeg it is relatively simple to query an existing video file to find details such as video codec, audio codec, bitrates, duration and dimensions.

Use the following FFmpeg command in a terminal window:

ffmpeg -i input_file.extension

FFmpeg will just open your input file without doing anything to it. Something like this will be returned in the terminal window:

phillc@phillc-laptop:~$ ffmpeg -i 848_Termi.mov
FFmpeg version SVN-r11213, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --enable-gpl --enable-pp --enable-libvorbis --enable-libtheora --enable-liba52 --enable-libdc1394 --enable-libgsm --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-libxvid --enable-pthreads --enable-libx264
libavutil version: 49.6.0
libavcodec version: 51.49.0
libavformat version: 52.2.0
built on Dec 13 2007 20:20:36, gcc: 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '848_Termi.mov':
Duration: 00:00:51.7, start: 0.000000, bitrate: 862 kb/s
Stream #0.0(eng): Video: h264, yuv420p, 480x360 [PAR 0:1 DAR 0:1], 25.00 tb(r)
Stream #0.1(eng): Audio: mpeg4aac, 44100 Hz, stereo
Must supply at least one output file

All very interesting, but what if you want to do something more with this information, like write it to a file for use in another program, or just want a more convenient way of viewing the details without having to remember an FFmpeg command? Write a small script to do the work for you. Here's one I created earlier in Perl.......

#!/usr/bin/perl

# Read command line input file
 
$input_file = shift;
 
# Read details of input file and display to user
 
$ffmpeg_input_details="ffmpeg -i ${input_file} 2>input_file.txt";
system($ffmpeg_input_details);
 
open(INPUTFILE,"input_file.txt");
@inputfile = <INPUTFILE>;
@input_file_video = grep (/Video:/i, @inputfile);
@input_file_audio = grep (/Audio:/i, @inputfile);
@input_file_duration = grep (/Duration:/i, @inputfile); 
 
print "Details for the file $input_file.\n";
print "It contains the following video data:\n"; 
print "@input_file_video\n";
print "It contains the following audio data:\n"; 
print "@input_file_audio\n";
print "It has a duration and bitrate of:\n"; 
print "@input_file_duration\n";

To use this script simply type the following at your command prompt:

perl scriptname.pl input_file.extension

Good luck extending this small script for your own uses.