Google VP9 "Next Generation Open Video" information posted

[mandarinka]

Maybe one could look at it this way: they want to lower the effective bandwidth, quality be damned. But if they do it with the existing formats, people could whine. However, if you use a new codec, you can spin it that the picture quality is still the same because "VP9 is better". Which might or might not be true (libvpx being bad, but yt's H.264 too), but you were able to achieve the real objective - bitrates were reduced. HEVC could really work too, of course.

[mzso]

Given the asymmetry of consumer broadband (much faster downloads than uploads), and that using a given amount of upload typically knocks out a lot more download capacity, P2P isn't that great for streaming. It seems like if you have a 50/10 connection, using 5 Mbps of upload "uses" 25 Mbps of download. So P2P can really cap the actual deliverable bandwidth by a lot.

What? How did you come up wit this nonsense?

And they're more like VOD than streaming, even Youtube. (Except for live streams)

[zerowalker]

Fun thing is that the don't really reduce bandwidth cost anyway, as they pretty much use same bitrate. Sometimes lower and higher. Doesn't make any sense.

[Nintendo Maniac 64]

However, if you use a new codec, you can spin it that the picture quality is still the same because "VP9 is better". Which might or might not be true (libvpx being bad, but yt's H.264 too), but you were able to achieve the real objective - bitrates were reduced. HEVC could really work too, of course.

Actually it's more complicated than that. VP9 is about equal quality to non-DASH h.264 720p (fmt22) but VP9 is higher quality than all the other h.264 formats; the thing about fmt22 is that it has a considerably higher bitrate as you can see from my screenshot below.

Fun thing is that the don't really reduce bandwidth cost anyway, as they pretty much use same bitrate. Sometimes lower and higher. Doesn't make any sense.

Uhh, the VP9 versions are consistantly of smaller size than the h.264 videos, the only exceptions being a couple small resolutions.

Video in question:
https://www.youtube.com/watch?v=FIc4Uj9RL2Y

Browser extension in question:
http://cys-audiovideodownloader.com/

http://i.minus.com/izF95htkdU5Iv.png

[zerowalker]

Damn they have fixed it now then..
When VP9 came, it was extremely random in my tests, some VP9 was much lower, but some were also higher than the h264 counter part, which i of course enjoyed.
Well, there broke that good part of it all;(

[Nintendo Maniac 64]

Well, there broke that good part of it all;(

As someone with only 3Mbps down, I'm glad they fixed it.

[zerowalker]

Well you were one of those that noticed it i think, when you and i did some tests back then;P

And damn you, it's cause of your internet i can't be satisfied! I demand more and more bitrates:(
Well, i hope VP9 looks better than H264 still, as in my old tests when the bitrate was about half in some cases, H264 looked better overall, which wasn't a good turn.

[Nintendo Maniac 64]

Well, i hope VP9 looks better than H264 still, as in my old tests when the bitrate was about half in some cases, H264 looked better overall, which wasn't a good turn.

In high-motion videos, such as that one I linked to 2 posts back, VP9 totally looks better.

Here's the link again if you need it:
https://www.youtube.com/watch?v=FIc4Uj9RL2Y

(note: I cannot test the VP9 formats above 720p30fps because my current CPU is way too weak - an AMD E-350; its replacement, a Pentium G3258, isn't ready for use yet - the E-350 was only a stop-gap solution from when the motherboard died to my Brisbane 4800+)

[zerowalker]

Well motion is the hardest, and dark parts. I take your word for it, did a little check on the VP9 60FPS and i can't complain. Though there is not much detail to be lost anyway.
But still VP9 was "bad" when it was released, my guess is they have made major updates sense release, even if Youtube itself probably get those releases a bit slower than the actual codec.

Still skeptical to how VP10 will go, if they keep releasing codecs without improving the encoder, it will just come to a standstill. HEVC is crap compared to x264, and if HEVC V2 would come next year, it would look even worse most likely:S
(Crap is an overstatement of course).

[Nintendo Maniac 64]

Regarding VP10, my only concern would be the unnecessary competition between it and Daala...

Though there is not much detail to be lost anyway.

That's likely due to the fact that the game is only being rendered at 480p with 4xAF and I think no AA.

EDIT: Maybe a better video? Same game, different track, but rendered at a much higher resolution:
https://www.youtube.com/watch?v=5I-nQtsJuhE

[zerowalker]

Can't speak for Daala, but i am hopeful about that codec, as Opus and Vorbis did just nicely. Not sure about Theora though, kinda missed that part, but remember Ogg (not sure what the codec was called, maybe it was Theora), and it did nicely compete with DivX.

Most likely. This video looked much clearer, Not sure how the original video looked. But i can see the usual VP9 Artifacts that i dislike (the weird square boxes, kinda similar to no-deblocking on x264 or older codecs).
But still, it's very acceptable when i know it's Youtube.

If VP10 etc goes as Google plans (and i hope it does) and everything will be less in size and same (hopefully a bit better) in quality. Then i can't really complain, even if i wish to have 10mbps+:P

[tuqueque]

VPx and Daala are fundamentally different technologies... The only similarities are their goals (free, open and unencumbered video codecs), but the internals are completely different. VPx will always (?) be DCT based; Daala is exploring Lapped Transform encoding, among other new, experimental techniques.

At the end, they are not competing, they are exploring different approaches; VPx with the more "traditional" one, and Daala goes on testing some new stuff to see if it's really viable as a video codec.

[zerowalker]

Well competition with new techniques is always good. It might be bothersome as it brings back the "Divx,Xvid,Vorbis,MP3," Wars that was going on before, now it's all x264/AAC pretty much as those are pretty much the best (As no one uses Opus yet).
But eventually it will lead somewhere when the best of the best is at the end of the horizon;)!

[Nintendo Maniac 64]

And because I can, here's another high-motion video; make sure there's no kiddies around for the giant on-screen f-bomb text that's at the end:
https://www.youtube.com/watch?v=CEo1D2Y57_U

OK then, I'm done. :p

Interesting note: Even though it's not available for playback via YouTube's own video player, the 1440p30 version of this video is actually available using a YouTube downloader, including VP9 1440p30.

EDIT: It turns out that VP9 actually is smaller at 144p as well, it's just the vorbis audio has a higher bitrate than the aac audio. Also you can actually kind of see what's going on with VP9 @ 144p; meanwhile h.264 @ 144p is pretty bad (though Baseline@1.2L probably isn't helping).

[foxyshadis]

I've yet to see a VP9 that was worse than the AVC version; even if it's a hash, at least it's smaller. Back when they had zero rate control and VP9 vids could be huge, I was pretty ecstatic by all the extra quality, though. Guess I'm spoiled like zerowalker. VP9 is a great format, it just feels mismanaged.

I typically download both formats for vids I want to archive, then combine and re-encode them. Sure I'd love to have all those bits in one perfect copy, but two vids damaged in different ways gives you some interesting ways of reconstructing a better one.

As for HEVC, at Youtube-ish bitrates it easily exceeds AVC and VP9 at this point. It's mainly for videophile encodes that x264 still beats HEVC, though x265 is slowly narrowing that gap.

[zerowalker]

Really?
Seen some that's worse, at least in the beginning. Though i think in some cases the VP9 won, like certain parts. And if i remember right it was like, AVC = 2mpbs, VP9 = 3mbps. Or something, which explained it.

And yeah welcome to the club, let's wish for a future with high bandwidth all over so bitrates don't have to suffer;P!

Interesting about HEVC, thought it still was "crap", you sure it beats x264 for like 3mbps 1080p? (Or whatever the bitrates is for 1080p)

[Tommy Carrot]

Interesting about HEVC, thought it still was "crap", you sure it beats x264 for like 3mbps 1080p? (Or whatever the bitrates is for 1080p)

I wouldn't generalize about HEVC, because as a format i believe it has the potential to be superior at all ranges, but currently x265 only has advantage at low bitrates. I mean above the crf 24-25 range of x264. Below that, they are usually similar, or even x264 has the quality advantage (not to mention the computation complexity advantage).

The bitrate depends on the compressibility, so for more complex videos 3 mbps at 1080p often would go above crf 25, so in those cases, x265 would beat x264, In other cases, not so much.

[zerowalker]

Yeah that's my view at it, the Codec itself has advantage, but the encoder doesn't (yet).
And crf 24-25 isn't something i even consider for next to anything myself. For me i need it to look at least like 16-18.
So i am really skeptical to how BD 4K will turnout cause of this, they high bitrates which i am guessing is above the 24-25 for 4K, but if that's the case then they should uxe x264.

Then again that's a year ahead, i hope the Encoder will be much better till then (guessing they don't use x265, so to whatever they use).

Ah miss when i thought DVD looked transparent and i couldn't complain as i didn't know anything else:(

[Bloax]

Well yes, it's not very fair comparing an encoder that has gone through many years of tuning, improvement, innovation and optimization to a rather recent encoder for a different standard. (^:

[Nintendo Maniac 64]

And if i remember right it was like, AVC = 2mpbs, VP9 = 3mbps. Or something, which explained it.

This isn't the case anymore, refer to the posts on the previous page.

[zerowalker]

Yeah that's what i mean, it Was something like that in my tests way back (it was at least more bitrate, that's for sure in those cases). But as you say, it's not like that any more.
Not sure if old files have been replaced by new VP9 encodings, highly doubt that happens, but it would be nice if they did that to "fix" those mistakes. If it increases quality:P!

[Nintendo Maniac 64]

Here's something interesting - it would seem the very last video I just linked to has the 1440p VP9 version use considerably more bitrate than the 1440p h.264 version...

It doesn't seem to be consistant though, the following videos have pretty much the same bitrate for both 1440p formats:
https://www.youtube.com/watch?v=_wEOK6Hf4h8
https://www.youtube.com/watch?v=5jO1ju4CFoE

And yet here's a video with the VP9 1440p having somewhat less bitrate than the h.264 1440p (again, only available though a downloader):
https://www.youtube.com/watch?v=THmD3BiLpuk

Maybe at 1440p the bitrate for VP9 is set to be more variable or something depending on the video? Like I've stated before, F-Zero GX has always been tough on video encoders, so maybe YouTube automatically determines that it needs more bitrate?

----------------------------------------------------------------

I typically download both formats for vids I want to archive, then combine and re-encode them.

Combine? How the heck does one do that for video? I only know how to do that for individual images, and not automatically either (so I can't just do it to a sequence of frames without it taking forever).

[zerowalker]

Hmm interesting about 1440p. Perhaps it's as you say, just have a bit less limit to it's bitrate, and if it has much motion it will just use what it can as any codec/encoder.
That would be the case for pretty much all recordings though, except simple 2D, as any kind of 3D movement eats bitrate to the max most of the time (as long as there is much movement).
Everything that matters is just that the pixels change colors and doesn't stay the same for long.

Good for for me though;), sadly my CPU hates 1440p+, so don't think i can see 1440p60 if/when that is supported:P

[Nintendo Maniac 64]

Good for for me though;), sadly my CPU hates 1440p+, so don't think i can see 1440p60 if/when that is supported:P

Even my HTPC's good ol' 2.4GHz Penryn handles 1080p 60fps VP9 just fine in MPC-HC 64bit with D3D Fullsceen (though at like 90% CPU utilization :p). Is your CPU really that weak, or are you one of the unfortunate people with a CPU that lacks SSSE3? (like I was before my AM2+ mobo died on me a few months back)

[zerowalker]

1080p is fine, it's above that. 4k VP9 lags for me for example. So guessing 1440p at 60fps would lag as well.

I got i5 760 @4Ghz, so i don't lack SSE features and speed in that sense.

[Nintendo Maniac 64]

Huh, that's interesting... on my new fancy Pentium G3258 I can decode 2160p VP9 in 64bit MPC-HC with around ~80% CPU utilization, and that's only at stock clocks. I didn't think Haswell's IPC was that much better in things other than emulation (where it does really well).

One thing I do know is that disabling Accurate VSync and using D3D Fullscreen can reduce the CPU utilization a teeny bit, which can be useful if you're at almost playable speeds.

[zerowalker]

Talking Chrome here, but i think i actually tried downloading one before. Though i think it was much higher quality then youtube, so can't compare to that.
Chrome is locked at 50% as far as i know, so perhaps 80% i can do it as well, or perhaps it's a better decoder, or my CPU is just not good enough;P

[Nintendo Maniac 64]

Well for one thing MPC-HC uses ffvp9 which is much more optimized than the Google reference VP9 decoder, especially with SSSE3 and 64bit.

Case in point: 1280x720 30fps VP9 is actually playable on a measly 1.6GHz AMD E-350 in MPC-HC 64bit, but the very same video is a stutter-fest in MPC-HC 32bit.

(Chrome has similar performance to MPC-HC 32bit)


And FYI, MPC-HC can totally play back a still-downloading WebM file along with its according external audio file.

[zerowalker]

Interesting, guess i will try next time:)

[Nintendo Maniac 64]

Forget that, I found something even better - SVPtube. It's a small program that just runs in the background and keeps an eye on your copy/paste clipboard at all times, and then when you copy a YouTube link it will automatically launch your preferred program of choice along with your preferred format and resolution (all of which can be configured).

Now normally it's used in conjunction with SVP, but it's not actually required, so you can use it for launching your 4k VP9/WebM videos in 64bit MPC-HC.

Link to program:
http://svp-team.com/wiki/SVPtube


Just an FYI though, the "Autoplay" function may be a bit finicky at times (I think it's caused by changing a specific setting in SVPtube, but I don't know what...); in such situations, you can just left-click the SVPtube icon on the taskbar to start the video manually.

[pandy]

Huh, that's interesting... on my new fancy Pentium G3258 I can decode 2160p VP9 in 64bit MPC-HC with around ~80% CPU utilization, and that's only at stock clocks. I didn't think Haswell's IPC was that much better in things other than emulation (where it does really well).

One thing I do know is that disabling Accurate VSync and using D3D Fullscreen can reduce the CPU utilization a teeny bit, which can be useful if you're at almost playable speeds.


With or without DXVA (or similar solution)?

[zerowalker]

VP9 has no hardware acceleration yet. Or well perhaps Mobile.

[mzso]

Forget that, I found something even better - SVPtube. It's a small program that just runs in the background and keeps an eye on your copy/paste clipboard at all times, and then when you copy a YouTube link it will automatically launch your preferred program of choice along with your preferred format and resolution (all of which can be configured).

Now normally it's used in conjunction with SVP, but it's not actually required, so you can use it for launching your 4k VP9/WebM videos in 64bit MPC-HC.

Link to program:
http://svp-team.com/wiki/SVPtube


Just an FYI though, the "Autoplay" function may be a bit finicky at times (I think it's caused by changing a specific setting in SVPtube, but I don't know what...); in such situations, you can just left-click the SVPtube icon on the taskbar to start the video manually.
I tried it before. Didn't find it too reliable. Opening videos often failed or took a long time. Plus it runs as a separate program which watches the clipboard for yt links which is annoying.

Just gave it a try again. It fails to open any videos.

[mandarinka]

Well for one thing MPC-HC uses ffvp9 which is much more optimized than the Google reference VP9 decoder, especially with SSSE3 and 64bit.

Case in point: 1280x720 30fps VP9 is actually playable on a measly 1.6GHz AMD E-350 in MPC-HC 64bit, but the very same video is a stutter-fest in MPC-HC 32bit.

(Chrome has similar performance to MPC-HC 32bit)


The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode. The developers chose to not care about 32bit performance, so it won't ever perform very well on non-64bit OSes/playback environments.

Some users may find that ffvp9 is a lot slower than advertised on 32bit; this is correct, most of our SIMD only works on 64bit machines. If you have 32bit software, port it to 64bit. Can’t port it? Ditch it. Nobody owns 32bit x86 hardware anymore these days. (see here (http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/))

[Nintendo Maniac 64]

The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode. The developers chose to not care about 32bit performance, so it won't ever perform very well on non-64bit OSes/playback environments.

(see here (http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/))

Already well aware of this - I'm arguably the first guy that found out that their optimizations are actually not just 64bit but also SSSE3 - if you have one but not the other, you'll essentually get the same performance as 32bit.

[Kurtnoise]

The ffvp9 encoder only has the full set of assembly optimised code in x86-64bit mode.
ffvp9 is the decoder not the encoder...

[mandarinka]

Yeah, of course. I know but made a mistake when writing that.

Already well aware of this - I'm arguably the first guy that found out that their optimizations are actually not just 64bit but also SSSE3 - if you have one but not the other, you'll essentually get the same performance as 32bit.

Yeah, the cause is probably the same - the developers didn't feel like supporting SSE2-only CPUs like K10 derivatives. I guess the reason is unwillingness, time and having less code to maintain.

I'm in the same boat here (2011 AMD chip) but luckily I don't experience need for VP9 decoding as such, so slowness is not an issue, hehe (yet, maybe that will change in time). ffmpeg/libav guys aren't the only people like this anyway, x265 is the same. I guess we are quite lucky that x264 was quite consistently developed with serious targeting of SSE2 as well as newer CPUs <3

[Nintendo Maniac 64]

I'm in the same boat here (2011 AMD chip)

You're on a Llano APU? That's the only 2011 AMD CPU without SSSE3 - even Bobcat supported SSSE3.

And FYI, I'm no longer in the same boat since my AM2+ mobo died back in July. The only SSSE3-less system that's actively used now is my file server (Pentium 3) and my father's PC (1.9GHz Brisbane G1).

[mzso]

I'm in the same boat here (2011 AMD chip) but luckily I don't experience need for VP9 decoding as such, so slowness is not an issue, hehe (yet, maybe that will change in time). ffmpeg/libav guys aren't the only people like this anyway, x265 is the same. I guess we are quite lucky that x264 was quite consistently developed with serious targeting of SSE2 as well as newer CPUs <3

I don't think luck has anything to do with it. x264 is a much older project which predates SSSE3.

[mandarinka]

I don't think luck has anything to do with it. x264 is a much older project which predates SSSE3.

In the relevant time (say 2006-2010), SSSE3 was available or even mainstream on Intel processors, so the "predating" isn't that important. The point is that they almost always implemented assembly for SSE2 (or even MMX in the past) path as well as the higher sets and didn't drop it later for sake of simplicity or like that. Same for 32bit mode, their assembly is always made for both, with only little exceptions with actual technical reasons. I'd call it luck that they cared so much even though 90 % of users usually had ~Core 2 chips that did not need it.

x264 doesn't even require SSE2 yet, although it wouldn't be unreasonable - you can run the encoder on Athlon XPs and it won't be significantly crippled in comparison to K8 cores with SSE2, actually.

Edit: But I'm getting fairly far form the thread's topic...

[foxyshadis]

Here's something interesting - it would seem the very last video I just linked to has the 1440p VP9 version use considerably more bitrate than the 1440p h.264 version...

It doesn't seem to be consistant though, the following videos have pretty much the same bitrate for both 1440p formats:
https://www.youtube.com/watch?v=_wEOK6Hf4h8
https://www.youtube.com/watch?v=5jO1ju4CFoE

And yet here's a video with the VP9 1440p having somewhat less bitrate than the h.264 1440p (again, only available though a downloader):
https://www.youtube.com/watch?v=THmD3BiLpuk

Maybe at 1440p the bitrate for VP9 is set to be more variable or something depending on the video? Like I've stated before, F-Zero GX has always been tough on video encoders, so maybe YouTube automatically determines that it needs more bitrate?

I'm pretty sure the explanation is more that VP9's rate control is mostly worthless, which at least is a step up from how it was it completely worthless a year ago. Instead of being anything from 50% less to 100% more, it's now within 25% either way.

Combine? How the heck does one do that for video? I only know how to do that for individual images, and not automatically either (so I can't just do it to a sequence of frames without it taking forever).

It's not that much different from images. Mask off anything that looks like blocking or flat detail-free parts, where only one is masked off mostly or only use the other there, where both or neither are just merge them. Detail can be good or bad, but it generally looks better. The masktools scripts are kind of a pain though.

[Nintendo Maniac 64]

Uhh, I just realized - shouldn't the whole VP9 on YouTube discussion have been in the other thread?

http://forum.doom9.org/showthread.php?t=170682

[easyfab]

New commit :" vp9_ethread: the tile-based multi-threaded encoder"

Vp9 should be a little faster now ( 2x ?) . I'll make some tests later .

[Selur]

that sounds nice, please report, may be this will make VP9 usable :)

[easyfab]

vpxenc v1.3.0-4967-ga3a4a34 x64
park_joy_1080p50.y4m
intel I2600k

--good --cpu-used=3
1.59fps
cpu usage 12%

--good --cpu-used=3 --tile-columns=2 --threads=4
3.4fps
cpu usage between 30 and 40%

so better but still progress possible to saturate the cpu usage, x3 with 100% ?

Still to slow for real encoding

[BadFrame]

--good --cpu-used=3 --tile-columns=2 --threads=4
3.4fps
cpu usage between 30 and 40%

so better but still progress possible to saturate the cpu usage, x3 with 100% ?


I just tried it myself, I got ~80% cpu utilization on a 2.67ghz core i5 using the following:

vpxenc --good --cpu-used=1 --codec=vp9 --end-usage=q --cq-level=10 --aq-mode=3 --lag-in-frames=25 -o clip.webm clip.y4m --tile-columns=2 --threads=4

using '--tile-columns=2 --threads=4' cut the encoding time down from 23 minutes and 12 seconds, to 7 minutes and 59 seconds on a 50 second 720p clip, so something like a ~65% faster.

[Tommy Carrot]

What's the difference between --end-usage q and cq modes? I can't find any real description about them. I'd guess one of them is similar to constant quantizer mode, but which one? Is the other similar to the crf mode in x264, or is it something different?

[Selur]

What's the difference between --end-usage q and cq modes?
Which cq modes?
Afaik there's "--end-usage=<arg> (vbr, cbr, cq)"
vbr = variable bitrate
cbr = constant bitrate
cq = constant quantizer
and "--cq-level=<arg> (valid values 0-63, default 10)" which defines the quantizer that is used with "--end-usage=cq",
but no "cq modes".

And no, at least atm. there is no such thing as similar to crf in x264.

[Tommy Carrot]

In the latest build from Kurtnoise, there are: --end-usage=<arg> vbr, cbr, cq, q
"cq" is supposed to be constrained quality, not constant quantizer, and i haven't found any description about "q" mode, but many people use it in their command lines.

[Selur]

You are right there is totally missed that,... sorry.
---
looking at http://wiki.webmproject.org/vp9/vp9-tips
it seems like:
--end-usage=q --cq-level=<desired quality in quant scale 0-63>
is constant quantizer
--end-usage=cq --cq-level=<desired quality in quant scale 0-63> --target-bitrate=<max_bitrate_constraint_in_kbps>
is some sort of constant quantizer, but restricted to a max bitrate (so the quantizer will be lowered if the choosen quantizer would violate the bitrate restriction)