This article is presented in reverse order, newest on top, oldest on the bottom. I’ve briefly summarized the goal and procedure, but you can read from the bottom up to get the background.
Briefly, the goal of the exercise was to compare the quality of Ogg Theora with H.264 using two test files — one SD, the other HD – that I’ve used over the years to compare codecs. I encoded to my standard parameters, which are:
- SD – 640×firstname.lastname@example.org fps@ 500 kbps, 468 kbps video/32kbps audio, maximum quality parameters. For H.264, this meant High Profile, CABAC enabled, B-frame interval 3, all quality options enabled.
- HD – 1280×email@example.com fps@ 928 kbps, 800 kbps video/128kbps audio, again maximum quality. The lowest data rate that I could achieve for Ogg was 928 kbps for video, so I used that file.
- I used Sorenson Squeeze to produce the H.264 files. I used Xiph QuickTime Components to produce the first set of Ogg Files, presented on the bottom of this page. Then, after learning that there was an update to the codec, I used ffmpeg2theora on the Mac to reproduce the results. Specifically, I used verson 0.26, dated 2/5/2010, downloaded from here. My command string for the SD file was (ffmpeg2theora SD.mov –videobitrate 500 –optimize –keyint 300 –audiobitrate 32 –channels 1), for the HD file it was (ffmpeg2theora HD.mov –videobitrate 900 –optimize –keyint 300 –audiobitrate 128 –channels 2). For a general overview of how I encoded with Squeeze, check out this tutorial here.
I called this article Round 1 because I knew from the start that it would involve multiple tries to get things right. I appreciate all the feedback that I got during this process and enjoyed the dialog. Here’s where we are.
I’ve created a comparison file using the 1.1 Thusnelda release and using the command line argument supplied by Gregory Maxwell.
ffmpeg2theora -V 500 -k 300 -d 99999 (the only additions provided to the commandline above is -d 99999 to remove the buffering constraint).
I encoded the file and then compared it to a file that Greg had encoded using the encoded H.264 file as the starting point. When I noticed that his quality was better than mine, I loaded both files into MediaInfo and found that he was using a later code version. This also was clear when I read KeyJ’s review and the associated comments. So, rather than test beta code ad infinitum, I decided to stop here.
I’ve pulled some images from the three files; here’s the display order in each image. The Ogg file I created is always on the left, the H.264 file in the middle, the file Greg created from the H.264 file on the right. You’ll see that the upcoming release has lots of promise and I look forward to seeing it. The images are in PNG format (as suggested) and you can see them at 100% by clicking them.
Some other notes:
- You can draw your own conclusions regarding quality. Clearly, Thusnelda 1.1 retains less quality than H.264, but the new version shows lots of promise, even encoding from H.264 source.
- I’m aware that the audio on the test files is sub-standard. I am drawing no conclusions about audio quality, but it’s necessary to ensure that sound synch is maintained through to the end.
- I’m aware that there are other techniques for producing the Ogg file. Greg is highly respected and works for Xiph, so I decided to go with his recommendation.
- I didn’t include the HD file because of time constraints.
- I know it’s unfair to compare a file encoded from H.264 encoded video to a file encoded from the original source. I’m sure I could have gotten the code base that Greg used, and encoded using the original source file, but I wanted to wait until Ptalarbvorm is released. I included Greg’s file only because it showed improvement over the Thusnelda 1.1 file encoded from the original source material.
You can also play the files themself via the links below.
Here are the video files (Chrome, Firefox and Opera only, for Ogg, Safari and Chrome for H.264)
The tests presented below are in two parts. The tests on top are with the latest Thusnelda 1.1 build; below with the previous codec. Thanks to Andraz for pointing out the codec update.
The goal of the exercise was to compare the quality of Ogg Theora with H.264 using two test files — one SD, the other HD – that I’ve used over the years to compare codecs. I encoded to my standard parameters, which are:
I know that mpeg2theora comes with multiple post processing filters that I didn’t try because that can turn hours of testing into weeks. If anyone has any good input on which switches produce the best results I’ll be glad to give them a try. Just let me know in the comments below.
Here are the files as they sit on my server to verify the file sizes and bitrates. I try to get the file sizes within about 5-10%.
The files aren’t protected in any way, so after viewing them, you should be able to save them to your own systems.
The Files – Thusnelda 1.1:
Click the links below to view the encoded test files, which will open in a separate browser window, facilitating a side by side comparison. The OGG clips are playing in Firefox but not Chrome; if someone can look at the HTML and figure out why, please let me know. Both Safari and Chrome play the HTML files, but not Firefox which doesn’t support H.264 within HTML5. IE won’t play any of these.
This is the second set of Ogg test files; the initial files are below:
I’ll let the videos and still images speak for themselves. Note that I did use two different encoding tools, the Xiph QuickTime encoder for the encodes below, and ffmpeg2theora for the most recent encodes. As before, click each image to view it in full screen.
Still Image Comparisons
Original Ogg Comparisons
These comparisons used the pre-Thusnelda 1.1 codec are are superceded by the findings above.
I understand that there’s code that would play the videos in more browsers (and fall back to Flash for the H.264 files). I’ll do better next time.
Still Image Samples
Here are some sample images grabbed from the clips, beginning with SD comparisons. I’ll start with a low motion scene, then move to higher motion. In all instances, click the photo to view the original in a separate window. In the SD comparisons, I created three files, two at 468 kbps as described above, the other OGG file at 1 mbps, more than double the data rate of the H.264 file. In the first low motion sequence, all the images look pretty good, and Ogg is competitive even at 468 kbps.
In the second clip, there’s a lot more motion, but the background has little detail. We see that Ogg suffers at the comparable data rate, but that the 1 mbps clip is about the same in quality as the H.264 clip. The H.264 clip has much better color fidelity and clarity, but that could probably be corrected by boosting contrast and saturation before encoding to Ogg format.
The third clip contains both high motion and high detail, a skateboarder coming to rest after a great run, framed against a chain link fence. Here we see that the H.264 clip retains superior detail to even the 1 mbps Ogg clip.
Let’s move to the HD samples. Starting with a low motion sample, you can see that the difference between the two technologies is very minor.
Here’s a higher motion clip, a closeup of a very talented piano player. Fast moving fingers, a noticeable difference in quality.
Here’s a higher motion clip. In this clip, the ballerina (Coppelia, actually) is walking across the stage, so the image pan is pretty significant. Lots of motion, some detail, very noticable difference in quality.
Here’s Beth the ballerina, coming down from a jump. High motion, neither clip looks particularly great, but H.264 is clearly superior.
That’s it for the samples, see the next page for some closing thoughts and considerations.