[jorvi]

Note that this can lead to horrid economics for the user.

An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU.

It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.

[pradn]

There's definitely some nuance around how many resources to consume at the client vs the server. Video decoding and ML inference are probably at the extreme end of what you can make a client do.

On the whole, since clients are so constrained, it usually pays to be efficient there - make websites load quickly to increase revenue, require only weak hardware to get more game/app sales, etc. Clients are also untrusted, so there's so many things you can only do on the backend.

[izacus]

How is that related to the tradeoff calculation at hand?

Implementing VP9, enabling it, transcoding videos and testing it COST SWE hours, it didn't save them. It also cost resources.

In what way did you envision the VP9 issue being related to SWE/resource hour computations here?

[interroboink]

I think what they're suggesting is that yes, Google spent some SWE hours to implement it, but they have (or will, over time) saved more than that in equivalent compute (by pushing it onto users). So, from Google's point of view, they saved SWE hours on the company balance sheet, so it's a win.

But from the larger point of view of "everyone," this actually made the total cost worse. The cost/benefit analysis from Google's point-of-view was worth it, even though it made things overall worse in the larger perspective. Hence "tragedy of the commons," where the short-sighted behavior of some actors makes things worse overall.

[izacus]

I'm don't think that metric applies here - "SWE years" is when you want for determine whether investing in certain optimisation is worth doing.

In case of VP9, there was no such tradeoff - it used more storage, more CPU time and age SWE hours. What it saved was a very clearly quantifiable financial cost of bandwidth and SWE hour tradeoff didn't have much to do with it.

It would be applicable if the debate would be investing engineering time to speed up VP9 encoder for example.

[pradn]

SWE-years are actually used for two things: a) measuring ongoing cost and b) for calculating if an investment will pay off.

There's a few benefits over just using a dollar figure. It's a unit that natural ties time to value. SWE-years is a natural unit for thinking about the time of SWEs. It's also convertible to other units. The conversion factors to other units can change over time, without having to pay attention to the minutiae.

All these factors make it useful for both measuring ongoing cost and making investment tradeoffs.

[crazysim]

It also saved licensing costs to MPEG-LA too I guess.

[ksec]

They still have to pay for H.264 and the cost of it are peanuts.

[okeuro49]

Do you have an article about this? What is the state now?

[acdha]

They did this during the period where Chrome was eating into Firefox usage, after telling Mozilla that they would drop H.264 in favor of open codecs but never keeping that promise. Here’s some period discussion:

https://www.osnews.com/story/24263/google-h264-stifles-innov...

What this meant in practice was that Firefox would play YouTube videos at close to 100% CPU and Chrome would use H.264 and play at like 5% CPU, and since it was VP8 the quality was noticeably worse than H.264 as well. Regular people talked about that a lot, and it helped establish Chrome’s reputation for being faster.

[ksec]

Unfortunately some 10 years later Google is still pretty much the same with regards to video codec understanding.

Never attribute to malice that which is adequately explained by stupidity. If there was something outside of stupidity, zealotry would be another one. Although I guess one could argue zealotry is also a form of stupidity.

[izacus]

Pretty much every device these days decodes VP9 in hardware.

It's been a long time since I've seen a VP8 video on YT, so I'd assume it's not even used anymore due to worse compression.