Hacker News Reader

Comment by motbob | Hacker News Reader

I would be careful about rooting for a codec that has strengths/weaknesses that are suspiciously tailored to extremely large media-serving companies. By which I mean, Netflix/Google don't care so much about encode time since their scale is so big, and they certainly don't care as much about decode time as users with their precious battery life do.

Just because something is open does not mean it is meant to serve consumers' interests.

View on HN

Netflix and Google definitely care about encoding time precisely because their scale is so big. A 1% increase in encoding time could mean a difference of a tremendous amount of computing time and thus money.

Google and Twitch also care about encoding time, but in a different way - they have strong use cases for real time encoding being possible.

Everyone cares about decoding efficiency - Google wants you to be able to watch more videos and thus more ads. If your battery is dead, you can't watch any ads. Netflix wants you to get hooked on more series. etc.

> Just because something is open does not mean it is meant to serve consumers' interests.

This is true in general, but I really don't see how it applies to this case at all. The big companies have incentives that actually do line up pretty directly with user's interests.

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."

Encoding time takes a backseat.

300% - 500% is indeed a bigger number than 20%. But, that is not proof that it doesn't "serve consumers' interests".

FWIW, 3-5x increase is about what x264 to x265 is for me.

> Netflix/Google don't care so much about encode time

And yet Netflix is working on SVT-AV1 with Intel, which is one of the fastest AV1 encoders available:

https://medium.com/netflix-techblog/introducing-svt-av1-a-sc...

https://www.reddit.com/r/AV1/comments/bxn2uw/svtav1_encoding...

https://github.com/OpenVisualCloud/SVT-AV1

How does that fit with your narrative?

Or Twitch and Google Stadia which live encode with VP9 now and will move to AV1 over the next few years

Netflix encodes and serves a lot of video. So obviously both encode time and low filesizes are important to them. That doesn't change my point that their priorities may be skewed towards lowering filesize moreso than other entities, since they serve more videos per encode.

> and they certainly don't care as much about decode time as users with their precious battery life do.

Of course they do. Google wouldn't sell many Pixels if you could only watch half as much YouTube or Netflix on a single charge compared to, say, an iPhone. Netflix wouldn't sell many subscriptions if you could only watch half as much on a single charge as Hulu or Prime Video either. Your point about encoding is valid, but Google and Netflix are definitely incentivised towards low decoding complexity on the client.

Huh? Have you noticed the stats of how much video is uploaded to YouTube? I won't provide any numbers, due to working there, but a back of envelope calculation should answer the question "how much money does it cost for Google to encode at twice the compute cost".

I think it used to be that Google encoded every video in H.264, but also encoded some videos in VP9: the popular ones. That made a lot of sense--no need to dedicate a lot of encoding power for every video when quick-and-dirty x264 will get the job done fine for >99% of them. And I assume the same will be true for AV1, where only a small percentage of videos will actually be encoded in it. So my envelope calculations aren't going to help me gain much insight.

All are VP9 now.

Reply on news.ycombinator.com