Question for codec developper about VC1, H264 and MPEG2 ratio

[Sagittaire]

Amirm on avsforum say:

DVD Forum, fully 3 years before either format came to market, did a double blind shoot out of codecs. MPEG-2 was bid by two companies. AVC I think by 4. And VC-1 of course by Microsoft. Tests were conducted at 7.7 mbit/sec, compared to uncompressed reference and MPEG-2 at 24 mbit/sec. VC-1 easily beat out all other codecs at the same 7.7 mbit/sec. Yes, this included MPEG-2. What's more, it matched the MPEG-2 reference at 24 mbit/sec on two clips I believe, and nearly matched it on the rest despite running at a third of the data rate. VC-1 would have never been accepted into HD DVD and later, BD, without beating MPEG-2. The blind test by the way, was conducted by many members of DVD forum from CE companies to studios.


DVDForum say that VC1 (here old and crappy wmv-hd implementation) is close to MPEG2 at 1:3 ratio. Joke or not. You can produce theorical answer about that or/and answer based on your experience.

[Dark Shikari]

A completely uninformed analysis of this would result in the conclusion that early implementations of H.264 were awful (true) and that VC-1 was good.

Of course, given how laughably awful the early implementations of VC-1 were as well, I would conclude "joke."

[Sharktooth]

BS. 3 years ago... and i guess they tried the first crappy AVC implementations.
In my experience the difference is M$ VC-1 is slightly better than DivX/Xvid (or other good Mpeg4 ASP implementations), but not always! while actual good implementations of h.264/AVC (like x264, elecard, etc) are another story. They're not even comparable to VC-1.
That's it. Sure, at ultra-high bitrates all codecs are the same (at least the good ones)... but remember that video compression is a science that wants to obtain a result as similar as possible to the souce at the lower as possible bitrate.
If DVD forums says VC-1 is better than h.264, then they need to conduct new tests with recent implementations... and consequently change their mind.

[cacepi]

A completely uninformed analysis of this would result in the conclusion that early implementations of H.264 were awful (true) and that VC-1 was good.
Or that Amirm was, at the time, a Microsoft employee (http://www.microsoft.com/presspass/exec/amirm/default.mspx) with a product to sell.

[Dark Shikari]

Or that Amirm was, at the time, a Microsoft employee (http://www.microsoft.com/presspass/exec/amirm/default.mspx) with a product to sell.That would explain it ;)

Also, note that "double blind" is totally useless for video encoding because you can trivially tell which video is which from the resulting output.

[Sharktooth]

i have no doubt VC-1 at that time was more mature than h.264.
h.264 was a completely new standard while VC-1 is basically MPEG-4 ASP with some additions and without the useless stuff like GMC...
so the VC-1 development was obviously faster.
but telling ppl VC-1 is better than h.264 is a complete nonsense. the comparison was made between early h.264 implementation and almost mature VC-1... not between standards.
on the paper h.264 is superior... and now, h.264 is superior even in practice with awesome implementations. And still there is a lot of room for improvement, while VC-1 is almost "done".

[Inventive Software]

A completely uninformed analysis of this would result in the conclusion that early implementations of H.264 were awful (true) and that VC-1 was good.

Of course, given how laughably awful the early implementations of VC-1 were as well, I would conclude "joke."

VC-1 started out as WMV9, which has been around for at *least* the last 5 years. It's good at certain things, and absolutely rubbish at others. ;)

[Dark Shikari]

VC-1 started out as WMV9, which has been around for at *least* the last 5 years. Even Benwaggoner has gotten quite a lot of mileage out of stating how bad the original Windows Media Encoder from 2003 was, and how much they've improved it with the new VC-1 SDK ;)

[Sagittaire]

No comment about 1:3 ratio for VC1/MPEG2 ...?

[*.mp4 guy]

That would explain it ;)

Also, note that "double blind" is totally useless for video encoding because you can trivially tell which video is which from the resulting output.

Thats really only true of people who have extensive experience with video encoding. It's surprising how much trouble some people have picking out distinguishing features of compressed video.

No comment about 1:3 ratio for VC1/MPEG2 ...?
from the results, I assumed that the tested videos were all standard definition, or were stupidly compressable, its the only explanation of how vc-1 could ever be nearly indistinguishable from mpeg2 at 3x the bitrate.

[Dark Shikari]

Thats really only true of people who have extensive experience with video encoding. It's surprising how much trouble some people have picking out distinguishing features of compressed video.Sure, but such tests are often done among video experts, compounding the problem.

[*.mp4 guy]

Sure, but such tests are often done among video experts, compounding the problem.

Well, the same problem aplies to a large extent to image encoding (its trivially easy to spot the differences between jpeg, jp2k, laplacian pyramid and fractal compression) and audio encoding. The only time double blind testing is really tamper proof is when you skimming the transparency threshold.

[Sharktooth]

dont forget VC-1 has pre-processing. it will rise compression quite a bit... and it's NOT part of the encoder.
when you denoise your source and then encode with any other codec it's obvious you gain more compression. even a simple undot() (that's almost unnoticeable) will help the encoder by a fair amount.
i dont think the test was fair for h.264 though, coz M$ put pre-processing in all their encoding applications and i have my fair amount of doubts the same pre-processing was used for other encoders than VC-1.

[CruNcher]

It's the same when X264 development started Visualy XviD could easily beat it because of the bugs and other problems nowdays even the Look & Feel of XviD can be reproduced entirely so you don't get that blurry look anymore, and since Dark Shikari appeared on the X264 Stage alot improved visualy especialy for Film Source :). And sure back then i think FreXt wasn't ready and Microsoft could easily beat H.264 back then with there Adaptive Transform in the STEM test nowdays this is history. But it's true without VC-1 there wouldn't be a H.264 High Profile (nor most probably FGM) if the Studios didn't complain about the Grain problem.

[Gabriel_Bouvigne]

If that was 3 years before HD-DVD and BD were introduced into the market, that should be about 5 years ago.
To me it sounds very possible that the best WMV9 (there was no VC-1 5 years ago) implementation could have been better than the 4 H.264 implementation that were then tested. (one was likely from FhG, which are the 3 other ones?)

[Golgot13]

Sure, but such tests are often done among video experts, compounding the problem.

About expert, to be an "expert" of DVD Forum you must be a member of DVD Forum
and it's not free. It's very expensive so there are not all true video expert on it.

And I prefer the word "video specialist" of DVD forum member.

About test comparison, the test are/were generally reserved at member of DVD Forum...

So you can understand why the MPEG2 at 24Mbps was bad (and the best H264 companies were not present at this comparison).
Don't forget that some company produce bad MEPG2 HD file with a high bitrate (I don't talk about bad video source but about macroblock,..)
eg: Sony and some MPEG2 BD title... (US guys after think that VC1, when they saw good work of MS on VC1 HDDVD, is the best codec).

[R3Z]

The thing that irks me about VC-1 and just about anything Microsoft does.... is that they release something early with promise and then we never hear about it again untill it dies out. Obviously VC-1 could be something really good and a competitor to h264, but lack of work and follow up just makes it a door stop.

[Dark Shikari]

The thing that irks me about VC-1 and just about anything Microsoft does.... is that they release something early with promise and then we never hear about it again untill it dies out. Obviously VC-1 could be something really good and a competitor to h264, but lack of work and follow up just makes it a door stop."VC-1" is actually just WMV9. WMV9 was designed as a successor to Microsoft's MPEG4 implementations, for the purpose of beating Xvid, DivX, etc. And thus it did--it was a "next generation ASP codec."

But then H.264 came out, wiping the floor with VC-1 (http://forum.doom9.org/showpost.php?p=1156582&postcount=21). Instead of trying to improve the standard to keep up with the times (or perhaps knowing they couldn't), Microsoft repurposed WMV9 to compete with H.264... by changing their marketing strategy. Not by actually updating the format, but by changing its name.

This doesn't work very well.

[R3Z]

"VC-1" is actually just WMV9. WMV9 was designed as a successor to Microsoft's MPEG4 implementations, for the purpose of beating Xvid, DivX, etc. And thus it did--it was a "next generation ASP codec."

But then H.264 came out, wiping the floor with VC-1 (http://forum.doom9.org/showpost.php?p=1156582&postcount=21). Instead of trying to improve the standard to keep up with the times (or perhaps knowing they couldn't), Microsoft repurposed WMV9 to compete with H.264... by changing their marketing strategy. Not by actually updating the format, but by changing its name.

This doesn't work very well.

It just strikes me as lazy. I am thankfull for the work people such as yourself do though :). Everyday i have less and less faith that these big companies can do anything except serve their own interests.

[Dark Shikari]

It just strikes me as lazy. I am thankfull for the work people such as yourself do though :). Everyday i have less and less faith that these big companies can do anything except serve their own interests.H.264 was designed primarily by "big companies" too ;)

[CruNcher]

Jep imho the only Codecs that will be able to compete currently with H.264 will be VP7,NGV(if it comes out) and Dirac(most impressive of all of them in my eyes) on the technical sides i see no other that could currently :) (except maybe Cineform if it would decide to go away from intermediate to a full solution same for Red Cinema) (but all of them will have to stand against H.265 then so their needs to be another generation of them allready to beat that (multi company research again). Im 99% sure that with H.265 tough the time of Block Based approaches will be over :)

[Gabriel_Bouvigne]

Im 99% sure that with H.265 tough the time of Block Based approaches will be over :)
You might be disapointed...

[*.mp4 guy]

Block based aproaches offer a lot of advantages over full frame aproaches, some of them are relatively new developments aswell.

for instance, block based advantages:
-Use of IIR filters instead of FIR filters for intra prediction, etc. (IIR are better speed/quality)

-The DCT has the best energy compaction properties of any known linear transform, DCT requires blocks for efficient implementation
*more efficient gradient compression
*more efficient texture and noise compression

-Block based allows for easily implemented frame partitioning, and area adaptive encoding, such as use of multiple transforms and transform sizes, certain rate distortion optimisations are more easily implemented, psy optimizations, such as aq are more easily implemented.

Inloop filtering removes blockiness, and ringing (not quite as) effectively, wavelet artifacts are more dificult to remove in post processing (low frequency "aliasing", for lack of a better word, artifacts from wavelets, would require Huge filters to remove)

-blockbased transforms are much more insensitive to motion compensation artifacts, since they don't have to deal with the block edges introduced by motion compensation; this is why whole frame compression methods use much more blocking resistent motion compensation methods, usually at very high complexity costs.

-Wealth of pre existing, easily reworked technology, research and infrastructure.

Wavelests have their merits, but imo, they aren't the clearly superior technology, a block based aproach is not necesarily a bad thing.

[akupenguin]

-The DCT has the best energy compaction properties of any known linear transform, DCT requires blocks for efficient implementation
The KLT has the best energy compaction properties of any known linear block-based transform. For typical image content, DCT is a good approximation of KLT. Both can be generalized to overlapped blocks, which also allow reasonably efficient implementation.
The framework in which KLT is proven optimal assumes a stationary distribution, which isn't really a good assumption. It implies that large DCT is always better than small, which is obviously false in real application of h264.
Blocks make it easy to partition the frame into approximately-stationary regions and pick a different transform for each. But this is possible for overlapped or multiscale transforms too. And I'm not entirely sure on this part, but multiscale might allow fewer different transforms for a given quality.

psy optimizations, such as aq are more easily implemented.
Snow doesn't currently implement spatially-localized QPs, but there's no reason it couldn't. AQ should be just as simple.

wavelet artifacts are more dificult to remove in post processing (low frequency "aliasing", for lack of a better word, artifacts from wavelets, would require Huge filters to remove)
Huh, the only wavelet artifact I've ever noticed is ringing.

blockbased transforms are much more insensitive to motion compensation artifacts, since they don't have to deal with the block edges introduced by motion compensation
I prefer to phrase it as: Transforms that don't accidentally code blocks also doesn't easily code blocks on purpose. So yes, you have to upgrade your MC algorithms at the same time.


... not that I expect blocks to go away soon. MC speed and IIR are big reasons.

[Dark Shikari]

Huh, the only wavelet artifact I've ever noticed is ringing.You're forgetting the most common one: blurring ;)

[*.mp4 guy]

The KLT has the best energy compaction properties of any known linear block-based transform. For typical image content, DCT is a good approximation of KLT. Both can be generalized to overlapped blocks, which also allow reasonably efficient implementation.
The framework in which KLT is proven optimal assumes a stationary distribution, which isn't really a good assumption. It implies that large DCT is always better than small, which is obviously false in real application of h264.
Blocks make it easy to partition the frame into approximately-stationary regions and pick a different transform for each. But this is possible for overlapped or multiscale transforms too. And I'm not entirely sure on this part, but multiscale might allow fewer different transforms for a given quality. A few points, the DCT is actually the optimal KLT transform for a specific set of data (the set that the KLT is most optimal for iirc, sorry to be vague) furthermore, the KLT is not what I would consider linear, because the basis vectors are not fixed (I consider them to be nonlinear, because each separate KLT transform will have different basis vectors, and thus, pixels will be treated in a non-linear manner) The non-fixed basis vectors make the KLT dificult to use for compression, because you would have to send data explaining the different vectors used by each KLT transform along with their coeficients, its also crazy slow, putting all of these together, I do not consider the KLT to be in anyway comparable to the DCT as a linear transform for use in compression, though it is technically slightly more optimal in some ways.


Snow doesn't currently implement spatially-localized QPs, but there's no reason it couldn't. AQ should be just as simple.I didn't say it wasn't possible, or even easy, but if you look at the number of wavelet codecs with spacially localized aq (0 iirc) and compare that to the number of block based codecs with aq (more then I would try to count) I think it is clear that it is more dificult, If only perhaps because wavelets are more dificult in general.


Huh, the only wavelet artifact I've ever noticed is ringing.Wavelets suffer from aliasing across the entire frequency spectrum, it is very hard to remove these artifacts, because many of them are very low frequency. It is a direct result of the short spatially localised wavelet transforms themselves, combined with the short (so as to avoid ringing, and be efficient) filters used to separate the wavelet sublevel decompositions, both of which provide poor frequency separation.
[edit]: Image example (http://img148.imageshack.us/img148/3168/aliasingln6.jpg), areas of interest in cyan boxes.

[akupenguin]

I didn't say it wasn't possible, or even easy, but if you look at the number of wavelet codecs with spacially localized aq (0 iirc)
JPEG2k

[foxyshadis]

Wavelets suffer from aliasing across the entire frequency spectrum, it is very hard to remove these artifacts, because many of them are very low frequency. It is a direct result of the short spatially localised wavelet transforms themselves, combined with the short (so as to avoid ringing, and be efficient) filters used to separate the wavelet sublevel decompositions, both of which provide poor frequency separation.
[edit]: Image example (http://img148.imageshack.us/img148/3168/aliasingln6.jpg), areas of interest in cyan boxes.

That's more of a multiscale artifact from the bilinear resize used as jpeg2k's scaler. Wavelets ring or blur but generally don't cause aliasing, at a single scale. Someday hardware might be powerful enough to use something like nnedi as a scaler in realtime video. ;)