Archive

Posts Tagged ‘FFmpeg’

FFmbc v0.5 Available

November 16, 2010 1 comment

It has been announced as available for a while now, but only recently was the download made publically available again for FFmbc 0.5. Lead developer Baptiste is doing a super job moving this project forward, but really needs the support from more media professionals to fully realise the early promise of this open source, broadcast media focused, transcoding solution.

FFmbc 0.5 download available here.

FFmbc 0.5 feature updates include:

  • Sync on FFmpeg svn r25202.
  • Yadif video deinterlacing filter.
  • Overlay video filter.
  • Fade video filter.
  • HQDn3d video filter.
  • Rename ffmpeg binary to ffmbc.
  • FFmbc is now GPL only.
  • Disable shared libraries.
  • Remove -s resizing output cli option, use -vf scale.
  • 23.98 and 24 fps support in MXF muxer.
  • Mpeg-2 aspect ratio bitstream filter, to change aspect ratio without reencoding.
  • Fix an issue with -async and audiomerge.
  • Fix an issue with the fade filter.
  • Write interlacing information in mov files, fix deinterlacing with quicktime player.
  • Correctly support interlaced in yuv4mpeg and quicktime.
  • Display interlacing when printing information.
  • Fix an issue with resampling and audiomerge.

Categories: FFmbc, FFmpeg, Video Tags: , ,

FFMBC 0.4 Now Available

June 25, 2010 Leave a comment

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:

- Sync on FFmpeg svn r21845.
- Full support for reading and writing covert art in mp3 and iTunes m4a,m4v,mp4.
- “-coverfile” commandline option to set a cover file. png,jpg,bmp supported.
- Correctly write Quicktime metadata as utf-8.
- Fixed a bug with temporal offset when muxing mpeg-2 long gop in MXF.
- Huge speedup when opening Quicktime and mpeg-4 files.
- Timecode for Quicktime and MXF files can now be set when stream copying.
- Added x264 sources in contrib directory, git 5b86182d1240b441f28462abf3d40b7371de5ba3
- Enable pthreads by default.
- Fixed a bug with interlaced VC-3 decoding.
- Integrate libavfilter. New commandline option -vf, see doc/libavfiter.texi
- Auto-rotate iPhone 3GS files.
- Support lyrics in mp3 and iTunes m4a,m4v,mp4.
- Automatically set current UTC time in created files.
- New AVFMT_HAS_PTS flag in AVInputFormat to specify that format has pts.
- Write and read metadata “reel_name” in mov timecode track if present.
- MPEG TS muxer now produces streams playable by VLC and Quicktime.
For me, the two most interesting updates in this list are the fixed VC-3 bug and the ability to now set timecode when copying QuickTime and MXF files.
FFMBC version 0.4 can be directly downloaded from here.
Categories: FFmbc, Video Tags: , , ,

Updates on WebM Support – All Aboard!

June 2, 2010 Leave a comment

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.

CNET posted a reasonably ordinary piece regarding the quality of WebM, when compared against H.264. However, there were two interesting links in this piece. 
The first pointed to a WebM project page where the indepth encoding parameters for WebM content are outlined. If you’re planning to create WebM files, reading this page is essential. 
The second link, to the quAVlive website provides some various examples of H.264 (using x264) encoding compared against WebM. I can’t really see a lot of visual difference in the “Sunflower” example. However, it is easily clear to my eyes, without even enlarging the screenshots, that in “Park Joy” and “Riverbed” H.264 is certainly superior. I would like to have seen more information regarding the time taken to transcode these examples, with each codec, and the resulting file sizes. Picture quality isn’t always everything, transcode time and storage requirements should also be taken into consideration.
Everyone’s jumping on the WebM bandwagon with software and hardware support. Gstreamer claims full plugin support, which means in turn there is Moovida support and the Transmaggedon transcoder can also output VP8 codec files, although not in the Matroska/WebM container yet. Not to be outdone, Flumotion, will also stream live VP8/WebM content. The Miro Video Converter will also output valid VP8/WebM files, claiming to be the first to do so. The list could go on, but the easiest thing is to probably just keep tabs on the WebM project page listing all the supported devices and software tools, both commercial and open source.
Also worth a shout is the fact that both Mozilla and Opera are pushing for VP8/WebM to be specifically included in the HTML5 specification. Previously, major browser makers couldn’t agree on one specific video file format – Mozilla and Opera backing Ogg Theora and Apple sticking with H.264. I can’t see that particular situation changing now. 

WebM – The New Open Source Codec on the Block

May 27, 2010 Leave a comment

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.

New FFmbc Release 0.3

November 19, 2009 1 comment

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

Enhancements in this version include:
  • 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.
Download the latest source, or a Windows binary, from the project homepage.
Also now included on the FFmbc wiki is a list of requested enhancements. These include support for additional codecs, bitstream validation for MPEG2 files and support for DNxHD 10-bit files. Go to the requested enhancements page to review and add your own requests to the FFmbc-user discussion group.
Categories: FFmbc, Video Tags: , ,

FFmbc – A Broadcast Media Alternative to FFmpeg

November 12, 2009 Leave a comment

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:

Import your files in Final Cut Pro or AVID Media Composer by

Creating XDCAM HD422 files in .mov or .mxf

Creating XDCAM IMX/D-10 files in .mov or .mxf
Creating AVID DNxHD files in .mov

Transcode your MPEG-2 4:2:2 Tranport stream files containing S302M audio.
Transcode your AVCHD Camera files correctly.
Merge and split your audio tracks.
Create Quicktime files containing time code tracks.
Advanced Metadata support.

ID3v2 complete support.
Itunes complete support.

We’ve been meaning to test some of FFmbc’s functionality for a while now and after a couple of false starts, we’ve been successfully able to convert a generic MPEG2 50i (50Mbps all Intra-Frame) 4:2:2 Transport Stream to IMX D-10 in a .mov container. This file contained PCM audio, which version 0.1 of FFmbc baulked at, but the latest version handled perfectly. The output IMX D10 file was imported without error directly into Final Cut Pro for editing. FFmbc has not yet renamed any FFmpeg libraries, so the same conversion syntax and commands can be used across both. Although, be careful as this may create some library conflicts if you try to have both FFmbc and FFmpeg installed at the same time.
Why would we want to use an Open Source transcoding tool in a predominantly proprietary video production environment? The answer is simple. Every commercial product we’ve investigated (Telestream’s Episode Engine and Flip Factory, Rhozet’s Carbon Coder, Digital Rapid’s Streamz) wanted to transcode our MPEG2 source file to IMX, rather than simply re-wrap the essence into IMX. Transcoding takes a considerable amount of time and will always lower the quality of the final output, no matter how minutely. FFmbc instead took our video and audio essence, extracted it from the MPEG2 Transport Stream and re-wrapped it all to IMX D10. 
Our 30 minute test file was around 16GB in size. Our test machine was a puny eeePC, with an Intel Atom N280 1.66Ghx processor, running Ubuntu Karmic Koala Netbook remix (hardly ideal for transcoding video). The entire conversion process took a little over 7 minutes, at a rate of approximately 110fps (frames per second). Pretty impressive!
There are a couple of caveats to mention with regards to FFmbc. The software is very new and Baptiste is very busy. I’m sure more developers would be a welcome addition to the project. We used the earlier Stream#0 tutorial for installing FFmpeg to achieve the same for FFmbc. However, FFmbc v0.2 didn’t like the latest SVN of x264, which is a bug that won’t be fixed until the next FFmbc release. Instead, we used the packaged libx264 from the Ubuntu repository. FFmbc then compiled and installed without error. Checking out the latest FFmbc from GIT also caused some issues The source compilation complained and failed regarding the absence of swscale. However, working around these small issues, we’ve achieved our goal – a quick conversion of a generic MPEG2 file to something that can be edited using Final Cut Pro.
FFmbc is an exciting prospect, targeted directly at the broadcast media world. If you’re looking for an open source file transcoding solution, to integrate with your Avid or Final Cut Pro editing environment, give FFmbc a chance to prove itself.

Possible Formation of FFmpeg Foundation NGO

November 6, 2009 Leave a comment

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

Full text of Ronald’s post is as follows:
Hi,

some developers have stated the intent to set up a NGO (non-governmental organization) to help us bring some structure, support and funding into the project. We haven’t decided on a name yet, although people agree that we dislike “FFmpeg Foundation” – if you can suggest better names, please do so in this thread. Right now, we’re at a point where I think most of the stuff is decided and there is just some paperwork to be filled out. All this with many thanks to Karen at the SFLC who helped to get all this going. The NGO will be registered in Delaware, USA (for administrative reasons). Its goal will be to “advance the state of free and open multimedia” or something like that.

For the time being, this organization will be run by a board consisting of 7 members. For the starting board, the following developers have volunteerd:

- Baptiste Coudurier
- Benjamin Larsson
- Carl Eugen Hoyos
- Diego Biurrun
- Mans Rullgard
- Michael Niedermayer
- Ronald S. Bultje

If you feel that these members will not be able to appropriately represent this project, now would be a good time to speak up and suggest something better. For the near future, the directors will elect a new board at the end of their yearly term (and that might end up in the same 7 members). If there’s enough interest, we might set up a member-structure so the board can be properly elected by its members (=developers, contributors, etc.), but ATM we lack the structure for even that ample task, so not for now.

The NGO will set up a bank account to accept tax-deductible donations (bank, paypal, etc.) from organizations, users and companies to benefit the further advance of “open / free multimedia”. These might be spend on FFmpeg development, FFmpeg development hackparties, FFmpeg developers attending conferences or anything else that we will would serve the greater good of “open / free multimedia” (i.e. it doesn’t have to be FFmpeg, specifically). We will also accept donations for a specific purpose (e.g. Snow, etc.). Lastly, we will host a bank account for MPlayer for donations intended specifically for MPlayer, rather than FFmpeg.

Comments?

Ronald
This sounds like some really positive news and various comments and questions followed this announcement.
Let’s hope this organisation becomes a reality and really benefits open source multimedia. We’re waiting for a formal announcement soon……

Categories: FFmpeg, Video Tags:

H264 Video Encoding on Amazon’s EC2

October 28, 2009 2 comments
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 1920×1080 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 1920×1080 -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 1920×1080 -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, 1920×1080 [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, 1920×1080 [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. 

AWS Debian Squeeze AMI with FFmpeg and X264

October 22, 2009 Leave a comment

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

How-To Build FFmpeg on Debian Squeeze

October 22, 2009 8 comments

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

Categories: FFmpeg, Video Tags: , , ,
Follow

Get every new post delivered to your Inbox.