I've been experimenting with x265 via ffmpeg, encoding some TV episodes in HEVC. My experience is that it takes 3.5-7 seconds of CPU time to encode 1 second of video. (These are things like 576x432 resolution at roughly 700 kbps, or 704x528 resolution at 530 kbps.)
As for decoding performance, VLC appears to use 30-50% CPU when playing these videos back. (Haven't tried one at uber-high resolution yet.) As far as I'm concerned, if it's fast enough to never stutter, then that's the biggest goal it needs to hit, and beyond that, reducing power consumption is desirable but not too important.
I believe YouTube's VP9 videos are all tiled, so its a shame to not see data for that type of file.
I was looking the other day and was pleasantly surprised by the amount of VP9 content (does it really take them a day to encode a minute of VP9?). The article's numbers also confirm my impression that the VP9 decodes where not much harder on the CPU than the H.264 ones.
I believe Chrome switched to ffvp8 for VP8 decode. I wonder if they'll do it again for ffvp9.
>I was looking the other day and was pleasantly surprised by the amount of VP9 content
How do you know that you recieve VP9 and not VP8, is there some download script for this?
>does it really take them a day to encode a minute of VP9?
I've done lots of encoding tests and it is indeed slow, also the encoder (vpxenc) currently only uses one core, of course you can run several encodings simultaneously to make use of all your cores, but it's certainly a limitation, particularly given how slow the encoder is.
On the brighter side the quality has been improving steadily during my testing over the last 8 or so months, it's certainly beating x264 in many of my tests, however with the huge speed difference in favour of x264, vp9 (and x265) are not yet near competitive in terms of 'practical' encoding in my opinion.
>I believe Chrome switched to ffvp8 for VP8 decode. I wonder if they'll do it again for ffvp9
As long as there aren't any compability issues I can't see why not, that said when playing some of my vp9 test encodings in VLC (which I believe uses ffvp9) I sometimes get decoding errors causing huge macro-blocks etc, when playing through Chrome or if I decode the vp9 stream to another format they play perfectly.
Oh, and I unfortunately missed and downvoted you instead of upvoting you (curse those small arrows!), I apologize and blame the crappy cold I'm currently down with which is making me drowsy.
> How do you know that you recieve VP9 and not VP8, is there some download script for this?
Right-click on a video, click on "Stats for nerds", see if there's VP9 on the "Mime type" line.
> As long as there aren't any compability issues I can't see why not, that said when playing some of my vp9 test encodings in VLC (which I believe uses ffvp9) I sometimes get decoding errors causing huge macro-blocks etc, when playing through Chrome or if I decode the vp9 stream to another format they play perfectly.
Well it will be interesting when x265 (which is the only HEVC encoder I'm interested in as it seems poised to become the x264 equivalent) has had more time to improve, in the last tests I did (which were more than a month ago) it was worse than x264 (and consequently VP9) due to losing a lot of detail, but as stated the encoder is very young and also under heavy development, chances are I would already get very different results if I redid the tests today (currently keeping an eye out for some major improvements before I start testing again).
I was comparing 8-bit x265 against 10-bit x264 a couple weeks back, and was quite impressed - x265 managed to preserve quite a bit more detail than x264 in many places (the previous time I had tested x265 it didn't manage to do even that). However, there were two pretty glaring issues. For one, x265 sucks at dealing with gradients, resulting in horrible banding. Two, as pointed out in the OP post, x265 is slow - I was pitting preset veryslow against preset veryslow (used CRF with x265, bitrate-matched with 2-pass x264), and 8-bit x265 was 5-6 times slower compared to 10-bit x264. Working 10-bit x265 could potentially fix the banding issue, but the speed issue would likely be even worse. There's still quite a few ways to go before using these new formats will be actually practical.
OH God, Dont trust the Marketing BS ( May be they are the same On2 people ) from Google. VP8 will never be able to beat H.264, at least the x264 implementation. And VP9 will be close or on par with x264. But should never be able to match H.265 / x265 if the same quality of x264 is expected.
There is VPx, which Google Market BS will likely say it will exceed H.265. But from the looks of it i guess it will be very close to the best of H.265 implementation once it is out, but not better.
I got downvoted because I pointed out the truth? Guys and Girls, you dont need to believe every word I have said. Download and test it out for yourself. Or go to Doom9 to search for rips or pics to judge for yourselves.
I admire what google is doing to get a patents free ( Which is again not true, but at least you dont have to pay for it ) video codec. But that doesn't mean it is automatically the best quality codec / encoder available.
As for decoding performance, VLC appears to use 30-50% CPU when playing these videos back. (Haven't tried one at uber-high resolution yet.) As far as I'm concerned, if it's fast enough to never stutter, then that's the biggest goal it needs to hit, and beyond that, reducing power consumption is desirable but not too important.