Energy Efficiency of Modern Codecs | Hacker News Reader

Energy Efficiency of Modern Codecs

shkspr.mobi

19 pointsedent11 comments

Codecs are normally defined/specified in terms of the decoding process, not of the encoding one. So if the encoding is one million times slower, it has very little to do with the codec itself and only to do with the encoder and the way it's configured. Even the most recent codecs have encoders that (in some configuration) can operate faster than real time (thereby achieving great energy efficiency) on virtually any application processor.

Furthermore, if energy efficiency is really what you care about, there are hardware encoders and decoders that are extremely energy efficient.

All in all, I guess what I'm trying to say is that I don't understand what is the point the article is trying to make.

It's a thought experiment, sure, but I do think that your point should be weighted in actual analyses. Plus, historically bandwidth grows slower than storage grows slower than processor speed, which should be noted (although like in finance, past performance may not reflect future performance).

Yes, if we cared about energy efficiency of computation, there are much lower hanging fruits than codecs, even besides cryptocurrencies.

And there are much lower hanging fruits than the computation.

Realistically, more advanced codecs do require more computation (or more transistors). Simplified encoders can be fast but they have no compression advantage over older codecs.

To take a concrete example: Zopfli, a slower gzip/DEFLATE encoder. According to Wikipedia: "Under default settings, the output of Zopfli is typically 3–8% smaller than zlib's maximum compression, but takes around 80 times longer.". This article is basically asking: "When should I use this over regular gzip/DEFLATE, and why?", and tries to answer that.

That is indeed a very good example of why the article is unclear in it's aim: zopfli is not a codec, it's an encoder. And furthermore the 80% figure is probably for the default configuration, as zopfli has an -i argument that can make it virtually arbitrarily slow.

This is exactly what I was arguing: comparing encoding speed (and "energy efficiency") of a codec in the way it's done in the article it's basically pointless and misleading. It can be done, but you have to compare specific encoders and decoders, not the codecs per se, and you can only do it meaningfully by measuring different inputs and configurations, as is done e.g. in the squash compression benchmark (that, note, only deals with lossless data compression: lossy data compression is a order of magnitude harder to compare, and video compression is a couple of orders of magnitude harder still because you have to consider delivery as well when designing your benchmark scenarios)

Thanks for the clarification, I now understand what you meant by the article being unclear.

The difference is that energy efficiency of CPUs has continued to improve exponentially fast, whereas we are already nearing asymptotic efficiency limits in things like fiber optics and know that we can't get exponential improvement.

A 1 kW server running for a day is peanuts in carbon cost compared to sending data to millions of people.

Interesting article, but the idea that video transmission meaningfully moves the needle on climate change can be disproven back of the envelope.

My phone uses like, 5w sustained.

The video decoders on fancy new TVs are about the same.

That is essentially all video decoding. It's also encoding for e.g. TikTok or whatever because again, my phone uses 5w.

Many of these are valid question. I wonder if the author has ever by chance read any of my comments scattered across the internet on codec. Because I have been writing and questioning this for many years.

For example, Facebook prefer JPEG XL over AVIF;

>JPEG XL encoding at speed/effort 6 is as fast as JPEG encoding (using MozJpeg with Trellis encoding enabled). This means that it's practical to encode JPEG XL images on the fly and serve to client. This can be compared with the encoding speed of AVIF which necessitates offline encoding which offers much less flexibility when it comes to delivering dynamically sized and compressed content.

This is encoding complexity at scale. Decoding complexity are often discussed in codec development meetings due to the fact CPU performance improvement has slowed down a lot in recent years ( Apple M1 being an outliner here ). You have double the complexity, did we have double the CPU performance improvement?

People often assume hardware decoding = dedicated / low power decoding. Which isn't necessarily true. On Desktop and Laptop you could have hardware decoding using up to 2W if not 4W or more for Semi-GPU assisted. Compared to Smartphone which generally prefer to have average ~0.1W during decoding. This is only for Qualcomm and Apple though. Some other brand may allow much higher power budget.

Then there is the storage requirement question. It makes sense for Netflix, which is a comparatively tiny amount of content, they could serve using any codec they sit fit and have all these different variation to lower bandwidth / provide higher quality. Compared to Youtube, which has more than 500 HOURS of content uploaded every "minute". Adding an additional codec variant will have a different storage cost calculation.

And Bandwidth, quoting Cloudflare;

>During the last ten years, industry wholesale transit prices have fallen an average of 23% annually. Compounded over that time, wholesale bandwidth is 93% less expensive than 10 years ago.

Compared to video codec development, x264 started "pre 2010", to the best AV1 / VVC Encoder ( Not even publicly available ), only provided a maximum of ~64% bitrate reduction ( or 40% reduction per generation )in both subjective and objective test by Moscow State University. Over the span of 15 years, compared to the best and non-widely available, non-widely supported codec we only have a 64% reduction. While bandwidth had 93% reduction in 10 years only.

Obligatory reminder that a carbon tax fixes this so that optimizing your cost also reduces your carbon footprint. Guilt-tripping yourself about efficiency is a waste of your time.

Reply on news.ycombinator.com