VP9 is getting a lot better. Since the advent of the -frame-parallel and -tile-columns options, encoding scales well with CPU cores. The only frustrating thing for me is these aren't used by default. The VP9 encoding guide has info on their use: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

On my i7-2600k, encoding a Blu-ray takes about 10-12 hours for H.265 or 18-20 for VP9 with handbrake's default 1080p settings for each.

So yea, quite a bit slower, at least on my old hardware.

I still go with VP9, though. I don't buy that many movies, and leaving it running in the background doesn't seem to make a big impact on gaming.

I should also mention that my BIOS has a performance setting that can be "Energy Saving", "Normal", or "High Performance", and I keep mine on "Energy Saving".

Kicking it up a notch or two could undoubtedly boost the performance a bit, and a manual overclock should go even further. (My chip is stable at 4.7Ghz, but it consumes way too much power to leave it there all the time - the computer idles at ~70 watts on "Energy Saver" mode!)

I jumped from your chip to a 6 core Broadwell-E and it seems to give me about 15% more performance out of x264 encoding and 5% from x265.

I see the same jump from C4 to C5 Amazon machines. I'd love to chat about encoding with you at some point.

Yikes! Is that 5-15% normalized to per-core performance, or does it really get almost 0 benefit from having 50% more cores?

That difference from C4 to C5 makes more sense given that they each have the same number of cores available and it was a smaller generational gap.

Send me an email sometime if you'd like - nathan@[my username].com

As a reply to other threads that ask if this means Apple will switch to AV1: encoding speed is the number one reason presented as a benefit of HEVC in one of the WWDC talks on HTTP streaming. So... I'd guess they'll still record things in HEVC, but maybe add support for decoding AV1.

Encoding speed right now is: either you have a computer cluster or you'll die before the encoding is done. But it will probably get better.

It's true that the encoder is very slow at the moment, but it's also true that Bitmovin managed to produce a live AV1 stream 9 months ago:

https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live...

They also have an AV1 demo page which works with Firefox Nightly:

http://demo.bitmovin.com/public/firefox/av1/

If they haven't tried optimizing encoding speed yet, how can they be sure there isn't some misfeature in the standard that will hinder high-speed encoding? Like IIRC with some old On2 codec, where the order of the tokens in the encoded stream was not ideal for an optimized implementation.

They don’t care. It’s Google, Netflix, and Amazon and their concern is recurring bandwidth, not onetime cpu costs.

http://www.streamingmedia.com/Articles/Editorial/Featured-Ar...

"We will be satisfied with 20% efficiency improvement over HEVC when measured across a diverse set of content and would consider a 3-5x increase in computational complexity reasonable."

Some of the Alliance members want to use it for video chat (e.g. Cisco, Google) or live streaming (e.g. Twitch/Amazon, Google) so it'll get done at some point.

I can see their point (and that of any other content provider) in that context, but I'm sure they do care. It would be fine even if it required a dedicated hardware encoding bloc, but lack of reasonable RT encoding (including low wattage) would create a significant technical impediment to full general adoption, so I can't believe that optimization hasn't been at least somewhat considered. There is of course still plenty of real time streaming that's important, though in those cases reduction in quality would often be an acceptable tradeoff. However, Apple and Google both have a quite reasonable and absolute need for real time (or a close enough cheat), high quality offline encoding on mobile systems within the physical constraints of a handheld form factor. End users will also want to (again, quite reasonably) be able to immediately share what they make without the need for a lengthy reencoding stage or trip through a middleman.

So if there wasn't at least a timeline for 4k+ RT on iPhone or Android devices I can't see how HEVC wouldn't stick around for a very long time. That a live stream has already been demonstrated should mean that this has been considered and they do care though, and thus won't be a problem. Ideally of course at least the high end of current generation devices would be capable of AV1 recording through software updates, which would enable moving on much more rapidly from HEVC. For that at least though I think it'd be an acceptable tradeoff to have those become legacy if that's what it takes to get us into a patent-unencumbered future afterwards. A pity software patents couldn't have just been eliminated entirely but I guess that remains politically infeasible for now.

It's not onetime CPU costs, at least for Google. Netflix and amazon don't process that much video (relatively), so they can afford slow encode times, but youtube gets tons of video uploaded every minute, they want fast and cheap encoding.

For each individual video, it is a onetime CPU cost, but not a onetime bandwidth cost.

For ongoing operation of the platform, at scale, you might argue that it's an ongoing CPU cost as more and more videos are added constantly, but the bandwidth to distribute those videos goes up at an equal rate on average.

I don't know any actual numbers, but it seems very plausible to me that a vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off.

If you're making an argument that availability of CPU power at that scale is a concern, it seems like YouTube has the option of Google's cloud services as an excellent candidate for massive, interruptible compute power.

It's not just bandwidth cost. Google suggests their big win with VP9 deployment is reaching people across the globe with relatively powerful computers but terrible internet connections. By using more powerful compression (paying for it with more computing work at both ends) they can get higher quality video to these users.

And from a blunt business perspective: Higher quality videos = more watch time = platform dominance = more ads viewed.

> vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off

I don't think that this would be true, though. Recall the 80-20 rule. They have to encode (CPU) a lot of videos, which will get very few views (bandwidth).

Not really. It’s the long tail. The most popular videos are (in addition to likely being ultra resolution like vevo media’s) watched many (8-10?) orders of magnitude more times than the least popular videos. Bandwidth matters, cpu doesn’t.

It’s actually the same 80-20 rule. Eighty percent of the costs come fro serving twenty percent of their videos:)

That is a real risk - however, this time around people are already working on their own fast implementations (both software and hardware versions), so a lot of the dumb mistakes will already be avoided. There is also the risk of a lot of features being too slow to use at all in a fast encoder, but that's not a risk exclusive to AV1. HM (the reference H.265 encoder) was far too slow to be practical, and given the current speeds of H.265 encoders compared to H.264 at their best quality settings, it's not clear that they totally succeeded.

Until the bitstream is frozen, there is basically zero work on optimization.