Results tagged “x264” from Stream #0

WebM - The New Open Source Codec on the Block

By
phillc
on May 27, 2010 3:59 PM |
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.

Late last week this rumour became reality and WebM was born. Alongside Theora and Dirac, WebM now enters the open source HTML 5 ready codec battle. Almost immediately all major web browsers, except one, but including Internet Explorer announced support for the codec. Using the might and muscle of Google WebM must have a solid chance of taking on the dominance of H.264 in the web video delivery battle. This really will be a solid kick in the pants for Theora, which now seems destined to remain a reasonably niche product, even with direct HTML 5 support from Firefox.

In short order some early comparisons between H.264 and WebM appeared online. Some with more technical detail than others. The debate also began as to whether Google was benevolent or evil. Did WebM contain submarine patents that not even Google were aware of?

Producing WebM video for the masses was the next step. Easy to follow FFmpeg tutorials are available and just a few days ago a major commercial transcoding software vendor announced WebM/VP8 support.

WebM video is already available on YouTube, in experimental form. How long before at least all new YouTube video is transcoded to this format? If WebM quality is on parity with H.264, and the jury is still out on that, what is the unique selling point of H.264? Why would anyone continue to use it? 

There will be a substantial legacy component to overcome. Many people and organisations have invested heavily in H.264 technology, and a move to WebM may represent an operational, although not licensing, cost. However, with Google behind it, many of Big Business' concerns around open source projects may be alleviated.

Adding to this, H.264 video within a Flash player still has significant advantages over HTML 5 delivered video content, in terms of presentation flexibility and perceived security.

H.264 video is of course still dominant for web delivery, just as VP6 and VP7 was in the past. However, WebM is an exciting development with a bright future. Using the collective power of open source development, and no small amount of corporate backing from Google, watch out for WebM to challenge MPEG-LA's codec in the future.


Tags:

H264 Video Encoding on Amazon's EC2

By
phillc
on October 28, 2009 8:52 AM |
Stream #0 recently started looking at Amazon's EC2 computing offering. We created our first public AMI, based on Debian Squeeze, including FFmpeg and x264 pre-installed. Now that we can easily start instances with the necessary basics installed, it is time to compare the relative merits of the different instance sizes that Amazon offers.

EC2 Instances come in a variety of sizes, with different CPU and RAM capacities. We tested the 64-bit offerings, including the recently announced High-Memory Quadruple Extra Large instance.

These 64-bit instances are listed on the EC2 website in the following way:

• Large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform
• Extra Large Instance 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform
• High-CPU Extra Large Instance 7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform
• High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform

We'll take a closer look later at the in-depth specifications of each below.

Our test file was 5810 frames (a little over 4 minutes and 285MB) of the HD 1920x1080 MP4 AVI version of Big Buck Bunny. The FFmpeg transcode would convert this to H264 using the following 2-pass command:

>ffmpeg -y -i big_buck_bunny_1080p_surround.avi -pass 1 -vcodec libx264 -vpre fastfirstpass -s 1920x1080 -b 2000k -bt 2000k -threads 0 -f mov -an /dev/null && ffmpeg -deinterlace -y -i big_buck_bunny_1080p_surround.avi -pass 2 -acodec libfaac -ab 128k -ac 2 -vcodec libx264 -vpre hq -s 1920x1080 -b 2000k -bt 2000k -threads 0 -f mov big_buck_bunny_1080p_stereo_x264.mov

Setting Threads to zero should mean that FFmpeg automatically takes advantage of the entire number of CPU cores available on each EC2 instance.

FFmpeg revealed the following information about the transcode:

Input #0, avi, from 'big_buck_bunny_1080p_surround.avi':
Duration: 00:09:56.48, start: 0.000000, bitrate: 3968 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 24 tbr, 24 tbn, 24 tbc
Stream #0.1: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
[libx264 @ 0x6620f0]using SAR=1/1
[libx264 @ 0x6620f0]using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
[libx264 @ 0x6620f0]profile High, level 4.0
Output #0, mov, to 'big_buck_bunny_1080p_stereo_x264.mov':
Stream #0.0: Video: libx264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], q=10-51, pass 2, 2000 kb/s, 24 tbn, 24 tbc
Stream #0.1: Audio: aac, 48000 Hz, 2 channels, s16, 128 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1

Ignore the duration, as that's read from the file header, and we only uploaded part of the overall file.

Now to look at how each EC2 instance performed.

m1.large
(Large Instance 7.5 GB of memory, 4 EC2 Compute Units)

Firstly, querying the machine capacity (cat /proc/cpuinfo) returns the following information:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5430 @ 2.66GHz
stepping : 6
cpu MHz : 2659.994
cache size : 6144 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca lahf_lm
bogomips : 5322.41
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

There's 2 of these cores available. RAM is confirmed as 7.5GB (free -g).

The FFmpeg transcode showed the following:

H264 1st Pass = 11fps - 18 fps, 5 minutes 30 seconds
H264 2nd Pass = 4-5fps, 18 minutes 38 seconds

Total Time: 24 minutes, 8 seconds

m1.xlarge
Extra Large Instance 15 GB of memory, 8 EC2 Compute Units

CPU Info:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5430 @ 2.66GHz
stepping : 10
cpu MHz : 2666.760
cache size : 6144 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca lahf_lm
bogomips : 5336.15
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

There's 4 of these cores available. RAM is confirmed at 15GB.

The FFmpeg transcode showed the following:

H264 1st Pass = 11fps - 14 fps, 5 minutes 30 seconds
H264 2nd Pass = 6-7fps, 14 minutes 19 seconds

Total Time: 19 minutes, 49 seconds

c1.xlarge
High-CPU Extra Large Instance 7 GB of memory, 20 EC2 Compute Units
CPU Info:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
stepping : 10
cpu MHz : 2333.414
cache size : 6144 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca lahf_lm
bogomips : 4669.21
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:

There's 8 of these cores available. RAM confirmed at 7GB.

The FFmpeg transcode showed the following:

H264 1st Pass = 24-29fps, 3 minutes 24 seconds
H264 2nd Pass = 11-13fps, 7 minutes 8 seconds

Total Time: 10 minutes, 32 seconds

m2.4xlarge
High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units

CPU Info:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5550 @ 2.67GHz
stepping : 5
cpu MHz : 2666.760
cache size : 8192 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr dca popcnt lahf_lm
bogomips : 5338.09
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

There's 8 of these cores available. RAM confirmed at 68GB.

The FFmpeg transcode showed the following:

H264 1st Pass = 35-38fps, 2 minutes 47 seconds
H264 2nd Pass = 12-15fps, 6 minutes 30 seconds

Total Time: 9 minutes, 17 seconds

What can be revealed from these figures? As expected, the High-Memory Quadruple Extra Large Instance performed best, but not by much. Certainly all the additional RAM didn't make much of an impact, and the time saving is probably really down to the slightly increased CPU specifications. Obviously, over a larger file set this time saving would be more evident.

Let's look at which EC2 instance gives best value for money for this test. Amazon charges per CPU hour, shown below:

m1.large: $0.40/hour
m1.xlarge: $0.80/hour
c1.xlarge: $0.80/hour
m2.4xlarge: $2.40/hour

These are US Dollars and for a US based instance (European instances are slightly more expensive). Amazon has also revealed that there will be a price reduction in effect from November 1st 2009.

Looking at the time taken to transcode our test file, on each instance, reveals the following:

m1.large
Total Time: 24 minutes, 8 seconds
Total Cost: $0.16 ((($0.40/60)/60) x 1448 seconds)
Cost per GB: $0.57 ((1024MB/285MB) x $0.16)

m1.xlarge
Total Time: 19 minutes, 49 seconds
Total Cost: $0.26 ((($0.80/60)/60) x 1189 seconds)
Cost per GB: $0.93 ((1024MB/285MB) x $0.26)

c1.large
Total Time: 10 minutes, 32 seconds
Total Cost: $0.14 ((($0.80/60)/60) x 632 seconds)
Cost per GB: $0.50 ((1024MB/285MB) x $0.14)

m2.4xlarge
Total Time: 9 minutes, 17 seconds
Total Cost: $0.37 ((($2.40/60)/60) x 557 seconds)
Cost per GB: $1.33 ((1024MB/285MB) x $0.37)

Clearly the c1.large instance represents the best value for money, although I was surprised how close behind the m1.large costs were. The additional RAM, and slightly better CPU specifications for the m2.4xlarge instance do not outweigh the much more expensive per hour cost, at least when it comes to video transcoding.

A typical HD file used for broadcast or high end post production purposes is around 85GB for 60 minutes (DnxHD at 185Mbps). Obviously the time taken to transcode this file, to an H264 at 2Mbps, could vary from the actual source content we used, but from the figures above we can estimate that it would cost $42.50 and take approximately 53.62 hours!

Taking into account that these figures may vary for different input and output files, the above should represent a worst case scenario. For example, I would expect an SD MPEG2 50Mbps file to take proportionally much less effort to transcode than a DNxHD 185Mbps HD file. Only a further test will tell......

Is Amazon's EC2 offering worth considering for high end video file transcoding? Compared to the prices charged by Post-Production facilities it is certainly a lot cheaper, as long as you have time to wait for the end result. However, that's the beauty of cloud based computing power - if you're in a hurry just scale up! Keep in mind though, content still needs to be uploaded to EC2 before transcoding can begin, that's going to take additional time and add further cost. 

Tags:

AWS Debian Squeeze AMI with FFmpeg and X264

By
phillc
on October 22, 2009 10:02 PM |
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

Tags:

Real World Open Source Video Editing

By
phillc
on February 7, 2008 12:34 PM |
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.

Tags:

Open Movie Editor How-To: Fade to Black Transition

By
phillc
on January 31, 2008 9:05 PM |
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.

Tags:

Optimised x264 Encoding with FFmpeg

By
phillc
on January 28, 2008 7:08 PM |
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

Tags:

FFmpeg Codec Comparison Test - xVid vs x264

By
phillc
on January 23, 2008 2:45 PM |

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.

After a couple of tips on the FFmpeg user mailing list, I re-ran this test with some command optimisations. Specifically:

  • De-blocking loop filter enabled with -flags +loop
  • CABAC enabled with -coder ac

New FFMPEG command example for x264, second pass is:

ffmpeg -i 2573-9.mpg -vcodec libx264 -flags +loop -coder ac -f mov -b 2000k -acodec libfaac -ab 128k -s 736x442 -croptop 34 -cropbottom 4 -cropleft 8 -cropright 8 -deinterlace -pass 2 2537-9_x2642passnew.mov

New screen grab is here, again click for a larger version:


x264 still on the left, xVid on the right. Old 2 pass files bottom. New 2 pass files, with - coder ac and - flags +loop added to the FFmpeg command, on top.

The new x264 file is slightly larger than the old one (50 bytes increase). The xVid file is the same size.

From the new screen grab, it can be seen that the x264 output is now clearly superior. In this case it can be really proved that optimising the FFmpeg command can truly make a difference.

Tags:

How-To: Install FFMPEG on Ubuntu Gutsy

By
phillc
on January 20, 2008 5:01 PM |

I wanted to install FFmpeg on my Ubuntu Gutsy Gibbon (7.10) desktop machine. This is so I can encode and transcode video files to various formats locally, and also render projects from the non-linear editor (NLE) PiTiVi.

This post will mainly cover just the commands I used to install FFmpeg on Gutsy, with very little commentary regarding why or how things work. If you want a more in-depth look at installing FFmpeg, you can read about the installation of FFmpeg on my Debian Etch server earlier today - which ultimately moves me closer to on-the-fly video transcoding of user submitted content on Kapital Moto TV

Installing FFmpeg on Ubuntu Gutsy:

sudo apt-get build-dep ffmpeg

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 checkinstall build-essential subversion

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

cd ffmpeg

make distclean (I used this because I already had an older SVN snapshot of FFMPEG downloaded, configured and made from last night)

./configure --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 --enable-shared

make

sudo checkinstall

Some things you might want to do when prompted to by checkinstall:

  • Select 0 change maintainer name
  • Select 3 to set version name. I used svn11213-ubuntu-gutsy-20071213

And that's it FFmpeg installed on Ubuntu Gutsy.

Other links:

Tags:

How-To: Install FFmpeg on Debian Etch

By
phillc
on January 20, 2008 4:58 PM |

NB: This How-To is now almost totally worthless as it is so out of date. Please click here for an updated version explaining how to install FFmpeg on Debian Squeeze.

--

I have to say, that the video manipulation program FFmpeg, while very powerful, is not very user-friendly when it comes to installation. While many Linux programs can be happily installed from either a pre-compiled package, or downloading source and compiling yourself, this isn't necessarily the case with FFmpeg. The ease of FFmpeg installation largely depends on how many different video codecs and containers you want to be able to input or output. The greater the number, the exponential increase in installation difficulty. My main need was for FFmpeg to accept a wide range of input formats, while outputting H.264 encoded QuickTime (MOV) files. Here's how I achieved this on a Debian Etch server........

I'm going to assume that you are familiar with using the Linux command prompt, moving between directories, editing text files and have at least some experience compiling programs.

The first thing I would recommend doing is making an addition to your source repository lists.

pico /etc/apt/sources.list

Add the following line:

deb http://www.debian-multimedia.org stable main

This repository contains some essential libraries for xvid and x264 (an open source H.264 codec) amongst other things. You'll need to install some software from here. The software may well be available from other repositories too, that are already in your sources.list file, but add this one to be safe.

Next rebuild your sources:

apt-get update

I would also recommend installing checkinstall. This program can be used instead of a regular "make install" command and produces a deb package file that will make re-installation or multiple machine installs much easier. If checkinstall isn't already on your machine download it from:

http://www.asic-linux.com.mx/~izto/checkinstall/download.php

Maybe navigate here with lynx, maybe use wget once you've found the actual file you need, maybe download it with a GUI based web browser and then copy it to your desired directory. It's your choice. I grabbed the latest .deb package. After the download, execute the following as root:

dpkg -i checkinstall_1.6.1-1_i386.deb

Checkinstall should have happily installed on your system. Now it's time to really get into FFmpeg.

Build the dependencies:

apt-get build-dep ffmpeg

Next we're going to install a whole lot more useful software that will allow FFmpeg to output many more than just the minimal file types.

apt-get install liblame-dev libfaad-dev libfaac-dev libxvidcore4-dev liba52-0.7.4 liba52-0.7.4-dev libx264-dev build-essential subversion,

We've also ensured that you have the necessary tools installed to compile from source (build-essential) and obtain files from the Subversion version control repositories.

We're ready to checkout FFmpeg itself:

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg,

At the time of writing the latest revision was 11212. If you'd feel more comfortable not using the lastest bleeding edge version of FFmpeg, issue the Subversion command as follows:

svn checkout -r 11212 svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

This will ensure that you are also downloading the 11212 revision. Once downloaded, move into the ffmpeg directory (cd ffmpeg) and configure:

./configure --enable-gpl --enable-pp --enable-libvorbis --enable-liba52 --enable-libdc1394 --enable-libgsm --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-pthreads --enable-libx264 -enable-libxvid --enable-shared

So, what have we done here......

The essence of his information, and many more options, can be found by typing ./configure --help first.

(You might also consider including libtheora in your configuration, but I forgot at the time)

We're now ready to make the installation files so at the command prompt:

make

If something goes wrong, and you need to start again, a useful command to know is:

make distclean

Make sure you do this first and then run the configure command again.

A finally:

checkinstall

You will be asked a few questions, which should be straightforward enough to answer - yes to creating the documentation, choose a name, select D for Debian package, lastly select number 3 and type a version name that means something to you. Mine was svn11212-etch-20071213. Checkinstall will now create a Debian package of FFmpeg, bespoke for your system with the configuration options you've selected earlier. Checkinstall WILL NOT install the package, so don't forget to do that:

dpkg -i ffmpeg_svn11212-etch-20071213-1_i386.deb

With some small amount of luck, you should now have a working version of FFmpeg installed on your Debian Etch server. You will be able to output H.264 encoded files in a variety of containers.

Now the fun part really begins as you spend days tinkering with commands to output the best possible files. Documentation for using FFMPEG can be found at:

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

Have fun!

(Credit for getting me started in the right direction goes to Paul Battley and his FFmpeg Ubuntu Feisty install how-to)

Tags:

Search

  • Case sensitive
  • Regex search

Tags

Find recent content on the main index or look in the archives to find all content.

Categories

Monthly Archives

Pages