3 ms·

Just curious, what's the memory footprint on the encoder in real life? Do different video encoders, for the same codec, and input produce different outputs, or

by sargun 8y ago

Just curious, what's the memory footprint on the encoder in real life? Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what?

TD-Linux 8y ago
Virtually all of the consumed memory is from the reference frames, so it depends on how big your video is. AV1 supports up to 8 reference frames, though if you're memory constrained you could use less. Different encoders produce different outputs, the algorithm isn't specified.
wolf550e 8y ago
For almost all compression algorithms (both lossless and lossy), only the decompression is specified. A compressor can do whatever it wants as long as it produces a bitstream that a compliant decompressor can decode. For example, you can make a video enocoder that produces a compliant video stream in which every frame is a keyframe and every macroblock is independently fully encoded, thus reducing AV1 (or H265, etc.) to MJPEG. But if the result is decodable by a compliant decoder, your compressor is compliant. It might even be somewhat useful (e.g. output needs to be zero latency or output is intended to be edited).
- tzahola 8y ago
  And this is how people keep making substantial improvements to ancient formats like JPEG or MP3. E.g. Guetzli from Google: https://github.com/google/guetzli/blob/master/README.md https://github.com/google/guetzli/blob/master/README.md
Pissompons 8y ago
> Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what? Someone else answered this but I thought I'd elaborate: A good way to think about a codec is as a toolbox. The specification tells you which tools you can use to build a frame (encoder) and which you must support to turn one into pixels (decoder). Which tools are used in what way makes a huge difference in the output of the encoder, particularly in terms of compression. Have a look at the results for a few H.264 encoders [0]. For the "video conferencing" use-case, the best encoder (x264) uses ~400kbps to produce the same quality of the worst at ~1000kbps. And like different tools have different costs (a jackhammer needs a generator, a handheld hammer does not), so do the tools in the codec toolbox. Some tools might make the encode slower or might make the decode drain more battery from a mobile device. Others might take a lot of physical space on a piece of silicon, so they're rarely used in hardware. So different encoders have very different characteristics, not just in terms of output but in terms of power usage, speed and complexity as well. [0]: http://www.compression.ru/video/codec_comparison/h264_2012/ http://www.compression.ru/video/codec_comparison/h264_2012/
conradev 8y ago
Different video encoders certainly produce different outputs. Even the same video encoders produce different outputs. Here is a good paper that explains why that is, and talks about how to make a deterministic video h264 encoder: http://www.ndsl.kaist.edu/~kyoungsoo/papers/mmsys14.pdf http://www.ndsl.kaist.edu/~kyoungsoo/papers/mmsys14.pdf

by sargun 8y ago

TD-Linux 8y ago

Virtually all of the consumed memory is from the reference frames, so it depends on how big your video is. AV1 supports up to 8 reference frames, though if you're memory constrained you could use less. Different encoders produce different outputs, the algorithm isn't specified.

wolf550e 8y ago

For almost all compression algorithms (both lossless and lossy), only the decompression is specified. A compressor can do whatever it wants as long as it produces a bitstream that a compliant decompressor can decode. For example, you can make a video enocoder that produces a compliant video stream in which every frame is a keyframe and every macroblock is independently fully encoded, thus reducing AV1 (or H265, etc.) to MJPEG. But if the result is decodable by a compliant decoder, your compressor is compliant. It might even be somewhat useful (e.g. output needs to be zero latency or output is intended to be edited).

tzahola 8y ago
And this is how people keep making substantial improvements to ancient formats like JPEG or MP3. E.g. Guetzli from Google: https://github.com/google/guetzli/blob/master/README.md https://github.com/google/guetzli/blob/master/README.md

Pissompons 8y ago

> Do different video encoders, for the same codec, and input produce different outputs, or is the algorithm specified in a way where it produces the same results for two given inputs, no matter what? Someone else answered this but I thought I'd elaborate: A good way to think about a codec is as a toolbox. The specification tells you which tools you can use to build a frame (encoder) and which you must support to turn one into pixels (decoder). Which tools are used in what way makes a huge difference in the output of the encoder, particularly in terms of compression. Have a look at the results for a few H.264 encoders [0]. For the "video conferencing" use-case, the best encoder (x264) uses ~400kbps to produce the same quality of the worst at ~1000kbps. And like different tools have different costs (a jackhammer needs a generator, a handheld hammer does not), so do the tools in the codec toolbox. Some tools might make the encode slower or might make the decode drain more battery from a mobile device. Others might take a lot of physical space on a piece of silicon, so they're rarely used in hardware. So different encoders have very different characteristics, not just in terms of output but in terms of power usage, speed and complexity as well. [0]: http://www.compression.ru/video/codec_comparison/h264_2012/ http://www.compression.ru/video/codec_comparison/h264_2012/

conradev 8y ago

Different video encoders certainly produce different outputs. Even the same video encoders produce different outputs. Here is a good paper that explains why that is, and talks about how to make a deterministic video h264 encoder: http://www.ndsl.kaist.edu/~kyoungsoo/papers/mmsys14.pdf http://www.ndsl.kaist.edu/~kyoungsoo/papers/mmsys14.pdf