Log in

View Full Version : SVT-AV1 (vs x265): seeking for suggestions


Losko
6th November 2020, 23:44
I was doing some encoding runs recently in order to evaluate SVT-AV1 performance.
My test is based upon a single scene - a rainy scene, so a pretty complex one - in form of a y4m file, yuv420p 1200x720, ~ 6100 frames (>7 GB).
As a reference, I encoded the scene using x265 (crf 20, preset is someway between slower and veryslow) in a nice small file (28.6 MB) and the quality is quite high: I almost can't see artifacts.
x265 --preset veryslow --crf 20.0 --y4m input.y4m --limit-refs 1 --limit-modes --tu-intra-depth 4 \
--tu-inter-depth 4 --selective-sao 2 --output output.265
On the other side, for libsvtav1 (used through ffmpeg) I used cqp bitrate control, preset 4 and started the encoding with -qp 26, which resulted in a poor video, full of horrible blocks.
Then I tried -qp 24, then -qp 20, then -qp 18, and finally -qp 16.
ffmpeg -loglevel verbose -i input.y4m -vcodec libsvtav1 \
-keyint_min 25 -la_depth 16 -rc cqp -qp 26 -preset 4 -y output.mkv
Step by step, I can see image quality increasing BUT still it isn't on par with x265's. Though, at -qp 16 the file size is already 30 MB, so more than what I assumed to be the maximum acceptable.
Then I tried switching to preset 3 (which halves the encoding speed) expecting more compression but the result was almost the same - similar file size, un-negligible image artifacts.

I can't stand the idea of this encoder unable to reach the same result of x265 (ok, x265 has been years in development, and this matters of course) so I think I should tune my command line.
I wouldn't go down further with preset, as the encoding can take forever, but at the same time don't like the idea of less quality parameter as well, as it makes the output file grow more and more.
Also, I think reducing keyint_min can increase visual quality, BUT also the final file size.
Now, I am open to suggestions to fine tune the encoding settings NOT in order to get a smaller file with astonishing quality - maybe this file being challenging indeed - but getting the same size with similar quality, well, I would finally call this a good result.

Blue_MiSfit
7th November 2020, 06:40
You sure you have the latest code?

Losko
7th November 2020, 09:12
From x265:
x265 [info]: HEVC encoder version 3.3+4-87b405d142ae
(this is quite old)


From ffmpeg:
SVT [version]: SVT-AV1 Encoder Lib v0.8.5-65-gf1bff042
(a few days old)

Sorry, I should have mentioned both those.

Beelzebubu
7th November 2020, 13:09
Can you post a screenshot of the artifacts? It reminds me of a bug in the past related to keyframe handling:

--keyint integer [Optional]

The intra period defines the interval of frames after which you insert an Intra refresh. It is strongly recommended to use (multiple of 8) -1 the closest to 1 second (e.g. 55, 47, 31, 23 should be used for 60, 50, 30, (24 or 25) respectively). When using closed gop (-irefresh-type 2) add 1 to the value above (e.g. 56 instead of 55).

Since -keyint-min is not a multiple of 8 and -g (ffmpeg's --keyint) is not specified, I don't know what the default is, and this may be causing issues. You can try -irefresh-type 2 also, of course, or whatever the ffmpeg equivalent is. Obviously, make sure keyframe interval is the same between the two encodes, otherwise it'll be hard to compare compression efficiency.

Losko
8th November 2020, 13:50
(in the meanwhile I updated the library to SVT-AV1 Encoder Lib v0.8.5-71-g2936d575 )


https://i.ibb.co/tqG3Gn4/1-raw-source.png (https://imgbb.com/)
https://i.ibb.co/P49mQS2/2-x265.png (https://imgbb.com/)
https://i.ibb.co/1RBKBD0/3-libsvtav1.png (https://imgbb.com/)

Even using preset=4, qp=16 and keyint=23 I can't see any improvement. Still large flat areas and an exaggerated blurry feeling all the way.

About -intra-refresh type, it seems this option is only provided by libx264.

Greenhorn
8th November 2020, 19:19
Just butting in-- SVT has never seemed very good at grain retention (even among AV1 encoders) to me, either. The lack of any really effective AQ doesn't help.

If you want to persist with it, you'll probably want to plumb into the standalone CLI encoder, which has many many many options that the ffmpeg library doesn't. It's a bit of a trick to deal with, though. (Especially since the default value for all options is, helpfully, "default.")

Regarding the keyframe bug mentioned by Beezebubu, note that SVT actually uses closed GOPs by default, meaning you'll want to use 24 instead of 23.

Losko
9th November 2020, 00:06
Latest encode:

https://i.ibb.co/XWk1ZVk/4-aomenc.png (https://imgbb.com/)

Same frame as the previous trials, of course.
aomenc --verbose --obu --fps=25/1 --end-usage=q --cq-level=16 --cpu-used=2 --bit-depth=8 --good --passes=1 -o output.obu input.y4m

I'm about to think that's me doing some big mistakes with those encoders...