Posts Tagged ‘encoding’

FFmpeg Makes an Official Release!

March 10, 2009 Leave a comment

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

The FFmpeg team have finally made a release – version 0.5 – with a silly long name. Previously, users were always told to download and compile the latest SVN version of FFmpeg, if they expected any support from the mailing lists.
Now it would seem that there is a stable release, only a few years since the last one, that can be used by software developers and packagers everywhere. I still expect that many mailing list issues will be dealt with by the instruction to download from the SVN or Git repository and compile. I also expect that bug fixes and enhancements will make it into SVN quite quickly, but that also the next release might be some time away.
Release notes are available on the FFmpeg changelog (long!) and there’s a lively, as always, Slashdot discussion around this momentous event.

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:

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

Categories: FFmpeg, Video Tags: , , , ,

FFmpeg Codec Comparison Test – xVid vs x264

January 23, 2008 Leave a comment

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

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 720×404 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 736×442 -croptop 34 -cropbottom 4 -cropleft 8
-cropright 8 -deinterlace -pass 2

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 736×442 -croptop 34
-cropbottom 4 -cropleft 8 -cropright 8 -deinterlace -pass 2

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.


Get every new post delivered to your Inbox.