5 ms·

This is awesome. I started tracking AV1 and TLS 1.3 1.5 years ago and they arrived within days of each other. I hope AV1 will get the kind of love that got us

This is awesome. I started tracking AV1 and TLS 1.3 1.5 years ago and they arrived within days of each other. I hope AV1 will get the kind of love that got us the x264 encoder. EDIT: my timeline was slightly off and reworded is make it clear I understand the difference between spec and implementation.

m1el 9y ago
It's a nitpick, but a necessary one. x264 is a codec. An implementation of H.264 standard. x264 is loved because it is very optimized and fine-tuned. There are plenty of H.264 implementations that aren't. We're probably not going to see AV1 implementations on the same level as x264 for at least a few years.
- FullyFunctional 9y ago
  I am COMPLETELY aware of the difference and I was deliberate in writing that. We need the kind of love, hard and excellent work on AV1 software (encoder is the harder, being open ended) that brought us the x264 encoder. AV1 decoders will come aplenty I have no doubt and I'm hoping for a good FPGA implementation.
- deleted 9y ago
  [deleted]
- aroman 9y ago
  That was entirely the point of the comment that you replied to correct.
- Shtirlic 9y ago
  It's correct that av1 based on vp9? So vp9 codecs exists and can be used as start for av1 implementation?
  - BTeam 9y ago
    The base was VP10 + tools from Thor (Cisco) and Daala (Xiph.Org/Mozilla), and it evolved from there to AV1 through a process of "experiments", test, IP checks and then its enablement. Assuming that VP10 shares a significant base design with VP9 it would not be surprising if some part of VP9 sillicons decoders could be leveraged on customer hardware, while awaiting for more dedicated circuits. But on the software end, libaom (AOM reference implementation) is indeed a fork of libvpx. But this library is not broadly considered a good implementation, even for VP9. Pehaps the guys behind EVE for VP9 [1] will produce an AV1 implementation based of their codebase. [1] https://www.twoorioles.com/eve-for-vp9/ https://www.twoorioles.com/eve-for-vp9/
    - floatboth 9y ago
      Hopefully fast implementations won't be proprietary like EVE is.
- gribbly 9y ago
  >We're probably not going to see AV1 implementations on the same level as x264 for at least a few years. True, on that note, over at the Doom9 forums, the x265 spokesperson there said that they will consider making a AV1 encoder should there be a market. Given the massive amount of support gathered for AV1 from web and hardware giants, and how it's a royalty free codec and thus in a great position to be the next generation 'de facto' video standard on the web, I'd wager there is a good market for a third party encoder from excellent developers like those behind x265.
BTeam 9y ago
VideoLAN's president, jbkempf, was considering finding manpower to build an AV1 implementation a couple months ago. Not sure of the status now.
- jmvalin 9y ago
  There's already a Rust AV1 encoder project you might want to look at: https://github.com/xiph/rav1e https://github.com/xiph/rav1e
  - BTeam 9y ago
    Indeed! This implementation was started by some people working on AV1 to test libaom's specification implementation correctness. There was a presentation about it at VDD17, if I remember correctly.
  - FullyFunctional 9y ago
    Interesting, but since I could conceivably be exposed to a malicious AV1 stream, I'd value a Rust AV1 decoder even more (which might exist, I don't know).
    - TD-Linux 9y ago
      That's a very good point. I chose Rust more to get ergonomics and more reliable threading - security was not the primary motivation. That said, the encoder is exposed directly to the web via the MediaRecorder API.
  - lossolo 9y ago
    > There's already a Rust AV1 encoder 80% of codebase is C. How is that Rust encoder? Seems like a binding to C AV1 encoder.
    - jmvalin 9y ago
      The C part is mostly for low-level functions and was brought in to help bootstrap development (it's easier to work on improving a working encoder than one that doesn't work yet). The amount of Rust code is expected to increase a lot over time, while the amount of C code is expected to either decrease or remain constant.
FullyFunctional 9y ago
Can't edit anymore, but as Daemon404 points out. It's a paper release. Nothing to see here, move along.

m1el 9y ago

It's a nitpick, but a necessary one. x264 is a codec. An implementation of H.264 standard. x264 is loved because it is very optimized and fine-tuned. There are plenty of H.264 implementations that aren't. We're probably not going to see AV1 implementations on the same level as x264 for at least a few years.

FullyFunctional 9y ago
I am COMPLETELY aware of the difference and I was deliberate in writing that. We need the kind of love, hard and excellent work on AV1 software (encoder is the harder, being open ended) that brought us the x264 encoder. AV1 decoders will come aplenty I have no doubt and I'm hoping for a good FPGA implementation.
deleted 9y ago
[deleted]
aroman 9y ago
That was entirely the point of the comment that you replied to correct.
Shtirlic 9y ago
It's correct that av1 based on vp9? So vp9 codecs exists and can be used as start for av1 implementation?
- BTeam 9y ago
  The base was VP10 + tools from Thor (Cisco) and Daala (Xiph.Org/Mozilla), and it evolved from there to AV1 through a process of "experiments", test, IP checks and then its enablement. Assuming that VP10 shares a significant base design with VP9 it would not be surprising if some part of VP9 sillicons decoders could be leveraged on customer hardware, while awaiting for more dedicated circuits. But on the software end, libaom (AOM reference implementation) is indeed a fork of libvpx. But this library is not broadly considered a good implementation, even for VP9. Pehaps the guys behind EVE for VP9 [1] will produce an AV1 implementation based of their codebase. [1] https://www.twoorioles.com/eve-for-vp9/ https://www.twoorioles.com/eve-for-vp9/
  - floatboth 9y ago
    Hopefully fast implementations won't be proprietary like EVE is.
gribbly 9y ago
>We're probably not going to see AV1 implementations on the same level as x264 for at least a few years. True, on that note, over at the Doom9 forums, the x265 spokesperson there said that they will consider making a AV1 encoder should there be a market. Given the massive amount of support gathered for AV1 from web and hardware giants, and how it's a royalty free codec and thus in a great position to be the next generation 'de facto' video standard on the web, I'd wager there is a good market for a third party encoder from excellent developers like those behind x265.

BTeam 9y ago

VideoLAN's president, jbkempf, was considering finding manpower to build an AV1 implementation a couple months ago. Not sure of the status now.

jmvalin 9y ago
There's already a Rust AV1 encoder project you might want to look at: https://github.com/xiph/rav1e https://github.com/xiph/rav1e
- BTeam 9y ago
  Indeed! This implementation was started by some people working on AV1 to test libaom's specification implementation correctness. There was a presentation about it at VDD17, if I remember correctly.
- FullyFunctional 9y ago
  Interesting, but since I could conceivably be exposed to a malicious AV1 stream, I'd value a Rust AV1 decoder even more (which might exist, I don't know).
  - TD-Linux 9y ago
    That's a very good point. I chose Rust more to get ergonomics and more reliable threading - security was not the primary motivation. That said, the encoder is exposed directly to the web via the MediaRecorder API.
- lossolo 9y ago
  > There's already a Rust AV1 encoder 80% of codebase is C. How is that Rust encoder? Seems like a binding to C AV1 encoder.
  - jmvalin 9y ago
    The C part is mostly for low-level functions and was brought in to help bootstrap development (it's easier to work on improving a working encoder than one that doesn't work yet). The amount of Rust code is expected to increase a lot over time, while the amount of C code is expected to either decrease or remain constant.

FullyFunctional 9y ago

Can't edit anymore, but as Daemon404 points out. It's a paper release. Nothing to see here, move along.