[HD 1080p24 Challenge] MPEG2, VC-1 and H264 with real uncompressed source

[zambelli]

In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate.

And it's false for this source and certainely for many other simply because MPEG-2 never requires a bit rate up to 3 times higher than VC-1 to achieve a given PSNR.
I think you guys are nitpicking over this quote. You're taking an MPEG-2 best case scenario (let's face, nobody expected MPEG-2 to do this well in this challenge) and saying that Microsoft's claims are universally false, which is a bit of a stretch.

And yeah, I know that marketing folks are always very eager to pick the best test results instead of average or worst test results, but even when taken with a grain of salt, I don't think saying VC-1 is 2-3 times more efficient than MPEG-2 is far from the truth. If somebody said the same about MPEG-4 ASP, I'd consider it to be a true statement. Most DVDs, for example, are encoded at 5-6 Mbps. Ripping those DVDs and re-encoding them to XviD at ~2 Mbps has been the principle this website was founded on. Isn't that essentially the same claim of 2-3 times better efficiency?

[Manao]

Isn't that essentially the same claim of 2-3 times better efficiency?But mpeg4 isn't 2-3 times more efficient than mpeg2. Mpeg2 in DVD has a gop of 12/15 frames ( that's a 20% bitrate loss ). Mpeg4 @ 2mbps doesn't have the same level of details than mpeg2 @ 5mbps ( even if, instead of reencoding the mpeg2, you started from the same uncompressed source ).

[Golgot13]

One of our co-workers had some time last week to try encoding this with PEP 1.0.7. We've got a 12 Mbps VC-1 encode now that scores 47.62 dB PSNR and 92.70 SSIM, versus 46.71 dB PSNR and 92.44 SSIM of Sagittaire's VC-1 encode. The video was encoded with PEP 1.0.7 (currently in development),

Can you give a link to donwload video ?
Sagitaire will put a video link on first page.

With same measure than MS comparison codec:
So at 12Mbps: H264 from x264 is the best codec than VC1 from PEP and MPEG2 from libavcodec.
And , if the result is true (I don't have the video), VC1 really best than MPEG2 at 12Mbps.





but with Dquant entirely off. This seems to be telling us that SSIM doesn't care about blockiness in dark and smooth areas - something that HD-DVD and BluRay studios do care about very much.

How can you measure the blockiness on video?
Some professional H264 encoder have some psychovisual option with 5 level to optimize this.
So I think if you have some measure tool some people can continue the challenge on this way of comparison.
It will be necessary if the PSNR measure between two codec (here, VC1 and H264) is less than 0.7dB
but there is a difference of 2.6dB at 6Mbps and 1.49dB at 12Mbps



So we'll continue looking into this, but it's far from being our #1 priority at this moment.


I hope to see better quality on HD DVD, and I know MS do the best of VC1.


... the best codec for generating highest SSIM scores, perhaps. :rolleyes:

SSIM of H264 is better :p
Yes, VC1 is better than MPEG2, fortunately



I hope anyone writing an article about this challenge actually understands that it is just a metric comparison, as Sagittaire has stated in his own words.

Yes, the same metric used by MS last year to compare VC1 at all codec:
http://www.microsoft.com/windows/windowsmedia/howto/articles/vc1techoverview.aspx#VC1ComparedtoOtherCodecs

And the conclusion was:
In Microsoft's own internal tests, VC-1 performs 2 to 3 times better than MPEG-2. In other words, to achieve a given PSNR, MPEG-2 requires a bit rate up to 3 times higher than VC-1. These results were measured using both low-motion and high-motion video sequences. Microsoft also compared VC-1 with H.264 and found that both codecs have comparable performance when PSNR is plotted against bit rate.


Zambelli can you update this MS weblink because it is not true ? (and I'm not sure it was true too).:rolleyes:

[Sagittaire]

One of our co-workers had some time last week to try encoding this with PEP 1.0.7. We've got a 12 Mbps VC-1 encode now that scores 47.62 dB PSNR and 92.70 SSIM, versus 46.71 dB PSNR and 92.44 SSIM of Sagittaire's VC-1 encode. The video was encoded with PEP 1.0.7 (currently in development), but with Dquant entirely off. This seems to be telling us that SSIM doesn't care about blockiness in dark and smooth areas - something that HD-DVD and BluRay studios do care about very much. So we'll continue looking into this, but it's far from being our #1 priority at this moment.

ahhhhhh ... interessing.

Well like I reported to Benwagonner there are certainely a "bug" for the RC in the core 1.06 and Benwagonner confirm this problem in complex part. Explain good result at SSIM and bad result at OPSNR if you compare with MPEG2 and H264 for my encoding. OPSNR at 47.62 dB with SSIM at 92.70 is a more conform result.

Like I say it's not a visual comparison but just a metric comparison. Anyway H264 can use Adaptative Quantisation exactly like VC1. It's possible to implement AQ Dark Masking for profesionnal H264 implementation (Elecard/Mainconcept make that for example) and certainely for x264 too. It's just a little HVS tweak. MPEG2 from libavcodec implementation can use lumi/dark/spatial/temporal masking for AQ.

[zambelli]

Can you give a link to donwload video ? Sagitaire will put a video link on first page.
Sure. I'll try to remember to upload it tomorrow at work.
I hope to see better quality on HD DVD, and I know MS do the best of VC1.
Well, fortunately our development efforts are focused at the segment of the market where eyes count more than metrics. ;)
Zambelli can you update this MS weblink because it is not true ? (and I'm not sure it was true too).:rolleyes:
One best case scenario MPEG-2 test doesn't make it universally false! If anything needs to be corrected in that article, it's that codec standards can't be compared in terms of PSNR - only codec implementations can. The article should really be saying "Microsoft VC-1 encoder is 2-3 times more efficient than xyz MPEG-2 encoder".

[Golgot13]

One best case scenario MPEG-2 test doesn't make it universally false!

Yes and no.


If anything needs to be corrected in that article, it's that codec standards can't be compared in terms of PSNR - only codec implementations can.

May be you can change the sentence about PSNR ?


The article should really be saying "Microsoft VC-1 encoder is 2-3 times more efficient than xyz MPEG-2 encoder".

If you can not change, can you put/update with your results and show how the test was made (encoders used,...) ?

[arfster]

Would have to be a pretty garbage mpeg2 implementation in the worst case scenario to be 2x worse at the same bitrate. 3x worse..... never going to happen, was never going to happen.

[Dark Shikari]

Would have to be a pretty garbage mpeg2 implementation in the worst case scenario to be 2x worse at the same bitrate. 3x worse..... never going to happen, was never going to happen.
At very low bitrates the advantages and disadvantages of codecs begin to show.

I can make a watchable H.264 movie at 720p at 1 megabit. MPEG-2 can't get close to that.

It converges at higher bitrates of course. I assume that Microsoft did their tests at lower bitrates to accentuate the difference between VC-1 and MPEG-2.

[benwaggoner]

Would have to be a pretty garbage mpeg2 implementation in the worst case scenario to be 2x worse at the same bitrate. 3x worse..... never going to happen, was never going to happen.
Well, 2x is a pretty vague metric.

Certainly, VC-1 can do 640x480 @ 1 Mbps better than MPEG-2 can do @ 2 Mbps with plenty of cases. MPEG-1/2 really fall off a cliff beyond a certain point, lacking any in-loop deblocking.

[Golgot13]

Well, 2x is a pretty vague metric.

Certainly, VC-1 can do 640x480 @ 1 Mbps better than MPEG-2 can do @ 2 Mbps with plenty of cases. MPEG-1/2 really fall off a cliff beyond a certain point, lacking any in-loop deblocking.

Yes, I agree, but I think that MPEG4 ASP produce same result too.
I will be nice to test it (may be if Sagitaire can do it, because sure Ben you can not).

[benwaggoner]

Yes, I agree, but I think that MPEG4 ASP produce same result too.
I will be nice to test it (may be if Sagitaire can do it, because sure Ben you can not).
I'd be interested in seeing that as well (althogh it's not entirely germane here, as it's not supported by any HD optical media format).

Remember we need to test that with postprocessing turned off as well, to match the workflow of other codecs.

[Sagittaire]

Yes, I agree, but I think that MPEG4 ASP produce same result too.
I will be nice to test it (may be if Sagitaire can do it, because sure Ben you can not).

At this time I make other test and encoding. Anyway for this challenge I have I think the best possible result for H264 and for MPEG2. pep 1.07 can certainely produce really better result for OPSNR but not for SSIM. I will remake VC1 encoding with part by part encoding for optimal result ...

[zambelli]

At very low bitrates the advantages and disadvantages of codecs begin to show.

I can make a watchable H.264 movie at 720p at 1 megabit. MPEG-2 can't get close to that.

It converges at higher bitrates of course. I assume that Microsoft did their tests at lower bitrates to accentuate the difference between VC-1 and MPEG-2.
I'm also guessing that might've been the case. I haven't seen the tests, but it sounds like they picked a PSNR, then raised bitrates until the PSNR matched. This is a different approach entirely than the one of this challenge because it is approaching the problem from the opposite angle (fixed PSNR, variable bitrate). Though I'm sure the upper "3 times" figure might've had some wishful marketing thinking applied to it, the "2 times" figure doesn't sound wrong at all. Like I said, if somebody told me they could get DVD quality at 3 Mbps with VC-1, MPEG-4 or H.264 - wouldn't that sound like a reasonable claim?

Anyway, I'll see if I can track down the author of the article in question and get more info about the tests. I'm no fan of technical ambiguity in articles either.

[zambelli]

At this time I make other test and encoding. Anyway for this challenge I have I think the best possible result for H264 and for MPEG2. pep 1.07 can certainely produce really better result for OPSNR but not for SSIM. I will remake VC1 encoding with part by part encoding for optimal result ...
Note that our higher PEP 1.0.7 score was attained by disabling dquant entirely. While that's typically not something we'd do in a real HD-DVD encoding scenario, it seems to favor PSNR & SSIM here, so I guess you should make sure you disable it in your further encoding too. As much of the work in PEP 1.0.7 has been focused on dquant, you should probably be able to get very similar results with PEP 1.0.6 when Dquant is turned off.

[akupenguin]

Like I said, if somebody told me they could get DVD quality at 3 Mbps with VC-1, MPEG-4 or H.264 - wouldn't that sound like a reasonable claim?
That sounds reasonable, but that's comparing those codecs against MPEG-2 + DVD restrictions (GOP, VBV, etc). Unrestricted MPEG-2 can also get DVD quality at less than DVD bitrates (though obviously not as much less as modern codecs).

[zambelli]

Here's a link to the new 12 Mbps VC-1 encode I mentioned in post 150 (http://forum.doom9.org/showthread.php?p=1033723#post1033723):

http://www.citizeninsomniac.com/video/ED_Microsoft_12Mbps_NoDQ.vc1

This was encoded with PEP 1.0.7 (unreleased), with dquant disabled.

[crypto]

Note that our higher PEP 1.0.7 score was attained by disabling dquant entirely. While that's typically not something we'd do in a real HD-DVD encoding scenario, it seems to favor PSNR & SSIM here, so I guess you should make sure you disable it in your further encoding too.

This is exactly one of the results, when relying on PSNR & SSIM alone. It can lead the codec development and the evaluation of settings into a totally wrong direction.

I would second the statement about caring about blockiness in dark and smooth areas or smooth fades are more important than metrics.

I remember when HD-DVD (VC-1) and Bluray (MPEG-2, AVC) entered the market with different visual experiences, people loved VC-1.

Maybe JND metrics would be more appropriate.

[Trahald]

I remember when HD-DVD (VC-1) and Bluray (MPEG-2, AVC) entered the market with different visual experiences, people loved VC-1.Just to be fair, any early unfavorable bluray reviews i saw were all mpeg2 based.

[CruNcher]

If i could propose something i would say we add 2 other metrics to this test (currently doing this for my stuff) this way we could also see how efficient they are under such real life conditions, the metrics i propose are both developed by MSU the Blocking measure and the Bluring measure they show quiet well results in my firsts tests.
This multi metrics way could enhance the overall look also in terms of tweaking it into a desired one http://www.compression.ru/video/quality_measure/info_en.html#start :), but it should be clear that only in combination it makes sense to tweak upon them especialy seeing that they not proven to be efficient enough.

[benwaggoner]

If i could propose something i would say we add 2 other metrics to this test (currently doing this for my stuff) this way we could also see how efficient they are under such real life conditions, the metrics i propose are both developed by MSU the Blocking measure and the Bluring measure they show quiet well results in my firsts tests.
This multi metrics way could enhance the overall look also in terms of tweaking it into a desired one http://www.compression.ru/video/quality_measure/info_en.html#start :), but it should be clear that only in combination it makes sense to tweak upon them especialy seeing that they not proven to be efficient enough.
I'd certainly be interested in seeing the results of new metrics.

Comparing blocking/blurring between codecs would be particularly interesting, and also comparing different post-processing techniques for more PC-based playback.

[zambelli]

If one was to do a series of A/B visual comparisons between an H.264 encoder and a VC-1 encoder in HD encoding scenarios, what you would probably find is that neither encoder completely blows the other out of the water for all content. There'd probably be frames where one looked better than the other (perhaps due to different ratecontrol & ME), and then there might be other frames where within the same frame some areas look better on one and other areas look better on the other encoder (perhaps due to different transforms, quantization, AC preservation, etc). It's rarely a clean-cut "this encoder wins hands down" situation. I've even heard compressionists say one encoder works better with titles from a particular studio, for example, simply due to the frequency ranges created by certain transfer equipment. This is why you often hear people in the HD-DVD/BluRay encoding world say the H.264 and VC-1 encoding solutions are "close enough" in terms of quality, meaning that ease of use, speed of workflow and degree of human interaction required often play a greater role in the selection of a codec than PSNR, SSIM, and other mathematical metrics.

I don't say this to discredit SSIM - it's a metric that I've used often and have evangelized quite a lot to other people on the codec team at Microsoft - but I simply want to illustrate the point that the HD-DVD/BluRay world tends to play by very different rules than some other video encoding market segments. Their goal is really to achieve transparency to the source - as much as possible within their given constraints. This is why they have professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result.

In the context of this challenge, the 18 Mbps example would probably be most similar to the conditions and requirements of HD-DVD encoding. 6 Mbps, on the other hand, might be better comparable to VOD offerings, IPTV, digital cable, etc, where quality doesn't need to be transparent to the source - it simply needs to be "watchable" and "good enough". A whole different set of requirements and criteria rule that world so I think one has to keep that in mind when evaluating this challenge too. The qualities/objections that matter at 18 Mbps aren't the same as the ones that matter at 6 Mbps.

[Golgot13]

I would second the statement about caring about blockiness in dark and smooth areas or smooth fades are more important than metrics.

I remember when HD-DVD (VC-1) and Bluray (MPEG-2, AVC) entered the market with different visual experiences, people loved VC-1.

Maybe JND metrics would be more appropriate.

Yes and No:
About Blu-Ray in MPEG2: Sony's compressionist are stup*d guy, because they used a bad MPEG2 encoder.
Second, BluRay titles were the first with true video: movie without preprocessing video
(no remove grain, no change contrast, sharpen,...)

About HD DVD, all first HD DVD used the best preprocessing video (less grain,
sometime without grain,change contrast, sharpen,...). Now with optimization of PEP
we can have better video with grain preserve (nice picture, thank you MS team).

[Golgot13]

I'd certainly be interested in seeing the results of new metrics.

Comparing blocking/blurring between codecs would be particularly interesting, and also comparing different post-processing techniques for more PC-based playback.

I'm agree with you.
And it will be a new development way for encoder opitimization. Ateme software and Mainconcept software
have nice options for grain and "psychovisual" optimization.

If we have new "metric" (for blocking, bluring, ...), I'm sure we will have better encoder (VC1, H24, VP6, MPEG2,...)

[CruNcher]

Exactly that's what im currently doing (doing since years actually) ;)

[honai]

This is why they have professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result.

No, they don't. I hate to say it, but that statement is objectively untrue. Unless these production facilities fired the old ones from the DVD era and magically grew new ones over night I don't see how you could get "compressionists" who don't screw up titles as they did with previous DVD releases. Point is that the vast majority of "compressionists" out there have very little understanding of their tools, the source material and the encoding process itself. (And don't get me started on audio compression.) It's like putting someone with 4 weeks of college courses in MS Word to work with Adobe InDesign and tell him to produce the next Newsweek edition. Eventually he'll come up with something ... and then blame the source/the editors/the reporters/the software for the bad results.

It's a sad state where your average scene encoder can put out better encodes from HD disc material than "professional compressionists" from raw, uncompressed 4:4:4 scans. The majority of the latter are not professional, and they don't compress but mutilate.

By the way: This situation is even more so perpetuated by complementary "professional HD disc reviewers" *cough* highdefdigest *cough* who make ridiculous claims about the "three-dimensional, palpable, flawless transfer" of such mutilated releases where even the casual observer could count numerous glaring mastering errors. It's like the mute teaching the blind how to see.

Unless guys like zambelli, who obviously wield some influence in that process, straighten their act up and admit that a vast array of releases are being butchered by those facilities I don't see the situation improving. Think of the initial Fifth Element release, where customer dissatisfaction and market pressure actually spawned a remastering. Ridiculous claims like "professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result" are counter-productive in that respect. Overall the industry is doing a really bad job right now, and we need more pressure so that we actually get the best possible result.

[vsv]

Compressionist Stacey Spears said:

"I finally got around to looking at the x264 encode of ED. (12 Mbps version) and it looks great! None of the AVC encoders used for HD DVD or BD are as good as the x264 encoder. If I had to rate them in order of quality it would go:

Thompson
MEI
Sony
Cinema Craft
Toshiba

Both Paramount and Universal have left the choice up to the compressionist w/r/t which codec to use for a given title. They really just want the best looking title they can get. Sadly, things are now date driven, so titles have to be done quickly. HDM is coming out of R&D and now people are wanting to make some money, so they can't afford to tweak until it is perfect anymore." (http://www.avsforum.com/avs-vb/showpost.php?p=11342184&postcount=120)

[CruNcher]

Hehe then he should try Mainconcepts Encoder and Ateme also :P if he likes those pro stuff, they in some degress even better then current x264 but not for much long for sure
and x264 bitstreams are yet still more decoding complex then Atemes for example (same levels same settings) dunno about Mainconcept situation ;)

[zambelli]

Unless guys like zambelli, who obviously wield some influence in that process
That's nice of you to think so, but I really have no influence over the mastering and encoding practices in the HD-DVD/BluRay encoding market.
"professional compressionists whose job is to tinker with encodes and do segment re-encoding until they truly have the best possible result" are counter-productive in that respect. Overall the industry is doing a really bad job right now, and we need more pressure so that we actually get the best possible result.
My impression is that the dedication to quality has been much higher than in DVD production, especially in these early days of the medium. As Stacey stated in that quoted post, the release schedule is indeed growing more and more date driven so we'll have to see how long the studios can stay quality-focused, but if you compare the early days of DVD to the early days of HD-DVD/BluRay encoding - it's a night and day difference.

[708145]

As Stacey stated in that quoted post, the release schedule is indeed growing more and more date driven so we'll have to see how long the studios can stay quality-focused, but if you compare the early days of DVD to the early days of HD-DVD/BluRay encoding - it's a night and day difference.

If I may ask, how much time is left in working days for each title?
Less than 3?

[arfster]

Compressionist Stacey Spears said:

[url=http://www.avsforum.com/avs-vb/showpost.php?p=11342184&postcount=120]"I finally got around to looking at the x264 encode of ED. (12 Mbps version) and it looks great! None of the AVC encoders used for HD DVD or BD are as good as the x264 encoder.


Interesting. That's either a fairly severe criticism of the professional stuff (given the money at stake pro stuff really shouldn't be outperformed by open source), or an enormous credit to the x264 coders.

Probably both.

[CruNcher]

arster it's a difference if a company researchs their entire lifetime on video only or has multiple sectors of research and then you have the guys that are behind this and especialy if it's a buisness changes aren't such fast provided to compressionists look for example VC-1 consumer encoder is 1 year old technology compare that with almost daylie new builds from x264 such a release shedule is unthinkable for open source, but thats because there aren't 1000 instances new developments have to go through in a buisness (Development,several big boses who decide how to make the most money with it,marketing,pr,design studios,private betas with 3rdparties :P all of this is slowing down imense (the brains behind it (coders) have allready created 2 new generations before the old one is finaly going out LOL) in small research companies alot of those isn't the case some is, for open source most of the times none of the above is the case so its lightning fast from coding to enduser sometimes 1 day even hours and really heavy projects even minutes compare that to waiting for a new VC-1 endconsumer encoder from MS 1 year long that is crazy how slow that is, but i think that sometimes to fast can also be a problem :P it can endup in stress situations for example efficiency testing you test something and know the next day everything, could have changed and you start again ;) definatly nothing humans are made for but definatly alot better then to wait 1 year for mini progresses, because of all the politics behind it :P.

[zambelli]

arster it's a difference if a company researchs their entire lifetime on video only or has multiple sectors of research and then you have the guys that are behind this and especialy if it's a buisness changes aren't such fast provided to compressionists look for example VC-1 consumer encoder is 1 year old technology compare that with almost daylie new builds from x264 such a release shedule is unthinkable for open source, but thats because there aren't 1000 instances new developments have to go through in a buisness (Development,several big boses who decide how to make the most money with it,marketing,pr,design studios,private betas with 3rdparties :P all of this is slowing down imense (the brains behind it (coders) have allready created 2 new generations before the old one is finaly going out LOL) in small research companies alot of those isn't the case some is, for open source most of the times none of the above is the case so its lightning fast from coding to enduser sometimes 1 day even hours and really heavy projects even minutes compare that to waiting for a new VC-1 endconsumer encoder from MS 1 year long that is crazy how slow that is, but i think that sometimes to fast can also be a problem :P it can endup in stress situations for example efficiency testing you test something and know the next day everything, could have changed and you start again ;) definatly nothing humans are made for but definatly alot better then to wait 1 year for mini progresses, because of all the politics behind it :P.
You bring up a lot of good points. The advantage of small projects (open or closed source) is definitely in the quick turnaround time. In small projects bugs can be fixed and new builds can be released in hours, new features can be implemented in a matter of days, etc. There's no doubt that a project's efficiency starts decreasing once you pass a certain "sweet spot" in size. On the other hand, I think large and slower projects definitely benefit from more thorough testing. With projects like x264, for example, practically every build is a beta build and every user is a tester. (My favorite examples are projects like Exact Audio Copy which after 8 years of development still haven't officially reached v1.0 :D ). Larger projects tend to set major milestones and handle testing between milestones in a more closed environment, hopefully producing more stable major builds for the public releases. Having dedicated people with a responsibility to find bugs and ensure stability goes a long way and is definitely more reassuring and efficient than just relying on random users to find the bugs for you.

[pandy]

Noise hides banding if it's added at playback time.
Noise increases banding at any given bitrate if it's added before encoding, because it takes bits away from the actual content.


No, proper noise (optimal from source point of view) is always ok - for example for linearization of quantizier


You mean, wastes bitrate equally everywhere. And why do you care about a "stable" bitrate anyway? You don't see bitrate, you see quality.


Yes but adding some noise can subjectively improve quality


Noise is always a problem. The only argument for including it in a test is that non-CG movies have a certain amount of unavoidable noise, and you want the test to reflect the imperfect real world.

Yes, noise is always problem due of nature of noise so very frequently instead noise we use regular patterns which are similar to the noise.

[CruNcher]

With projects like x264, for example, practically every build is a beta build and every user is a tester

Yep, but that's happening in our daylie lives more and more see the CE market same situation, because everything relies on firmware (software) now, this also gives alot of Power to the industry (industry = certain groups of humans) deciding what the user can and what not and especialy what he has to pay for, with this developments comes great responsibility by the industry for the whole society not to missuse this power, but @ the moment they do, so they shouldn't be suprised if other try to avoid being put in that scenario (controled) we are humans after all and everyone knows history and everyone knows how so much ended and Microsoft is @ the moment in the same position as the Roman Empire @ that time now and definatly has to change to survive.
But for Americans this is hard to understand because in Shool you only learn American History allways from the American view (Patriotical), but hey if i look sometimes into the history and compare it with our situation now i allways think what are we doing we repeat everything we did wrong in the past and that on a worldwide base not only America makes the same mistakes but everyone, for what have we been teached history in Shool sometimes i can just think for the fun of it :P

[akupenguin]

No, proper noise (optimal from source point of view) is always ok - for example for linearization of quantizier
Give an example of such "optimal" noise? And what does it have to do with quantizers, linear or otherwise?

Yes but adding some noise can subjectively improve quality
That's what I said -- at playback time.

Yes, noise is always problem due of nature of noise so very frequently instead noise we use regular patterns which are similar to the noise.
If you agree that noise is a problem, then why are you trying to emulate it? Just making it non-random doesn't make it take any fewer bits.

[Sharktooth]

@cruncher: Roman empire was not evil @ all.

[arfster]

With projects like x264, for example, practically every build is a beta build and every user is a tester.

True - but you could also that's exactly the case for all drivers put out by NVidia and ATI, which are hardly tiny companies. X264 is a paragon of stability and maturity compared to the stuff those two produce.

[Dark Shikari]

True - but you could also that's exactly the case for all drivers put out by NVidia and ATI, which are hardly tiny companies. X264 is a paragon of stability and maturity compared to the stuff those two produce.Agreed: proprietary and expensive does not mean stable or reliable. In fact it often means it was kludged together by a bunch of incompetents, and then Very Highly Paid Consultants were hired to fix it up, after which the company released it 6 months ahead of schedule, long before it was finished.

[zambelli]

Agreed: proprietary and expensive does not mean stable or reliable. In fact it often means it was kludged together by a bunch of incompetents, and then Very Highly Paid Consultants were hired to fix it up, after which the company released it 6 months ahead of schedule, long before it was finished.
I didn't mean to bring up x264 as a bad example - it certainly seems to be a very stable project. I just mentioned it as a pretty common example of the "latest build is the greatest build" trend in software projects. In many small projects (open and closed source) believing that the latest incremental build is neccessarily also the best build tends to be more a form of blind faith than actual confidence based on testing. Large projects tend to have a more strictly defined plan, goals, milestones, which *usually* (but not always) leads to more stable milestone releases.

Anyway... We're off-topic again, and I'd hate to see this thread derailed and closed like the VC-1 vs H.264 thread, so I'll stop talking about software engineering philosophies now. :)

[MfA]

Maybe JND metrics would be more appropriate.
Hell no.

[crypto]

Hell no.

OK, it was just an idea. I already wondered why nobody mentioned it before. :D

[MfA]

There was a JND like metric for Avisynth. The approach was quite popular before SSIM came around since it was almost as simple. The only problem is that it just doesn't correlate that well with subjective testing (IMO because there is a big mismatch between local frequency spaces and the way the HVS works).

[cannuck]

H.264 will be supported natively by most new graphics cards. NVidia, ATI and Intel have made a commitments to have full support for it. This means better than HD video on your PC will become possible in the not so distant future.


http://www.kaourantin.net/

The above quote is from Adobe's Prinicpal Engineer for Flash Player, Tinic Uro.

What exactly is he saying?

[cannuck]

Hmmm...

I wonder if Tinic Uro would be interested in joining this particular discussion? Be good to have another corporate view of the H.264 world.

[CruNcher]

he allready visits here (he lists links to doom9) and many video engineers from commercial R&D companies actually do :)
and yes what he actually says is that the 100 kb Mainconcept Decoder is gonna do Hardware Acelleration with Nvidia/ATI/Intel cards soon :)
also very interesting the Flash Decoder is 10 bit capable (High 10 Profile) :P

[cannuck]

I wonder why Motion JPG-2000 isn't included in the comparison here. Some Motion JPG-2000 companies claim that Motion JPG-2000 is 10 times faster than VC-1.

At the same time there is a study that concludes that:
At very high resolution and high bit-rates, Motion-JPG-2000 clearly outperforms H.264/AVC"



http://64.233.167.104/search?q=cache:dGvLLNoK74IJ:www.f4.fhtw-berlin.de/~barthel/paper/spie03_marpe_et_al.pdf+Jpeg2000+versus+h.264&hl=en&ct=clnk&cd=1&gl=ca

[Sergey A. Sablin]

I wonder why Motion JPG-2000 isn't included in the comparison here. Some Motion JPG-2000 companies claim that Motion JPG-2000 is 10 times faster than VC-1.

At the same time there is a study that concludes that:




http://64.233.167.104/search?q=cache:dGvLLNoK74IJ:www.f4.fhtw-berlin.de/~barthel/paper/spie03_marpe_et_al.pdf+Jpeg2000+versus+h.264&hl=en&ct=clnk&cd=1&gl=ca

it is comparison of pure intra coding, ie each picture is encoded as a key frame, thus limiting H.264 abilities.

one of the reasons why MJ2K isn't widely used is its complexity on decoding - it is far slower than performance of block based codecs. 10 times faster? BS!

[Golgot13]

I wonder why Motion JPG-2000 isn't included in the comparison here.


Because it's not compliant with HD DVD or BD (see first page)


Some Motion JPG-2000 companies claim that Motion JPG-2000 is 10 times faster than VC-1.


Yes but it don't have the same limitation (vbv and other contraint).

[cannuck]

Because it's not compliant with HD DVD or BD

Oops! ;)

Since Motion JPG-2000 is used in theatres , I wonder how it got excluded from the specs for HD DVD? Another one of M$'s gambits?

http://www.groklaw.net/article.php?story=20070829070630660

[Golgot13]

Oops! ;)

Since Motion JPG-2000 is used in theatres , I wonder how it got excluded from the specs for HD DVD?


Simple=> money

And I don't know if there are some manufacture compagny which made a chipset decoder.