On2 VP8

[IgorC]

@DS

If you are saying that VP7 is worse than MPEG-2.
Prove it!!!
Here is the original lossless sample. ftp://ftp.tnt.uni-hannover.de/pub/sv...rig_02_yuv.zip
Encode it at sane bitrates like 1500 kbit/s.

[Dark Shikari]

Originally Posted by IgorC

@DS

If you are saying that VP7 is worse than MPEG-2.

No, I said in that particular case it came out worse, demonstrating that VP7's quality is rather schizophrenic.

As I said, I think the format is probably comparable to VC-1 on a good day.

But since people are incapable of reading my posts and are blinded so much by their hated of x264 that they cannot parse simple logical statements, I'm not going to continue explaining anything in this thread. Enjoy your fantasy that VP7 is competitive with even non-x264 H.264 encoders; I hope On2 is at least paying you to take such an absurd position.

[IgorC]

Originally Posted by Dark Shikari

No, I said in that particular case it
But since people are incapable of reading my posts

You're not exception at all. 4 people was telling about "past glory of VP7" but you didn't understand the message was:" on2 can prepare good codec in future just as it was in 2005".

Originally Posted by Dark Shikari

and are blinded so much by their hated of x264 that they cannot parse simple logical statements

???
I'm x264's f.... fan.

Originally Posted by Dark Shikari

I hope On2 is at least paying you to take such an absurd position.

You wayyyyyyyyy crazy

You may think anything you want. That I was paid by on2, Ateme, Elecard ..because I was a beta tester of their codecs or gui .. I didn't receive any f.. cent from them ...so my speech is free
So stfu!!!

[IgorC]

Originally Posted by Dark Shikari

Enjoy your fantasy that VP7 is competitive with even non-x264 H.264 encoders

And you can enjoy your fantasy about that you have statistically average eyes of whole world.
Many people have told you here: You never admit that you can wrong.

[IgorC]

Originally Posted by Dark Shikari

I hope On2 is at least paying you to take such an absurd position.

Yes, they paid to me, to Ateme developer, Sagi, *.mp4 guy and many other peoples.

Go to sleep, boy.

[Sagittaire]

Originally Posted by Dark Shikari

No, I said in that particular case it came out worse, demonstrating that VP7's quality is rather schizophrenic.

As I said, I think the format is probably comparable to VC-1 on a good day.

But since people are incapable of reading my posts and are blinded so much by their hated of x264 that they cannot parse simple logical statements, I'm not going to continue explaining anything in this thread. Enjoy your fantasy that VP7 is competitive with even non-x264 H.264 encoders; I hope On2 is at least paying you to take such an absurd position.

Well Choose short and really particular test sequences never produce general conclusion. In my memory One2Tech provide really particular test sequences where VP7 produce by far better quality than all the other codec at high quantisation level. VP7 produce in general case by far better quality than MPEG4 ASP ...

[Sagittaire]

And for test ...
http://www.on2.com/index.php?609

In fact when I make test with foreman I find in practice more than 1 dB for x264 in this test without Psy tools.
Internal test from dev are always bad when they test other codec (Dark Shikari is not exception) ... I don't know why ... lol

D:\Mes dossiers\Codec\x264>x264 --fps 30 --crf 27 --threads 1 --bframes 3 --b-adapt 2 --b-pyramid --
ref 5 --mixed-refs --direct auto --deblock -1:-1 --psy-rd 0.0:0.0 --aq-mode 0 --aq-strength 0.0 --pr
ogress --8x8dct --subme 9 --me "tesa" --partitions "all" --trellis 2 --qcomp 0.75 --keyint 120 -o x2
64HP-896.mp4 352x288.yuv
x264 [info]: file name gives 352x288
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 1.3
mp4 [info]: initial delay 2000 (scale 30000)
x264 [info]: slice I:3 Avg QP:25.33 size: 12448 PSNR Mean Y:39.03 U:42.39 V:44.35 Avg:40.03 Gl
obal:39.85
x264 [info]: slice P:139 Avg QP:28.22 size: 2033 PSNR Mean Y:37.04 U:41.29 V:42.86 Avg:38.14 Gl
obal:37.97
x264 [info]: slice B:158 Avg QP:30.31 size: 573 PSNR Mean Y:36.08 U:40.94 V:42.63 Avg:37.28 Gl
obal:37.11
x264 [info]: consecutive B-frames: 15.2% 31.6% 30.3% 22.9%
x264 [info]: mb I I16..4: 14.2% 34.1% 51.7%
x264 [info]: mb P I16..4: 2.7% 2.9% 1.4% P16..4: 39.9% 16.2% 7.9% 1.3% 0.6% skip:27.0%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.1% B16..8: 39.1% 3.0% 2.1% direct: 1.9% skip:53.5% L
0:35.8% L1:47.2% BI:17.0%
x264 [info]: 8x8 transform intra:40.2% inter:57.2%
x264 [info]: direct mvs spatial:98.7% temporal:1.3%
x264 [info]: ref P L0 77.0% 9.3% 6.6% 3.1% 4.0%
x264 [info]: ref B L0 74.1% 11.9% 10.3% 3.7%
x264 [info]: ref B L1 92.0% 8.0%
x264 [info]: SSIM Mean Y:0.9431324
x264 [info]: PSNR Mean Y:36.553 U:41.119 V:42.753 Avg:37.703 Global:37.509 kb/s:328.38

encoded 300 frames, 11.79 fps, 328.90 kb/s


Anyway VP8 seem produce exceptional metric result because I use the extreme quality profil for x264 and it's certainely the best in the area for H264 codec.

[*.mp4 guy]

It apears that Dark Shikari's opinion of vp7 is due to testing with its default settings (besides setting quality to best), and vp7's defaults are incredibly bad. In my experience, you always need to completely disable its post processing, and set sharpness to 0 to get good quality output from it.

Dark Shikari provided a lossless segment from the sample those screenshots are from, and vp7 without its incredibly bad post filter, and with sharpness set to 0 looks as good as just about everything but x264.

screenshot ( I know its not the same frame, but you get the idea).

[Sagittaire]

Originally Posted by *.mp4 guy

It apears that Dark Shikari's opinion of vp7 is due to testing with its default settings (besides setting quality to best), and vp7's defaults are incredibly bad. In my experience, you always need to completely disable its post processing, and set sharpness to 0 to get good quality output from it.

Yes ... anyway this sequence is here to prove the AQ utility. VP7 can't really fight here.

[avih]

Originally Posted by IgorC

Yes, they paid to me, to Ateme developer, Sagi, *.mp4 guy and many other peoples.

Go to sleep, boy.

Hey, take it easy there please. No need to patronize or turn the discussion into a fight. Please be polite and on topic. That was a warning, Thanks.

[hurry]

I think Dark Shikari has his right to point things out. Unlike what On2 did to VP7, he has never stopped tirelessly developing x264 and making it better and better for us almost on a daily basis, unlike On2, he is dedicatedly developing x264 for us video encoders and not just for commercial purposes, and unlike On2, he has never made absurd claims about his x264 codec being some x% better than other codecs etc. even though the quality of x264 just talks for itself.

Also, among all other codecs, On2 chose to compare VP8 quality with x264 on their site without even making the VP8 codec available to Dark Shikari and giving him a fair chance or even informing him about their tests. This would obviously upset anyone, especially someone like Dark Shikari who tirelessly works on developing x264 with much dedication. I think Dark Shikari is not biased and does appreciate and give credit where it is due like for example in the case of Divx7.

I also agree with Dark Shikari that the claims by On2 for VP8 over x264 and other codecs should be supported by tests by neutral observers before they can publicize their claims like they have done. If they want to claim that they are the best, then they should have made the VP8 codec available for testing on their website to support their claims. So as Dark Shikari says, unverifiable claims create a very unpleasant atmosphere in the community of video codec developers.

Dark Shikari, we certainly appreciate your extraordinary development of x264 and we will always be grateful for it.

[Mc Onyx]

Originally Posted by hurry

Dark Shikari, we certainly appreciate your extraordinary development of x264 and we will always be grateful for it.

Well said, right on...

[chenm001]

"50% better than h.264"
This means that VP8 not good as VP7.
Because, On2 VP3 better than MPEG4 as 30%, and VP4 than VP3 50%, VP5 than VP4 50%, VP6, VP7...
At the VP7, it has 4.375% bitrate than MPEG4, so a DVD(D9) can be record in 64MB USB-Flash.

[Sharktooth]

well those are obviously marketing claims.
however VP7 aint that bad... recent h.264 encoders are obviously a step (or more) ahead but it's a shame there isnt a free-for-personal-use VP8 encoder...

[CruNcher]

it's not unbelievable that VP8 is visually (HVS) wise more optimized compared to H.264 the idea of the motion region adaptive deblocking is great, though how it looks in real is another thing also see Real Networks last claims with NGV and it's still not here @ that time X264 was already much more optimized then any of this only VPx really delivers something interesting every time vs MPEG's technology and always without being able to use B-frames and also don't forget the amount of companies and Research organizations involved in MPEG vs On2's rather small in house Research

[the Mad Duke]

I think VP7 has been continually updated for On2's clients/customers according to the news they release but they stopped updating the personal use version a long time ago so it would not be possible to do any accurate comparrisons anymore.

[CruNcher]

yep i wonder if this http://www.on2.com/index.php?592 made it's way into the currently available VP7 Encoder i guess it did but somehow i doubt as they shutoff VP7 com development long time ago in favor of their business with Adobe and improved Vp7 in the darkness , i remember that sequence being from one of the users here supplied to On2 in the beta test.




Also seeing this is interesting though in reality it's nothing to really jump into the air about (especially as it's theoretic assumptions) also H.264 complexity can be lowered without causing to much quality drains AVS being the best example and of course it depends on the Decoder heavily bad unoptimized decoder of course would result in this best to use Apples Decoder for that purpose, Apples stuff is allways good to test his more efficient optimized stuff against be it either Decoder/Encoder (guess it's already a industry tip).
I guess they rather test it with the most unoptimized encoder for both in that case it would be someway impressive (if it holds the same quality with that power consumption) But yeah at least it lets suspect that they improved heavy especially on the loop filter seeing that it now takes some more cycles. As Dark Shikari already mentioned it looks similar to VC-1's complexity i would say it will beat VC-1 but that already could also bring it up to match with H.264 (it depends on the visual improvements) if they do some certain visual stuff right it could even beat it, i wouldn't say it's not possible though H.265 is in the making and gonna beat it again (in compression efficiency at least)

What i find rather funny is that they advertise Golden Frames being new though they already used them in VP7 according to their own documents so for them actually VP7 never existed only in com tests that we provided ideas for also that chart shows they ignore the intermediate VP7 research (it wouldn't look that impressive ) the feedback from this beta though brought them a lot of ideas (especially improving the very bad inloop deblocking and they seem not only to have brought it up to H.264 but also gone one step further) also this alone is unique we have been part of their Research i like that i never could have had such influence @ MPEG :P which brings me to the question what is MPEG planing to improve inloop deblockings visual efficiency in H.265 ?

[benwaggoner]

Do those estimates pass the sniff test? I haven't profiled H.264 much myself, but bidirectional prediction itself shouldn't add much decode complexity. If anything, we've found they reduce overall decode load in VC-1.

Unless they're assuming 16 reference frames that then don't fit into cache or something...

[Mr VacBob]

Well, prefetch takes care of most reference problems if you do it ahead of time enough. I think their H.264 decoder isn't optimized well (it might not be using SIMD, or reference software, or fictional); dequantization is nearly free and inter/intra prediction are very efficiently SIMDed.

They could've made that graph look better for them, just double the entropy decode time for H.264 and change "optional sub pixel" to "mandatory 1/8th pixel".

[Manao]

For h264, loop filter is roughly 30 to 50% of the pixel processing (intra prediction / inter prediction / idct / dequant / deblocking). Entropy obviously depends on bitrate (almost linearly). Intra prediction and inter prediction don't add up (since a MB is either intra or inter, not both at the same time). Worst case scenario for bidir prediction is more than twice inter prediction. IDCT / dequant depends slightly on bitrate (low bitrate -> skips), but remains fast comparatively to entropy.

At high bitrates (1080p, ~50 mbps), CABAC can take up to 70% of the processing time. At low bitrates (1080p, ~5 mbps), it takes roughly 20% of the processing time.

Those percentages suppose some SIMD-like optimizations.