Hacker News Reader

Comment by mikenew | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com