Ogg vs H264 – Round One

Home/Articles/Ogg vs H264 – Round One
By | 2010-02-19T00:00:00+00:00 February 19th, 2010|Articles|Comments Off on Ogg vs H264 – Round One


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×480@29.97 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×720@29.97 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)

SD – H.264

Greg’s File

Thusnelda 1.1 – Greg’s recommended encoding parameters

Older material:

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:

  • SD – 640×480@29.97 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×720@29.97 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 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%.

file sizes.jpg

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:

SD – H.264

SD – Ogg – Thusnelda 1.1

SD – Ogg 1mbps – Thusnelda 1.1

HD – H.264

HD – Ogg – Updated

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.

SD – H.264

SD – Ogg

SD – Ogg 1mbps

HD – H.264

HD – Ogg

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.

skate 2.jpg

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.

hd rod.jpg

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.

hd jenna.jpg

Here’s Beth the ballerina, coming down from a jump. High motion, neither clip looks particularly great, but H.264 is clearly superior.

hd beth.jpg

That’s it for the samples, see the next page for some closing thoughts and considerations.


#1AndrazSaid this on 02/21/2010 At 04:26 pm


which exact version of Xiph QuickTime Components have you used?

According to http://www.xiph.org/quicktime/ the last version was released on 14.6.2009

Theora "Thusnelda" 1.1 was released on 29.9.2009 (as stated on http://www.theora.org/news/).

Since the major improvements to Theora encoder happend in that 1.1 release it seems that you were comparing to the previous generation of Theora encoder.

#2Jan OzerSaid this on 02/21/2010 At 04:54 pm


Thanks for letting me know. I'll rework and circle back.


#3John DowdellSaid this on 02/21/2010 At 05:33 pm

Hi Jan, thanks (once again) for this analytic work you do.

re: "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."

Although the WhatWG's "HTML5" proposals specify a VIDEO tag, the only codec-resolution is hierarchical: a list of video files compressed with different codecs, which the user-agent is expected to resolve. In practice, Apple browsers and Google browsers for Windows work with H.264, while Firefox (and beta Opera) use Ogg Theora.

Put another way, there is no "'HTML5' video" implementation, only VIDEO/Theora and VIDEO/H.264 implementations.

For current Theora encoders, Chris Blizzard and Chris Double of Mozilla have been tracking this:





#5Jan OzerSaid this on 02/21/2010 At 06:53 pmIn reply to #3Thanks. As I mentioned in the article, ffmpeg2theora was the first one that I tried, but it won't meet my data rate targets without dropping frames. I tried on Windows, I'll try it on the Mac and see if that makes a difference.

Thanks!#6Jan OzerSaid this on 02/21/2010 At 07:12 pmIn reply to #3

Got it. The Ogg file itself will play in Chrome if I load it directly, but not via the HTML.

Any more specific leads to encoding tools would be appreciated. I tried the two listed into Mark Pilgrim's excellent Dive into HTML5, but neither was able to produce a file at my target configuration. As mentioned below, I'll try mpeg2theora on the Mac and see if that works.

Thanks for weighing in.


#11DaveSaid this on 02/22/2010 At 02:03 pmIn reply to #3

I can see how you would jump to that conclusion John, but actually Theora works in all but one of the browsers that implement the video tag, including both the Google browsers, Chrome and Chromium. The only browser vendor that didn't implement Theora as a baseline interoperability codec when they added the video tag was Apple and indeed their refusal to support a single codec that could  be guaranteed to work in all browsers is why Theora was removed from that role the spec.

The more prosaic reason why the Theora pages linked above aren't working is the lack of a closing quote after the type=video/ogg part of the video tag. This stops it working in Chrome and Safari as the rest of the page gets eaten. Strangely in Chrome, you can't even see the video tag when you view source because of this, which meant I couldn't see where the video files were hosted when I was looking at this earlier.

#4AndrazSaid this on 02/21/2010 At 06:09 pm

It's been a while since I was paying close attention to theora, but at the time ffmepg2theora (http://v2v.cc/~j/ffmpeg2theora/) was the best bet when needing general purpose encoder.


#7DaveSaid this on 02/22/2010 At 10:39 am

Your images show that the newer Theora version 1.1 (a.k.a Thusnelda) is noticeably worse than the older version.

This is the opposite of what you would expect (as there was a significant improvement) so either you've simply got the two sets of images mixed up, or you've done something very wrong with your 1.1 encodes.

#8janSaid this on 02/22/2010 At 10:58 am

I agree that the new results show no improvement. I attributed it to the fact that I used different encoders, and that different encoding tools often produce different results. For example, with the previous version of the codec, ffmpeg2theora produced poor results that exhibited lots of dropped frames, while the Xiph QuickTime version worked pretty well. I saw definite improvement in the two ffmeg2theora versions, but the Xiph output was still better.

Not sure what I could have done wrong - is there any way to analyze the encoded file and see what version of the codec is used?

Anyway to get Xiph QT components updated to Thusnelda 1.1? That would give us an apples vs apples comparison.


#9DaveSaid this on 02/22/2010 At 11:47 am

The use of XiphQT or ffmpeg2theora shouldn't really make a big difference since they are both using libtheora to do the actual encoding.

It appears the maintainer of XiphQT hasn't made a release since 1.1 Thusnelda, which is a bit unfortunate. Someone asked about it on the Theora mailing list recently and it just petered out. They really should fix that:


Personally, I would forget about Theora 1.0. it was broken in several important ways, and just try and get a representative 1.1 encode with ffmpeg2theora as it makes it easy to state what you did and let others try it themselves.

The Theora clips don't seem to be linked from your article at the moment, but the audio seems surprisingly poor on all these clips (e.g. even the HD H.264 clip of the blond gentlemen talking about surgery sounds like an mp3 from the 90s despite being high bitrate AAC), but even more so on the Ogg clips that I found by guessing at URLs.

Normally bad Vorbis is a result of using the ffmpeg encoder rather than the libvorbis one, but the process you've described wouldn't make this possible (ffmpeg2theora only uses ffmpeg decoders) so I'm a bit stumped.

Even if the originals had dodgy audio (and posting the original files would be helpful in helping people guage quality, rather than assuming that an H.264 artefact is correct, just because everyone knows that H.264 is better.) I'd expect Vorbis to do at least as well, and probably better at low bitrates than AAC. Instead it sounds actually painful even at 128. Hold that thought, the HD ogg clip that I thought had a high audio bitrate actually only had 32kps, 32Hz mono audio (currently at doceo.com/HD.ogv and apparently only 430kbps for video too yet looks, at a glance, similar to your screenshots that say 800 or 900kbps) . It still sounded much worse than I'd expect with those settings though.

I'm just confused now and don't really want to go digging through files to check bitrates, so I'd recommend:

  • just forget about Theora 1.0, it was broken, particularly for hitting bitrate targets rather than quality targets
  • use ffmpeg2theora and post the command line you use
  • post the originals as well as the encodes
  • check your links, the test videos seem to have disappeared
  • maybe just ditch the audio if you're not interested in comparing them on that front (it seems to be widely considered a tie)
  • I believe the H.264 video you're producing won't work on iPhones since you use CABAC. Might be worth mentioning since one of the big talking points recently is about what will and wont work on iPhones?
Sorry for the ramble.
#10Jan OzerSaid this on 02/22/2010 At 12:15 pmIn reply to #9


Thanks for your note. All the links appear to be working.  Not sure what's up with your results.

Agreed the audio isn't optimal - not assessing that in these tests.

How are you computing bitrates on the files that you're viewing? I've added the file sizes to the main article (or will in a minute).

The command lines that I used are in the article already (see third bullet point)

Files won't play on iPhones or iPods. Neither will H.264 video on YouTube. Neither will Ogg. Not sure why that's relevant.

Source files at 6 GB in size (raw formats) so impractical to post them. If you'd like to send me FTP information off list (jozer@mindspring.com) I'd be glad to send the files to you.



#12DaveSaid this on 02/22/2010 At 02:14 pmIn reply to #10

Hi Jan,

As I mentioned in my reply to John above, due to a single missing quote Chrome was eating part of the page in view source, which confused me as to where the videos were to be found. I just guessed based on the H.264 examples.

The one file I found (HD.ogv) was reported by the default Video app in Ubuntu as 463kbps video bitrate and 32kbps mono audio. Since the audio seemed in the right ballpark, I assumed the video bitrate was correct too. However, I just downloaded the file again and ran oggz-info on it. This revealed the video bitrate to be over 1000kbps so the Ubuntu Video Player was reporting that wrongly (and a simple size/time calculation shows the higher value to be more likely). Oggz-info does however confirm the low bitrate of the audio.

Sorry for the confusion earlier,


#13JanSaid this on 02/22/2010 At 06:01 pmIn reply to #12

No worries, I appreciate the input. I think I've fixed all the HTML, though the files aren't playing on all browsers that they should be on all OS.

Does Oggz-Info tell you what version of Thusnelda was used to create the file? 

#14DaveSaid this on 02/23/2010 At 08:06 am

The related Oggz-comment will show the comments embedded in the file, which usually include the encoder version and the application used e.g. your files show:


$ oggz-comment -l HD.ogv
Theora: serialno 1321572250
Vendor: Xiph.Org libTheora I 20081020 3 2 1
Vorbis: serialno 1911018872
Vendor: Xiph.Org libVorbis I 20090604
ENCODER: XiphQT, CAVorbisEncoder.cpp $Rev: 12399 $

$ oggz-comment -l HD1_1.ogv
Theora: serialno 0720323403
Vendor: Xiph.Org libtheora 1.1 20090822 (Thusnelda)
ENCODER: ffmpeg2theora-0.26
SOURCE_OSHASH: 82b2cdaec8f30c8c
Vorbis: serialno 1158945499
Vendor: Xiph.Org libVorbis I 20090709
ENCODER: ffmpeg2theora-0.26
SOURCE_OSHASH: 82b2cdaec8f30c8c

It might be interesting to see if --soft-target and/or --two-pass enable Thusnelda enough wiggle room to prevent the sudden drops in quality. The encode you've done is basically CBR, soft target lets it stray further from that set bitrate for the easy or difficult frames, just as you set the max bitrate constraint to 200% in your Squeeze tutorial. The --two-pass mode goes even further in that direction and is completely VBR.

#15Jan OzerSaid this on 02/23/2010 At 09:30 amIn reply to #14Excellent, I'll give it shot in the next day or so. Do you recommend any of the post processing options?

Thanks.#16Jan OzerSaid this on 02/23/2010 At 10:13 amIn reply to #14

Tried the soft target, but low motion sequences looked bad (high motion did improve). I see there's a way to set a minimum bitrate with a -v setting, but can't figure out the syntax. would like to set minimum at 300 kbps to see what it looks like. Here's where I am - can anyone tell me how to add a mimimum target of 300 kbps.

ffmpeg2theora SD.mov  --videobitrate 500 --soft-target  --two-pass --optimize --keyint 300 --audiobitrate 32 --channels 1

Here's what the wiki says: 

Soft target also allows an optional -v setting to specify a minimum allowed quality.

I tried that, but the command line encoder keeps acting like I'm setting the quality option.
#17DaveSaid this on 02/23/2010 At 11:06 am

I think the minimum level set by -v is quality (0-10) not bitrate as why would you want the encoder to use up all 300kbps if it's confident it can get the required quality with less bits. Obviously if this minimum is set high enough compared with the bitrate, it's going to be roughly the same as just specifying that quality. Relatedly you might want to try quality level minus two for Vorbis which should come out at around 32kbps.

There is some kind of post-processing in Theora I believe, but I think the new settings in ffmpeg2theora are actually post-processing the decoded output from ffmpeg before it is given to libtheora. So technically you'd then be giving the two encoders different inputs.

I think --soft-target and --two-pass might be mutually exclusive, I assume the latter wins.

#18ScaevolusSaid this on 02/25/2010 At 05:52 pm

Why did you not use x264 to encode H.264 in these comparisons? It is free and open source, and is widely recognized to be the best encoder available for H.264.

#26JanSaid this on 02/25/2010 At 07:37 pmIn reply to #18

Great. Can you point me to a comparison? Which encoding tool would you use to produce the best results?

#19chrisSaid this on 02/25/2010 At 06:23 pm

i hope the author realize that the method she/he used will not produce variable bitrate product for ogg. set a bitrate, in my experiences, is not the way to produce variable bitrate ogg files, and consequently, the motion pictures gets blurr.

you should us quality controler, 5==>450kbps, 8==>800kbps.

#29JanSaid this on 02/25/2010 At 07:40 pmIn reply to #19Chris:

Thanks for your note - please send a complete string along and I'll give it a shot. here are the two I'm currently working with:

SD file was - ffmpeg2theora SD.mov --videobitrate 500 --optimize --keyint 300 --audiobitrate 32 --channels 1 (I've also experimented with two-pass since then with no benefit, but if you think that would help, add it.

HD file was - ffmpeg2theora HD.mov --videobitrate 900 --optimize --keyint 300 --audiobitrate 128 --channels 2.



Thanks.#81CeeSaid this on 07/06/2014 At 08:19 amIn reply to #29

Thusnelda Ver 1.1 (theora) keyint by default is 64 not 300.

Same for ver 1.2 Alpha

ffmpeg2theora#20MarkSaid this on 02/25/2010 At 06:29 pm

Why don't you simply ask the developers at Xiph.org how to use their codec properly? Clearly they get better results than you do. Please do not use Quicktime, as Apple are a member of MPEG LA, so they have a self-interest in promoting h264, and are actively against Theora. A year ago, Xiph.org did make a Quicktime plugin for Theora, but that is ancient history now and is not in any way representative of Theora's current performance.

"Thusnelda" was a development project funded by Mozilla that started in January 09, and it produced version 1.1 of the Theora codec towards the end of September 2009. The "Thusnelda" project has therefore finished now. Theora version 1.1 is significantly improved over earlier versions, and it is far better than any version for which there is a Quicktime plugin available.

As for the "cost" of conversion of videos, it is only a matter of CPU time. The openvideo.dailymotion.com website has already converted over 300,000 videos to Theora, so it cannot be all that expensive. Examine some of the recent videos on that site to find samples of Theora encoding that is entirely competitive with the equivalent h264 videos on the main dailymotion site.

Ongoing development of Theora at Xiph.org is now underway with the development codename "Ptalarbvorm". Ptalarbvorm is the successor to Thusnelda, if you will, and it is in the early experimental stage at this time. Nevertheless early results are very encouraging, as an experimental build of Ptalarbvorm has been able to produce a video clip at 367 kbit/s with the same objective quality as Youtube h264 at 499 kbit/s.

#21chrisSaid this on 02/25/2010 At 06:36 pmIn reply to #20

The problem is simple, setting a bitrate will NOT generate variable bitrate videos with ffmpeg2theora, he should have used the quality number instead. This is a huge mistake in methodology.

#31JanSaid this on 02/25/2010 At 07:53 pmIn reply to #21Chris:

Tried the quality level - needed to go to 3 to get to the target overall data rate. Note that the file might have data spikes that would make it unacceptable for wireless or other transport.

High motion segments looked better, low motion segments really suffered. I'll post the file tonight.


Jan#22J_DarnleySaid this on 02/25/2010 At 06:44 pm

Why do your comparison images have a levels issue?  It looks like the H.264 ones have been through a TV-PC levels conversion while the Theora ones haven't.  Since both formats use the same colour space, neither one should have "much better color fidelity"

#32JanSaid this on 02/25/2010 At 07:55 pmIn reply to #22I've used the same source file for all these encodes for years. disagree that two codecs can (or encoding tools for that matter) can't have different color fidelity, since I've seen huge differences in the past.

Thanks for weighing in.

Jan#23guiodicSaid this on 02/25/2010 At 07:12 pm

conversion from h264 to theora is pretty a nonsense. You should start from the original, uncompressed, footage and compare h264 with theora.

If you convert from theora to h264 you'll see theora clip is better than h264 clip....


#24JanSaid this on 02/25/2010 At 07:27 pm

From what I've seen of the other tests, they either used cartoons, talking heads or very easy to compress clips at high data rates. I mean, Chris Dibona of YouTube claims that Ogg is inferior and someone from Xiph attempts to prove him wrong with a comparison of cartoon footage? Are you kidding me? If you have any tests with comparable footage at comparable data rates, I'd like to see them.

According to Ars Technica, "DailyMotion has acknowledged that its Ogg streams have some technical deficiencies compared to its current Flash-based video streaming solution, but is confident that it's the best approach in the long run. (http://arstechnica.com/open-source/news/2009/07/de...). That was before Thusnelda 1.1, but so was Xiph's cartoon related post. 

And I did "ask Xiph" for their help. I went to their web site and used encoding tools that they listed (three of them in fact), including the QuickTime tool. I don't have to call MainConcept or Dicas to learn to use H.264 or contact Sorenson or Telestream to learn how to use their encoding tools. Part of the responsibility of those developing new technologies is to make it usable. The most functional encoding tool for Ogg is a command line utility that's inadequately documented on its own site and incompletely documented at others.

My only agenda when I started this process was to objectively assess the quality of the Ogg codec and how it compared to H.264. It would have been a much bigger story if Ogg was better than H.264, a real man bites dog. Unfortunately that's not what I found.

I've been completely transparent with my procedures and have updated my results once already and will do so again if someone can show how to improve the quality. I've offered to send my source files to anyone who wants to try to encode them --  all I ask is that they share their procedure with me so I can duplicate their results. If you want the files, send me an FTP address and I'll start uploading, or a snail mail address and I'll send the files.

Or, just tell me which tool to use, and which settings to use to produce the optimal results at the settings that I've defined. I'll give it another shot here and let you know if it bears fruit. 



#25chrisSaid this on 02/25/2010 At 07:35 pmIn reply to #24

easy, set quality number "-v 5" and "-v 7" rather than "-videobitrate 500"

#27chrisSaid this on 02/25/2010 At 07:38 pmIn reply to #24

also, find an original VOB file please, i  hope your original file is not already compressed in some format already

#39JanSaid this on 02/25/2010 At 09:09 pmIn reply to #27


The original footage was all first generation DV, deinterlaced and scaled to 640x480, then saved into an uncompressed format.


#36MarkSaid this on 02/25/2010 At 08:24 pmIn reply to #24

And I did "ask Xiph" for their help. I went to their web site and used encoding tools that they listed (three of them in fact), including the QuickTime tool.

Don't use the Quicktime tool, it is ancient. It is not Xiph's job to update Quicktime, just as it is not the job of MPEG LA to update h264 codec in Adobe Flash. If you use the aging Quicktime tool at Xiph.org website, you will get horrendous results that are not at all representative of Theora.

As far as I know, there is no available software for Quicktime that implements an even remotely capable version of Theora.

If you are at all truly interested in getting a fair and objective contemporary comparison of Theora vs H264, you probably shouldn't be using any Apple platform at all.

#38Jan OzerSaid this on 02/25/2010 At 09:08 pmIn reply to #36


Listen to yourself. If video producers can't get a good result with Theora on the Apple platform, you're bound for failure. If Microsoft can produce a respected product on the Mac, so can Xiph.

If the QuickTime component tool was so odious, Xiph should pull it from their site, or at least inform potential users that they could get "horrendous" results.


#41MarkSaid this on 02/25/2010 At 11:02 pmIn reply to #38

Xiph isn't in the business of making Quicktime plugins, Xiph researches codecs. Quicktime is an Apple product, not a Xiph.org product.

Unfortunately, Apple have absolutely zero incentive for enabling good performance of Theora on Apple platforms, considering that Apple is a member of MPEG LA. Sorry, but that is just the way it is.

I'm just saying the same information as post #1 ... try not to shoot the messenger, OK?

#43JanSaid this on 02/25/2010 At 11:56 pmIn reply to #41

Xiph better be in the business of making Ogg succeed, or the entire effort is a total waste of time. A significant percentage of video production and encoding takes place on the Mac. If Xiph or other Ogg promoter can't make a tool that works well on the Mac, the codec won't succeed. Period.

Turning that around, people like using Mac tools because they're typically easy to use and work well. The Quicktime-based encder was the third tool I tried, after ffmpeg2theora on Windows (with Thusnelda 1.1), which dropped too many frames, and FireFogg, which couldn't meet my data rate targets. These were the tools recommended in Dive into HTML5 and the Jilion folks I spoke with. 

So, I turned to the Xiph web page, used a tool they recommended and it actually produced a file that met my target specs and played without dropping frames. Hallelujah. Then I find out it's using an out of date codec (yes, I actually did read the first note) and reproduced all my tests, using a command line tool on the Mac. Perhaps you didn't notice that I redid the tests? So, I'm not shooting the messenger, but pointing out that I heard it the first time, and draw no conclusions from those tests.



#44MarkSaid this on 02/26/2010 At 12:31 amIn reply to #43

Xiph better be in the business of making Ogg succeed, or the entire effort is a total waste of time. A significant percentage of video production and encoding takes place on the Mac. If Xiph or other Ogg promoter can't make a tool that works well on the Mac, the codec won't succeed.

This is a real problem, becase both Apple and Microsoft are members of MPEG LA, and they both have a vested interest in everyone using h264 and not using Theora. Apple and Microsoft are both better off if people's experience with Theora is bad, and that people believe that Theora cannot produce competitive quality.

Meanwhile, Xiph.org's interest is in producing reference codecs that are as platform agnostic as they can possibly be.

Perhaps the best thing would be for an enthusiast of video on the Mac platform to establish a project, perhaps hosted at Sourceforge or at Google Code or somewhere like that, with the aim to produce the latest and greatest Theora codecs as a Quicktime plugin. It seems to be clear that without such an effort, for most Mac users Macs are simply not going to be able to produce competitive quality Theora-encoded videos such as for example some that are available at openvideo.dailymotion.com.

#45Jan OzerSaid this on 02/26/2010 At 09:06 amIn reply to #44

I disagree with your fundamental assumption. If you follow the links from this page (http://www.mpeg-la.com/main/programs/AVC/Pages/FAQ...), you can download an attachment that contains a list of patents. it's 47 pages long, and companies like Philips and Panasonic have multiple pages worth of patents. Apple has ONE, while Microsoft has over 60. Sure, Apple's could be the most important patent there is, and they could be drawing a totally disproportionate share of revenue from the patent pool, but even if that's the case, you're assuming that Apple, who reported close to 10 billion in revenue last quarter, is guarding revenue from MPEG-LA like a pensioner and his social security checks.

If a codec becomes important to their customers, I'm sure Apple will do everything they need to make it accessible on their platform. Heck, you can encode VC1 on the Mac quite successfully with a number of encoding tools.

Since you brought up DailyMotion, 'd love to hear from someone there about:

- their current stance on Ogg's quality vs. H.264 - the last time they weighed in, they " acknowledged that its Ogg streams have some technical deficiencies compared to its current Flash-based video streaming solution" (http://arstechnica.com/open-source/news/2009/07/de...).

- how they encode their files

- what encoding parameters they use (resolution, frame rate, data rate, etc). I'm guessing someone can get this information from one of the Linux Ogg analysis tools; I'd love to know.



#55MarkSaid this on 02/28/2010 At 06:55 amIn reply to #45

This articel you linked on arstechnica:


Has the following title & byline:

Decoding the HTML 5 video codec debate
By Ryan Paul | Last updated July 5, 2009 4:30 PM

The date of July 5 2009 means that any quotes in that article from Dailymotion about the "current" state of Theora refer to the sate of play back in July, 2009. That means they are talking about Theora 1.0 or earlier. Everyone knows Theora 1.0 was considerably behind h264, as the poor quality of the old Quicktime plugin for Theora will demonstrate.

AFAIK, the video on Dailymotion is largely user-contributed:


Given that fact, most of the content on the openvideo.dailymotion.com is probably transcoded fromthe main dailymotion.com site. If that is the case, since most user-contributed videos will probably be in mp4 format, then the Theora videos transcoded from that are necessarily going to be lesser quality. As you are no doubt aware, you have to encode from uncompressed higher-resolution video down to each format in order to be able to compare them fairly. Dailymotion is therefore probably not a good place to get videos for comparison purposes from.

Even so, every now and then, you do find a high-quality Theora video on the openvideo.dailymotion.com site. These are probably encoded from a significantly higher-resolution source. When you do find such a video, posted recently, you can compare it with the same video encoded in h264 on the main dailymotion.com site. Such videos are quite comparable in quality, but they are reasonably rare. They do however nicely illustrate what CAN be achieved recently with Theora comapred with h264.

I have no real idea why Apple are strongly opposed to and biassed against Theora, but there is absolutely no doubt that they are. They were one of the main objectors who recently prevented Theora from becoming the agreed standard codec for HTML5.#59JanSaid this on 02/28/2010 At 10:20 amIn reply to #55

I know the Ars site was dated, that's why I was asking for their "current stance." Sorry that I didn't make that clearer.

ASAIK, Apple is against Theora because there may be submarine patents that could effect usability - that's been their public stance anyway. They're also H.264 proponents because it's the format they've chosen for all their devices, and it's worked well for them in those huge markets.

Just for the record, I am not going to respond to any comments here on the existence of submarine patent claims on Ogg.

Still, it's a very long way to go from H.264 proponent to making sure that you can't produce high quality Ogg encodes on the Mac. QuickTime is a well documented interface, and there are lots of very high quality plug-ins that video producers use every day, including to VC1 and VP6, both formats that Apple totally has no interest in. Do you think there's a hidden Ogg flag that tells quicktime to degrade the quality of any file produced in QuickTime to that format? Seems pretty out there to me. 

The problem with using comparisons from a site like DailyMotion is that you don't know how each file was encoded and since its user submitted, it's tough to track down the producers and ask. I'm gonig to post my final quality comparisons in the next day or so (once I learn from Gregory Maxwell when 2.0 will be out) and that will be the end of this.

Thanks for your comments, I've learned a lot from everyone.


#66MarkSaid this on 02/28/2010 At 08:48 pmIn reply to #45

There are three obvious problems with Apple's logic when it comes to Theora and patents.

The first problem is that h264 itself is patented. So Apple are trying to argue that there might be patent trolls out there when it comes to VP3/Theora, while simultaneously ignoring the fact that there ARE petent trolls when it comes to h264. As you point out, 47 pages worth of them.

The second problem is that VP3 itself was patented. It was patented before h264 was. In order for there to be a successfult patent troll against VP3/Theora, someone has to hold a valid, OLDER patent against the same technology. If someone does in fact hold a valid, older patent against the same technology, then the USPTO has made an error, because in that case the USPTO should not have awarded the same patent a second time later on to VP3 technology. If someone does in fact hold a valid, younger patent against the same technology (perhaps one of the ones in the 47-page-long list you mentioned), then the VP3 patent would prevail because it is older.

The third problem is highlighted by the last paragraph. Despite Apple trying to claim that there might be a patent troll out there with a valid patent against Theora/VP3, and thereby effectively "telegraphing" their desire for someone to come forward with exactly such a claim, no-one has. Therefore it is fairly certain that no-one actually does hold a valid patent against the patented technology in VP3. Furthermore on this same line of reasoning, if there WAS patentable technology in VP3 that was not covered by the patents for VP3, then why didn't On2 apply for another patent over that technology as well at the same time as the patents for VP3 that they do hold?

Apples claim about patents and Theora/VP3 is obviously flawed on several fronts.

#28Gregory MaxwellSaid this on 02/25/2010 At 07:39 pm

The bigest reason why the 1.1 clips have surprisingly poor quality is because these are stricly buffer constrained encodes.  The ffmpeg2theora commandline given imposes constraints roughly equiuivlent to an x264 encode with --vbv-bufsize 5000 --vbv-maxrate 500.  

The buffer constraint means that user with a very bandwidth limited connection can playback without stalls and excessive buffering. So it's a good thing to have if you're streaming  But— its absolutely brutal on the quality and it's not a restriction that your h264 encode has been subjected to.

I'd really like to have the option to try transcoding the files myself. It's very unfortunate that the files haven't been made available.

The "color fidelity" issue is because the software being used here managed to mishandle the colorspace (BT.601 vs BT.709) and lumanance offset.  Generally if the color/contrast differ between encodes you've done something wrong with your test... the manner in which lossy codec manipulate image data should not generally influence color or contrast.



#30Gregory MaxwellSaid this on 02/25/2010 At 07:45 pm

I did a quick one-pass non-buffer constrained 500kbit/sec reencode of the SD h264 file:

The transcoding obviously hurts quality, so this isn't suitable for comparison but it does demonstrate the instantaneous bitrate constraint is hurting things.

#33JanSaid this on 02/25/2010 At 08:01 pmIn reply to #30


Sorry I wasn't clearer - I used the same raw source footage for both clips, I didn't encode to H.264 and then Ogg. That would be nonsense.


#34JanSaid this on 02/25/2010 At 08:03 pmIn reply to #30

Impressive. What encoding tool, what encoding parameters?

#35Gregory MaxwellSaid this on 02/25/2010 At 08:17 pmIn reply to #34

ffmpeg2theora  -V 500 -k 300 -d 99999    (the only additions provided to the commandline above is -d 99999 to remove the buffering constraint).

Two-pass also disables the buffer constraint by default, but I wanted to make it clear the the improvement is from removing the buffering constraint, not from switching to two-pass.   If you're not live-streaming two-pass is highly recommended.  Many other encoders use a significant amount of lookahead in one-pass mode, while in one pass theora is a live-streaming-sutiable zero latency encoder.  The only way to do a apples to apples comparison is to either run both encoders as two-pass or both as zero latency,  and make sure to use the equivalent buffering constraints on each.

#37Jan OzerSaid this on 02/25/2010 At 09:04 pmIn reply to #35

Thanks - SD file looked better in most places, worse in others.

should I add an audio bitrate switch to set that a 32? Seems like it was around 50, which could confuse folks who look at both files.

What about for the HD file - that was the more challenging encoding config.

Once I get both of these done I'll post the files (but probably not the comparison images tonight).

Thanks for helping out.


#40Gregory MaxwellSaid this on 02/25/2010 At 10:35 pmIn reply to #37

It will be the same story for the HD file,   unfortunately since I do not have the source material I didn't bother trying the second encode.  ... it would be insanely unfair to compare h264 transcoded to theora against the h264.  I only posted the one file to point out what a huge difference the instantanious bitrate constraint can make.  

The audio in these files is pretty bad.  It sounds like its being transcoded from a low bitrate mp3. I can only assume the original sounds that bad, since both the h264 and Ogg/Theora file are worse than I'd expect at the respective bitrates. I'd personally leave the audio out on all of them.


#42JanSaid this on 02/25/2010 At 11:09 pmIn reply to #40

Yeah, audio is bad, I don't draw any conclusions about audio quality from the file, just video.  Send me your address, I'll send you the source files. Be interested to see what you can do with them.


#53JanSaid this on 02/27/2010 At 07:15 pmIn reply to #30

Hey Greg:

I analyzed the file that you encoded and noticed that it had been encoded with ptalarbvorm. Notably, I couldn't match the quality that you produced from the H.264 stream when encoding from the original file.

When will this be ready to go? If soon, it really doesn't make sense for me to spend any more time messing with the current code base. Once available, I'll redo and repost and you're welcome to check my work to make sure that it's fair.

Please let me know.