Intel SVT-AV1

[Blue_MiSfit]

I wanted to make a thread dedicated to discussing Intel's SVT AV1 encoder, as it seems to be quite good and rapidly improving. I'm seeing fantastic results using fixed QP encoding, though as far as I can tell rate control is pretty basic still.

For example, using fixed QP 44 encoding of a 1080p24 hand drawn animation source, I was able to get very nice looking video (average VMAF of 93.6) at 2.8 Mbps using enc-mode 1 (next to the slowest preset).

Speed is quite good for AV1 - I got 0.2 fps on my i7-7700k. This encoder scales very well and saturated my whole system!

What have others seen?

[Tadanobu]

The last time I made subjective comparisons, SVT AV1 was behind libaom in term of grain and very fine details, even at speed 0. The image looked a bit smoothed, like comparing stock x265 with stock x264. But for real world scenarios, the quality for speed for compression was already quite good. Speeds 3/4 give very decent results and are way faster than libaom and rav1e. It's very promising.

[Blue_MiSfit]

Any suggested encoding settings other than the usual "pick the slowest preset you can tolerate"?

[quietvoid]

My line for 10 bit tests:
SvtAv1EncApp.exe -i sample.y4m -enc-mode 4 -bit-depth 10 -irefresh-type 2 -q 17 -tile-rows 6 -tile-columns 6 -output-stat-file out.stats -input-stat-file out.stats -enc-mode-2p 6 -b out.ivf
Has to be executed twice for 2 pass QP. :)

[Blue_MiSfit]

Thanks for sharing.

Just to be clear, do you use tile-rows and tile-columns to make decoding more parallel?

Also, you set irefresh-type to 2 (which makes the encoder use closed GOP), is this for an adaptive streaming use case?

[quietvoid]

Using tiles makes both encoding and decoding "parallel", decoding scales better.

From what I've read, irefresh-type 1 (default) produces a non-seekable output.
Also I omitted 'intra-period 24' because that's specific to my tests (just an input source divided in scenes of 24 frames), but that requires closed GOP.

[Blue_MiSfit]

I see. And you see a quality benefit to 2 pass even when using fixed QP?

[quietvoid]

Have not compared, but 2 pass is only fixed QP for now.
I don't even know if it's worth using because of that.

[Blue_MiSfit]

Scratching my head a bit trying to understand the 2 pass procedure. You literally run that full command above two times (specifying enc-mode enc-mode-2p input-stat-file and output-stat-file each time)?

[Atak_Snajpera]

. Speed is quite good for AV1 - I got 0.2 fps on my i7-7700k. This encoder scales very well and saturated my whole system!

1) 0.2 FPS on 4c/8t means that on epyc 64c/128t you would get less than 3fps. That's still pathetic encoding speed.
2) Saturated all CPU 8 threads during encoding is not a spectacular achievement. 100% CPU usage on ryzen 9 3850x would be something.

[quietvoid]

Scratching my head a bit trying to understand the 2 pass procedure. You literally run that full command above two times (specifying enc-mode enc-mode-2p input-stat-file and output-stat-file each time)?Currently that's how it works, it will change to be more user friendly.

However I'm looking at the user guide and I think my 2 pass options are wrong.
-output-stat-file is for the first pass, -input-stat-file is for the 2nd pass. The two should probably not be used at the same time like I did (I used an example cmd from an issue :)).
-enc-mode-2p is the preset at which the first pass is done, from what I understand.

Perhaps like this:

First pass: SvtAv1EncApp.exe -i sample.y4m -enc-mode 4 -bit-depth 10 -irefresh-type 2 -q 17 -tile-rows 6 -tile-columns 6 -output-stat-file out.stats -enc-mode-2p 6 -b out.ivf
Second pass: SvtAv1EncApp.exe -i sample.y4m -enc-mode 4 -bit-depth 10 -irefresh-type 2 -q 17 -tile-rows 6 -tile-columns 6 -input-stat-file out.stats -enc-mode-2p 6 -b out.ivf

[Blue_MiSfit]

1) 0.2 FPS on 4c/8t means that on epyc 64c/128t you would get less than 3fps. That's still pathetic encoding speed.
2) Saturated all CPU 8 threads during encoding is not a spectacular achievement. 100% CPU usage on ryzen 9 3850x would be something.

That was with very high quality encoding. This is still AV1 :) 0.2 fps isn't too bad, to be honest.

Using faster settings (preset 5) I was able to achieve 4 fps, which is quite fast for 1080p AV1 with 4 cores. The fastest preset delivers 12 fps for me.

Regarding point 2, I think that's exactly what SVT AV1 is designed for, particularly when encoding multiple bitrates in parallel for ABR delivery. A full ABR ladder encoded live appears to be one of the goals of the project. libaom has terrible threading last I checked, as many big OTT VOD services will run encodes single threaded.

[Blue_MiSfit]

Okay I finally got 2 pass working. @quietvoid you're correct, you have to use -enc-mode-2p with -output-stat-file for the first pass and -enc-mode with -input-stat-file for the second pass.

Here's a quick example using the fastest speed preset and raw 8 bit yuv input, targeting 1080p at 3 Mbps VBR.

First Pass

svtav1encapp -i Beauty.yuv -w 1920 -h 1080 -fps-num 24000 -fps-denom 1001 -intra-period 96 -irefresh-type 2 -rc 2 -tbr 3000000
-enc-mode-2p 8 -output-stat-file stats.file -b Beauty_svtav1_8_3000.ivf


Second Pass

svtav1encapp -i Beauty.yuv -w 1920 -h 1080 -fps-num 24000 -fps-denom 1001 -intra-period 96 -irefresh-type 2 -rc 2 -tbr 3000000
-enc-mode 8 -input-stat-file stats.file -b Beauty_svtav1_8_3000.ivf


I get an output that decodes okay (and looks awful, predictably), but curiously there's an error during the second pass:

Error in freed returnVal 0

Odd.

Rate control seems to at least hit the target, it achieved 2995 Kbps which is within tolerance.

Any ideas on that error?

[Tadanobu]

I think I've read somewhere that high -tile-rows and -tile-columns values are bad for quality encode. Can somebody confirm this ? I have deleted my test encodes but I think I tried not to go above 2x2. Or is it CPU related ?

[Blue_MiSfit]

It makes sense to me that these would impact quality somewhat, since they're a bit like slices for MPEG codecs.

I don't know exactly how much they would impact quality.

[Blue_MiSfit]

Yikes. It's not too bad for small numbers of tiles, but it blows up really fast.

Using fixed QP 45, here's some results. Not a full BD-Rate analysis, but some food for thought. I used identical values for tile-column and tile-row for each of the below examples


row/column | bitrate | fps | vmaf average
0 | 4867 | 4.52 | 91.773
1 | 4923 | 4.94 | 91.759
2 | 5000 | 4.88 | 91.725
4 | 5346 | 4.88 | 91.676
6 | 5995 | 5.01 | 91.557


So, similar encoding quality across the board but with an enormous bitrate cost when using 6 columns + rows with 1080p, almost 23% more bits.

I imagine the impact would be less for UHD.

[Tadanobu]

Yeah, I made some new tests and I can confirm that. Higher numbers give higher bitrates while the encoding speed is not significantly faster. I can't see any good reason to use it at the moment.

So, here are some screenshots for subjective comparison. Source is 8bits 1080p, encoded with an i7-8750H using ffmpeg.

Speed went from 0.01FPS (-q 20 -enc-mode 0) to 8.07FPS (-q 50 -enc-mode 8). I personally find -q 20 -enc-mode 4 to be a good balance but it is still as slow as 0.89FPS.

Cropped and zoomed in
https://i.imgur.com/Q0IDhhL.jpg
https://i.imgur.com/JuviCld.jpg
https://i.imgur.com/jBSR00P.jpg
https://i.imgur.com/XCZucKs.jpg
https://i.imgur.com/Sw9fTs5.jpg
https://i.imgur.com/fzT3jba.jpg
https://i.imgur.com/RMlXto3.jpg
https://i.imgur.com/FM7Iwj8.jpg
https://i.imgur.com/ZoNvbsh.jpg
https://i.imgur.com/YQiPuvE.jpg

Full frames
https://i.imgur.com/y6VX0j9.png
https://i.imgur.com/9QHBAnK.png
https://i.imgur.com/IuhcV8j.png
https://i.imgur.com/IkDEXT5.png
https://i.imgur.com/oHFdv3Q.png
https://i.imgur.com/mCavZbf.png
https://i.imgur.com/G4n1vtt.png
https://i.imgur.com/TJ72o5A.png
https://i.imgur.com/3wWDFld.png
https://i.imgur.com/B83rdXk.png

[nevcairiel]

I would generally recommend to use at least two tiles at this point for the significant decoding boost it gives. Two tiles, compare to only one, almost doubles possible decoding speed, which for a new codec like this is quite significant.

[Blue_MiSfit]

Interesting, so to make two tiles, would you set tile-row to 2 and leave tile-column at 0 (or vice versa)?


Just did some research, the config params are log2 values.

e.g.
param -> actual
1 -> 2
2 -> 4
3 -> 8
4 -> 16

I have no idea WHY this is the case (seems to be in order to use the same syntax as libaom)...

Did a quick sanity check, using -tile-columns 1 gave slightly better metrics than -tile-rows 1, but that's just a couple quick tests. It will likely be content dependent based on motion.

[Tadanobu]

Thanks for the tiles trick. I'll use it from now on.

By the way, what do you guys think of SVT HEVC and SVT VP9 ? Is it my tests that are wrong or do they compress better than SVT AV1 ?

Visually speaking, SVT HEVC has been giving me very nice results. SVT VP9 is a little bit behind in term of compression, but I have almost similar results with faster encoding. Even -enc-mode 0 is ~3.5FPS, not bad. -enc-mode 10 goes up to 82FPS and the difference with -enc-mode 0 is barely perceptible. I need to do more tests, but seriously I'm impressed.

[Blue_MiSfit]

I've yet to try either! Good to know, I'll see if I can set some time aside for analysis.

[quietvoid]

SVT-AV1 2 pass still doesn't work properly with a higher target bitrate. I set -tbr for 10 mbps and the resulting encode is only 4-5 mbps.
Both -rc 2 (4.6 mbps) and -rc 3 (3.8 mbps).

[Blue_MiSfit]

Hm, it seemed to work fine in my 1080p smoke test clip. I got a 10 Mbps output in 2 pass mode using -rc 2

[Blue_MiSfit]

I get some really bad dealbreaker artifacts at high bitrates using fast presets though. For example, my smoke test at QP 30 with enc-mode 8 through 5 has really bad glitches in certain parts of the frame. These should not be happening at 12 Mbps :)

They clear up at enc-mode 4

https://imgur.com/a/46Oeofq

[quietvoid]

Hm, it seemed to work fine in my 1080p smoke test clip. I got a 10 Mbps output in 2 pass mode using -rc 2I've exhausted all the options I could think of, -rc 2 -tbr 10000000 never gives me a bitrate close to the target.

Trimmed 500 frames of a BT.709 1080p 8-bit SDR clip, ran these two lines:
SVT-AV1\SvtAv1EncApp.exe -i sample.y4m -fps-num 24000 -fps-denom 1001 -rc 2 -tbr 10000000 -output-stat-file out.stats -enc-mode-2p 4 -b out.ivf

Result: 716.24 kbps
SVT-AV1\SvtAv1EncApp.exe -i sample.y4m -fps-num 24000 -fps-denom 1001 -rc 2 -tbr 10000000 -input-stat-file out.stats -enc-mode 4 -b out.ivf

Result: 455.21 kbps

:confused:

[Blue_MiSfit]

Maybe some weird edge case with y4m input? I've been doing my tests with raw yuv.

Try this exact 2 pass command (my documentation PR just got merged :) )

https://github.com/OpenVisualCloud/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#sample-command-lines

[Tadanobu]

2 pass will only work for me if I specify the number of frames to encode (-n). Otherwise 1st pass works fine but 2nd pass freezes at first frame. But I've noticed I've had the following error several times : "Error in freed returnVal 0"

[quietvoid]

Maybe some weird edge case with y4m input? I've been doing my tests with raw yuv.

Try this exact 2 pass command (my documentation PR just got merged :) )

https://github.com/OpenVisualCloud/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#sample-command-lines
Raw .yuv was an option tested :)
I've tried again with the example CLI and it behaves the same.
I'll just give up, I don't think it's implemented properly yet.

I had asked 4 months ago on another site and got this response:
Target bitrate only works in mode 1, and as you said, It's not implemented yet. The target_bitrate variable is for future use and currently is ignored.
Mode 1 refers to the rate control mode, and that mode is still disabled.

[Blue_MiSfit]

Any chance you can share the sample? I'm sure the developers would be interested by that.

If you use constant QP can you achieve a higher bitrate?

[quietvoid]

Yes, using -q does change the bitrate. It's only -tbr not reaching the target bitrate.

The sample isn't special, I've tried with 24 frames scenes, 500 frames of one scene and multiple samples.

I'm sure I could reproduce it with Tears of Steel but I'll wait for a couple PRs to be merged first (including the kbps one :))

-tbr has never worked for me, 2 pass still hasn't changed that.

[NikosD]

Ryzen 3950X is very fast on SVT-AV1, no doubt about it, it's even faster than latest HEDT from Intel Core i9-10980XE which has 2 more cores, BUT Threadripper's devastating performance is simply out of this world.

It's three times faster than previous Threadripper 32C and two times faster than latest Intel 18C

https://i.postimg.cc/Bn7dyfhg/y-V94uwn-ZCpkfk4-B3z-UR4-Td-650-80.png

[Funky080900]

100 fps using -enc-mode 4?

[birdie]

SVT-AV1 0.75 is out (https://github.com/OpenVisualCloud/SVT-AV1/releases) with a long list of changes.

I've compared it to x265 at a similar bitrate and x265 came up on top - a lot more details were generally preserved and SVT-AV1 output is kinda blurry/too smooth.

ffmpeg -i source.mkv -vf fps=30 -an -c:a copy -c:v libx265 -preset veryslow \
-x265-params keyint=600:min-keyint=30:bframes=16:crf=20:no-sao=1 265.mkv
ffmpeg -hide_banner -loglevel panic -nostats -i source.mkv -nostdin -f rawvideo -pix_fmt yuv420p - \
| ./SvtAv1EncApp -i stdin -w 1280 -h 720 -n 25038 -b out.av1 -enc-mode 1 -q 24 -rc 0 -intra-period 250

The encoding speed of SVT-AV1 was roughly 0.2fps and x265 ran at around 12fps. x265 compressed to 822.96 kb/s, svt-av1 to roughly 750 kb/s.

Maybe there are flags to retain details better but I didn't find them.

enc-mode 0 is even slower and basically impossible to use.

[RanmaCanada]

100 fps using -enc-mode 4?

HAHA, no. Not even close (https://www.phoronix.com/scan.php?page=article&item=amd-linux-3960x-3970x&num=8)

[osgZach]

I'm actually more shocked to see a performance graph that actually uses an FPS metric than anything. I got frustrated and stopped looking at such charts because they always had useless, or obscure metrics that involve extra math to find out what the performance is; and that's on top of them not even telling you the encode settings or other critical information


Someone should ask Toms what the hell "1080p encoder mode 4 to AV1 encode" even means and if they speak english.

[quietvoid]

Version 0.8.0, still getting final bitrates way off of the target I set.
SVT-AV1\SvtAv1EncApp.exe -i tos_10b.y4m -fps-num 24000 -fps-denom 1000 -bit-depth 10 -intra-period 24 -irefresh-type 2 -rc 1 -tbr 10000 -tile-rows 3 -tile-columns 3 -output-stat-file out.stats -enc-mode-2p 4 -b out.ivf
SVT-AV1\SvtAv1EncApp.exe -i tos_10b.y4m -fps-num 24000 -fps-denom 1000 -bit-depth 10 -intra-period 24 -irefresh-type 2 -rc 1 -tbr 10000 -tile-rows 3 -tile-columns 3 -input-stat-file out.stats -enc-mode 4 -b out.ivf

Resulting encode: 6305.63 kbps :)

[NikosD]

Running Linux, tested by Phoronix.
https://i.postimg.cc/nL6c7W9H/svt-av1-39xx-9900.png

[foxyshadis]

SVT-AV1 0.8.1 has been released. (https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.8.1) Mostly a bugfix release, plus 10-bit palette support for screen coding.

[utack]

Does anyone know how the SVT-AV1 Gui (https://moisescardona.me/svt-av1-gui/) does 2pass?
2 times the same speed or first pass at speed 8?

[foxyshadis]

Does anyone know how the SVT-AV1 Gui (https://moisescardona.me/svt-av1-gui/) does 2pass?
2 times the same speed or first pass at speed 8?

It uses the same speed on both passes, no fast-first-pass. That doesn't seem ideal, the consensus is that speed 7 or 8 is fine for generating statistics.

[utack]

It uses the same speed on both passes, no fast-first-pass. That doesn't seem ideal, the consensus is that speed 7 or 8 is fine for generating statistics.

I figured that yes, thank you for confirming it

[stax76]

In case somebody is looking for a GUI maybe try StaxRip 2.1.0.3 Beta.

https://staxrip.readthedocs.io/intro.html#download

[birdie]

In case somebody is looking for a GUI maybe try StaxRip 2.1.0.3 Beta.

https://staxrip.readthedocs.io/intro.html#download

Not really, SVT-AV1 is still considerably worse than x265 --preset slow: at least ten times slower and blurrier (at the same bitrate).

[stax76]

Not really, SVT-AV1 is still considerably worse than x265 --preset slow: at least ten times slower and blurrier (at the same bitrate).

I just add the features people ask for, the encoder support was completely done in 4 hours, the problem was that this encoder writes progress without new line characters and dotnet and staxrip couldn't handle it, took a full day to support because I had to do an own version of a somehow complicated piece of dotnet code (https://github.com/microsoft/referencesource/blob/master/System/services/monitoring/system/diagnosticts/AsyncStreamReader.cs), it was OK doing it because I like to learn about threading, streams and text encoding and particularly everything console related. Apparently not all codec developers have a talent for console topics, x265 shines here, it followed the excellent x264 and the talented nvenc author rigaya also followed it, for GUI authors it's a big deal but it helps users greatly as well.

This encoder might not be very interesting for everybody but it's often interesting to just take a look at something and play with it, staxrip makes it effortless to try tools, it supports over 190 tools and everything just work, without a GUI some things can be complicated to set up for users like this encoder, vapoursynth, qtgmc etc. It's very transparent what staxrip does because the command lines and scripts can be seen in the app and there is also a very clean log file.

[Tadanobu]

I certainly appreciate the SVT-AV1 support. Thank you very much ! If you someday have time to add libaom too, that will be awesome.

[stax76]

If you someday have time to add libaom too, that will be awesome.

It was supported with 106 GUI options (auto generated from --help output...), not sure why it was disabled, I can take a look.

https://github.com/staxrip/staxrip/blob/master/Encoding/AOMEnc.vb

[Tadanobu]

Yeah ! It looks like most of the options are already here. If it's not too much trouble re-enabling it, please give it a go. No hurry tho.

Also, new options are available. I haven't checked all and every lines but the most recent options like --tune=vmaf or --enable-fwd-kf are missing. But, well, we can still pass them manually. Thanks in advance.

[MZ/X]

Initial version of xAV1vfw v0.82 is released on http://mpxplay.sourceforge.net

The GUI is similar to the other (x264,x265) VFWs (video for windows codec).

XAV1vfw uses the svt-av1 encoder library (git 20200419), with several limitations, like
- it doesn't work properly under Windows 7 (at me), only under Win10 (wrong CPU detection)
- it's very slow, even in the fastest encoding mode (full HD encoding, 4 cores, AVX2, ~5 fps)
- AVX512 support is unofficial/experimental, disable it (on the GUI) at encoding problems (crash)
- some GUI settings have no svt-av1 support yet (encoder may rejects these), like YUV, Tuning and Profile non-default settings

Enabling the Debug log level to Full can display some additional svt-av1 errors and infos.

You can follow the updates on my sf.net page
https://sourceforge.net/p/mpxplay/discussion/219198
or on my FB page
https://www.facebook.com/mpxplay

[foxyshadis]

Version 0.8.2 released, download at https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.8.2

Encoder
- Initial Super resolution support
- Mode decision rate estimation enhancements
- Altref improvements
- Manual prediction structure support
- Enhanced RDOQ support
- Improved warp motion
- Improved documentation and help menu
- New command line parameters
- Fix non-multiple of 8 resolution video corruption for 8bit
- Improved multi-stage mode decision support
- Added multi-stage motion estimation support
- Chroma mode decision optimizations
- Added 16bit pipeline support
- Added Mode decision non-square partition weights
- Enhanced qp-scaling assignment
- Memory optimizations
- Added AVX512 Optimizations
- Added AVX2 Optimizations

Decoder
- Improved multi-threading support
- Memory optimizations
- Updated documentation
- Loop filter flow optimization

Encoder and Decoder
- Encoder-Decoder-Common folder structure improvements

Build and Testing
- Bug fixes
- Improve CI
- Improve Unit Test Coverage
- Address C vs asm mismatches
- Support C only builds (for platforms other than x86)

[benwaggoner]

Version 0.8.2 released, download at https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.8.2
Looks like some good additions!

I've wondered about SVT-AV1 having RDOQ, which is something I'm mainly familar with from x265. Is the SVT implementation derived from x265 or the HM? Does libaom have something similar by another name?