VC-1 and H264

[Golgot13]

@Golgot13
How often again Hollywood Studios rated on Visual Quality and the H.264 implementation they chose @ the time of their STEm tests wasn't tweaked for that.

Yes, old implementation: Toshiba, Panasonic and Sony H264 encoder
(it's like to compare Intel H264 with Ateme).

Sonic Encoder is optimized for Film Grain when Mainconcept develop a good new SDK:
CineVision 2.0 is "good" to be compare with CineVision PSE (PEP 1.06 core)
available only this year, 3-4 months ago, so no tested by this studio.

@CruNcher: I recommand you to go at next Ceatec to see good H264 uses (HD DVD and Bluray
which use last H264 encoder; you will see may be UHD from NHK and Ateme in H264 not VC1).

Here with test the quality of codec, for this we need measure tool not subjective result.
Bobololo "said" at some show (or private test for authoring/video house):
"you can demonstrate anything and especially things"
You need a nice place, nice food, nice person,...=> after everything is beautifull.

[CruNcher]

@Golgot
Yes i know Atemes implementation and look & feel very well i beta tested it (found some bugs) and made the sugestion for a adaptive deblocking back then and i liked it @ that time the most of all dunno how it advanced as i have no acess to it @ the moment but it should be very very far from the others now @ that time it was allready more advanced (look & feel wise) then any other implementation (x.264, elecard) and even NeroDigital should have reached my old beta encoder now im surely gonna check this sometime, but for the moment i think of how to improve the look & feel of x.264 and especialy how it will compare to the look & feel of XviD 2.0 AVC when it's being released, so maybe it makes no sense todo this now but just wait first.

[Golgot13]

@ CruNcher

Last year, professional H264 encoders (except Mainconcept familly and Ateme) were not
optimized to give the best possibility of H264 standard.

If you have access at some solutions, you can try to encode at 10Mbps, you will be surprise
by the quality (can not be compared with x264).

Open Source accelerate the development of optimization because the community is high (thanks
lot of at schools, universities, teachers and students who give time and best solution code)
and x264 is one of this development.

[CruNcher]

Yep Golgot but we shouldn't forget that Fenrir left to Ateme and took all his knowledge with him improving their encoder with a biger team (very specialized) and even that aku and all the others do big here improving x264 fenrir is missing only that's why Ateme could overun x264 so fast, but it was fenrirs decission todo so now we have to get back on track aku would say now: "Don't talk so much CruNcher code" ;) anyway if you compare x264 resource wise vs Ateme and Mainconcept/Elecard x264 does pretty good and for sure is gonna grow in the next half year im sure as soon as XviD 2.0 AVC is released we gonna see Visual Quality improvements on both sides by shareing their knowledge :) in my eyes the biggest improvement x264 has done over the years is speed sooner or later it will be time to optimize Visual Quality and i think that time is coming :P (But i really have to say it's to early to compare x264 vs VC-1 in terms of Visual Quality it isn't mature enough yet, in sense of optimal Detail Preservation not in the Sense of optimal Metric Quality ;) )

[Sagittaire]

Since i did XviD PSNR Lab and all the Visual tests with it (long time ago) i lost my interest in Metrics they aren't efficient enough in such fine Scenarios as HVS tweaking they can give you a clue about the overal quality and are nice to find bugs sure (Rate Controll) but they never gona replace blind tests and also SSIM is far from being perfect on the Motion Aspect your SSIM results are nice but they don't say much in numbers about the look and feel of the final encode (actually it does currently SSIM prefers the blurry look over the sharp detailed one you can clearly see this with inloop deblocking it gets more artificial the higher an SSIM likes it ), and with this Source (as good as i find that it's openly available) we can't proof much. I would even go so far and say a Grainy Blu-Ray Mpeg-2 Source would be better for this then this Animation Source (and i also have allready 1 Source in target but i still need to test some stuff) :P

1) In my memory your delta for OPSNR was something like 0.2 or 0.3 dB. With this little difference you can't conclude. But if you have 2 dB for delda then all the possible HVS optimimisation can't reduce the visual difference. You must use PSNR and the other metric with good confidence threshold and 0.5 dB is not a good confidence threshold.

2) The optimal inloop setting for PSNR is 0,0. The optimal setting for SSIM is -2,-2. I don't see test to prove that SSIM prefere blur over sharp. SSIM prefere simply source convergence and SSIM can detect blur.

3) The best BD source available are AVC encoding at very high bitrate (35 Mbps). "Casino royale" source has incredible grain retention level. "Pirate des caraibes" is actually the reference stream for the BD fan.

[arfster]

Yes, as you say in the Bluray world the best discs are AVC at gigantic bitrates. However, oddly enough at lower (HDDVD) bitrates AVC seems to struggle a little compared to VC1. Rather the opposite of what seems to be the case here.

I guess it might be just the compression tools need to be absolutely top notch to compress heavily down <20mbit, where with Bluray peaks up to 50mbit in PotC it doesn't matter so much.

[Sagittaire]

Yes, as you say in the Bluray world the best discs are AVC at gigantic bitrates. However, oddly enough at lower (HDDVD) bitrates AVC seems to struggle a little compared to VC1. Rather the opposite of what seems to be the case here.

HDDVD don't use H264 at this time. Anyway I make HDDVD9 backup with BD50 "casino royale" source for test the quality. An I have a very good quality and good grain retention level. x264 can keep very well the big grain but it's really more difficult for small grain. You must use particular filter in pre-process to help x264 with grain retention.

[arfster]

HDDVD don't use H264 at this time.


Not many, but there are some - I have Equilibrium and Babel for example, and there are more coming out all the time.

[Golgot13]

Not many, but there are some - I have Equilibrium and Babel for example, and there are more coming out all the time.


If some people read my post about VC1 and H264 (on doom9 and AVS),
you saw my little reflection between this 2 formats:

VC1 is the best codec for BluRay because it need more bitrate to give nicely picture and use a little part of CPU.
H264 is the best codec for HD DVD because the space is limited (video in AVC and all audio in lossless codec).

[CruNcher]

Some scenes of Casino Royale have been shoot digital (HDCAM) and the grain looks different (artificialy added) then with the Analog shooted scenes that are Digital Intermidiate some scenes have no grain @ all (effect shoots) :P
Don't think it's good to test with that and also it is H.264 that would give an advantage to H.264 codecs recompressing it.

[Golgot13]

Some scenes of Casino Royale have been shoot digital (HDCAM).

HDCAM is a very bad format !!!!
Lot of informations are lose with HDCAM support (not HDCAM SR).

[CruNcher]

Yep the most impressive source i saw the last times now (now you gonna lough) but that was "Herbie Fully loaded"
Imho Disney does the best Digital Intermidiate @ the moment of all Studios :P (so it doesn't wonder me that Pirates looks as good or better)

http://img207.imageshack.us/my.php?image=snapshot20060806011746oj1.png compressed (720p) from a compressed source (HDTV Mpeg-2 1080i) (lol)
http://img207.imageshack.us/my.php?image=snapshot20060806012724nq1.png (can't wait for the Blu-Ray)
http://img206.imageshack.us/my.php?image=snapshot20060806011226sb5.png (can't even imagine how this looks uncompressed but the Blu-Ray AVC should come near it)

[Golgot13]

Imho Disney does the best Digital Intermidiate @ the moment of all Studios :P (so it doesn't wonder me that Pirates looks as good or better)


Disney use H264 for BD Titles, and it is a Hollywood Studio which choose H264 and not VC1 :D

[CruNcher]

hehe yeah but Disneys Transfers have no grain they are cristal clear (You could say New Age Hollywood away from the Grain into the Digital era) ;)
alot of studios and Directors wan't the possibility to simulate that Grainy old unreal Hollywood look (Universal,Warner, MGM and Sony) especialy for their old Blockbusters think about Blade Runner as Cristal Clear as Disneys transfers hmmm ;) for the new Generation that doesn't know the Movie it would be cool but for the old Generation it would look strange) :P and artisticly that's fine Disney is one of the Studios that doesn't wan't this old Grainy Hollywood look anymore most probably because they come from Comics and the look in their Company was allways cristal clear and never Grainy and this Philosophy they bring to Blu-Ray and that's for sure why they use H.264 optimal non Grainy transfers and you can see especialy the younger Generation likes that rating every Disney Blu-Ray with 5 stars :P
All their Transfers seem to be ultra compressable and it makes no real difference what source their Digital Intermidiate Process seems to kill any noise/grain and without that it's clear that H.264 will win for them over VC-1 then the SSIM/PSNR results of Sagittaire make sense again in that case so you never gonna see Disney useing VC-1 :)
on the 14th August Premiere HD is gonna Broadcast "Herbie Fully Loaded" in H.264 this will for sure top the 1080i Mpeg-2 Broadcast, won't also be that far away from the Blu-Ray but the Blu-Ray jesus should top everything (Pirates not it has much more colors bright sunshine scenes watter everywhere and great actors :P) we gonna see.

[bobololo]

Yep Golgot but we shouldn't forget that Fenrir left to Ateme and took all his knowledge with him improving their encoder with a biger team (very specialized) and even that aku and all the others do big here improving x264 fenrir is missing only that's why Ateme could overun x264 so fast, but it was fenrirs decission todo so now we have to get back on track.

Please Cruncher, don't claim things you absolutely don't know about. Fenrir has obviously contributed to our H.264 encoder but it would be unfair for all other contributors from ateme to associated the progress of our implementation to the key person of Fenrir.

You know, when Fenrir joined us (may 2004) we were already working on our 2nd generation of AVC encoder which was already more advanced than x264. Only 2 months later we started our first beta program based on this 2G encoder which development started long before Fenrir arrival.

If *you* remember correct, by that time the development of x264 was more of less stalled. Fenrir hadn't have much time to spend into it and he was the only active developer. x264 features was not so advanced by that time (the RDO was only brought by aku later) and most of the people were still backing xvid "supremacy" ;) This is only in mid-2004 (according to x264 repository) that x264 got back to life through a bunch of fresh commits from aku. Curiously this corresponded to the same time frame when we led the first beta test of our encoder. A naive person would have say that the reports from the beta had generated enough interest to make oss devs have their hands on H.264 standard following our track ;)

aku would say now: "Don't talk so much CruNcher code" ;) anyway if you compare x264 resource wise vs Ateme and Mainconcept/Elecard x264 does pretty good

And I 100% agree with Aku, you definitely speak too much ;) And especially about things you really don't know. I can insure you that you're far to understand and imagine the resources and constraints we could have along all the different project we're dealing with. So please stop propagating erroneous ideas.

[CruNcher]

Please Cruncher, don't claim things you absolutely don't know about. Fenrir has obviously contributed to our H.264 encoder but it would be unfair for all other contributors from ateme to associated the progress of our implementation to the key person of Fenrir.

Sorry if it sounds to you like i discredit the achivements the other devs brought to the Ateme Encoder that was absolutely not my intention the same also not on X264s side, that's why i wrote "with a biger team (very specialized)" <- this was actually thought as honouring the whole teams (every single person including your) achivements for the Ateme Encoder then to discredit them, and i think you know me (virtual) good enough that i wouldn't do anything else then that in this case :)


x264 features was not so advanced by that time (the RDO was only brought by aku later)

Yes i know this very well :)


and most of the people were still backing xvid "supremacy" ;)


At that time it was a close race (and at high bitrates it still is) ;)


And I 100% agree with Aku, you definitely speak too much And especially about things you really don't know. I can insure you that you're far to understand and imagine the resources and constraints we could have along all the different project we're dealing with. So please stop propagating erroneous ideas.

Yes true i don't know how resources being managed @ Ateme so sorry for speculateing here that was indeed not right forget that sentence about (if you compare...) but it's not 100% wrong as your advancements in this area proof that you steadily working on the Encoder don't ya ? (btw i never made it to crash nvidias display driver with playing back Video but with a stream by bobor from Luxe HD i get a BlueScreen with any player) Luxe HD useing the Ateme Hardware Encoder don't they ? (LUXETV.HD.Eutelsat.W3A.7E.10jul.2007-crash.ts)

[zambelli]

Open Source accelerate the development of optimization because the community is high (thanks
lot of at schools, universities, teachers and students who give time and best solution code)
and x264 is one of this development.
Like I've said many times before, I would LOVE to see an open-source encoder project for VC-1. If we can all at least agree that VC-1 specification is capable of producing better implementations than MPEG-4 ASP, it's hard to explain why there's such strong community support for XviD MPEG-4 ASP development but absolutely none for VC-1 development. Given that most HD-DVD titles are VC-1 encoded (and would thus naturally lend themselves better to VC-1 re-encodes), you'd think enough people would be interested in developing a VC-1 encoder superior to Microsoft's WMV9 to serve their HD-DVD backup interests. But I suppose it's always easier to just complain and go with the pack than actually sit down and write new code.

[Sagittaire]

Like I've said many times before, I would LOVE to see an open-source encoder project for VC-1. If we can all at least agree that VC-1 specification is capable of producing better implementations than MPEG-4 ASP, it's hard to explain why there's such strong community support for XviD MPEG-4 ASP development but absolutely none for VC-1 development. Given that most HD-DVD titles are VC-1 encoded (and would thus naturally lend themselves better to VC-1 re-encodes), you'd think enough people would be interested in developing a VC-1 encoder superior to Microsoft's WMV9 to serve their HD-DVD backup interests. But I suppose it's always easier to just complain and go with the pack than actually sit down and write new code.

Well I think that for many developper VC1 = MicroSoft and MS is not really popular in the Open Source world. It's strange because MPEG is not really a philantropic organisation.

[zambelli]

Well I think that for many developper VC1 = MicroSoft and MS is not really popular in the Open Source world. It's strange because MPEG is not really a philantropic organisation.
Thank you, I'm glad I'm not the only one who sees the paradox of it. Too many people forget that it's mostly representative of corporations (many of them more powerful than MS in the media industry) that sit on MPEG commitees. The idea that MPEG-4 is somehow more "open" and "free" (!!!) than VC-1 is just absurd.

[burfadel]

There may be a time when x264 and xvid AVC merge. In the free AVC codec world, only one will survive, and I think that may be the xvid implementation as they already have the name behind them. If this does happen, since both are open source they can pool their knowledge and code :)

[Dark Shikari]

Thank you, I'm glad I'm not the only one who sees the paradox of it. Too many people forget that it's mostly representative of corporations (many of them more powerful than MS in the media industry) that sit on MPEG commitees. The idea that MPEG-4 is somehow more "open" and "free" (!!!) than VC-1 is just absurd.
The difference is that MPEG has a long history and is supported by many many corporations whose main agenda in creating MPEG-4 is to make their standard as widely used as possible, for the benefit of everyone involved. This means that no single company is monopolizing it all.

VC-1 is created by Microsoft to benefit Microsoft and nobody else.

[foxyshadis]

The patent distribution would belie that. We know you don't like or trust microsoft, you've said as much, but until you can come up with some kind of proof that microsoft is acting any differently than all the other media companies looking to pad their bottom line ("the common good" does not exist for corporations), or that Microsoft is preventing 3rd party implementations, don't start a baseless flamewar.

I was wondering again, after seeing the snow thread, why Microsoft hadn't created a range coding alternative to CABAC in advanced profile. You'd get almost all of the benefit with less than half the cost. Then it truly would rival h.264 all the way down, no compromises, and still be able to trumpet reduced performance requirements.

[Dark Shikari]

I was wondering again, after seeing the snow thread, why Microsoft hadn't created a range coding alternative to CABAC in advanced profile. You'd get almost all of the benefit with less than half the cost. Then it truly would rival h.264 all the way down, no compromises, and still be able to trumpet reduced performance requirements.
Considering in my lower bitrate tests (--crf 25 to 35 ) H.264 outperforms VC-1 by as much as 50%, adding a CABAC-like encoder to VC-1 isn't nearly enough.

H.264's multiple reference frames, improved inter and intra prediction, and many of the features that make it relatively slow to decode compared to VC-1, even without CABAC, are the same features that make it so superior.

At high bitrates the entropy encoder becomes much more important relative to the other encoder features, of course.

[akupenguin]

At high bitrates the entropy encoder becomes much more important relative to the other encoder features, of course.
My experiments disagree. CABAC is most important at low bitrates. There's also a peak at lossless (because frext lossless skips dct, and cabac adapts to such drastically different coefficient distribution better than cavlc's fixed vlc tables do.) But CABAC is least important at low QPs other than 0.

graph 1: average of all the mpeg standard cif clips (http://akuvian.org/src/x264/entropy_mpegcif_avg.png).
graph 1b: the individual clips that were averaged. (http://akuvian.org/src/x264/entropy_mpegcif.png)
graph 2: animated content (I don't remember exactly what sources). (http://akuvian.org/src/x264/entropy_anime.png)

[Dark Shikari]

My experiments disagree. CABAC is most important at low bitrates. There's also a peak at lossless (because frext lossless skips dct, and cabac adapts to such drastically different coefficient distribution better than cavlc's fixed vlc tables do.) But CABAC is least important at low QPs other than 0.

graph 1: average of all the mpeg standard cif clips (http://akuvian.org/src/x264/entropy_mpegcif_avg.png).
graph 1b: the individual clips that were averaged. (http://akuvian.org/src/x264/entropy_mpegcif.png)
graph 2: animated content (I don't remember exactly what sources). (http://akuvian.org/src/x264/entropy_anime.png)
Well of the various features, CABAC is the most important I would agree; it makes a pretty solid 15% difference in almost any case, more than any other single feature.

What I mean is that at, say, HD-DVD bitrates, H.264 might have a 25% advantage over VC-1. 15% is CABAC and 10% is other prediction improvements. At, say, 1000 kbps for 720p, there might be a 50% advantage... 15% is still due to CABAC, and 35% is due to other predictive improvements. In other words, CABAC's improvement is relatively constant regardless of bitrate, while other improvements are much more obvious at lower bitrates.

RDO does seem to improve CABAC's efficiency considerably, as does trellis.

[Golgot13]

Like I've said many times before, I would LOVE to see an open-source encoder project for VC-1.

Simple give some source at community or good school (I'm french so: Ecole Central Paris, ENSIMAG,...).
I sure you will surprise by the quality of VC1 codec and speed encoding process after that.



If we can all at least agree that VC-1 specification is capable of producing better implementations than MPEG-4 ASP.

Simple to prove this: now you have ED movie just make the best encoding of this MOVIE !!!
I do not understand why you or Ben can not make encoding (no more that one night on your presonal computer),
I angry about that...
I think it is nice to have another video (movie with grain) to "finalize" this "SUMMER challenge" (I will ask
for others H264 professional solutions to be include on "MSU Codec comparison" with HD DVD restriction).


it's hard to explain why there's such strong community support for XviD MPEG-4 ASP development but absolutely none for VC-1 development. Given that most HD-DVD titles are VC-1 encoded (and would thus naturally lend themselves better to VC-1 re-encodes), you'd think enough people would be interested in developing a VC-1 encoder superior to Microsoft's WMV9 to serve their HD-DVD backup interests. But I suppose it's always easier to just complain and go with the pack than actually sit down and write new code.

Only one way to open your VC1 development:
- Give some source (vc1_enc.exe is nice and have more option that PEP)
- Participate at MSU codec comparison




Regards,



Golgot13

[Golgot13]

The idea that MPEG-4 is somehow more "open" and "free" (!!!) than VC-1 is just absurd.

I agree, but some people study this format at school/university.
They finish the development many years after and they give source...

[bond]

i for myself cant explain why hollywood studios choose vc-1 for their movies, while for hdtv avc is used

the only reason for that i can come up with is that m$ bought themselves into hollywood, trying to push their encoder by being cheap (becoming more expensive later on of course once everything used in the studios is designed to work with vc-1)

[Golgot13]

i for myself cant explain why hollywood studios choose vc-1 for their movies, while for hdtv avc is used


Simple for hollywood studios:
When a company come with software which worked and gave for free, you use it.
And about HD DVD, the Advanced Content is a format from MS (please Bond don't use $)
so which company know well this format.
If I'm a company and MS come with all, a solution, to make new HD format (HD DVD)
=> Sure I will say yes :D (it's a problem of money, because I win time and I buy little software)

About HDTV:
all broadcaster must to buy hardware and they have to pay the bandwidth.
So to don't lost lot of money, they use the best solution to broadcast more channel
on same bandwidth. Today the best solution is H264 codec



Last, I will support VC1 if some people can show me that it is the best format vs H264.
And I think I will need to wait next generation of MS codec (but SVC is nice format and not finish)

[zambelli]

Simple give some source at community or good school (I'm french so: Ecole Central Paris, ENSIMAG,...). I sure you will surprise by the quality of VC1 codec and speed encoding process after that.
A reference VC-1 encoder that Microsoft provided to SMPTE is available from the SMPTE store. The VC-1 standard defines how to decode VC-1, but there's no standard way of writing the encoder. Searching the Internet for VC-1 code can reveal some interesting documentations, such as MultimediaWiki (http://wiki.multimedia.cx/index.php?title=VC-1), Kostya's VC-1 blog (http://codecs.multimedia.cx/?cat=8) and VC-1 Transforms code (http://codecs.multimedia.cx/wp-content/vc1itrans.c).
I would guess a lot of the ratecontrol and motion estimation code could probably be borrowed from existing open-source encoder projects.

I do not understand why you or Ben can not make encoding (no more that one night on your presonal computer),
I angry about that...
You're angry because I don't have free time? Sounds like I should be the one angry about that.

Only one way to open your VC1 development:
- Give some source (vc1_enc.exe is nice and have more option that PEP)
It's not easy for Microsoft to give out source code, but in this case it's probably not even necessary. Just like x264 was written from scratch, a new VC-1 encoder could be written from scratch too. The spec and test materials can be obtained from SMPTE.
- Participate at MSU codec comparison
I talked to MSU about it several weeks ago. They aren't able to expand the scope of their free public codec comparison to include non-H.264 codecs at this moment.

[Golgot13]

A reference VC-1 encoder that Microsoft provided to SMPTE is available from the SMPTE store. The VC-1 standard defines how to decode VC-1, but there's no standard way of writing the encoder. Searching the Internet for VC-1 code can reveal some interesting documentations, such as MultimediaWiki (http://wiki.multimedia.cx/index.php?title=VC-1), Kostya's VC-1 blog (http://codecs.multimedia.cx/?cat=8) and VC-1 Transforms code (http://codecs.multimedia.cx/wp-content/vc1itrans.c).

Nice, but the open-source community "scratch" some standard because they "believe" it.
And when we know the story about MPEG standard (MPEG1, MPEG2, MPEG3->MPEG2 TS)
we understand it is nice to develop some encoder or decoder. It will be same for H264 (today) and MPEG4 SVC(futur).



You're angry because I don't have free time? Sounds like I should be the one angry about that.

Yes and no, I'm not agree when you say something if you can not prove it (it is not the best preset, or it is not PEP or it is not a good video example).
If you take all time, since the begin of test, of post reply and answer you had the necessary time to make the encoding...
I understand that like me you answer on your free time (after work or in pause/smoking time) or after work
so it's easy to launch a encoding process at night to have the file at morning...


It's not easy for Microsoft to give out source code, but in this case it's probably not even necessary. Just like x264 was written from scratch, a new VC-1 encoder could be written from scratch too. The spec and test materials can be obtained from SMPTE.

Yes, but the open-source community believe at H264 so they develop quickly something
(ask some school or university, there is lot of student project for H264 or MPEG format but nothing, I think, for VC1).
I'm sure we will see some encoder from open-source release because Zune, video network box but not quickly
than H264 or MPEG2.


I talked to MSU about it several weeks ago. They aren't able to expand the scope of their free public codec comparison to include non-H.264 codecs at this moment.

Yes, I remember it was before to see that H264 from x264 is better than VC1 from PEP.
But I don't like to listen some people (now MS will not say than VC1 is better than H264, I hope) or video magazines
who/which say VC1 is the better codec on HD format (now with your politic when some people read that the movie is in VC1,
they think it's the best quality).


We can make a "little" analogy with OS system. :p

[zambelli]

Yes and no, I'm not agree when you say something if you can not prove it (it is not the best preset, or it is not PEP or it is not a good video example).
Prove what? I don't think I've made any statements here that have been controversial. Are you under the impression that I suggested the results were flawed and biased in favor of x264? Check the thread, I never said anything like that. I provided feedback to Sagittaire about VC-1 encoding settings, that's all, as I wanted to ensure he was getting the most out of PEP. In fact, I've gone out of my way to suggest improvements to the comparison that wouldn't even necessarily benefit VC-1 (see my comments about post-processing settings). I'm not sure what exactly it is that I'm supposed to be proving.

so it's easy to launch a encoding process at night to have the file at morning...
... yeah, and then you gotta set up an .avs script to calculate PSNR & SSIM, let that run for an hour or more, inspect the results, go back and re-tune the settings, kick off another encode, and repeat until happy. This stuff is time-consuming. As much as I like doing it, I've got 10 other similar tasks that I need to be doing first for the people who pay my bills.

(ask some school or university, there is lot of student project for H264 or MPEG format but nothing, I think, for VC1).
A good idea and a point well made. :thanks:

But I don't like to listen some people (now MS will not say than VC1 is better than H264, I hope)
Because x264 scored a higher SSIM score on Doom9 forums? :rolleyes:
or video magazines who/which say VC1 is the better codec on HD format (now with your politic when some people read that the movie is in VC1, they think it's the best quality).
The 34 people who bought HD-DVDs this year think so, yes. :)

VC-1 and H.264 are close enough in terms of efficiency that most of the time the quality of an HD-DVD/BluRay release depends 90% on the quality of the transfer, the preprocessing workflow and the bitrate available on the disc. There are plenty of reference HD-DVDs out there encoded with VC-1 that show what the codec is capable of. It's not like anyone is making that stuff up; all one has to do is rent any of the recommended reference HD-DVDs (http://www.avsforum.com/avs-vb/showthread.php?t=856119) and see for themselves.

[Golgot13]

Prove what? I don't think I've made any statements here that have been controversial.

When I said you, I think at You, Zambelli, and Ben.



In fact, I've gone out of my way to suggest improvements to the comparison that wouldn't even necessarily benefit VC-1 (see my comments about post-processing settings). I'm not sure what exactly it is that I'm supposed to be proving.

But the challenge is to test encoder only.
I and many person on this forum are open for every suggestion.


... yeah, and then you gotta set up an .avs script to calculate PSNR & SSIM, let that run for an hour or more, inspect the results, go back and re-tune the settings, kick off another encode, and repeat until happy. This stuff is time-consuming.

Yes, but in 2 week, I think you can give more than one night (3 nights are enough).


As much as I like doing it, I've got 10 other similar tasks that I need to be doing first for the people who pay my bills.

Yes, it's same for me :rolleyes:
But MS use on "Professional Training", "Consumer Show" and "Journalist comment" the web forum, this and others,
to affirm something (like HD DVD is appreciate; people like/love VC1,...). I can post some powerpoint file from MS :p
And, I think, you (MS team) are encoraged to go on web forum to show "the best (for MS) way".:rolleyes:



A good idea and a point well made. :thanks:

Thank you, it will be nice if you can give something at students (because they don't have lot of money...).



Because x264 scored a higher SSIM score on Doom9 forums? :rolleyes:

At first, Sagitaire said he use SSIM2 (like Inventive Software with 500kps on other thread...).
If you not agree say it, and show the result with SSIM (you can download file to make it).


The 34 people who bought HD-DVDs this year think so, yes. :)

Yes, but there is not lot of H264 HD title (except BD). But I listen than Warner will use H264
some studio house finalize purchase of H264 solution (BD and HD DVD).



http://www.avsforum.com/avs-vb/showthread.php?t=856119 and see for themselves.

I think the moderator on this forum are PRO MS (agree with you). And there is lot MS people
(I don't see Amir here on doom9, ?).

[cannuck]

Great comparative study of H.264, Flash, WMV, and M$'s implementation of VC-1.Conclusion: "So, clearly there's little reason to switch from Flash or QuickTime to WMV." And H.264 in general comes out on top!

http://www.streamingmedia.com/article.asp?id=9659&page=1&c=8

In terms of M$'s business ethics - just jump over to Groklaw and check out what M$ is doing in terms of SCO, OOXML versus ODF, and Linux.

http://www.groklaw.net/

[benwaggoner]

Great comparative study of H.264, Flash, WMV, and M$'s implementation of VC-1.Conclusion: "So, clearly there's little reason to switch from Flash or QuickTime to WMV." And H.264 in general comes out on top!

http://www.streamingmedia.com/article.asp?id=9659&page=1&c=8
Sure, codecs have only rarely been different enough to override questions around the broader platform ecosystems.

The more interesting data point is how much VC-1 improved relative to the other codecs since last year's test.

In terms of M$'s business ethics - just jump over to Groklaw and check out what M$ is doing in terms of SCO, OOXML versus ODF, and Linux.

http://www.groklaw.net/
Probably not for this forum, but feel free to propose a better format for maintaining full backwards compatibility with a couple decades of .doc files within XML :).

[zambelli]

I and many person on this forum are open for every suggestion.
Are you? How about this suggestion: Stop interpolating this challenge to mean that one codec is better than another. And don't deny you said it in those words exactly, because there are posts of yours like this one (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1955775&SiteID=1) that prove otherwise. This is exclusively a metrics challenge, as Sagittaire himself has stated. While it certainly has a value and there's good data to be gathered from it, it's absolutely absurd to take *one* metrics challenge to make a conclusion on which codec is universally better. You complained just a few posts ago about Microsoft's wording in an article where VC-1 is claimed to be 2-3 times more efficient than MPEG-2 (and while I agree they used clumsy wording, notice that plotting PSNR against bitrate is a completely different test than what this challenge is about), yet you're doing exactly the same thing every day.

Yes, but in 2 week, I think you can give more than one night (3 nights are enough).
To do what? I'm sorry, I didn't realize I was on your schedule to prove something.

At first, Sagitaire said he use SSIM2 (like Inventive Software with 500kps on other thread...).
If you not agree say it, and show the result with SSIM (you can download file to make it).
:confused: You must've missed my point entirely. I wasn't talking about the difference between SSIM and SSIM w/ Lumimask=2 at all.

I think the moderator on this forum are PRO MS (agree with you). And there is lot MS people
(I don't see Amir here on doom9, ?).
Did you stop to consider that maybe it's not the moderator that's pro-MS, but that it's you who's anti-MS? I think your posts paint a very clear picture for anybody who visits the forum.

And for the record, Ben and I are the only people from the MS codec team active on this forum. Others from MS might be reading, but only Ben and I are writing.

Golgot, if you don't have anything constructive to add anymore except jabs at MS, I think we're done talking here.

[Golgot13]

Golgot, if you don't have anything constructive to add anymore except jabs at MS, I think we're done talking here.

:confused: Exactly like you on this challenge.

About web link, it's to show this challenge :D
If you're not agree you can try to prove than VC1 is better or can do better.

You have access at VC1 encoder (same I can on Sonic PSE but we use it all day in my work),
you can make some preset or test, but you do notthing only suggest about preset for PEP. :devil:

[Sharktooth]

He did it... and he posted the stream... made with an unreleased software (ok, i trust him on the fact the new version was only about dquant optimizations) but still the scores are widely inferior when compared to x264.
Someone, including me, do not trust metric tests results when difference between scores is too low, but such a difference (49.11db PSNR vs 47.62db PSNR and 94.18 SSIM vs 92.70 SSIM) in favour of x264 was quite explicative and does not even need any comments.
My "guess" is some commercial h.264 solutions (ateme, mainconcept...) could get even better results than x264, and i also believe some good MPEG-4 ASP encoders can be directly comparable to VC-1 in terms of metrics and maybe even perceived quality.

[benwaggoner]

He did it... and he posted the stream... made with an unreleased software (ok, i trust him on the fact the new version was only about dquant optimizations) but still the scores are widely inferior when compared to x264.
My guess is some commercial solutions (ateme, mainconcept...) could get better results than x264...
Better results in the objective scores? Before you talk about "better" in the abstract, we should do some viewing of the actual clip.

We'll also share a version that uses DQuant, because it'll look subjectively better, in particular on LCD and similar displays with elevated blacks, even though it'll score worse on the metrics.

[Sharktooth]

"better" in a metric test comparison means better scores... dont you agree?:p
i've edited the previous post so it's more clear...

[CruNcher]

Jesus what does this here become, everyone calm down :P
ok fact is that x264 has not been made for the purpose of where this test is heading towards and Microsofts (tweaking) goes, so it is absolutely unfair (from Microsoft) to compare it HVS wise in that case x264 needs still some time to be ready for that comparision and other solutions should be compared here vs Microsofts VC-1 claims.
Atemes and Elecard/Mainconcept it's time for them to show what their H.264 implementations are capable of (they allready show it in the broadcast and studio sector tough but dunno wich HD-DVD/Blu-Ray is mastered with their research results).
@ Beenwaggoner i think if you release that Source you talked about, everyone (of those companies) would be happy to show of their Encoding results here (they know their implementations the best) in terms of HVS Quality and Metric Results constrained to HD-DVD.

[benwaggoner]

"better" in a metric test comparison means better scores... dont you agree?:p
i've edited the previous post so it's more clear...
Sure, this test is this test. I just want to point out that one shouldn't overgeneralize from this test to broader assumptions about visual quality across all scenarios, since we're not testing visual quality directly.

[Trahald]

What would be good at this point is a 'by eye' test. setup a blind test (single blind in no particular order) and allow voting. although hosting 1gb files may be rough (all contestant files would need to be on same server to keep test blind).. might have to go with screen shots?

[CruNcher]

The result is clear Trahald it would prove that H.264 is better suited in terms of Compression vs VC-1 giving the same visual quality @ lower filesizes (thus being more decoding complex) for this Animation Sceneario as i said earlier it shouldn't suprise everyone that Disney supports H.264 on Blu-Ray they have cristal clear transfers compared to other Studios and H.264 benefits for their purpose big time.
For the other Sceneario Film/Grain x264 is not suited yet and it was never optimized extensively for that purpose here solutions from Ateme and Mainconcept/Elecard should be taken into consideration first. And if you wan't to go 1 step behind FreXt (FGM/FGT) x264 is no canditate yet to be tested, because simply it isn't integrated yet.
Btw thx for your great work on the HRD patch without this such a test wouldn't be even possible with x264 :)

[Golgot13]

it shouldn't suprise everyone that Disney supports H.264 on Blu-Ray they have cristal clear transfers compared to other Studios and H.264 benefits for their purpose big time.


At high bitrate, VC1 and H264 are very similar (same for MPEG2). The PSNR difference decrease...

Disney use H264 solution from CinemaCraft because it is easy and quick to use it.
The speed encoding of this solution is fast (much faster than PEP/CineVision PSE:
@ Sagitaire, CC-HDe use all processor core not like PEP).

[Sharktooth]

uhm... i searched the web for mainconcept h.264encoder info and didnt find anything about FGM. btw i dont own it so i cant confirm.
the only encoder with an early implementation of FGM i know about is the ateme h.264 encoder i beta tested some time ago...

[crypto]

@CruNcher
BTW. The Herbie transfer shows grain. The mpeg-2 encoding simply cannot preserve it. I made a comparison shot from the H.264 transfer (http://dvbportal.dyn1.de/forum/gallery/2_16_08_07_7_52_34.png) under the same conditions (bicubic downsize 720p + compression). Have a look at the darker parts of the facade in the bachground.

[CruNcher]

Yes that seems to be real grain from the kodak print indeed but its very faint compared to other transfers another screen please :D can't wait for the Blu-Ray :P that face how many details

[honai]

The result is clear Trahald it would prove that H.264 is better suited in terms of Compression vs VC-1 giving the same visual quality @ lower filesizes

I envy the rare gift of foresight bestowed upon you. Us mere mortals rather rely on actual data and scientific evidence, as in actually conducting a double-blind test before we draw such conclusions.

[crypto]

Yes that seems to be real grain from the kodak print indeed but its very faint compared to other transfers another screen please :D can't wait for the Blu-Ray :P that face how many details
I totally agree :D