Archive

Posts Tagged ‘x264’

Handbrake 0.9.5 Released

January 5, 2011 Leave a comment

Handbrake is one of the very few, functionally mature open source video transcoding tools with a decent, usable user interface (of course command line options are still available).
 
Generally the Handbrake development team take a long time between official releases, and v0.9.5 is no exception. This latest version comes more than a full calendar year after the previous milestone release.

While Handbrake doesn’t support a wide range of broadcast video formats, which would be a nice addition for me personally, this is not really their target market. Handbrake does a great job on web targeted and home use video encoding jobs. Ripping Blu-Ray DVDs, encoding for Apple TV2 and advanced finite controls for H.264 transcoding are all now supported in the latest release.

Further details about the release available here.

Discussion thread, specific to this release, available here.

Multi-platform downloads found here.

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.

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

Real World Open Source Video Editing

February 7, 2008 1 comment

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.

Open Movie Editor How-To: Fade to Black Transition

January 31, 2008 1 comment

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 720×576.
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.

var so = new SWFObject(‘http://stream0.org/flash/flvplayer.swf’,’player’,’640′,’500′,’9′);
so.addVariable(‘height’,’500′);
so.addVariable(‘width’,’640′);
so.addVariable(“displayheight”,”480″);
so.addParam(“allowfullscreen”,”true”);
so.addParam(“allowscriptaccess”,”always”);
so.addVariable(“file”,”http://stream0.org/video_files/OMEfadehowto.mov”);
so.addVariable(“backcolor”,”0x000000″);
so.addVariable(“frontcolor”,”0xCCCCCC”);
so.addVariable(‘lightcolor’,’0xCC0000′);
so.addVariable(“screencolor”, “0x000000″);
so.addVariable(“shownavigation”,”true”);
so.addVariable(“autostart”, “false”);
so.addVariable(“smoothing”,”true”);
so.addVariable(“showvolume”,”false”);
so.addVariable(“shownavigation”, “false”);
so.addVariable(“overstretch”, “fit”);
so.write(‘player’);

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.

Optimised x264 Encoding with FFmpeg

January 28, 2008 Leave a comment

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

Categories: FFmpeg, Video Tags: , , , ,
Follow

Get every new post delivered to your Inbox.