How VP9 Video Encode/Decode Compares To H.264/H.265

[brent]

When it comes to desktop browsers, at least on Linux, both Firefox and Chrome use ffmpeg only for h264 decoding, vp9 is decoded with libvpx. Not really sure why that is.

Likely because initially libvpx was the only availabe VP9 decoder. ffvp9 came quite a bit later. These days there are no reasons to stick with libvpx for decoding, though. It just sucks.

[plantroon]

My PC with Athlon BE2350 and nVidia GT 520 can't playback 4k youtube video or 720p@60FPS video without stutter. Only M$ Edge browser can play it just fine. I'm using Archlinux 90% of the time. The 10% is when I need to copy a file out of my Windows 10 (it's on raid0 which is not accessible from linux for reasons). But still, Windows 10 is insanely fast on this 7 years old thing. Nothing else plays 60 FPS video on this.

[Gusar]

Likely because initially libvpx was the only availabe VP9 decoder. ffvp9 came quite a bit later. These days there are no reasons to stick with libvpx for decoding, though. It just sucks.

Yeah, at the beginning there was no choice but to use libvpx. But now there is choice, so the browsers could switch. Chrome contains ffmpeg anyway, and Firefox can interface with it. Though I think Firefox's ffmpeg code is only for Linux and OSX.

My PC with Athlon BE2350 and nVidia GT 520 can't playback 4k youtube video or 720p@60FPS video without stutter. Only M$ Edge browser can play it just fine.

Probably because Edge is served h264 which will be decoded in hardware, while other browsers get vp9 and so software decoding with the libvpx decoder. There are scripts out there to force Youtube to serve h264 also to Firefox or Chrome. These scripts won't help much in Linux where html5 video won't be hardware decoded. The only way to get hardware decoding in a browser in Linux is Flash. But that will be crashy as hell.

[bug77]

Yeah, VP9 software decode performance is great, but that doesn't help if the encoder is so slow that you can't encode video for it in reasonable time. The libvpx VP9 encoder is easily an order of magnitude slower than x264 when using a single core and multicore scaling is a (stale) joke. It's so bad that using VP9 easily becomes impractical.

Except that in a world of streaming, it's not you that encodes the video, it's the content provider. And they do have the resources to throw at the problem (even if they won't like throwing them).
The issue I see here is embedded implementations. We'll get cameras and phones claiming to encode H265 and such, but they'll do it with such lax parameters, the results will be worse that H264 actually.

[Azrael5]

Are there browsers which supports directly h.264 videos!? youtube supports h.264 instead of vp9!? What about ffvp9!? thanks

[brent]

Except that in a world of streaming, it's not you that encodes the video, it's the content provider. And they do have the resources to throw at the problem (even if they won't like throwing them).

Sorry, but that is bullshit. Just because you're a company doesn't mean there are almost infinite resources to throw at a given problem. Electrical energy is expensive, and so is fast hardware. If VP9 is super slow, it may just not be economical to utilize it. And seriously, apart from Google, who uses VP9?

The issue I see here is embedded implementations. We'll get cameras and phones claiming to encode H265 and such, but they'll do it with such lax parameters, the results will be worse that H264 actually.

These devices use hardware encoders, which always have been more optimized for speed than quality. However, both H.265 and VP9 have some powerful tools for improving efficiency that should be hardware friendly. We'll see. Anyway, it's not really comparable to high quality CPU-based encoding required for streaming etc., IMHO.

[bug77]

Sorry, but that is bullshit. Just because you're a company doesn't mean there are almost infinite resources to throw at a given problem. Electrical energy is expensive, and so is fast hardware. If VP9 is super slow, it may just not be economical to utilize it. And seriously, apart from Google, who uses VP9?

First, if you're a company, it's worth it as long as you make more money then you spend on resources to encode/transcode content. Of course this is not a boon, but it isn't a show stopper (as it would be for a home user) either.
Second, this is not strictly about VP9, H265 is just as slow (or in the same ballpark).

[SystemCrasher]

My PC with Athlon BE2350 and nVidia GT 520 can't playback 4k youtube video or 720p@60FPS video without stutter. Only M$ Edge browser can play it just fine. I'm using Archlinux 90% of the time. The 10% is when I need to copy a file out of my Windows 10 (it's on raid0 which is not accessible from linux for reasons). But still, Windows 10 is insanely fast on this 7 years old thing. Nothing else plays 60 FPS video on this.

1) That's where we come to the question why xorg is better to be killed with fire at some point. For the real, this ancient shit is unable to be FAST when it comes to 2D output. Especially if programs do not use numerous workarounds, tricks, extensions and so on. It has been amended a lot, etc... but to be honest, it still suxx a lot as graphics system when it comes to fast output of 2D. And 4K or 60FPs _are_ demanding. Hopefully this explains why most "serious" players are usually prefer to output video via OpenGL. It has been meant for gaming wihch is all about fast output of computed graphics. So it sucks much less in this regard. Yet, I'm not really sure if Linux browsers can match "real" players in this regard. It seems they're bad at it.

You can easily check it by running "top" (or more advanced tool like perf) to see what's going. One of unpleasant discoveries you can have it to see xorg process in top of the list. In worst case, xorg getting CPU-bound on single core and rendering is not decoder-bound, but rather xorg-bound. It can easily hog more resources than decode itself!

2) And like if this was not enough: even if system fits real time and not hits 1000% CPU flatline anywhere, there is yet another pest. It called "vsync". Efforts bringing this insanity into some reasonable state are worth of its own epic tales. Epic battles were there against ancient evil code to get it right. But so far, evil has prevailed. And so, vsync in Linux is something odd at least 50% of time. This means you'll get tearing. Some stuff like decent players using OpenGL or VDPAU output can be better about it. But still it do not have to be taken as granted and can be a rocket science.

Basically, 1) and 2) are both fucking shame of Linux graphic stack so far.

Then there is another "fancy" thing, which fucks up both Linux and Windows equally:

3) Google did something really weird in their DASH player, so the very same video can demand about 2x more CPU power when being streamed via DASH compared to plain classic file streaming. Its really odd same 720P, H.264 plays fine on my notebook without dash but lags like a hell if I would enable DASH. Somehow, this Dynamic "Adaptive" SHit fails to adapt all the time, putting me a show. Slide show, actually. I'm not really sure what these morons meant as "adaptive" but I never seen it being able to actually adapt to the fact it does not fits real time. So, for relatively slow systems it makes a lot sense to disable DASH to the hell. While it cuts off highest-quality options on youtube, at least it gives about 2x more headroom to CPU and at least one can expect decent 720P playback even on slow-CPU system. I really fail to get idea how Google managed to do it so freaking inefficient. At least when you use it together with Firefox. Maybe its Firefox who is bad at it either. Whatever, DASH proven to be resource hog and could work really bad unless you have high-end CPU. And since it manages to suck balls even on 720P@30FPS, I can imagine it can get order of magnitude worse with 4K VP9 and I would not even bet its VP9 decoder takes most CPU time, it can easily be some dumbass DASH overhead.

[xeekei]

VP10 presentation: https://www.youtube.com/watch?v=gkz1ZvejmEc
Daala presentation: https://www.youtube.com/watch?v=g7fVwIZBW8Q
Thor presentation: https://www.youtube.com/watch?v=g6m_N3QlqOI

All presentations are from the recent VideoLAN Developer Days. Daala is coming along nicely, but is at the same time quite far away, finalization is planned for May 2017. Thor isn't meant to ever be complete, it's meant as a test bed for features that'll eventually make NetVC and/or the Alliance codec (Daala has already been stealing Thor features). VP10 is still basically about figuring out new features.

Good talks. The light flicker is annoying though. Somebody forgot to record in 25/50 Hz in a PAL region country.

[plantroon]

1) That's where we come.............................................. ...................magnitude worse with 4K VP9 and I would not even bet its VP9 decoder takes most CPU time, it can easily be some dumbass DASH overhead.

Hell yeah! That was some interesting reading for me. Thanks. All my problems with Linux summed up. My friends were like "You're blind, I get no tearing whatsoever with vsync enabled" but I always got it... well I thought let's replace this ATI card with nVidia. So I did. Better experience, still I got tearing. Nobody believed me again. So indeed Xorg is a bad thing that somehow survived since 70s? Well, I try to use Wayland as much as possible, but window positioning is weird and I have to use nouveau which is not so good. Mir and ubuntu's experimental desktop is unusable as of my last attempt to use it.