Encoder tuning Part 4: A 2nd generation guide to aomenc-av1, shooting for the stars!

[FranceBB]

Originally Posted by benwaggoner

Are there really still devices that need --slices 4 for H.264 encoding?
all the players I can think of from the last 10+ years work just fine with single slices.

Probably not, but you know, the spec was there back then and it's still there now.
Could it be tossed? Probably, but you know, who would take the risk when you have something in production that has been like this for years and years and suddenly *poof* you get that 1 customer coming back to you complaining eheheheheh
You know what they say "as long as it works, don't touch it" xD


@Beelzebubu... Thank you so much for the very detailed explanation!
Looks like libaom is already doing all the things I want by default (new sequence header for each keyframe, closed gop, temporal delimiter)!
Very very nice.
Now it's just a matter of me tweaking and trying to optimize it for our trailers (yes, that's gonna be the ONLY thing we'll trial with AV1 when we publish to the web, for now).
It's gonna be a good exercise for... next year!
It's December 23rd, so I think I can safely say this now: Merry Christmas and Happy New Year guys!!

[FranceBB]

Houston, we have a problem.

The encoding is going:


however at 0.1 fps and when I check the task manager...



So... I've implemented AV1 encoding in FFAStrans (the free software I keep working on along with the community) with a simple workflow:



which receives a request via REST API, indexes some XDCAM-50 files with FFVideoSource() and FFAudioSource(), grabs CH.1-2, deinterlaces to 25p if needed, downscales the chroma from yv16 to yv12 creating the AVS Script automatically and then encodes the video in AV1, the audio in Opus, muxing everything in webm, delivers the result and replies to the API request.

The following encoding settings are used:

-strict -2 -c:v libaom-av1 -profile:v 0 -level:v 4.1 -refs 4 -crf 18 -keyint_min 25 -g 25 -enable-cdef true -enable-global-motion true -arnr-strength 4 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -color_range tv -field_order progressive -c:a libopus -b:a 510k -ar 48000 -max_muxing_queue_size 700 -map_metadata -1 -f webm

The question is: is the fact that AV1 uses non square blocks and macroblocks making it hard to parallelize?
I mean, I can play the parallelism card by encoding several contents at the same time rather than 1 at a time of course like I do with x262 for MPEG-2, but seeing a 56c/112th AVX-512 Intel Xeon sit idle with just 1 core at 100% on such a new codec breaks my heart a bit.

Anyway, I'm testing in production and so far so good.

[Selur]

Yeah, parallelism wasn't great with video encoders from google (vp8, vp9 and isn't great in aomenc), I don't think it's format inherent.
Assuming you don't want to switch to another encoder (i.e. svt-av1) you could also use Av1an which uses chunked encoding and seems like a wrapper for ffmpeg.

Cu Selur

[benwaggoner]

Originally Posted by Selur

Yeah, parallelism wasn't great with video encoders from google (vp8, vp9 and isn't great in aomenc), I don't think it's format inherent.
Assuming you don't want to switch to another encoder (i.e. svt-av1) you could also use Av1an which uses chunked encoding and seems like a wrapper for ffmpeg.

YouYube encoding is all about segment-level parallelism, run on whatever cores are free for long enough in Google's cloud. I don't think multithreading has ever been a key scenario for them.

There are AV1 encoders that do provide good parallelization, so I concur it's not codec-specific.

VP8 did have some seriously serialized aspects which hampered multithreaded encode and decode.

[Beelzebubu]

Originally Posted by FranceBB

Houston, we have a problem.
[..]

 -strict -2 -c:v libaom-av1 -profile:v 0 -level:v 4.1 -refs 4 -crf 18 -keyint_min 25 -g 25
 -enable-cdef true -enable-global-motion true -arnr-strength 4 -color_primaries bt709
 -color_trc bt709 -colorspace bt709 -color_range tv -field_order progressive
 -c:a libopus -b:a 510k -ar 48000 -max_muxing_queue_size 700 -map_metadata -1
 -metadata creation_time=now -f webm

Building a bit on what's said above: you're expected to provide parameters for parallelism in your encoder configuration when working with Google encoders. Please look into -tile-rows, -tile-columns etc. - and make sure -row-mt 1 is set also (I don't recall if it's set by default). --threads should be set by default when encoding with FFmpeg. Note that -tile-columns and -tile-rows are in log2 unit, so -tile-columns 3 means exp2(3)=8 tile columns.

Each tile can be encoded independently, so with enough tiles, you can keep a number of cores active in parallel.

[Selur]

@Beelzebub: you can see in FranceBBs screenshot the issue isn't that the cores aren't active, the issue is that they are hardly utilized.
=> only way I see to properly utilize a more cpu power at the same time to get good results faster is chunked encoding.
Tweaking

-t <arg>, --threads=<arg>             Max number of threads to use
--row-mt=<arg>              Enable row based multi-threading (0: off, 1: on (default))
--fp-mt=<arg>               Enable frame parallel multi-threading (0: off (default), 1: on)
--tile-columns=<arg>        Number of tile columns to use, log2
--tile-rows=<arg>           Number of tile rows to use, log2

doesn't really change much here.

[foxyshadis]

Av1an is a really nice little project that supports massively chunked encoding, via (as one option) a real-time scene detector lookahead, and a lot of other niceties in addition. It's more designed for VapourSynth, but simple workflows like that are a snap to convert from Avisynth.

SVT-AV1 on its own has much better thread-utilization capabilities on a single process than aom, but with that many cores it'll still run into limitations.

[FranceBB]

As a bit of an update on this, I've encoded 106 trailers in total from XDCAM-50 and PCM Stereo to AV1 + Opus Stereo, very briefly QCed 'em and they look fine.
Although it's true that a single encode didn't use all the cores on a server (and I have a farm dividing jobs as they come etc), I played the parallelism card in terms of files, so I encoded all 106 trailers at the same time.
This was really part of a trial and I've sent those out to the distribution team who will... uhm... do something with them, dunno, but they will hopefully be distributed to end users if everything is ok.
As for FFAStrans, given that it will be used by other users as well, I'll try tweaking the parameters that Selur suggested above and see how it goes given that I'm trying to find the least painful way to implement the node for the users to be able to use it.

Anyway, thank you everyone for the support, you've been really kind and I'll let you know how the trial went once they'll tell me something (keep in mind that this will now go into distribution and I don't work there, so it's outside of my area, but I'll keep you posted).