I'd be interested in comparisons to https://github.com/xiph/rav1e.
back
1 comments
Rav1e is an encoder. dav1d is a decoder. (Hence the last letter).
Am I right to conclude that av1 takes like 100x+ the duration of the video to encode? Like it's extremely impractical at the moment?
What you are referring to is the encoding time using the libaom reference encoder, which was developed as a research code base to test bitstream features. AV1 (the format) was designed to be used for a variety of use cases including real-time and interactive streaming and it is possible to create a non-libaom based encoder that does so (see the https://github.com/xiph/rav1e project).
And still, for some companies the bandwidth savings of AV1 are worth deploying today even with the longer encode times of libaom. For example, you can try AV1 streams on YouTube right now:
So here is a possibly naive question.
From my viewing of Youtube, Google transcodes uploaded videos (typically H.264 stuff) to VP9 only when a certain view threshold is reached, which makes sense from their perspective.
However, I have also noticed that due to the chain of encodes source -> H.264 -> VP9 (latter two available to Google), the VP9 stream is often of noticeably lower quality. Thus, whenever I can, I use an H.264 stream.
This problem will not go away with AV1. In fact, from an archival/local usage standpoint, as others have noted here, AV1 is pretty much impractical due to heavy encoding time increases that will unlikely go away with SIMD as compared to x265 or x264.
As such, from an end user experience point of view, what does AV1 offer that H.265/H.264 do not already?
YouTube encodes are always done from the source. When new codecs like AV1 are introduced they reencode from the originally uploaded source not from other YouTube encodes.
The immediate benefit of AV1 will be felt by people with decent machines but terrible bandwidth as the higher compression will give them higher quality. There's talks given by YouTube employees about this process when VP9 initially rolled out and how different parts of the globe benefitted depending on their tech and infrastructure levels.
Youtube will transcode your H.264 anyway, AFAIK there's no way to prevent that. Hopefully it also saves original file, so VP9 won't be of worse quality.
As others have said, it is for encode once, decode many scenarios. Same quality, less bandwidth and cpu time spent decoding.
20% less disk space usage compared to H265
Not impractical, just resource intensive. :) IIRC extreme optimizations in favor of the decoder even at the expense of encoder burden was an explicit design goal of the codec, to meet the needs of Netflix-esque 'encode once, decode thousands of times' scenarios.
It depends on what your usecase is. If you are Netflix and you have a show that gets watched 5 million times then having 100x on encoding is no big deal.
However if you want to do live-streaming to a group of friends, its very impractical.
Its only really worth doing a lot of work the encoder once you are sure its not gone change anymore, so work on that is surely ongoing.
Pretty much, yes. Benchmark comparison from April https://wyohknott.github.io/video-formats-comparison/
But do keep in mind that it's competing against x265 (HEVC) which has been on the market around 5 years now, compared to 5mo for AV1 - it's still early days.
Improvements for performance as well as hardware specific versions of the algorithm or parts of generally come a few years after a specific encoding has a first working release. h.265 for example still has room to grow in hardware accelerated encoding, it's very fast. And x265 being software based is much better, but slower.
It takes time.