
Why Experts Are Wrong About AV1 Being Slow - clouddrover
https://medium.com/@luc.trudeau/why-experts-are-wrong-about-av1-being-slow-1e9bda9f09d4
======
willvarfar
Quite right.

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.

~~~
2StepsOutOfLine
Like [https://github.com/xiph/rav1e](https://github.com/xiph/rav1e) ?

------
tombert
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?

~~~
clouddrover
> _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](https://github.com/OpenVisualCloud/SVT-AV1)

~~~
tombert
That's a great idea, actually. I'll play with that tonight and see if I can
contribute.

------
Ace17
> "with default settings, the AOM encoder is slow, but as we have seen, that
> does not mean that the AV1 format is too slow."

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.

~~~
clouddrover
Cisco AV1. Live AV1 encoding and decoding on a laptop:
[https://blogs.cisco.com/collaboration/cisco-leap-
frogs-h-264...](https://blogs.cisco.com/collaboration/cisco-leap-
frogs-h-264-video-collaboration-with-real-time-av1-codec)

A talk about it with a demo:
[https://vimeo.com/344366650](https://vimeo.com/344366650)

~~~
madez
What is Cisco's motivation for working on video codecs?

~~~
clouddrover
To make their Webex conferencing platform better:

[https://www.webex.com/](https://www.webex.com/)

[https://www.cisco.com/c/en/us/products/conferencing/index.ht...](https://www.cisco.com/c/en/us/products/conferencing/index.html)

------
Someone
_”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)

~~~
clouddrover
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:

[https://vimeo.com/344366650](https://vimeo.com/344366650)

~~~
sp332
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](https://people.xiph.org/~jm/daala/paint_demo/index.shtml)

~~~
derf_
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).

~~~
mntmoss
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).

------
benj111
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.

