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.

[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 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.

[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.

[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.

[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.

[benwaggoner]

Originally Posted by Tack

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.)

This is a technical forum - I think it'd be more useful if you could bring up some specific examples of anything you object to in either the standard or the license. Companies like Main Concept have done their own implementation of VC-1 without any involvement from Microsoft without any issues.

As for OOXML, I think most of the criticisms miss the fact that its primary goal is to provide a XML implementation that's backwards compatible to all existing .doc files, which introduces painful complexity. You might argue about whether or not that's worth doing, but for enterprises that want to take their existing past few decades of .doc content and make them searchable in a structured way while preserving the layout precisely, OOXML is a great solution.

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.)

Sure. Telestream's Episode and Flip4Mac products encode WMV with VC-1 on Mac. Those can plug into other tools, like Compressor and Squeeze.

As for Linux, I think there are some embedded VC-1 solutions using derivatives of the VC-1 Porting Kit (portable C++ implementation we license). And there's some Summer of Code thing going on:

http://wiki.multimedia.cx/index.php?...r_Of_Code#VC-1

And I'm sure someone's working on xVC1 somewhere, based on the SMPTE reference implementation. Since Microsoft doesn't control either the specification or license, we only hear about projects are they are announced just like everyone else.

The out-of-the-box media experience on Windows has always been ridiculously annoying...

Well, yes, only a very small percentage of users are watching anime fansubs and that kind of stuff, and there are readily available 3rd party players for those who are interested. Given how many formats and codecs there are out there, I hope you can understand why we don't take on the development and particularly test hit of getting everything working. There's an extremely high bar for security and stability for anything bundled with windows.

[Shapierian]

Originally Posted by benwaggoner

Well, yes, only a very small percentage of users are watching anime fansubs and that kind of stuff, and there are readily available 3rd party players for those who are interested. Given how many formats and codecs there are out there, I hope you can understand why we don't take on the development and particularly test hit of getting everything working. There's an extremely high bar for security and stability for anything bundled with windows.

But it is kind of funny that Microsoft that produced a reference implementation of MPEG-4 and considering the ubiquity of MPEG-4 that windows doesn't support it out of the box.

[PuzZLeR]

Hello Ben,

I know there’s about a dozen other “organizations”, or rather “corporations” behind it, but VC-1, although officially “open standard”, has the, albeit indirect, profitable goals, motives and characteristics of a proprietary format, and this is just another example of M$’s second-mover status – where something of merit is introduced into our mainstream and then the Big M yelps “Me too!” Instead of properly employing its status as the world’s most widely used O/S, where it should warrant some responsibility to embrace a standard, M$ instead leverages its advantage by unleashing something to compete against it unfairly … again. Of course, since (pun intended) Gates holds the gates with his operating system, and regardless of quality, or lack-thereof, from any M$ product, this time disguised, as “the standard”, it will still sadly get a wider-than-deserved attention, especially when it will be “pre-packaged”, and bullied on us with a unilateral premise, with added excuses of some over-abundance of existing codecs - and “an extremely high bar of security”, which apparently includes the standard of H.264 - an implication that it's a "trivial" codec that may also be a "threat".

Yeah, whatever.

Well, Ok, yes, it's a "threat" alright, but we all know what that "threat" to the Big M really is. As for “security” – I would call it INsecurity, a trait commonplace among the bully behavior.

Now instead of enjoying H.264, a common video format standard, widely portable, with high quality/compression that intends to be fluidly compatible universally among all platforms, we have to now put up with another M$ entry for no beneficial reason whatsoever to the industry - an analogy similar to that of a spoiled brat rich kid, living off a stolen heritance, that wants to play too with ONLY his/her crappy toys that the estate’s owner manufactures…

Ben, I do however respect your stance with Microsoft, and appreciate what you’re doing, but you will not be without challenge in this forum. And I won't insult you with fluff either.

But if you’d like to discuss “technical” comparisons in this forum, which may or may not be what this thread is about, as of this writing, the implementations of H.264 clearly outperform those of VC-1 for good reason beyond a head start. I see very little that VC-1 offers other than “faster processing” (such as decoding) – an “issue” that can easily be considered short-term and an “advantage” that will be negligible, and laughable, as hardware further progresses towards the world of HD. The law of diminishing returns will certainly apply to VC-1 as newer methods are developed into the H.264 standard – 4:4:4, lower bitrate encoding, chroma, etc on top of features like CABAC currently – none of which exist, or will exist, with “VC-1” as is.

Actually, I lie. Yes, H.264 does have this VC-1 “advantage”, and impersonation. It’s called BASELINE.

Don’t worry folks. This is one M$ joke that will definitely reveal lucidity and implode and choke and this will be a case based purely on the tangibles of the intangible – pure product features. My vision as a marketing administrator? VC-1 will still be around, and will boast this-and-that to those who will listen, but as H.264 further progresses M$ will lead us into yet ANOTHER new codec to compete… again, this time with their WMMVM4XVMV10VC2-whatever…but this time the general public, unless it’s not already doing it, will just roll back its eyes and sigh…

Thank you... methinks I'm done with this thread...

Geordie, BSc, CompSci, MBA
Finance & Electronic Marketing Concentration
Marketing Administrator

[bond]

here you can check the patents owned by specific companies like microsoft on avc and vc1 and the licensing terms of avc and vc1

as you can see microsoft owns more patents in avc than in vc1 (just counting the amount, not looking into the details)
the licensing terms for avc and vc1 are pretty similar, with vc1 having higher overall caps, so imho for big producers being slightly more expensive
-> therefore i think microsoft might earn on the patent side the same with both formats any maybe even more with avc

this leaves the implemenation side:
all in all vc1 has been imho created because microsoft creates own "standards" as a business model using their strong standing in the os sector (and therefore media player sector) to push this "standard", exlcuding competitors.
in the vc1 case they have been forced by the dvd/bluray bodies to make the prior closed vc1 "standard" an open standard, harming microsoft's tactic of exlcuding competitors but still being better than being not included in hddvd/bluray


in the end in the vc1 case imho it would have been better for the industry, the end customer and propably even microsoft if ms would have pushed avc right from the start, using their os standing to push THEIR avc implementation and not some extra implementation of a different open standard