Advanced Video Coding on Linux
It is nice that QuickTime 7 supports H.264-encoded video. Apple itself encodes all of its movie trailers on-line using H.264. Although this is good, and fosters the adoption of this codec, the QuickTime implementation has some limitations, most notably with B-Frames and Profile support. We need a short detour to explain what this means for our encoding project.
The MPEG standard for H.264 includes a number of profiles, such as Baseline, Main, Extended and High. These profiles delineate different technical capabilities that a decoder may need to possess. As its name suggests, the Baseline profile is the simplest and least-demanding profile, and Main, Extended and High require more processing power and the interpretation of more technical features in order to decode properly. QuickTime 7 supports Baseline and parts of the Main profiles; however, it chokes on features of the Extended and High profiles.
B-Frames are a type of storage format for digital video. These types of frames reference information from other previously decoded frames in order for the decoder to do its job properly, which is to decode the video. B-Frames are interleaved amongst other frame types known as I-Frames and P-Frames. It's a technical detail, but the QuickTime 7 H.264 decoder can support only up to two B-Frames, no more. This is unfortunate, because using more B-Frames would let us increase quality under some circumstances.
To remain QuickTime-compatible, we need to keep these limitations in mind. However, the quality of our low-bitrate encoding will not really suffer that much, even with these limitations. And, we can enable a few additional options to improve things quite a bit. The first is the subpixel motion estimation (--subme) size, which controls the precision of motion estimation calculations used by x264 during the encoding process. By increasing this to 6, the maximum, we gain a lot of visual quality at the cost of some additional encoding time, but it is worth it. We also can configure how x264 analyzes frames to perform better motion estimation (--analyse), which leads to higher-quality encodes. Note that some types of analysis are for High profile encodings only, such as 8x8 DCT, which are not supported by QuickTime, so we avoid those settings. We also can disable PSNR calculations (--no-psnr) to buy back a little speed during the encode. PSNR is simply a quality measurement and has no effect on the actual encoding quality.
Putting all this together, we can now output a high-quality, low-bitrate, QuickTime-compatible and standards-compliant video encoding using H.264:
mkfifo tmp.fifo.yuv
mencoder -vf format=i420 -nosound -ovc raw -of \
rawvideo -ofps 23.976 -o tmp.fifo.yuv \
max.dv 2>&1 > /dev/null &
x264 -o max-video.mp4 --fps 23.976 --bframes 2 \
--progress --crf 26 --subme 6 --analyse \
p8x8,b8x8,i4x4,p4x4 --no-psnr tmp.fifo.yuv 720x480
rm tmp.fifo.yuv
We can make further improvements. Because this video file is destined for the Web, we most likely want to reduce the frame size to something more friendly, possibly crop out unwanted areas, and make other adjustments. For example, to reduce the frame size, run the following commands:
mkfifo tmp.fifo.yuv
mencoder -vf scale=480:320,format=i420 -nosound -ovc \
raw -of rawvideo -ofps 23.976 -o tmp.fifo.yuv \
max.dv 2>&1 > /dev/null &
x264 -o max-video.mp4 --fps 23.976 --bframes 2 \
--progress --crf 26 --subme 6 --analyse \
p8x8,b8x8,i4x4,p4x4 --no-psnr tmp.fifo.yuv 480x320
rm tmp.fifo.yuv
Here we instruct mencoder to scale the output to 480x320 and also tell x264 to accept that frame size. This will further reduce the file size, which is appropriate for video on the Web.
Based on the QuickTime format, the .mp4 container format can store many types of media and is also the MPEG standard for storing H.264 video and AAC audio, which is how we will be using it. Use MP4Box, which is part of the gpac project, to combine the audio and video streams we've just created:
MP4Box -add max-video.mp4 -add audiodump.aac \ -fps 23.976 max-x264.mp4
This produces the final output file max-x264.mp4. You can play back the file with MPlayer, or with Apple's QuickTime player on a non-Linux OS. You also can embed this file into a Web page for playback from a browser by using Apple's instructions for embedding QuickTime movies (see Resources). Free software tools such as the mplayer-plugin can be used to play this file from within Firefox on Linux.
By way of comparison, here are the file sizes and bitrates of the original raw DV file max.dv, our H.264-encoded file max-x264.mp4 and a corresponding XviD encoding max-xvid.avi, which was created from the same source video (see Resources):
mencoder max.dv -vf scale=480:320 -ovc xvid -xvidencopts \ fixed_quant=7:qpel:nopacked -oac mp3lame \ -ofps 24000/1001 -o max-xvid.avi
Table 1. Table of Results
| File | File Size | Video Bitrate |
|---|---|---|
| max.dv | 32M | 3MB/s |
| max-xvid.avi | 623K | 418kb/s |
| max-x264.mp4 | 522K | 392kb/s |
And here are accompanying screenshots for each sample.



Figure 1. DV



Figure 2. XviD



Figure 3. x264
As you can see, the visual quality of the H.264-encoded file is just as high as the XviD version, arguably higher, but at a lower bitrate and file size. This shows that you can achieve similar results in less space, or much better results in the same space, with H.264 compared to other codecs such as XviD. In addition, the work flow and options for encoding with x264 are similar to XviD, but with greatly improved output. So, if you are used to encoding with XviD, many of the concepts and options should be familiar to you when working with x264.
The more you experiment with x264, the more you will discover the amazing savings in bitrates and file sizes while still maintaining an extremely high visual quality. The world of video encoding is definitely a black art, as there are hundreds of variables and options that can be brought to bear in any particular encoding project. There is no one-size-fits-all method of video encoding. However, the technical superiority of H.264 over XviD or regular MPEG-2-encoded video is too great not to take advantage of it. And, you can start taking advantage of it today, using the tools described above. Because H.264 is an MPEG-standard encoding, used with an MPEG-standard audio codec inside of an MPEG-standard container format, all the work you invest in using these tools to encode your video will be future-proof as well as high-quality. Use the techniques outlined above as a starting point for your own H.264-encoding projects, and you'll discover why H.264 is becoming the next standard for video encoding.
Resources for this article: /article/9197.
Dave Berton is a professional programmer. He can be contacted at mosey@freeshell.org.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
3 hours 18 min ago - Reply to comment | Linux Journal
3 hours 35 min ago - Favorite (and easily brute-forced) pw's
5 hours 26 min ago - Have you tried Boxen? It's a
11 hours 18 min ago - seo services in india
15 hours 49 min ago - For KDE install kio-mtp
15 hours 50 min ago - Evernote is much more...
17 hours 50 min ago - Reply to comment | Linux Journal
1 day 2 hours ago - Dynamic DNS
1 day 3 hours ago - Reply to comment | Linux Journal
1 day 4 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?






Comments
A quick ending.
mplayer -ao pcm -vc null -vo null max.dv
MPlayer SVN-r29237-4.4.1 (C) 2000-2009 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing max.dv.
File not found: 'max.dv'
Failed to open max.dv.
Exiting... (End of file)
Also tried sudo with the same result.
Son :) max.dv is the name of
Son :) max.dv is the name of the file you're processing. That the name of his (author's) file. Maybe your file has a different name?
Why don't you try replacing the max.dv with the name of your file!?
Cheers!
H264 coding/decoding in hardware?
Hi everybody,
It is very pleasing to see solid and rapidly growing Free Software / open source support for H264 video encoding standard. There are multiple options for doing H264 under GNU/Linux. The completeness of implementation is also getting better - for example handling of interlaced video had been finally improved in 2009 for libavcodec - it decodes *supposedly* H264 specification compliant Mobilygen MG1264 audio/video codec chip produced streams now - you can check MG1264 MP4 samples here - http://www.linuxmedialabs.com/LMLCD/MG1264samples/ - if D1 (full resolution) samples are NOT playing back for you properly it means that your version of libavcodec / mplayer is not recent enough :-) These are full D1 2000 Kbps samples and one 500 Kbps CIF sample, which should playback well everywhere, except from QT player maybe.
Although this article shows the way to use H264 software encoding based on x264 tool, I think it's a good place to ask author and readers about other known Linux H264 hardware devices - for either PCI / PCI-E bus or USB bus - any H264 done in hardware and usable under Linux for integration - with GNU/GPLed drivers like LML26415 PCI card has, or even binary-only non-free drivers or transparent interfaces like RTP/RTSP streams etc. We are building various multi channel video processing systems and having additional choices for H264 standard (720x480/576) and especially high definition video (1920x1080) done in *hardware* for very low CPU overhead is very important. Although hardware design and OEMing is fun thing to do and we enjoy every moment of it :-), sometimes it's desirable to use something that is already available - if only it's Linux friendly. I would appreciate any feedback here or sent to my email vleo@linuxmedialabs.com
V.L.
avi to mp4
I have one question. Is posible to improve the quality of a avi raw, compressing this in mp4? I have seen in some places taht people download the avi raw and convert it to mp4 codec and the result is better than the source (avi raw). I tried to do this with x624 and similar options like you, but the result is the same than the raw.
Thanks and sorry for my english :S
no it is not unless you use
no it is not unless you use some filters, but you have to remember that h264 and xvid aren't lossless codecs so each time you re-encode something using these codecs you lose quality
The two wires crossing the top of the clock tower ?
Hi,
What happened to the two wires which were crossing the top of the clock tower ? You can see them in the DV image but missing in the xvid and x264.
Thanks
--sig
Interlaced Video
I generally use mencoder to convert interlaced 720:480 m2v transport streams to x264 AVIs. I would like to use this method to make Quicktime friendly files, but mencoder says "Skipping Frame!" (which it always does with this video source) which results in mp4 files in which every other frame is blank. Is there an easy way around this? I've played around with the usual pullup and deinterlace filters that I use to make AVIs, but no luck...
Interlaced Video
A solution is to use -of rawvideo with mencoder's native x264 encoder and then mux it all up with MP4Box... If I use the same quicktime-friendly settings I get a quicktime-friendly MP4 out in the end.
An aspect ratio problem
I enjoyed your article, but I think there is a subtle problem with your examples. You start with a DV stream whose natural resolution is 720x480. This seems to be 3:2 aspect ratio, but the stream is designed to play back at 4:3 aspect ratio or 640x480 resolution. This has to do with the legacy of NTSC video having more pixels per inch along a horizontal scan line than vertically across scan lines. I'm not sure, but I don't think H.264 has an aspect ratio flag to account for this issue (MPEG-2 does have such a flag). As a result, I think all of your H.264 output files are stretched horizontally by 720/640. To get the correct result, you probably have to tell the encoder to output a file with a 4:3 aspect ratio. You don't seem to be doing that in the examples.
Specifying aspect ratio, and issues with Quicktime playback
You can set this ratio by specifying the "sample aspect ratio" to x264 using --sar, and also by specifying the "pixel aspect ratio" to MP4Box using :par. I believe these both effect the aspect ratio in the same way. The calculation of the aspect ratio will depend on the properties of the source video clip. More discussion of aspect ratios here. H.264 does have support for aspect ratio signalling, but it of course depends on the decoder to interpret it correctly. For small web clips, it is often best to just resize the source video so that the aspect ratio is 1:1, which will be displayed correctly by any decoder which understands h264.
As one example, Quicktime 7 will not respect these aspect ratio settings, and part of the article deals with issues of compatibility with Quicktime. Although you can set the aspect ratio in the .mp4 file, it will still appear incorrectly when played in the Quicktime player. To fix this problem, open the properties of the video file in Quicktime and manually specify the correct horizontal and vertical dimensions, then save the file (the ability to do this may be restricted to Quicktime Pro). This (non-standard) method will correct the aspect ratio (for Quicktime-playback only).