Realistically it will probably come down to what's implemented in hardware. Youtube's 4k video in chrome is really a terrible experience when you don't have hardware acceleration for vp8. It pegs your CPU at nearly 100% and god help you if you're viewing a 4k 60fps video.

Luckily it looks like most hardware manufacturers are getting on board with VP9 these days, but the current support for encoding at least is abysmal: https://en.wikipedia.org/wiki/VP9#Hardware_encoding.2Fdecodi...

Browser support is the most important factor for web video. H.265 currently has no browser support but VP9 is supported by Firefox, Chrome, Microsoft Edge, Opera, Vivaldi, etc.

Odds on Safari ever supporting VP9? Especially since Apple are already using HEVC/H.265?

I'd say there's a reasonable chance, and if not VP9 then definitely AV1. The next version of macOS and iOS supports WebP (a still image format based on VP8) so the VP8/VP9/AV1 family has a foot in the door:

1. http://www.cnet.com/news/apple-ios-macos-tests-googles-webp-...

2. https://developers.google.com/speed/webp/

What makes you think that 4k 60fps is even possible without hardware acceleration? That's 12.7 Gbps output bandwidth (assuming true color), barely possible even using just memcpy, let alone decoding.

Interesting point. However, just to be pedantic, if memory bandwidth were the only bottleneck, you'd expect video decoding to generate output faster than memcpy, since it wouldn't have to read as much :-)

My Intel NUC cost me £300 in January and is therefore a fairly low-end machine. It has 307 Gbps of memory bandwidth (2 slots of DDR4-2400). It's surprising how big that number is on a cheap machine today.

I'd love to see a profile of where the CPU time goes in a modern CPU-only video decoder. I guess I could get off my arse and do the profiling myself instead of posting this. Anyway, my guess is that the processor speed is the bottleneck, not the memory bandwidth.

That's mostly partial acceleration. Chips now support a lot of codecs. And aside H264/AVC chips makers cannot afford to use so much hardware surface for codecs that are not so popular.

You must be talking about either a wimpy laptop CPU, a cellphone or a tablet.

Old desktop Sandy Bridge does 4k 60 FPS decoding with no problems, as long as output can sustain it. And integrated GPU does not. You need quite a lot of bandwidth to sustain that much image data.

>You must be talking about either a wimpy laptop CPU, a cellphone or a tablet.

Surely margin-of-error-sized markets to ignore them that easily.

Unfortunately these codecs still have a few important issues (http://www.gpac-licensing.com/2016/07/12/vp9-av1-bitstream-f...). I wish AV1 can fix those but they want to go for such a tight timeline...

It's always weird to read codec commentary from broadcast people; their world and concerns are just so alien to me. I also rather wonder what he considers a raw bytestream that HEVC has and VP9 doesn't...

Anyway, I guess the only major concern from him is the DCT overflow? I mean, for the extra precision, even HEVC has increased from 16-bit intermediates in the newer profiles. I think Daala's transforms would solve his issues with VP9's, I'd imagine they're being considered.

You forgot to mention the skeleton in the closet on vp9's license terms.

It is patent encumbered, by Google owned patents, but they allow free use, so long as you promise to never sue them for patent infringement.

Given how many pies they have their fingers in, that seems like a pretty big catch.