[ Saturday, 7 June 2008, Marcin Seredyński ]
I had an ambitious plan to have a perfect knowledge of ffmpeg as well as possible. I have to admit that getting the most of this program is out of my reach at the moment. That’s why a little disclaimer is necessary; I’m not an expert in video transcoding, but I will show my personal experiences.
A short instruction of ffmpeg compilation
Unfortunately, in the Ubuntu repositories we have a version of ffmpeg that doesn’t support some formats (mostly because of law and license issues). The best solution as always is to download the source code and to individually configure and compile the program. We can download the source from:
svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg-source
You need a Subversion client to do this, so if you don’t have one, install it with
sudo apt-get install subversion first.
There is a faster way to do it by downloading the daily snapshot of the source and than updating it:
wget http://ffmpeg.mplayerhq.hu/ffmpeg-checkout-snapshot.tar.bz2 tar jxvf ffmpeg-checkout-snapshot.tar.bz2 rm ffmpeg-checkout-snapshot.tar.bz2 mv ffmpeg-checkout-* ffmpeg-sources cd ffmpeg-sources svn update ./configure --help
The last command will display a long list of configuration options. At this moment we are interested in the “External library support” section. Based on it, we can find out what libraries we will need to compile ffmpeg’. Because the individually compliled ffmpeg is much more useful than the one we get in the package, we should add the following libraries:
# If we have an installed ffmpeg before: sudo apt-get remove ffmpeg sudo apt-get install liba52-dev libfaac-dev libfaad-dev libgsm1-dev \ libtheora-dev libvorbis-dev libx264-dev libxvidcore4-dev liblame-dev
After downloading the latest version of the source, it is better to clean it, and then to can go on with its configuration:
make clean distclean ./configure --enable-gpl --enable-postproc --enable-swscale \ --enable-pthreads --enable-liba52 --enable-libfaac \ --enable-libfaad --enable-libgsm --enable-libmp3lame \ --enable-libtheora --enable-libvorbis --enable-libx264 \ --enable-libxvid --enable-x11grab --disable-ffserver \ --disable-ffplay disable-debug
Of course you can add more configuration options. For example changing the system architecture or the type of the processor. The “expert”options will allow you to turn on or off the use of single codecs, in and out devices, multiplexers and demultiplexers, etc… The default configuration gives support to everything what is included in the source code.
If everything went well (we didn’t receive any informations about errors), we can start the compilation, take a break, and then install our personal version offfmpeg’. In the end we can check its version. Here are the simpla commands:
make sudo make install ffmpeg -version
How to use ffmpeg?
Launching ffmpeg without any arguments displays the list of available options. At the moment there are 525 lines available. It is obvious that analyzing all of them would take a lot of time and of course a big dose of experience in audio/video transcoding would would be necessary. For our purposes (the recording and transcoding of a screencast) the basic functions of ffmpeg should be sufficient.
Recording a screencast with ffmpeg
Option –enable-x11grab during the compilation permits the use of ffmpeg to record o video of everything that happens on the desktop. To do it, you have to choose x11grab as the input format, then set up the size and location of the input area and the quantity of frames per second for the recording. In order to find the best settings I’ve tried many options and I’ve checked many combinations of codecs and options for ffmpeg. In my opinion, screencasts of a very good quality can be recorded in a very simple way:
- Recording of the screen with the use of the mpeg4 codec
- The bi-processed transcoding into H.264 with the use of libx264
We can easily examine the use of our compiled ffmpeg
# The recording of the screen into a video ffmpeg [-an] -s <width>x<height> -r <fps> -f x11grab -i \ :0.0[+<ox,oy>] -codec mpeg4 -sameq -y <temporary-file>.mp4 # The first processing into H.264 ffmpeg -i <temporary-file i> -vcodec libx264 -pass 1 \ [-b <quality-bps>] -f mp4 -y /dev/null # The second processing into H.264 ffmpeg -i <temporary-file> -vcodec libx264 -pass 2 \ [-b <quality-bps>] -f mp4 -y <final-file>.mp4
This is a short description of the options used:
- [-an] – the optional switch to turn the sound recording off
- <width>x<height> – the size of the recorded area, for example: 800×600
- <fps> – the number of frames per second, for example: 15
- +<ox>,<oy> – the coordinates of the upper left corner of the recorded area, for example:+0,25
- <temporary-file>.mp4 – the name of the temporary file in which the video will be saved “live” during the recording, for example: scast-temp.mp4
- <quality-bps> – the required quality, expressed in bits per second (to get the value in kbps we simply multiply the number by 1024), or add the letter k for example: 240000 equals to 240k
- <final-file> – the name of the final file with the bi-processed conversion of the screencast into H.264, for example: scast-final.mp4
The first command writes the contents to the file, so this is where the recording really takes place. The mpeg4 codec ensures quite good quality of the video (it is guaranteed thanks to the –sameq option that informs ffmpeg to use the same quality as in the input so in the case of x11grab it is the maximal value). Also another good side of using this codec is its low usage of the processor power. For example, a screen with a resolution of 1280×1024 and a speed of 15 frames per second giveis a bitrate of about 6000-10000 kbit/s, depending on what’s happening on this screen. This file is a good starting point for a conversion to a more digestible (smaller) format.
The second command executes the first part of the coding. In fact, it scans the content of the temporary file and creates a log file with the information about the changes in the frames. It is a necessary step to continue the optimization of the bitrate’ which will be accomplished in the second part of the processing. We define the bitrate with a value for the -b parameter. Attention: in the case of libx264 this file is created automatically in the current directory. If you want to use other codecs in your bi-processed transcoding, it is necessary to define the parameter –passloglogfile <file> identically in both parts of the process.
The third command executes the second part of the coding, by using the file created during the first operation. By replacing /dev/null with the path to the file, we will get the result of the coding from the first part, containing the results without optimization of the bitrate’. To make everything clear, I published the commands with the parameters replaced by real values:
ffmpeg -an -s 800x600 -r 15 -f x11grab -i :0.0+0,25 \ -vcodec mpeg4 -sameq -y scast-temp.mp4 ffmpeg -i scast-temp.mp4 -vcodec libx264 -pass 1 -b 240000 \ -f mp4 -y scast-pass1.mp4 ffmpeg -i scast-temp.mp4 -vcodec libx264 -pass 2 -b 240000 \ -f mp4 -y scast-final.mp4
A test launch of commands and the result of their activity:
- scast-temp.mp4 (mpeg4) – 8,994,982 bites – 1369.8 kbits/s
- scast-pass1.mp4 (libx264, without vbr) – 3,504,037 bites – 533.6 kbits/s
- scast-final.mp4 (libx264, with vbr) – 1,869,733 bites – 284.7 kbits/s
A test recording of 52,5 seconds in a SPE editor and a test of a program written in the terminal a typical content of a screencast.
- The documentation of ffmpeg: mplayerhq.hu
- A very good comparison of codecs quality (Ateme, DivX, x264, XviD) na doom9.org
- The creation of thumbnails from the film frames flashcomguru.com
Feel free to comment my article below and share your findings about screencasts, not only in Ubuntu!
I would like to thank Patrick Bajer for reading the post before the publication and giving me a few good hints how to improve it. Thanks!