4 ms·

What I think the AV1 initiative neglects as a way of spreading their tech would be giving away a great open implementation of an encoder. x265 and x264 spread t

by mihaic 5y ago

What I think the AV1 initiative neglects as a way of spreading their tech would be giving away a great open implementation of an encoder. x265 and x264 spread their respective codecs all over the internet through pirated content, which forced adoption. The fact that you can play .mkv files almost anywhere now is a testament to that.

planck01 5y ago
I think backing companies like Google and Netflix don't care about that. They need hardware decoding support in phones and TVs, and they will serve av1 from their platforms and save a lot of money. It might become the dominant codec without you even noticing it.
- mihaic 5y ago
  Sure, but I meant that hardware support is implemented if vendors are forced to support something -- such as user downloaded files. Netflix will serve both av1, h265 and h264, so my TV doesn't have to implement av1 support.
  - verall 5y ago
    HW vendors have already/are implementing AV1 because they were on the big consortium and the industry is a bit more grown up now. AV1 is a big compromise between a bunch of vendors. It is definitely the future, the powers that be have already decreed this, but these things move slowly.
- xiphias2 5y ago
  Couldn’t they reuse the tensor cores that are shipped in every device at this point? There are already lots of papers on compressing images using deep learning, I don’t see any reason why the companies couldn’t make a video standard that relies on that hardware.
  - goeiedaggoeie 5y ago
    having a hardware encoder and decoder on a device is super useful for streaming content of that device. Not sure I would want to use other compute for that, that compute is much better used doing CV on the video stream :)
    - xiphias2 5y ago
      Why do you think so? Those tensor processors are actually already optimized for video processing: all of the complex postprocessing in the iPhone camera app is done by the tensor cores inside the M1 chip. I wouldn't be suprised if it would already far be able outperform the mentioned codecs, but of course it needs lots of software development that can only be done by the big companies.
      - Teknoman117 5y ago
        In something like a mobile device, every watt counts. If it takes more energy to decode video on the tensor cores than it does to have a dedicated hardware block, you keep the hardware video decoder.
      - LtdJorge 5y ago
        The iPhone doesn't yet use M1. Besides, post-processing a video is one thing, encoding is completely different. What Apple does with the neural processing is most likely the analysis of the content, not the "editing".
      - motoboi 5y ago
        A codec it’s static, almost not changing at all over a decade. This allow you to implement it as a single purpose hardware which is orders of magnitude more efficient and fast than code running in a multipurpose chip, tensor or not. For things that evolve fast, as deep learning, an programmable chip is the right choice.
jillboyce 5y ago
There is an open source AV1 encoder implementation available: https://github.com/AOMediaCodec/SVT-AV1 https://github.com/AOMediaCodec/SVT-AV1
Paianni 5y ago
No, OS support for H.264 happened because the industry wanted more efficient codecs, and it didn't have much competition at the time. H.265 and AV1 are both competing to replace H.264 and so far neither have a clear lead.
Twirrim 5y ago
There's 3 that I know of, libaom https://aomedia.googlesource.com/aom https://aomedia.googlesource.com/aom, the reference implementation. https://gitlab.com/AOMediaCodec/SVT-AV1 https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising. https://github.com/xiph/rav1e https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places where libaom is too slow.
- mihaic 5y ago
  I have used x265 fairly easily to encode a 4K Bluray. None of the AV1 options seem to have the required performance (both quality and encoding speed) and ease of use.
  - elabajaba 5y ago
    SVT-AV1 has been both faster and higher quality than x265 for awhile now though? For ease of use, you can just use ffmpeg, or one of the many CLIs or GUIs that support AV1 (preferably either Av1an for CLI, or a gui that uses it under the hood eg. nmkoder). https://i.imgur.com/hHs2qz9.png https://i.imgur.com/hHs2qz9.png
  - prvc 5y ago
    This is false, relative to x265, there is some preset which provides both faster encoding and higher "quality", iso-bitrate, across the whole gamut of x265 settings, and I believe x264 as well, although I am not entirely sure about what is available at the extreme inefficient/fast end (the usefulness of which is questionable).
- LtdJorge 5y ago
  Also dav1d
  - LtdJorge 5y ago
    Actually no, dav1d is a decoder
ghostInTheSSH 5y ago
AFAICT AV1 is just a significantly more complex byte stream to create vs h264, especially if you want that byte stream to be meaningfully more compact than h265 created with x265 @ slow. x265 @ slow was already pretty time consuming[1][2]. And x265 itself had a hard time against x264 for years too[3]. So it may not be that the AV1 initiative is neglecting the public encoders and more that the math and algorithms for computing an AV1 byte stream really are that difficult. [1] https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/ https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/ (this is x265 medium, but it has a nice gui) [2] I ran a test 1080P encodes using x264 and x265 slow both CRF 20 via handbrake on my m1 MacBook Air and got ~20FPS, and ~4.4FPS for x264 and x265 slow respectively. On my i7-1165G7 NUC I ran the same test but directly invoked FFmpeg and got ~16FPS and ~4FPS for x264 and x265 slow respectively. [3] This is just a short debate on reddit as an example https://www.reddit.com/r/DataHoarder/comments/lx41cx/x264_vs_x265_in_2021/ https://www.reddit.com/r/DataHoarder/comments/lx41cx/x264_vs...

by mihaic 5y ago

planck01 5y ago

I think backing companies like Google and Netflix don't care about that. They need hardware decoding support in phones and TVs, and they will serve av1 from their platforms and save a lot of money. It might become the dominant codec without you even noticing it.

mihaic 5y ago
Sure, but I meant that hardware support is implemented if vendors are forced to support something -- such as user downloaded files. Netflix will serve both av1, h265 and h264, so my TV doesn't have to implement av1 support.
- verall 5y ago
  HW vendors have already/are implementing AV1 because they were on the big consortium and the industry is a bit more grown up now. AV1 is a big compromise between a bunch of vendors. It is definitely the future, the powers that be have already decreed this, but these things move slowly.
xiphias2 5y ago
Couldn’t they reuse the tensor cores that are shipped in every device at this point? There are already lots of papers on compressing images using deep learning, I don’t see any reason why the companies couldn’t make a video standard that relies on that hardware.
- goeiedaggoeie 5y ago
  having a hardware encoder and decoder on a device is super useful for streaming content of that device. Not sure I would want to use other compute for that, that compute is much better used doing CV on the video stream :)
  - xiphias2 5y ago
    Why do you think so? Those tensor processors are actually already optimized for video processing: all of the complex postprocessing in the iPhone camera app is done by the tensor cores inside the M1 chip. I wouldn't be suprised if it would already far be able outperform the mentioned codecs, but of course it needs lots of software development that can only be done by the big companies.
    - Teknoman117 5y ago
      In something like a mobile device, every watt counts. If it takes more energy to decode video on the tensor cores than it does to have a dedicated hardware block, you keep the hardware video decoder.
    - LtdJorge 5y ago
      The iPhone doesn't yet use M1. Besides, post-processing a video is one thing, encoding is completely different. What Apple does with the neural processing is most likely the analysis of the content, not the "editing".
    - motoboi 5y ago
      A codec it’s static, almost not changing at all over a decade. This allow you to implement it as a single purpose hardware which is orders of magnitude more efficient and fast than code running in a multipurpose chip, tensor or not. For things that evolve fast, as deep learning, an programmable chip is the right choice.

jillboyce 5y ago

There is an open source AV1 encoder implementation available: https://github.com/AOMediaCodec/SVT-AV1 https://github.com/AOMediaCodec/SVT-AV1

Paianni 5y ago

No, OS support for H.264 happened because the industry wanted more efficient codecs, and it didn't have much competition at the time. H.265 and AV1 are both competing to replace H.264 and so far neither have a clear lead.

Twirrim 5y ago

There's 3 that I know of, libaom https://aomedia.googlesource.com/aom https://aomedia.googlesource.com/aom, the reference implementation. https://gitlab.com/AOMediaCodec/SVT-AV1 https://gitlab.com/AOMediaCodec/SVT-AV1 - from the Alliance for Open Media, which Intel is deeply involved with and is spending a lot of time optimising. https://github.com/xiph/rav1e https://github.com/xiph/rav1e - written in rust, also subject to a lot of optimising. It's not complete coverage of all features, intended to be used for places where libaom is too slow.

mihaic 5y ago
I have used x265 fairly easily to encode a 4K Bluray. None of the AV1 options seem to have the required performance (both quality and encoding speed) and ease of use.
- elabajaba 5y ago
  SVT-AV1 has been both faster and higher quality than x265 for awhile now though? For ease of use, you can just use ffmpeg, or one of the many CLIs or GUIs that support AV1 (preferably either Av1an for CLI, or a gui that uses it under the hood eg. nmkoder). https://i.imgur.com/hHs2qz9.png https://i.imgur.com/hHs2qz9.png
- prvc 5y ago
  This is false, relative to x265, there is some preset which provides both faster encoding and higher "quality", iso-bitrate, across the whole gamut of x265 settings, and I believe x264 as well, although I am not entirely sure about what is available at the extreme inefficient/fast end (the usefulness of which is questionable).
LtdJorge 5y ago
Also dav1d
- LtdJorge 5y ago
  Actually no, dav1d is a decoder

ghostInTheSSH 5y ago

AFAICT AV1 is just a significantly more complex byte stream to create vs h264, especially if you want that byte stream to be meaningfully more compact than h265 created with x265 @ slow. x265 @ slow was already pretty time consuming[1][2]. And x265 itself had a hard time against x264 for years too[3]. So it may not be that the AV1 initiative is neglecting the public encoders and more that the math and algorithms for computing an AV1 byte stream really are that difficult. [1] https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/ https://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/ (this is x265 medium, but it has a nice gui) [2] I ran a test 1080P encodes using x264 and x265 slow both CRF 20 via handbrake on my m1 MacBook Air and got ~20FPS, and ~4.4FPS for x264 and x265 slow respectively. On my i7-1165G7 NUC I ran the same test but directly invoked FFmpeg and got ~16FPS and ~4FPS for x264 and x265 slow respectively. [3] This is just a short debate on reddit as an example https://www.reddit.com/r/DataHoarder/comments/lx41cx/x264_vs_x265_in_2021/ https://www.reddit.com/r/DataHoarder/comments/lx41cx/x264_vs...