Archive

Posts Tagged ‘H.264’

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.

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.

Interview with Magic Lantern Creator

November 6, 2009 Leave a comment

Several months ago we posted an article about the Magic Lantern firmware for the Canon 5D Mark II video DSLR. This open source software adds functionality to the 5D that Canon didn’t provide out of the box. There has been quite a lot of progress on Magic Lantern over the last few months. The latest release is version 0.1.6, but even since then further enhancements have been made, including Autoboot.

The originating creator of Magic Lantern, Trammell Hudson, recently participated in an interview available on the Cinema5d website. Here are some short excerpts from Trammell’s responses:

4. What plans do you have for the new 5d firmware update? Can we expect anything beyond 24p/25p?

You would have to ask Canon about their plans…  I’ll update my code to work with their new firmware once it is available.  It would really please me if Canon incorporated all of the features from Magic Lantern into their firmware.

On my roadmap for upcoming Magic Lantern releases:

* 1080i HDMI output (still having technical problems)

* SMPTE timecode jamming

* Scripting

* USB control from the Impero remote follow-focus

* Waveforms and vector scope

* Autoboot (now available)

5. On your Wikia Page you describe the Magic Lantern as ” an enhancement atop of Canon’s firmware that makes your 5D Mark II into the 5D Mark Free” What exactly do you mean?

Most equipment is “closed” in that what you buy is what you get. Sure, you can put it on rails, add a follow focus and mattebox, but you can’t really change what is going on inside the box.  With Magic Lantern, however, the internals of the camera have been opened up so that it is possible to add new features that the manufacturer might not have ever imagined.

Read the full text of the interview over at Cinema5d.

A potentially useful enhancement to the Magic Lantern firmware would be the ability to change the codec used in the 5D Mark II. Currently, content is stored as H.264 at around 40Mbps. While this provides for some very nice high quality footage, it’d be nice if additional open source options were included, like Lagarith and Dirac Research. The Magic Lantern Wikia Discussion page has a few comments around this idea already.

BBC R&DTV – Creative Commons Tech TV

April 18, 2009 1 comment

In an interesting, and to be applauded, move from the BBC, they are now releasing a technology based television programme under a Creative Commons non-commercial attribution licence. R&DTV’s first episode is now available for free download in a number of file formats. There is a full 30 minute version available, a shorter 5 minute highlight version, as well as a complete Asset Bundle, which includes rushes that may not have made it into the final programme versions.

The BBC’s RAD blog has a launch announcement about this, followed up by another post 24 hours later outlining some small fixes.

The programme is PAL 720×576. The aspect appears to be 14:9 anamorphic. The little person inside me who wants the greatest and the best all the time, wonders why the filming wasn’t done in HD, even HDV would do.

I thought the “formats” described on the R&DTV website were a bit vague. What does QuickTime format and Matroska format really mean? Sure, I know about QuickTime and Matroska containers, but this doesn’t say anything about the video and audio essence contained therein. The best way to find out about this is to download each video and let FFmpeg take a look.

QuickTime Format (461.3MB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins.mov':
Duration: 00:05:59.08, start: 0.000000, bitrate: 10777 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: h264, yuv420p, 720×576, 25 tbr, 25 tbn, 50 tbc

That’s H.264 video with PCM audio. Strange they didn’t use AAC audio in a QuickTime file. Looking at that 10Mbps bitrate though, I’m guessing perhaps the BBC is expecting people to use this version for editing. But then why use H.264, rather than something that’s I-Frame only like IMX50? There’s also an Uncompressed version and another QuickTime version, which we’ll come to later.
 
Matroska Format (28.4MB):

Input #0, matroska, from ‘RDTV_ep1_5mins.mkv':
Duration: 00:05:59.04, start: 0.000000, bitrate: N/A
Stream #0.0(eng): Video: mpeg4, yuv420p, 720×576 [PAR 1:1 DAR 5:4], 25 tbr, 1k tbn, 25 tbc
Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16

Generic mpeg4 video this time (Xvid perhaps) and here’s our AAC audio!

MP4 Format (65.4MB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins.mp4′:
Duration: 00:05:59.10, start: 0.000000, bitrate: 1526 kb/s
Stream #0.0(eng): Video: h264, yuv420p, 720×576 [PAR 1:1 DAR 5:4], 25 tbr, 48k tbn, 50 tbc
Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16

H.264 video again and AAC audio again. When opening this file with Totem to view, the Comments section says “HandBrake 0.9.3 2008121800″. Nice to know the BBC is using Open Source software for at least some of their video transcoding.

AVI Format (63MB):

Input #0, avi, from ‘RDTV_ep1_5mins.avi':
Duration: 00:05:59.04, start: 0.000000, bitrate: 1470 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720×576 [PAR 1:1 DAR 5:4], 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: mp3, 48000 Hz, stereo, s16, 160 kb/s

Generic mpeg4 video again, but this time with mp3 audio.

FLV Format (37.4MB)

Input #0, flv, from ‘RDTV_ep1_5mins.flv':
Duration: 00:05:59.07, start: 0.000000, bitrate: 844 kb/s
Stream #0.0: Video: vp6f, yuv420p, 1024×576, 716 kb/s, 25 tbr, 1k tbn, 1k tbc
Stream #0.1: Audio: mp3, 44100 Hz, stereo, s16, 128 kb/s

VP6 for the video codec and mp3 for the audio. No surprises there then. The bitrate is quite low though for VP6 content, quality will suffer.

Ogg Format:

Input #0, ogg, from ‘RDTV_ep1_5mins.ogg':
Duration: 00:05:59.08, start: 0.000000, bitrate: 683 kb/s
Stream #0.0: Video: theora, yuv420p, 720×576, PAR 1:1 DAR 5:4, 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: vorbis, 48000 Hz, 5.1, s16, 516 kb/s

Theora for the video and vorbis for the audio, again no surprises there. 5.1 audio is a nice touch though. However, again, the bitrate is very low. Why would the BBC do this? The MP4 version, with H.264 video at a higher bitrate, is going to look far superior.

QuickTime 2 Format (155MB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins_2.mov':
Duration: 00:05:59.08, start: 0.000000, bitrate: 3627 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: h264, yuv420p, 720×576, 25 tbr, 25 tbn, 50 tbc

H.264 video and PCM audio. This second QuickTime file is found only on the FTP site and not linked to directly from the main page. The bitrate is much lower than the previous QuickTime file.

QuickTime Uncompressed Format (7GB):

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘RDTV_ep1_5mins_uncompressed.mov':
Duration: 00:05:59.08, start: 0.000000, bitrate: 167428 kb/s
Stream #0.0(eng): Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream #0.1(eng): Video: rawvideo, uyvy422, 720×576, 25 tbr, 25 tbn, 25 tbc

There we go, raw video in the 4:2:2 colour space at 165Mbps, with PCM audio again. I wonder whether the content was filmed at anywhere near this resolution. Given that the programme is only SD, I’m guessing that the highest quality recording would have been done direct to Digital Betacam, which is only the equivalent of 90Mbps, unless of course the whole thing was done tapeless, which I must admit to doubting.

One last puzzlement is why a Dirac version wasn’t supplied, given that this is the BBC’s own R&D developed codec.
 

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
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 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 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 736×442 -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.

Follow

Get every new post delivered to your Inbox.