VC-1 and H264

[weaver4]

Is there any web site that compare VC-1 and H264?

I am moving to DivX to either WMV9 or X264 and I want to encode my movies now so they will play on Stand-Alone-Players in the future.

It appears that both of these are going to be supported by Stand-Alone-Players in the future. But, WMV9 seems to have the edge if you want to encode now and ensure it will play on one of these players in the future. H264 doesn't seem to have the guidance to the SAP manufactures to tell them what specifications they should meet.

Anyone know of good reviews of video quality?

[Manao]

H264 is quite well standardize, and SAPs know what specifications they must follow ( bluray's and HDDVD's aren't far away from your everyday encodes, the biggest difference being the short GOP size, but that doesn't matter ).

VC1, as a standard, is less efficient that AVC ( it lacks CABAC, good intra prediction, reference bframe ). Would I guess, I'd say it translate to a 10 to 15% bitrate increase at same quality ( PSNR, which might not be perfectly suited here, since codecs are different )

But comparing standard isn't equivalent to comparing encoders - there I can't help you, I never used WMV9 encoder.

[Dark Shikari]

I used VC-1 on "better" to encode a recent EVE Online video I made (49 minutes, 1152x720 resolution for the WMV version). I don't normally use VC-1, but I wanted to give it as an option for people who don't want to download the an H.264 decoding codec set. This isn't a 100% accurate codec comparison, its just a recent experience I can share.

x264 settings were --ref 3, --subme 6, --trellis 2, and all the other usual high quality settings. WMV was "better" at twopass bitrate 1000kbps (as I didn't know what quality would yield what filesize due to a lack of experience with VC-1), x264 was CRF 30.

Encoding time, WMV took about 14 hours, x264 took about 3 hours or so.

Result: WMV was about 50% higher bitrate and had about 10% lower SSIM (about 0.957 vs 0.961 I believe, remember how SSIM scales before you say "that's not 10%").

You're going to need a lot more bitrate with VC-1 to equal x264, by a long shot. I'm guessing at higher quality levels the gap closes a bit, but still... in my honest opinion, VC-1 encodes too slow for too low of a quality to be worth using except if you're on a really slow computer for decoding, need to watch HD content, and don't have CoreAVC.

[benwaggoner]

Originally Posted by Dark Shikari

x264 settings were --ref 3, --subme 6, --trellis 2, and all the other usual high quality settings. WMV was "better" at twopass bitrate 1000kbps (as I didn't know what quality would yield what filesize due to a lack of experience with VC-1), x264 was CRF 30.

Encoding time, WMV took about 14 hours, x264 took about 3 hours or so.

Result: WMV was about 50% higher bitrate and had about 10% lower SSIM (about 0.957 vs 0.961 I believe, remember how SSIM scales before you say "that's not 10%").

Can you share what VC-1 settings and version you used (Advanced Profile? WMP11 dlls?)? That was a lot of detail on the H.264 encode, but not on the VC-1. That's a much, much bigger diffeence than I'd expect, both in encoding time and in bitrate. I expect somethign went askew in your VC-1 encode.

[Dark Shikari]

Originally Posted by benwaggoner

Can you share what VC-1 settings and version you used (Advanced Profile? WMP11 dlls?)? That was a lot of detail on the H.264 encode, but not on the VC-1. That's a much, much bigger diffeence than I'd expect, both in encoding time and in bitrate. I expect somethign went askew in your VC-1 encode.

I used the VBScript VC-1 encoder with presets that's popular here, with "fast", "normal", "better", "best" and "insane". I used "better".

[benwaggoner]

Originally Posted by Dark Shikari

I used the VBScript VC-1 encoder with presets that's popular here, with "fast", "normal", "better", "best" and "insane". I used "better".

Surprising there was that much of a speed difference. Did you do your preprocessing before encoding? What file format did you use for input? What kind of hardware were you running?

Also, for a real quality test, you should be doing "Best."

[benwaggoner]

Originally Posted by Dark Shikari

I used the VBScript VC-1 encoder with presets that's popular here, with "fast", "normal", "better", "best" and "insane". I used "better".

Reviewing the settings, it looks like you got:

Complexity = 3 (-v_performance 60)
Lookahead = 30 (-v_lookahead 30)
Loopfilter = On (-v_loopfilter 1)
Motion Search Level = Auto w/ Integer Chroma (-v_mslevel 0)
Motion Search Range = Auto (-v_msrange 0)
Motion Vector Cost = Dynamic (-v_mvcost 1)
B-frames = 1 (-v_bframedist 1)

To get a good quality encode without going crazy on performance, I'd do:

Complexity = 4 (-v_performance 8)
Lookahead = 0 (v_lookahead 0) - not needed with 2-pass encodes
Loopfilter = On (-v_loopfilter 1)
Motion Search Level = Auto w/ True chroma (-v_mslevel 4)
Motion Search Range = Auto (-v_msrange 0)
Motion Vector Cost = Dynamic (-v_mvcost 1)
B-frames = 1 (-v_bframedist 1)
Motion Match Method = Auto (-v_mmatch 0)
DQuant on I & P Frames (-v_dquantoption 2)
Adaptive Deadzone (-v_percopt 2)

and if you're seeing artifacts, use

Overlap filter (-v_overlap 1)

Also, since you're comparing with a quality VBR encode, make sure you're using

2-pass VBR (-v_mode 3)

Note that some of the above settings are for optimizing video quality not PSNR/SSIM, so you should compare the quality of the two encodes visually. And since you already have a H.264 encode at bitrate you like, go ahead and use the same bitrate for the 2-pass VBR VC-1 encode so you're at least controlling one axis of the comparison.

Also remember that your encode time comparison isn't particularly germaine, since you're comparing a 1-pass to a 2-pass encode.

Still, how much RAM is in your machine? The Lookahead parameter doesn't help in a two-pass encode, and can eat up quite a lot of RAM in a HD encode. That could slow you down some.

[weaver4]

Manao: OK, thanks for your input.

What profile would I use in MeGui or AutoMKV to encode x264 so that I am guaranteed that it will play on H264 SAPs in the future? Right now neither of these can do an encode that will work with Apple TV; a H264 player. (This info is a few months old, they may have one now.)

[benwaggoner]

Originally Posted by weaver4

I am moving to DivX to either WMV9 or X264 and I want to encode my movies now so they will play on Stand-Alone-Players in the future.

I didn't want to miss this in the incipent codec discussion war .

Really, the current encoders aren't shipping with explicit compatibilty modes for HD DVD or BD, so that really shouldn't be driving your short term decisions. There's a lot of tweaky compliance details in gettig a bitstream tuned to be compliant with either format.

That said, we should start seeing commercial products with HD Optical modes for VC-1 in a few months. Today that's only really available via our CineVision PSE product that Sonic is distributing for us.

[zambelli]

Let's also keep in mind that comparing x264 and WMV9 is just a comparison of two implementations and doesn't represent all H.264 and VC-1 encoders. A codec is only as good as its implementation.

[bond]

Originally Posted by zambelli

Let's also keep in mind that comparing x264 and WMV9 is just a comparison of two implementations and doesn't represent all H.264 and VC-1 encoders. A codec is only as good as its implementation.

i think comparing x264 with wmv9 is ok, as x264 is one of the best h.264 encoders and wmv9 is propably the only (?) vc-1 encoder existing

[benwaggoner]

There are actuallly diffferent implementations of VC-1 available to the public today. Format SDK 11. Tarari. The version of the codec used in the Inlet products. The non-PSE version of Sonic's CineVision. SMPTE reference code. Telestream's implementation used in FlipFactory, Episode, and Flip4Mac. Main Concept has one. There's some DSP implementations used by folks like VBrick...

And of course we've got newer stuff we've done post FSDK 11. And there's been three major releases of FSDK with VC-1 (9, 9.5, and 11).

[Sagittaire]

The non-PSE version of Sonic's CineVision use Mainconcept VC1 SDK ...

[PuzZLeR]

Is this thread about the quality difference between the two, or the long-term support comparison? Or how to encode for stand-alones? All distinct topics.

For stand-alones and H.264, stick with a common denominator of QT compatibility, a standard within a standard, and you won't go wrong, even if it costs a bit more bitrate. However, hardware will eventually catch up with MRFs, B-pyramids, etc in due time, even though they make several decoders choke today.

Don't care what Apple TV and iPod are accepting. These machines have obvious tech limitations, not restrictions on a standard. It's also Apple's way of skimming the market, making us keep buying the "next great exciting" model coming up... In 5 years time my phone will be playing all my encoded clips of today, with all the gravy, and it doesn't even have to be a phone from Apple either...

Personally, I would say that for better support you can't go wrong with an MPEG codec. H.264 is the latest face of MPEG. In fact it *IS* MPEG.

The only reason VC-1 even got this far is because its parade is led by M$, otherwise it would be scratching for a niche market like VP-7 and RV10 are.

H.264 is also an open standard, while VC-1 has proprietary characteristics. There is no "corporation" that owns H.264, and any support it gets is rather genuine, which is plenty. VC-1's support is biased, as is those comments from obvious backers of the big M.

Quality difference? Don't care. Even if VC-1 is "better" quality, which I have yet to see evidence of, it wouldn't be distinguishable enough to beat an MPEG codec.

[benwaggoner]

Originally Posted by PuzZLeR

H.264 is also an open standard, while VC-1 has proprietary characteristics. There is no "corporation" that owns H.264, and any support it gets is rather genuine, which is plenty. VC-1's support is biased, as is those comments from obvious backers of the big M.

What kind of proprietary characteristics are you thinking of? H.264 and VC-1 are both fully specified by a standards body (ISO or SMPTE) with the usual set of reference encoders and decoders, reference streams, etcetera. And both have similar patent terms, and have patent licensing handled by MPEG-LA.

Quality difference? Don't care. Even if VC-1 is "better" quality, which I have yet to see evidence of, it wouldn't be distinguishable enough to beat an MPEG codec.

Well, there's many flavors of "quality". PQ is one axis. PQ per MIPS is another. Installed base is another - clearly many more of the world's computers can play VC-1 out of the box than H.264.

It's never possible to say any codec is better or worse in the abstract. It's always comparing implementations and scenarios. Clearly there are places where H.264 is better (for example, playback on an iPod for example) and where VC-1 is better (for example, playback on corporate desktops, or in portable devices in software instead of via ASIC).

[Tack]

Originally Posted by benwaggoner

What kind of proprietary characteristics are you thinking of?

Past experience has certainly taught me to treat with great skepticism anything that comes from Microsoft, and even more so anything that Microsoft is pushing as a standard. (OOXML is one potent example.)

There is of course the pragmatic issue of platform availability. Can I encode VC-1 on Linux or OS X? (It's not a rhetorical question; I actually don't know, but I suspect not at least on Linux.)

Installed base is another - clearly many more of the world's computers can play VC-1 out of the box than H.264.

Ah yes, clearly. Because Microsoft is less interested in providing a seamless user experience than they are with pushing "standards" on which they have a firm, proprietary grasp.

The out-of-the-box media experience on Windows has always been ridiculously annoying. Certainly if you confine yourself to MS-blessed codecs (WMV, WMA) it's great. MP3 is supported, but only because of the sheer volume and demand. Microsoft missed the boat on MP3's popularity explosion -- not one to make the same mistake twice, VC-1 is Microsoft's answer to h264. I wonder why Windows doesn't support Ogg Vorbis out of the box? Are the licensing costs too high, perhaps?

Should you be unfortunate enough to have a file with an unsupported codec, like those unknown, esoteric, obscure ones such as xvid/divx, AC3, or h264 -- scantly used on the Internet and the AV/HT scene in general, to be sure -- then you are confronted with the ever-helpful dialog that consults MS's servers to download the codec, which I have never once seen actually work.

Ubiquity of VC-1 "on the desktop" is achieved only thanks to Microsoft's desktop monopoly. If you're a content provider and your motives are commercial in nature, then sadly your argument is valid. (I would still argue outweighed by other factors.) But otherwise, as with the case of the original poster, desktop penetration is moot, and in fact I would say the full transparentness of projects like x264 are an utterly compelling reason to embrace h264.

[Manao]

VC-1 was designed for HD and film content from the get-go, while H.264 only really became competitive in that arena relatively late with the addition of High Profile, created after VC-1 beat MPEG-2, and both beat H.264, in the initial DVD Forum HD tests.

Technically speaking, H264 main profile is superior to VC1 & MPEG-2 for HD. High profile is, of course, a lot better, because 8x8 transform is really a must for HD stuff, but even so, H264 MP outperforms both codecs.

However, when they did those tests, they may not have used a good h264 encoder. And it's easy to make a H264 encoder less efficient than Mpeg2. Look at ATI's software H264 codec...

So I'm interested in knowing what encoders where used for that DVD Forum HD comparison.

MPEG-4 Part 2 has been a great success

No. For the industry, Mpeg4p2 is a huge failure. The only success for Mpeg4 part 2 is that it's widely used by pirate. That doesn't make it a success Finally, mpeg4 part 2 is only ~20% more efficient than Mpeg2. Don't be fooled by the fact that you convert a DVD 9 to a 700MB CD to rate mpeg4's efficiency. DVD9 is an overkill, it has a GOP of 12, and professionnal mpeg2 encoders used for DVD aren't that good.

[benwaggoner]

Originally Posted by Manao

Technically speaking, H264 main profile is superior to VC1 & MPEG-2 for HD. High profile is, of course, a lot better, because 8x8 transform is really a must for HD stuff, but even so, H264 MP outperforms both codecs.

Superior in what sense? That's certianly not my experience, especially for contet with film grain.

Sounds like a promising option for doing some actual head-to-head testing!

[Shapierian]

Originally Posted by Manao

No. For the industry, Mpeg4p2 is a huge failure. The only success for Mpeg4 part 2 is that it's widely used by pirate. That doesn't make it a success Finally, mpeg4 part 2 is only ~20% more efficient than Mpeg2. Don't be fooled by the fact that you convert a DVD 9 to a 700MB CD to rate mpeg4's efficiency. DVD9 is an overkill, it has a GOP of 12, and professionnal mpeg2 encoders used for DVD aren't that good.

Slide 19 of http://www.ihollywoodforum.com/documents/IPTV/15.ppt shows certainly more than a 20% bitrate reduction.

MPEG-4 was only the current standard for a narrow windows. There weren't many standards between DVD and HD-DVD for MPEG-4 Part 2 to be adopted by. ASP was only finalized in 2002. I'll admit some of the more ambitious profiles of MPEG-4 did fail but certainly not SP/ASP. It also depends on what segment of the industry to which you are are referring. The stated goal of MPEG-4 was for streaming/mobile platforms so it's no surprise it wasn't adopted for broadcast use and the like. For video distributed over the internet: legitimate, illegitimate, or both MPEG-4 has been quite popular.

[Manao]

I must admit I'm mostly used to test TV content ( broadcast ), which is quite a lot more complex than movie, but which also is less grainy.

I must also admit I'm not a grain/noise addict, and that between ringing/blocks and sharp without grain, I'll choose the second any time.

And finally, I've never worked with anything higher than 10 mbps for HD stuff, and it may not be the bitrate at which the test was done.

That said, the encoder definitely matters. If the JM was used for the test ( gods forbid ), I can understand why h264 lost. JM is efficient, but doesn't have a good ratecontrol ( not even average ), and cares only about PSNR - which is completely the opposite of what is needed for keeping grain.

That's why I wanted to know what encoders were used for the comparison.