Hacker News Reader

Comment by mikenew | Hacker News Reader

With ffmpeg 5 using libaom it's actually reasonable. Obviously it depends on quality and whatnot, but I'm able to get about .25X of realtime playback speed with AV1 encoding. The magic switch is setting -cpu-used to something higher than the default of 1, which is go-on-vacation-and-maybe-it-will-finish slow.

Rough example: `ffmpeg -i video.mkv -c:v libaom-av1 -cpu-used 5 av1_test.mkv`

View on HN

On my PC I get .329x of realtime playback speed with AV1, and 4.85x with libx264. So AV1 encoding is 15 times slower than H.264 encoding !

I used ffmpeg "-cpu-used 8" for AV1 (higher than this and I get "Error setting option cpu-used to value X"). I removed the -cpu-used command for H.264 as the encoder defaults to autodetecting the number of threads to max out CPU usage. My CPU is an 8-core 16-thread AMD Ryzen 7 PRO 5750G. My source material was the first 20 seconds of the H.264 blu-ray rip of Titanic. top(1) shows the AV1 encoder uses around 500% CPU (meaning only 5 of the 16 hardware threads are utilized) while the H.264 encoder uses around 1600% (exactly 16 of 16 threads utilized). So there is a lot of potential parallelization optimization that could be exploited. But even assuming perfect scaling from 5 to 16 threads, the AV1 encoder would get to 1.1x of realtime playback speed. It would still be about 5 times slower than the H.264 encoder.

cpu-used is (somewhat confusingly) not for how many threads it uses, but how good the quality of the video should be in a scale from 0 to 9, where 0 is best quality and slowest, and 9 is worst quality and fastest. Very similar to how -preset was used for x264.

https://github.com/AOMediaCodec/community/wiki#how-to-make-e... explains the different settings that most change the speed of encoding.

Shouldn't we be comparing AV1 to HEVC, not H.264? Seems like an unfair comparison. I would expect that AV1 is computationally (and quality-size-ratio) much more comparable to HEVC than to H.264.

If we're going to do AV1 vs. H.264, and complain that AV1 is much slower, we might as well compare XviD and H.264 and complain about the latter.

HEVC is in principle the same as VP9.

AV1 is one generation newer. It was made by merging the projects for VP10, Thor, and Daala.

AV1 is computationally better than HEVC/VP9 and more comparable to H.264. Visually it’s better than either.

We should rather compare AV1 to VVC aka H.266.

Try adding `-row-mt 1 -tiles 2x2`. That will essentially tile the video into parallel streams that can be encoded on different threads. You should get better CPU utilization that way.

I don't think AV1 will ever get to the encoding speed of a codec like h264, because in a very general sense; simpler math is easier to do. AV1 can encode the same information into fewer bits, but that efficiency has a computational cost.

It really depends on what you're doing. If you're trying to livestream it could be a big issue. If you're going to encode a video once and then store it for years, it's probably not a big deal. Totally up to you. For me AV1 has become a pretty good option.

Nah, tiles hurt quality. Use Av1an (or Nmkoder on Windows if you want a GUI) with AOM to multithread the encoding by scene for offline encodes.

For livestreaming, SVT-AV1 1.0 is now usable on good CPUs (eg. AMD 5800x+ desktop CPUs, Intel 12600+ desktop CPUs) at higher CPU presets (8+, depending on your CPU and what you're streaming), just currently no one allows for AV1 ingest for livestreams.

That is not entirely true. Using scene-chunking to multi-thread the encode means that the video buffer can not be transferred between scenes making the start of each scene visually worse in video streaming situations where the bit-rate is capped.

For example, a 2Mbps video stream will usually have a 4Mb video cache that can be used to preload data. Having this video cache means that a 2Mbps video stream can burst up to 6Mbps for one second while still maintaining a 2Mbps cap.

My bad, I assumed -cpu-used controlled the number of threads.

I retried with "-row-mt 1 -tiles 2x2" (keeping "-cpu-used 8" so the benchmark is comparable to my previous test): the encoding speed is 0.443x of playback speed; top(1) shows about 8 of my 16 cpu threads are utilized.

Without "-row-mt 1 -tiles 2x2" the encoding speed was 0.329x. So these options only increases speed by 34%. This doesn't match the increased in cpu utilization of +60% (5 to 8 threads). Contention on shared data structures? Looks like it's better to just spawn multiple ffmpeg instances working on different source files instead of leveraging the encoder's multi-threading. That way I could get close to 1x of playback speed.

I have 3500 hours of video content. At 1x I need 5 months to reencode all. Heavy. But doable I guess.

What cpu do you have?

Reply on news.ycombinator.com