The author, monty, is an inspiration for his ability to patiently break down and explain deep topics. It's a rule that every time something of his hits HN someone must post a link to the following video of his, as a benchmark of quality for other technical presentations: https://xiph.org/video/vid2.shtml
AV1 encode times are, compared with h264, very slow. Encoding 4k video on a dual socket Xeon server of 30min in length took almost four days last time I tried. That's probably why you can't find much yet.
Yes, now with the bitstream finally frozen I'm hoping we'll see a flurry of effort in optimizing aomenc.
I'm also hoping there will be a future xAV1 encoder from the x265 developers, a while back a spokesperson for them over at the Doom9 forum said that they will go where the market goes, and from the looks of it, AV1 will eventually become the new de facto video codec on the internet (which is currently h264).
> AV1 will eventually become the new de facto video codec on the internet (which is currently h264)
As much as I would like to agree with this, I think we should expect H.264 to be the de facto codec for quite a while longer. Consider the following:
* An industry research group's 2017 survey [0] showed us that most users still only stream at 720p and that will probably not change in the immediate term. When 4K is the norm, we'll have a glaring need for AV1.
* That same Harmonic 2017 survey also showed that most distributors don't plan to leave H.264 because it is serving their needs just fine.
* x264 only got to where it is today after nearly 10 years of active development. I remember how painful it was to encode H.264 with open source tools in the beginning. Most distributors will not want to take the plunge immediately into AV1 until x264-style stability and acceptance are imminent.
AV1 isn't just for 4K, though. Netflix recently showed a demo of 720p AV1 at only 200kbps. It should massively improve the low end - in fact, maybe the low end first because lower resolution streams are the fastest to encode.
Is the bitstream actually frozen now?
There was a weird "AV1 is there" message recently and then some comments saying, "but not really, bitstream is still not frozen". I saw several claims of bitstream freeze, but never sourced by any official statement.
As someone who's not deep into AV1, but watching interested from outside, I can say that communication is not ideal.
> As someone who's not deep into AV1, but watching interested from outside, I can say that communication is not ideal.
That former announcement was PR/Marketing only. The devs (all the ones I saw) didn't know it was coming.
Yes, the bitstream is frozen. I can't find an HTML version for some reason, but this page links to the finalized 1.0 version of the spec: https://aomediacodec.github.io/av1-spec/
It seems that ffmpeg 4.0 supports av1, but only via the reference encoder. The faster rav1e encoder isn't a bundled option... ( https://github.com/xiph/rav1e )
However that does make me hopeful that I could annotate the start delay for each track, split off the video track, and re-combine an externally encoded video stream.
How does it compare to hevc with preset veryslow? An Epyc server gets about 2FPS (but I've found it most efficient to run 2 jobs that both get about 2FPS simultaneously).
Even non-hardware-accelerated H.264 encoding is very fast via the libx264 library.
"Very fast", in my opinion, means encoding good-quality (better than hardware accelerators!) 4K video faster than real-time on hardware reasonable attainable in a $1000-$1500 desktop system.
Most content isn't encoded with hardware encoders due to their rather poor performance vs. bitrate. If you don't need to do realtime encodes, using HW encoders is a huge waste of bitrate (and by extension money for bandwidth).
Sorry, they're very likely running A/B testing of some sort, as this link was AV1 (Codecs: avc1.64002a (299) / mp4a.40.2 (140)) for me earlier, but no longer:
