Holy Crap! h.264 Killer!

I will be honest with you. While the encoding times of h.264 were always pissing me off, I recognized the format as the best option to do video online regarding bandwidth consumption. I was always bummed by the fact that Flash used a niche format for its video support rather than h.264. I felt like grabbing Tinic (Adobe engineer working in Flash video, but also an ex-Be, Inc. engineer and my ex-housemate) from his hair and shout at his ear (I am adorable, yes). ;-)

So, I did some research today.

I found that Flash uses a video format called VP6, from a company called On2. Never heard of them. But I gave them the benefit of the doubt, and I checked their latest format version, called VP7. I downloaded one of their movie trailer samples, and then I downloaded the same trailer in high-resolution and re-encoded it in h.264 at the same bitrate. Results below.

WOW! That’s all I can say. VP7 kicks h.264’s ass any time of the day at the same bitrate. Not only h.264 had 2 fps less in its advantage, 6 horizontal fewer pixels to deal with, somewhat bigger resulted filesize overall (it wouldn’t let me encode video below 32kbps you see) and terrible quality at that bitrate, but also it required more CPU power to decode than VP7. I encoded the h.264 video with multi-pass for better(!) quality and low-enough AAC encoding so it fits together with the video at that 1200 KBs as the VP7 does. So, at the same resulted filesize, VP7 is miles better.

Now, I only pray that Adobe uses VP7 in Flash 10 and that Joost also switches to VP7 instead of using h.264. And I also hope that VP7 becomes a standard and services use it enough to provide good video quality via cellphones or 56k modem lines. I am impressed. I never thought that it was engineeringly possible to have anything that much better than h.264 and definitely didn’t expect usable video on a 56k modem line. Never say never I guess.

Update: Reader AC re-encoded the video using the x264 encoder variant of h.264 and he came up with this very good quality at 58kbps. There is no audio in his video so we are not sure what the filesize would really be with some AAC in there, but for the resulted 870 KBs, I’ll bite. Problem with the x264 encoder is that it is a bitch to use. The GUIs for it only make it more difficult to use, not the other way around (MediaCoder fails to use x264 properly, MEgui is made for people with IQ 200 by people with IQ 50 and StarTrix just fails to read the .mov or .mpg source file here).

27 Comments »

Phil wrote on March 22nd, 2007 at 11:11 AM PST:

I remember looking at On2 a while back, and also this post by Tinic – link


mikesum32 wrote on March 22nd, 2007 at 11:32 AM PST:

VLC has been able to play vp6 and flash, like videos for a little while.


This is the admin speaking...
Eugenia wrote on March 22nd, 2007 at 11:35 AM PST:

Yes, but we are talking about VP7 here, which in itself is much better than VP6.


Oliver wrote on March 23rd, 2007 at 2:14 AM PST:

It hasn’t much to do with being better than, it’s a matter of the proper encoding. And VPx ist slow, very slow, compared to other codecs and inferior – just comparing features and shots on their website isn’t enough.

You should frequent this forum,

http://forum.doom9.org/index.php

these people are pros in every aspect of video encoding. You will see many engineers there from different companies like On2, Ahead etc. for example.


ac wrote on March 23rd, 2007 at 2:18 AM PST:

Where did you find a HD version of the S&H trailer?

I couldn’t find any (my bad :) so I used the 720p version of the 2nd 300 trailer, which should be harder for a dct codec.

This is my first try. (Note that the bitrate is in the mid 40s, ffdshow shows the current bitrate, not the average of the clip)

No codec optimizations (I’ve no experience with ultra-low-bitrate encodes), no advanced filter magic (I ran into some avisynth troubles that took a while to sort out and didn’t have the time for repeated tries), just a basic resize and noise filter with a basic x264 ultra-slow profile (due to the resolution I nevertheless got 17 fps on an Athlon 3500).

Despite all this, my video looked much, much better than your screenshot.
This means that either you’re exceptionally bad at encoding, your source was bad or you deliberately picked a non-representative sample


This is the admin speaking...
Eugenia wrote on March 23rd, 2007 at 2:20 AM PST:

The point of the matter is that VP7’s sample was better than ANYTHING I could encode at home with freely or cheaply available tools. Sure, VP7 costs money, but you know, they do a good job. I hear Elecard’s h264 encoder is very good, but you know, their resulted mp4 file does NOT play on Quicktime, so why would I ever bother with that? If I wanted incompatible encoders because they use tricks to make better encoders, I better use VP7 and be incompatible 100%, but at least I will know that I will have good quality without tricks.

And please, for the love of God, please use HTML for links. :)


This is the admin speaking...
Eugenia wrote on March 23rd, 2007 at 2:26 AM PST:

It is not an HD version of S&H, is the 480pix wide version that Apple has on their site. The input version was good enough for what we wanted to do. It had good quality to be used as source for a 40kbps re-encoding.

>This means that either you’re exceptionally bad at encoding,

Don’t piss me off AC. “I” am not bad encoding, I simply used Quicktime Pro with the most sane options available to match VP7’s. You didn’t use the same encoder, so don’t put this on me.

>your source was bad

The source was good enough as I said.

>or you deliberately picked a non-representative sample

No, the whole resulted h264 video from Quicktime was as shitty as the screenshot.

How did you EXACTLY encoded your video? I can retry with your encoder and settings. Please *email me* with the applications and the switches you used.


ac wrote on March 23rd, 2007 at 2:32 AM PST:

>Don’t piss me off AC. “I” am not bad encoding, I simply used Quicktime Pro with the most sane options available to match VP7’s.

I wasn’t really serious. I assumed the problem was the source and not your incompetence or malevolence =)
Now I know I was wrong =P

Let me explain, but first a screenshot and a download link.

1. No, the 480×204 version isn’t “good enough” to make no difference. Apart from some blocking and swimming macroblocks in the background, we’re not even lowering horizontal and vertical resolution by a third. Both together means we’d need extensive filtering to get a similar quality as with a high resolution source.

2. The Quicktime encoder sucks.

3. The video file is 45kbps for those extra 5kbps I slightly raised the resolution because this way the pixel aspect ratio is closer to 1:1

4. The screenshot is clearly in favor of x264; VP7 is exceptionally blurry (Just look at the face) and the colors are awful (look at the tie). That said, there are also scenes where VP7 looks better.
Btw. I used some blur filters in ffdshow to get a slighly more similar blurring/blocking balance, but those were switched on when I took the screenshot.

5. For even more blurring I’d have to do more extensive filtering before encoding (well, I don’t *have* to but otherwise it looks like sh*t) but to do that I’d have to download vdub and a bunch of filters, just to do something I haven’t done since the times of lq anime raws :)

6. Furthermore I prefer the look of the x264 encode to vp7 even the way it is now.

7. Nevertheless, if you think vp7 is better and don’t believe me that pre-filtering would further improve the x264 encode, I concede :)

8. The Graphedit file shouldn’t be necessary but my avisynth does strange things when I let it built its own graph.

9. I haven’t really tweaked the avs file because, as I said, I would need vdub to see the actual results of the tweaking for it to be useful. But what you’d wanna do is roughly:
-quadrupel the resolution of the source (i.e.->1280×408 or so)
-spatial and temporal smoothing
-warpsharp
-lower the resolution to final size
-another smoothing filter

10. The file is .mkv because .mp4 played at the wrong fps unless I muxed the sound in. I assume it’s a problem with the parser.

11. I encoded the file using MeGUI, latest versions due to the auto-updater. x264, two-pass, deblocking at -4,-4 or -6,-6 or something similarily high, mocomp etc. at maximum. Due to the low resolution I nevertheless get about 20fps. x264 works fine here, but if you can tell me the error message perhaps I can help you.

12. Is there any vp7 sample available where you can also get an hd source, so we could compare those codecs at useful bitrates? With rising broadband penetration, being the best codec at 40kbps isn’t really relevant. Doom9 rated VP7 lower than x264 at 600kbps but that was 1 1/2 years ago

http://rapidshare.com/files/22397727/snh.rar.html


hd_maven wrote on March 23rd, 2007 at 4:25 AM PST:

If you think that’s impressive, check out VP7 in live production action for ABC TV online (via Move Networks):

http://dynamic.abc.go.com/streaming/landing


ac wrote on March 23rd, 2007 at 4:53 AM PST:


I encoded the file using MeGUI, latest versions due to the auto-updater. x264, two-pass, deblocking at -4,-4 or -6,-6 or something similarily high, mocomp etc. at maximum. Due to the low resolution I nevertheless get about 20fps. x264 works fine here, but if you can tell me the error message perhaps I can help you.

You realize that I’m extremely stupid? I thought lower values meant stronger deblocking but that was a different codec. And there I was, wondering why it needed that much extra deblurring. :P
It’s really been too long since I’ve done this stuff regularily :(

updated link. This time I did two tries and now I’m sure that higher leads to more deblocking, the encode is the blockier version, as I mentioned above I prefer more blocks to more blur.


This is the admin speaking...
Eugenia wrote on March 23rd, 2007 at 5:08 AM PST:

I spent the whole afternoon trying to work with ffmpeg and x264 but to no avail. Ffmpeg has a bug (feature?) that won’t allow videos to be encoded below the 64kbps rate (for a 320×138 size) and x264 simply does not seem to work on windows with anything I tried (megui and command line). It just encodes some garbled noise.

So, AC, please download the video file from Apple for the Starsky&Hutch large trailer, and then re-encode with your way at 320×138, 12 fps that should create a file size of 1.1 MBs. I give you the benefit of the doubt, so I will allow you to not encode audio, but instead give all of that 1.1 MBs of the resulted file to the video. I am interested to see with what you can come up with.


This is the admin speaking...
Eugenia wrote on March 23rd, 2007 at 8:24 AM PST:

AC, could you please write for us the EXACT steps on how you made the original .mov file to transcode to matroska via MEgui? I find MEGui a terrible app you see, it is very difficult to use, so please write down the EXACT steps of what you did.


ac wrote on March 23rd, 2007 at 9:56 AM PST:

1. Open the .grf in graphedit. You need the haali splitter I used or any other filter that can demux .movs. Replace the source I used with the location where you put your source mov. (graph->insert filters->directshow filters->haali splitter, then choose the file in the file dialog that pops up)

2. Open the .avs. Replace all paths to the plugin dlls and to the .grf with the paths to those files on your system. You might need to d/l a few of the plugins, you can get them from the avisynth page. If you want to play around with the script you might also want avsedit.

3. Start MeGUI. Let it update itself.

4. Click on the “…” in the “Avisynth Script” line, select the .avs from 2.; select x264 as codec; click on config, choose a profile (with maxquality or something in the title) in the pulldown menu at the bottom of the config dialog and select “automated 2-pass” in the one at the top (I didn’t use some options, so your encode may end up better but slower. If you need more speed, cut down on trellis first, then ME). Close the config dialog.

5. Click enqueue, change to the queue tab, select the first pass and click start. Wait a few minutes.

6. Depending on your profile and the quicktime decoder, the movie may or may not play in quicktime (I’ve really no idea how qt implements the h264 options), if it doesn’t MPC or VLC will. (Staying within a specific h264 profile isn’t really a priority in a comparison with a proprietary format :) )


ac wrote on March 23rd, 2007 at 10:09 AM PST:

oops:

4.5 Reopen the config dialog, set the correct bitrate, close it again. ;)


This is the admin speaking...
Eugenia wrote on March 23rd, 2007 at 10:20 AM PST:

The way you used is very difficult. I much prefer to recompile 10 Linux kernels rather than go through this procedure. This is why VP7 wins in my book: click 2-3 settings and go.


ac wrote on March 23rd, 2007 at 10:45 AM PST:

yay, don’t you love the smell of moving goal posts in the morning?

Unless your vp7 guys wrote their own media framework you’d still need a directshow graph, you’d still have to resize the image (you can do that stuff graphically with megui’s avs creator, but this was about how you can use my script because without control over the source I couldn’t troubleshoot your megui; although I gather your comment means it was a case of PEBMAC :P ), you’d still need the filters.

Just about the only thing that’s x264 related is choosing profile, 2-pass and bitrate.

Oh, and a finally tidbit of wisdom: If this wasn’t about comparing it to a similarily sized vp7, I’d lower the resolution of the output file. 288×120 (or even lower) could probably provide less encoding glitches with more details.

And while we’re talking about crappy usability: When the anti-spam image is expired, it doesn’t give me a page with a new one, I can’t even reload the image (well, I can but it reloads the expired one and not a valid new one), so I have to copy the text, reload the page and paste the text.
That’s kinda stupid.


This is the admin speaking...
Eugenia wrote on March 23rd, 2007 at 10:53 AM PST:

>you’d still need a directshow graph,

I didn’t need anything like that with QuickTime. I find Quicktime’s dialog to be the best in terms of usability. I don’t want to deal with graphs and other weird things like MEGui and avisynth have. I just want to be able to select the format (e.g. h.264 in .mp4), resolution/aspect_Ratio (e.g. QVGA, letterbox), bitrate and frame rate. Why is this so hard to do? Everything else should be setup under the hood for the best encoding result. The work of what are the best options overall should be already done for the user by the application itself. The user should not be loaded with anything else. And of course, the application should “understand” most formats out there out of the box, so no “filters” and other such crap should be needed to be installed manually. THAT is what I call a nice encoding app for the average user.

>When the anti-spam image is expired

Honey, I can’t do anything about it. This is not my server.


ac wrote on March 23rd, 2007 at 11:18 AM PST:

>I didn’t need anything like that with QuickTime.
Then complain to the Quicktime guys that their h264 encoder is so shitty. And no matter what they call it, you need something that decodes the source video.
The reason I can’t just click on trailer.mov in MeGUI is, that by default that opens the mov with QT-alternative.
Why is that a problem? Because it screws up the frame serving, so there are blank frames.
Then why do I use QTA instead of replacing it with ffdshow, like I do -by hand- with the grf file? Because ffdshow’s Sorenson 3 decoding isn’t perfect. There are a few fishy trailers that look like shit with ffdshow. And there’s no proper dshow filter for sorenson because Apple with their usual lock-in attitude don’t provide one.

If that vp7 examples page had even one example with a proper mp4 hd source instead of Apple’s proprietary POS, x264 encoding would look something like this:

1. Start MeGUI, start the AVS wizard
2. Select the source file, select target resolution.
3. Put an additional “SelectEven()” in the script — this is the only “fault” of MeGUI. It just isn’t built for ulq encoding that needs fps adjustment. But this is the only act that isn’t pointy clicky.
4. Select codec, profile and bitrate.
5. Click start.

>Honey, I can’t do anything about it. This is not my server.

Sweety, I didn’t assume you could, it was just the xth time I had to c&p my posts.
But this time I outsmarted them, this time I c&ped before clicking submit. MWAHAHAHAHA. Sry.


This is the admin speaking...
Eugenia wrote on March 23rd, 2007 at 11:38 AM PST:

The only x264 gui I like is SUPER. However, SUPER just doesn’t work with directshow (it fails to encode the mov video if it’s checked) and without directshow I can’t set a custom resolution. And because it’s using ffmpeg, SUPER can’t encode below 64kbps either (which renders it useless for the example of Startsky&Hutch trailer we use here).

So, basically, what I want is a better SUPER application that doesn’t have these few limitations.


l3v1 wrote on March 23rd, 2007 at 12:40 PM PST:

Well, I have some collegues who’ve spent considerable amounts of time evaluating h264 on a very broad range of video resolutions (mostly large resolutions though) and very broad range of h264 encoding settings both externally available and also in the innards, tweaking the encoder algorithms to some extent. Thing is, we didn’t test vp7 yet, but it’s very hard to think it can so easily surpass h264 as you say. But I’ll take a look at it, it wouldn’t hurt :) Additionally, h264 and the mpeg family of license term stand closer to my liking than on2’s.


Luis wrote on March 23rd, 2007 at 12:50 PM PST:

I believe that h.264 is a great codec for high bitrates, but it’s always been bad a low bitrates.

You should compare this VP7 with other codecs optimized for lower bitrates, like WMV9 or maybe one from Real Player. That would be a more fair comparison.

Did you compare VP7 with h.264 at high bitrates? I guess that trying to encode from a DVD with the best quality possible at reasonable filesize will show h.264 strengths and possibly VP7 weaknesses.


This is the admin speaking...
Eugenia wrote on March 24th, 2007 at 1:03 AM PST:

VP7 is available as its own solution atm, but I am pretty sure that Flash 10 will use it. For now, Flash comes with VP6, which is not as good as VP7.


Kronos wrote on March 24th, 2007 at 1:27 AM PST:

Thanks Eugenia, so, in other words, I just need to wait for flash 10 to come out? What about H.264? do I need to setup something like the flash media server?


Luis wrote on March 24th, 2007 at 1:33 AM PST:

Now I understand why I thought h.264 was bad a low bitrates. It’s just because Apples’ h.264 implementation is bad.

I just tried with Avidemux and it works quite good. And it’s easy and the resulting video can be seen in Linux (I asume in quicktime too.

Here’s the sample.

Options: codec x264, no sound (it didn’t work and I didn’t want to investigate), two pass encoding, 44kbps, 2 filters just to resize and resample to 12 fps.


This is the admin speaking...
Eugenia wrote on March 24th, 2007 at 3:48 AM PST:

Yes, your output is pretty good.


ac wrote on March 24th, 2007 at 4:14 AM PST:


Reader AC re-encoded the video using the x264 encoder variant of h.264 and he came up with this very good quality at 58kbps. There is no audio in his video so we are not sure what the filesize would really be with some AAC in there, but for the resulted 870 KBs, I’ll bite.

IIRC the file was 850KB, but in either case the video bitrate was about 43kbps ( (43kb/s)/(8kb/kB)*150s = 806, the remaining 40kB are the container — like other things, mkv isn’t designed for 40kbps files, mp4 is and the file would be significantly smaller, about 825kB, but ais it messed up the fps here), not 58; the additional 3 kbps are to compensate the increased resolution — the bits/pixel/frame ratio isn’t all that different. This leaves about 24kbps for audio, if we want to make the target filesize. Does on2 ship their own audio codec or do they use aac, or something else?

The only x264 gui I like is SUPER. However, SUPER just doesn’t work with directshow (it fails to encode the mov video if it’s checked) and without directshow I can’t set a custom resolution.

Are you certain you have the necessary dshow filters to handle Quicktime with the Sorenson codec?
If yes, you can either get rid of QTA or use the graphedit file in my rar to override your default filter chain.

OTOH you can hardly blame SUPER, a program that according to your description seems geared for normal users, that it doesn’t support a very abnormal use-case.
Encoding stuff at half the framerate and 40kbps is just not something many joe averages need to do, they’d either use a streaming solution (like an inline youtube video) or a free filehost (like I did with rapidshare), both with much higher bitrates.

If anything you should compare VP7 and h264 with a better (and less proprietary) source at a more normal bitrate. Some current hd trailer redone at 440kbps or something (at about that bitrate a 2:30 trailer with 96kbps sound will need about 10MB)


Kronos wrote on March 24th, 2007 at 12:51 PM PST:

Say I want to use the VP7 or even H.264 to enable my little web site to host videos a la youtube, is that possible? what do I need?

Thanks.


Comments are closed as this blog post is now archived.

Lines, paragraphs break automatically. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

The URI to TrackBack this blog entry is this. And here is the RSS 2.0 for comments on this post.