3 ms·

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 lit

by cafxx 5y ago

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.

zinekeller 5y ago
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).
kozikow 5y ago
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.
wmf 5y ago
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.
Zababa 5y ago
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.
- cafxx 5y ago
  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)
  - Zababa 5y ago
    Thanks for the clarification, I now understand what you meant by the article being unclear.

by cafxx 5y ago

zinekeller 5y ago

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

kozikow 5y ago

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.

wmf 5y ago

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.

Zababa 5y ago

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.

cafxx 5y ago
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)
- Zababa 5y ago
  Thanks for the clarification, I now understand what you meant by the article being unclear.