But the adoption of video formats is hampered by the lack of a fast en/decoder.
The people pushing for the adoption of one or anther codec really ought sink their time and money into making ffmpeg work really well.
They gain nothing from saying "it could be really fast" when all people looking for a format to use for something have is a slow reference implementation.
Q: Will any part of Cisco's AV1 encoder be released as open source?
A: Not in the immediate future. Maybe in the far future we will do something like OpenH.264. We'll also have to see what the adoption pattern looks like.
So for practical purposes their encoder isn't available and you can't point people to it.
Also low-latency high-bandwidth encoding is different from the typical use case where you just want smaller video files, so again kind of misleading.
2. Intel's SVT-AV1. A highly scalable AV1 encoder. It will use as many cores as you can give it. Netflix is also working on it: https://github.com/OpenVisualCloud/SVT-AV1
4. Cisco AV1. Closed source. It's the best live encoder yet shown. Only takes it about one and a half cores on a recent laptop to do a live AV1 video call at 1080p30, both encoding and decoding: https://vimeo.com/344366650
I really really really want AV1 to be successful, since I would prefer if all my infrastructure were unencumbered by patents, but until we can get a reasonably fast encoder working in FFMPEG, I'm basically blocked on using it. My current encoding infrastructure for blu-ray backups is a simple script I wrote that uses ffmpeg to convert rips into h264 and flac, and stream with Emby.
Keep in mind, that for me, it doesn't have to be fast...I'd put up with an encoder that performs around 5-10fps on an ODroid board. As it stands though, with libaom, I'm getting around 0.25fps, which is too slow.
I really wish I knew more about the guts of video encoding...I would really love to help get AV1 off the ground for the average consumer. Does anyone here know a way that I could help?
You could test Intel's SVT-AV1 encoder and report any issues to them. SVT-AV1 will scale to as many cores as you can give it. It's still quite fragile and buggy, but in fairness it's only at version 0.6:
That particular niche probably won't be conquered until hardware encoders come to GPU. In the meantime you might be able to get hardware accelerated VP9 encoding on some devices if patents are important.
It's a slightly unfortunate situation that VP9 got overshadowed by AV1. If Apple had got on board with it at the time we'd already have a royalty free codec utopia.
But no point crying over spilt milk, hopefully they follow through on AV1 as they are rumored/expected to.
I actually tried VP9; while the hardware encoders might be great, the software encoders were literally an order of magnitude slower than libx264 on an ARM SBC; libx264 gets around 8fps in software mode on there, while VP9 was getting around .5-.9fps.
I typically prefer software encoders since they tend to give you more configuration options, and AFAIK the ODroid XU4 series doesn't have any hardware support for VP9 anyway, which limits my options.
I definitely agree that it's a pitty that VP9 kind of got lost in the mix; it's a great codec, and typically offers a bit better compression than h.264.
That was the whole thing that really irradiate me, they started the whole campaign, purposefully or not market / misled many as the other side are patents ridden, and they are patents free. I believe even their marketing team did not realise it until 2018. And just to be clear, both AVC and HEVC do have OSS Encoder. So it really boils down to royalty issues.
”More coding tools don’t make formats slower, they have the potential to make them faster.”
That’s not quite true. If your encoder has more options, encoding what option you chose takes more bits. That means that picking only options that were available in older encoders produces a (slightly or less slightly, depending on how many times you change encoding strategy) larger file.
So, to get equal image size, you may have to pick newer options, which may be slower (and, AFAIK, often are, in exchange for better compression/higher image quality)
It sounds counter-intuitive, but Cisco found that having more coding tools available actually helped their live, low latency video encoding use case for video conferencing and screen sharing. They discussed it in their presentation at Big Apple Video:
GP is right though. It's possible to add options that don't pay for themselves in terms of the entropy of encoding "don't use option X here." Here's an example of a feature that didn't make it into the Daala codec: https://people.xiph.org/~jm/daala/paint_demo/index.shtml
It's possible, but with adaptive probabilities, the cost for never using a feature is pretty negligible (roughly O(log N) bits of overhead to learn that the probability is ~zero, where N is the number of times you code the symbol... and potentially even smaller depending on your initial probability).
Intra paint was not defeated because of the cost of entropy coding "don't use feature X here", it was defeated because due to "lapping and block size alignment issues, we cannot just turn it on and off when we want" (last paragraph of the "Pretty Images" section).
It's analagous to optimizations for resource-starved systems. If you have trouble processing 16 of something, you don't really benefit from improving the O(n) at the cost of higher overhead, you benefit from the same algorithm processing each item twice as fast. Linear micro-optimizations rule the world.
Being able to use lots of tools and hybridize your engineering to get relatively bigger savings is a result of having the headroom for algorithmic complexity to start ruling, which for video might be a relatively recent phenomenon(I don't actually know the domain).
I'm no expert in these things, but I find the comparisons to language unconvincing.
Eg if 'Pneumonoultramicroscopicsilicovolcanoconiosis' exists, decoders have to know about it regardless of whether its used, it does have a cost, and arguing its ok because it isn't used seems strange from a security/bug finding pov.
24 comments
[ 3.4 ms ] story [ 62.2 ms ] threadBut the adoption of video formats is hampered by the lack of a fast en/decoder.
The people pushing for the adoption of one or anther codec really ought sink their time and money into making ffmpeg work really well.
They gain nothing from saying "it could be really fast" when all people looking for a format to use for something have is a slow reference implementation.
OK, so there's currently no proof that AV1 is slow.
But arguing that "it could be made fast" is actually propagating the idea that "currently, it's slow".
There's no better way to convince everyone than pointing to an existing fast implementation.
A talk about it with a demo: https://vimeo.com/344366650
https://www.webex.com/
https://www.cisco.com/c/en/us/products/conferencing/index.ht...
Q: Will any part of Cisco's AV1 encoder be released as open source? A: Not in the immediate future. Maybe in the far future we will do something like OpenH.264. We'll also have to see what the adoption pattern looks like.
So for practical purposes their encoder isn't available and you can't point people to it.
Also low-latency high-bandwidth encoding is different from the typical use case where you just want smaller video files, so again kind of misleading.
1. Alliance for Open Media's libaom: https://aomedia.googlesource.com/aom/
2. Intel's SVT-AV1. A highly scalable AV1 encoder. It will use as many cores as you can give it. Netflix is also working on it: https://github.com/OpenVisualCloud/SVT-AV1
3. Mozilla's rav1e encoder. Implemented in Rust. Vimeo is also contributing to it: https://github.com/xiph/rav1e
4. Cisco AV1. Closed source. It's the best live encoder yet shown. Only takes it about one and a half cores on a recent laptop to do a live AV1 video call at 1080p30, both encoding and decoding: https://vimeo.com/344366650
5. EVE-AV1. Closed source from Two Orioles (https://www.twoorioles.com/). It's aiming to be the best quality AV1 encoder available: https://vimeo.com/344663992
6. Visionular Aurora (https://www.visionular.com/). Closed source. Aims to be better than libaom on both speed and quality: https://vimeo.com/344633364
Pick the one you like and don't feel misled.
Keep in mind, that for me, it doesn't have to be fast...I'd put up with an encoder that performs around 5-10fps on an ODroid board. As it stands though, with libaom, I'm getting around 0.25fps, which is too slow.
I really wish I knew more about the guts of video encoding...I would really love to help get AV1 off the ground for the average consumer. Does anyone here know a way that I could help?
You could test Intel's SVT-AV1 encoder and report any issues to them. SVT-AV1 will scale to as many cores as you can give it. It's still quite fragile and buggy, but in fairness it's only at version 0.6:
https://github.com/OpenVisualCloud/SVT-AV1
It's a slightly unfortunate situation that VP9 got overshadowed by AV1. If Apple had got on board with it at the time we'd already have a royalty free codec utopia.
But no point crying over spilt milk, hopefully they follow through on AV1 as they are rumored/expected to.
I typically prefer software encoders since they tend to give you more configuration options, and AFAIK the ODroid XU4 series doesn't have any hardware support for VP9 anyway, which limits my options.
I definitely agree that it's a pitty that VP9 kind of got lost in the mix; it's a great codec, and typically offers a bit better compression than h.264.
You do realize AV1 is only Royalty free and not patents free?
That’s not quite true. If your encoder has more options, encoding what option you chose takes more bits. That means that picking only options that were available in older encoders produces a (slightly or less slightly, depending on how many times you change encoding strategy) larger file.
So, to get equal image size, you may have to pick newer options, which may be slower (and, AFAIK, often are, in exchange for better compression/higher image quality)
https://vimeo.com/344366650
Intra paint was not defeated because of the cost of entropy coding "don't use feature X here", it was defeated because due to "lapping and block size alignment issues, we cannot just turn it on and off when we want" (last paragraph of the "Pretty Images" section).
Being able to use lots of tools and hybridize your engineering to get relatively bigger savings is a result of having the headroom for algorithmic complexity to start ruling, which for video might be a relatively recent phenomenon(I don't actually know the domain).
Eg if 'Pneumonoultramicroscopicsilicovolcanoconiosis' exists, decoders have to know about it regardless of whether its used, it does have a cost, and arguing its ok because it isn't used seems strange from a security/bug finding pov.