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?

[TomV]

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?

Are you asking about SVT-HEVC or SVT-AV1?

[foxyshadis]

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?

I'm not exactly sure what the implementation's provenance is, although it started out almost the same as the aomenc version, but in aomenc and the older versions of SVT it goes by trellis, and was renamed in SVT in 0.8.0 to match up with SVT-HEVC and current industry norms. In libaom, it's on by default up to encmode 5, and manually turned on/off by --disable-trellis-quant.

[foxyshadis]

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

Encoder

- Presets optimization

Build and Testing

- Bug fixes
- Xcode build support

"Presets optimization" has some tweaks for preset 0, and a lot of changes for preset 1, to include slower settings and make smaller files, possibly not at the same quality. Anyone who uses preset 0 or 1 after this will want to retest their settings.

[quietvoid]

Has anyone managed to make --film-grain work yet?
There's no difference in output whether it's set to 0 or 50 for me, last tried on 0.8.2.

[foxyshadis]

Has anyone managed to make --film-grain work yet?
There's no difference in output whether it's set to 0 or 50 for me, last tried on 0.8.2.

In the current implementation, you have to generate a noise profile, and then feed it in as a second pass. aomenc works the same way. (The implementation is almost 100% identical to aomenc.)

[quietvoid]

In the current implementation, you have to generate a noise profile, and then feed it in as a second pass. aomenc works the same way. (The implementation is almost 100% identical to aomenc.)

Right, but the 2 pass VBR in SVT is completely broken for target bitrates. It also looks worse than CQP.
aom allows you to pass a grain table file, I don't think SVT does.

[quietvoid]

I've tried using --film-grain 10 with 2 pass CQP, unfortunately it still doesn't add any film grain on decode.
Results in a lot of Error in freed returnVal 0

[foxyshadis]

0.8.4 released: https://github.com/OpenVisualCloud/SVT-AV1/releases/tag/v0.8.4


Bug fixes
Improve CI
Improve Unit Test Coverage
Address C vs asm mismatches
Fix static analysis warnings / errors
Add address sanitizer
Various ffmpeg patch fixes


Newly included is an ffmpeg build, to make it easier for ffmpeg users.

Unfortunately fixing film grain didn't make it in, that's among the priorities for the next release.

[foxyshadis]

0.8.5 released: https://github.com/AOMediaCodec/SVT-AV1/releases/tag/v0.8.5

Relicensing notice

Change the outbound license from BSD+Patent to the AOM license / patent

Encoder

Added tpl support to adaptively change lambda and quantization parameters within the frame
Added multi staged hme support
Quality speed trade-offs tuned to VOD use cases
Added first level non-optimized support for 2pass VBR and CRF
Added combined cli two pass support with options for stats being written to a memory buffer and a specified file
Added non square partitioning optimizations
Improved lambda generation

Build and Testing

Bug fixes
Improve CI
Improve Unit Test Coverage
Address C vs asm mismatches
Fix static analysis warnings / errors
Add address sanitizer
Fix symbol conflicts with libaom and libvpx when staticly lined to ffmpeg


Quality tuning and overall improvement, fewer crashes, initial 2-pass, and fixing symbol conflicts are the highlights.

Edit: New URL, since the move to AOM is complete.

[foxyshadis]

0.8.6 minor release: https://github.com/AOMediaCodec/SVT-AV1/releases/tag/v0.8.6


Encoder

Further quality-speed tradeoffs tuning for VOD use cases
Improved TPL support within 1-pass and 2-pass CRF moode
Continued non-optimized support for 2pass VBR and CRF
Align kernel nomenclature to prefix svt_aom for kernels brough from libaom to avoid symbol conflicts

Build and Testing

Bug fixes
Improve CI
Added CI support for gitlab
Improve Unit Test Coverage
Address C vs asm mismatches
Fix static analysis warnings / errors
Add address sanitizer
Fix symbol conflicts with libaom and libvpx when staticly linked to ffmpeg


Missing is that this currently won't build on BSD or ARM due to a last-minute change. I imagine it'll be re-released with a hotfix soon.

[quietvoid]

Has something happened to SVT-AV1? There hasn't been any feature/bugfix update in the months before the move to GitLab, and still nothing since.
See https://www.reddit.com/r/AV1/comments/m9kb4x/svtav1_hasnt_had_a_single_commit_in_almost_a/

[Blue_MiSfit]

Looks like the maintainer is out on child bonding :)

[benwaggoner]

Looks like the maintainer is out on child bonding :)
Yay for parental leave becoming a tech industry standard!

Hopefully integration work is going on inside of AOM as part of their switch to SVT-AV1 from libaom as their default encoder.

[foxyshadis]

SVT HEVC and VP9 already fell off into minimal maintenance a year ago, so it's probably not that surprising. Intel is probably redirecting resources; all of the prolific contributors are Intel employees or adjuncts, and I haven't seen any Google employees step in to fill the void. I hope it's not a "not now, I'm too busy designing my own language to rewrite the application in first" that's all too prevalent at Google.

[quietvoid]

I was under the impression that Netflix also participated in the development, maybe that changed.
Still hopeful for either SVT-AV1 or rav1e to become good encoders. Especially now that there are some good GSoC 2021 project ideas aimed at improving rav1e.

[foxyshadis]

For sure, Netflix and other companies do contribute, and so has Google... but 90% of the last few years of SVT maintenance has come from Intel. I'm crossing my fingers that the it's a momentary blip and going to pick up again, given how long it took x265 to recover after its initial dream team left.

[Kurtnoise]

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v0.8.7

[0.8.7] - 2021-05-08
Encoder


Feature optimizations: creating new mode decision / encode-decode feature levels allowing better speed / quality trade-off granularity
Preset repositioning after adopting new levels
Preset 8 achieving similar speed levels to that of x265 medium in the VOD (shot-based encoding) use-case while maintaining quality gains
New 1-pass and 2-pass VBR implementation ported from libaom and adapted to the SVT architecture - still a WIP
Cleaned up old VBR and CVBR RC code along with the lookahead mechanism associated with them
Improvements for TPL algorithm to handle long clips and easy content
Added HDR support and color primaries SEI signaling (off by default until integrated with ffmpeg)
Memory optimizations, cleaning up data structures to reduce memory usage up to 2x memory reduction in multi-threaded VBR environment
Additional AVX2 and AVX512 optimizations
Cleaned up unused command line parameters except the config params that are linked to ffmpeg
Update user guide and documentation

Build and Testing


Bug fixes
Improve CI coverage
Improve Unit Test Coverage
Address C vs asm mismatches
Fix static analysis warnings / errors

[benwaggoner]

And it is back. Sounds like some pretty solid improvements in this release. Matching x265 medium performance is impressive if the quality is decent.

[Blue_MiSfit]

Looks like 0.8.8 RC1 is tagged with the new optimized speed presets folks have been talking about :D

https://gitlab.com/AOMediaCodec/SVT-AV1/-/tree/0.8.8-rc1

Exciting. I'll have to figure out how to get that cooking in media-autobuild-suite... or maybe wait for it to be merged to master.

I have to see the whole "faster and better quality than x264 placebo even at the fastest svt-av1 setting" thing for myself to believe it ;)

[Blue_MiSfit]

Okay, wow.

I just went ahead and did my own docker build instead of waiting for this to get merged to master.

The new default speed preset is 12, which is indeed about as fast as x264 placebo for me on my Ryzen 9 5900x using a 1080p 8 bit version of the Netflix foreman test clip.

I found that using crf 40 in svt-av1 with a 240 frame GOP produced an ABR of ~970 Kbps, and crf 33 in x264 produced an ABR of ~ 955 Kbps. The AV1 version was _dramatically_ better, even if it did suffer a bit in temporal coherency in certain cases.

Overall, the x264 version was more consistent, but overall consistently much worse. Both were soft in high frequency details, but the AV1 version completely dominated the x264 version, both in still frame and in-motion comparison. In a totally non-scientific quick little single blind comparison my video literate girlfriend said that on a scale of 1-5 the AV1 version scored a 4 and the x264 version scored a 2, and I have to say I think she's spot on.

Again, this was at the same encoding speed. Wow. SVT-AV1 has come a LONG way.

Here's a Docker image if you want to use it: https://hub.docker.com/repository/docker/dprestegard/svt-av1/general

And here's some test encodes:
https://d1bl6f264cdx5.cloudfront.net/svt-av1_crf40_speed12.mp4

https://d1bl6f264cdx5.cloudfront.net/x264_crf33_placebo.mp4


x264:
https://i.imgur.com/JQNguFJ.jpg

svt-av1:
https://i.imgur.com/BGAzsQ6.jpg

[takla]

Going by your image comparison, If I had to choose between watching x264 or svt-av1, I'd pass on watching either, because both look absolutely horrendous. And how does av1 look better here? It just has different types of artefacts. Where it cannot retain detail it blurs. And it has some major artefacts around the head. Just preblur the source, and x264 probably comes out ahead. And with higher device compatibility too.

[Blue_MiSfit]

That’s not really the point. This is sub 1 Mbps 1080p it’s not something most people on doom9 care about.

The artifacts in motion are way less distracting. It’s just very impressive to see what can be done with an AV1 bitstream using the same amount of compute as x264. This demonstrates very clever optimization and lots of smart early exits.

It’s the “superfast” of SVT-AV1 :)

[VoodooFX]

the Netflix foreman test clip
Any link to it? Hard to tell what is what without source.

[benwaggoner]

Any link to it? Hard to tell what is what without source.
That is "Foreman" - one of the older canonical video test sources. I think it's available from VQEG, but it seems their FTP server is down.

[benwaggoner]

That’s not really the point. This is sub 1 Mbps 1080p it’s not something most people on doom9 care about.

The artifacts in motion are way less distracting. It’s just very impressive to see what can be done with an AV1 bitstream using the same amount of compute as x264. This demonstrates very clever optimization and lots of smart early exits.

It’s the “superfast” of SVT-AV1 :)
Yeah, it's quite impressive to get that good that fast with AV1 compared to where aomenc performance was 2+ years ago!

While we mainly talk about new codecs in terms of potential bitrate reductions at constant quality, quality @ perf is also really important. In general a new codec should be able to provide at least somewhat better quality at the same perf as the prior generation.

[VoodooFX]

That is "Foreman" - one of the older canonical video test sources.
This doesn't look like that canonical "Foreman".

[Blue_MiSfit]

Ah yeah it's the newer one that Elemental (not netflix, sorry lol) put together and offered up in 4k for free awhile back. Sadly since they were acquired by AWS their old website is gone, so I'm not sure if these clips are available anymore :(

[Blue_MiSfit]

Looks like rate control is still pretty terrible. I did a 2 pass VBR encode on the slowest preset targeting 1 Mbps for a ~1000 frame clip and it ended up hitting an average bitrate of like 640 Kbps and looked quite bad :|

So... that's a work in progress I guess!

[Blue_MiSfit]

I continue to be impressed by this encoder. My favorite animated 1080p24 test clip encoded at 8.5 fps on my Ryzen 9 5900x using preset 4. This is actually a bit faster than CRF 36 x265 on preset slower (both producing similar data rates, approx 1 Mbps). The resulting file from svt-av1 had better min and harmonic mean VMAF scores by several points and avoided moving artifacts that were quite distracting on the x265 version.

This is by no means comprehensive, but outperforming x265 slower while running faster is a significant accomplishment.

Granted.. this is with CRF. Per my last post, rate control is still hilariously bad, at least in my test clip (which I think is a very realistic rate control test).

[takla]

v0.9.0 Release (https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v0.9.0)

New faster presets M9-M12, M12 reaching similar complexity level to that of x264 veryfast
New multi-pass and single pass VBR implementation minimizing the quality difference vs CRF while reducing the cycle overhead
Quality vs density tradeoffs improvements across all presets in CRF mode
Added support for CRF with capped bitrate
Added support for overlay frames and super resolution
Fixed film grain synthesis bugs
Added experimental support for higher than 4k resolutions
Added experimental support for the low delay prediction structure
Significant memory reduction especially for faster presets in a multi-threaded environment
API configuration structure cleanup removing all invalid or out of date parameters
Speedup legacy CPUs for faster development by adding SSE code for corresponding C-kernels
Updated the code license from BSD 2-clause to BSD 3-clause clear
Cleaned up the code for various kernels
Updated the user guide and feature documentation

[YagmurunSuyu]

Has anyone built 0.9.0 fsv-av1 with ffmpeg? I would be glad if you share it.

[marcomsousa]

Phoronix - Intel Releases SVT-AV1 0.9 For Quicker AV1 Video Encoding
https://openbenchmarking.org/embed.php?i=2201222-NE-2201224NE67&sha=15b7ba5b8d20&p=2
https://www.phoronix.com/scan.php?page=article&item=svt-av1-09

[benwaggoner]

Phoronix - Intel Releases SVT-AV1 0.9 For Quicker AV1 Video Encoding
Is this a purely performance update? The link doesn't mention any compression quality or efficiency improvements.

If so, it's not that impressive for a year of development of a still maturing codec like AV1.

[Blue_MiSfit]

Here's a Docker image for 0.9.0

https://hub.docker.com/repository/docker/dprestegard/svt-av1

[poisondeathray]

Just some early impressions of v0.9 - the speed improvement is nice over older versions, but the quality leaves a lot to be desired. General trend is too much blurring (testing around presets 3 to 8) and detail loss compared to x265 at the same lowis to mid bitrate ranges (I can't believe I'm writing that. For the longest time x265 was the blur king) . scd is disabled by default, but some issues with fades and transitions whether enabled or not

(using the binaries from )
https://jeremylee.sh/bins/

[Blue_MiSfit]

In motion I disagree. I found SVT-AV1 to have significantly fewer distracting artifacts in motion at typical OTT streaming quality levels. To be fair, I compared mostly at the lower bitrates to exaggerate the differences :).

My still frame comparison very much agrees with your statements.

[benwaggoner]

In motion I disagree. I found SVT-AV1 to have significantly fewer distracting artifacts in motion at typical OTT streaming quality levels. To be fair, I compared mostly at the lower bitrates to exaggerate the differences :).
Compared to x265 or older SVT-AV1 verisons?

[Blue_MiSfit]

Compared to x265 running at similar encoding speed.

[wswartzendruber]

Has anyone gotten film grain to look right with 1.0.0? I've set --film-grain as high as 12 and barely any comes through.

[quietvoid]

The parameter only increases the denoising strength, hence increasing the parameterized grain intensity.
If that's not enough, you can increase it and use "--enable-dnl-denoising 0" to avoid denoising unnecessarily.

You might find some good info here: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1875

[wswartzendruber]

I did some experimentation with The Matrix. What I've found is that denoising seems to work correctly as I adjust that value. What I find myself wanting on playback (and side-by-side comparison with the original input) is for VLC to simply increase the magnitude coefficient(s) of the grain table on playback.

The emulated grain patterns and color are quite good. But it's like someone put a 50% opacity filter over them on playback. This seems like a more concise (and simple) problem to solve than encoding grain via MDCT and encoding weak grain in tables.

I contend that either:

1. SVT-AV1's modeling is undershooting the intensity of the grain.
2. libdav1d is rendering the grain much more weakly than intended.

[quietvoid]

Is your clip HDR? As far as I know, VLC uses libplacebo to handle that, which has a default setting that reduces grain intensity in HDR only.
dav1d also can make use of libplacebo to render the grain, but I'm not sure if that path is affected by the same alteration.

You could also play with rav1e, which can generate "photon noise": https://github.com/xiph/rav1e/pull/2924

[wswartzendruber]

It's HLG and tagged as such. BT.2020 for both color parameters.

[quietvoid]

Hmm, either way I got confused with *deband grain*, so AV1 should be fine.
You can always use dav1d directly to see.

[Beelzebubu]

I contend that either:

1. SVT-AV1's modeling is undershooting the intensity of the grain.
2. libdav1d is rendering the grain much more weakly than intended.

Although grain reconstruction is not actually mandated to be bit-exact, I can guarantee that dav1d plays it back to the letter of what the spec says, and we have plenty of tests to make sure that doesn't break. You might want to further confirm that #2 is unlikely by using other software decoders (aom, gav1) and confirming their grain scales are identical to what dav1d generates.

[mastrboy]

Does anyone have a example qpfile for svt-av1? The documentation over at https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md#rate-control-options does not specificy the format...
Can I reuse the same qpfile I use for x264 when specifying keyframes?

[benwaggoner]

Does anyone have a example qpfile for svt-av1? The documentation over at https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md#rate-control-options does not specificy the format...
Can I reuse the same qpfile I use for x264 when specifying keyframes?
Give it a try, and let us know.

The x264/x265 qpfile format is simple, useful, and well understood. The only real "drawback" I've faced is that it is frame based without a timecode-based option. However, supporting TC would add a bunch of complexity and ambiguity (drop frame? non-drop frame? 24000/1001 or just 24.000?).

[Selur]

In Hybrid, the 'normal' x264/x265 qpfile format is used for svt-xxx and svt-xx isn't complaining, but to be frank I never checked whether it actually does what I assume it does. ;)
0 I -1
125 I -1
500 I -1
1250 I -1
1500 I -1
seems to work fine for setting chapter points. (which is the reason I usually use the qp file for)

Cu
Selur

[foxyshadis]

The SVT qpfile format is just one qp per line, nothing else. You cannot adjust frame type decision with it. Selur's file would give 0 and then clipped to 63 for the next four frames, because it just tries to convert each line to an integer and ignores anything else.

28
23
29
40
22
etc.

It would certainly be nice if it was as flexible as the x26X format.

[Selur]

argh,... that is disappointing.

[hajj_3]

v1.6.0 - 2023-06-18

Encoder:

Improve the tradeoffs for the random access mode across presets M1-M13:
Speeding up the higher quality presets by 30-40%
Improving the BD-rate by 1-4% for the faster presets
Improve the tradeoffs for the low delay mode for both screen content and non-screen content encoding modes
Add a toggle to remove the legacy one-frame buffer at the input of the pipeline allowing the low delay mode to operate at sub-frame processing latencies
Add a new API allowing the user to specify quantization offsets for a region of interest per frame

Build, cleanup and bug fixes:

Various cleanups and functional bug fixes
Fix the startup minigop size BD-rate loss
Add ability to run the ci-testing offline

[ShortKatz]

Version 1.8.0

Encoder

Improve the tradeoffs for the random access mode across presets:
Speedup CRF presets M6 to M0 by 17-53% while maintaining similar quality levels
Re-adjust CRF presets M7 to M13 for better quality with BD-rate gains ranging from 1-4%
Improve the quality and speed of the 1-pass VBR mode
More details on the per preset improvements can be found in MR !2143
Add API allowing to update bitrate / CRF and Key_frame placement during the encoding session for CBR lowdelay mode and CRF Random Access mode
ARM Neon SIMD optimizations for most critical kernels allowing for a 4.5-8x fps speedup vs the c implementation
Cleanup and bug fixes and documentation

Various cleanups and functional bug fixes
Update the documentation for preset options and individual features

[Marsu42]

Version 1.8.0

Does anyone happen to have a Windows binary to share?

Strangely, except for being built into Handbrake (nightly) and ffmpeg I cannot finde recent "SvtAv1EncApp.exe" anywere for use with av1an or custom command lines.

And yes, I know about just-learn-to-compile-it-yourself so with me asking this isn't the answer. :thanks:

[Boulder]

There are some community builds available at the SVT-AV1 Discord channel.

[nakTT]

Version 1.8.0

Tested the ARM version of SVT-AV1 1.8.0 and it is as good as advertised. It is WAYYYY faster than the last one I tested (Version 1.4.1 released on 2022-12-12). HUGE progress made on the ARM front of the SVT-AV1 encoder within the space of just ONE year.
Many thanks to the AV1 development team.:thanks:

[Blue_MiSfit]

I highly recommend you get media-autobuild-suite up and running to cut binaries for you :)

[ShortKatz]

Does somebody know if there are plans to add support for YUV422 to SVT-AV1 ?
The only (outdated) information I found is this: https://www.phoronix.com/news/Intel-TODO-AV1-Decode-FFmpeg

[nakTT]

Version 2.0.0
Changelog

[2.0.0] - 2024-03-13

Major API updates

- Changed the API signaling the End Of Stream (EOS) with the last frame vs with an empty frame
- OPT_LD_LATENCY2 making the change above is kept in the code to help devs with integration
- Removed the 3-pass VBR mode which changed the calling mechanism of multi-pass VBR
- Moved to a new versioning scheme where the project major version will be updated everytime API/ABI is changed


Encoder

- Improve the tradeoffs for the random access mode across presets:
- Speedup presets MR by ~100% and improved quality along with tradeoff improvements across the higher quality presets (!2179)
- Improved the compression efficiency of presets M9-M13 by 1-4% (!2179)
- Simplified VBR multi-pass to use 2 passes to allow integration with ffmpeg
- Continued adding ARM optimizations for functions with c_only equivalent
- Replaced the 3-pass VBR with a 2-pass VBR to ease the multi-pass integration with ffmpeg
- Memory savings of 20-35% for LP 8 mode in preset M6 and below and 1-5% in other modes / presets


Cleanup and bug fixes and documentation

- Various cleanups and functional bug fixes
- Update the documentation to reflect the rate control changes

[ShortKatz]

Did someone experiment already with the new variance boost feature, especially with the values of variance-boost-strength and variance-octile?

[Boulder]

Did someone experiment already with the new variance boost feature, especially with the values of variance-boost-strength and variance-octile?

The default values are very good already and prevent boosting areas unnecessarily. For darker material, changing strength to 3 and/or octile to 4 can be useful.

[ShortKatz]

OK, thanks. I used the default values for some time and started with variance-boost-strength=3 today, so not much experience yet.

[benwaggoner]

The default values are very good already and prevent boosting areas unnecessarily. For darker material, changing strength to 3 and/or octile to 4 can be useful.
I imagine different parameters would be optimal for gamma versus PQ. Algorithms based on code values often fall apart when applied to PQ if they don't account for the big perceptual differences in PQ code values. For example, gamma needs lower QPs near black, but PQ does not. However PQ doesn't have a defined max brightness like gamma does, and can vary hugely between titles and shots.

[ShortKatz]

There is now a handy documentation for the new variance boost feature:
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Appendix-Variance-Boost.md

[benwaggoner]

There is now a handy documentation for the new variance boost feature:
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Appendix-Variance-Boost.md
Great link with some helpful illustrations.

[BlueSwordM]

SVT-AV1-PSY 2.0.0-A Release:
https://github.com/gianni-rosato/svt-av1-psy/releases/tag/v2.0.0-A

This time, we've decided to change the way we name these updates as they've been difficult to keep track of versioning against mainline SVT-AV1 and our own. We'll still follow the cadence of mainline SVT-AV1, but with letter releases added in between for additional clarity.

## PSY Updates

### Features
- The CRF range, previously capped at 63, has been extended to a maximum value of 70. It can also be incremented in quarter increments of 0.25
- New option: `--enable-dlf 2` for a slower, more accurate deblocking loop filter
- New option: `--qp-scale-compress-strength` *(0 to 3)* which sets a strength for the QP scale algorithm to compress values across all temporal layers. Higher values result in more consistent video quality
- New option: `--frame-luma-bias` *(0 to 100)* enables experimental frame-level luma bias to improve quality in dark scenes by adjusting frame-level QP based on average luminance across each frame

### Quality & Performance
- A temporal layer chroma qindex offset has been added to Tune 3 for more consistent quality across frames when encoding
- Minor speed bump to Preset 8
- Encoder innovation:
Dynamic delta_q_res switching implemented to help reduce signaling overhead, which should improve quality especially at CRF ≥40!
- Other general improvements to Tune 3

### Documentation
- PNG images have been replaced with smaller lossless WebP images, resulting in faster loading & repository cloning times.
- More consistent & thorough [PSY Development page](https://github.com/gianni-rosato/svt-av1-psy/blob/master/Docs/PSY-Development.md), including build instructions

### Bug Fixes
- Help menu formatting adjusted for less frequent underlining
- `--progress 2` no longer reports the same information as `--progress 3`

### Other
- Introducing **PSY Micro-releases**! Each micro-release will be marked with a letter, bringing a bundle of new features & improvements. The release letter will reset back to the initial `A` each time our mainline version is updated. More info can be found in this project's README & the PSY Development page


Yes, this is a near copy paste of what I've posted on other public forums :)

[ShortKatz]

Version 2.1 with variance boost has been released.

[2.1.0] - 2024-05-17
API updates

One config parameter added within the padding size. Config param structure size remains unchanged
Presets 6 and 12 are now pointing to presets 7 and 13 respectively due to the lack of spacing between the presets
Further preset shuffling is being discussed in #2152


Encoder

Added variance boost support to improve visual quality for the tune vq mode
Improve the tradeoffs for the random access mode across presets:
Speedup of 12-40% presets M0, M3, M5 and M6 while maintaining similar quality levels
Improved the compression efficiency of presets M11-M13 by 1-2% ( !2213)
Added ARM optimizations for functions with c_only equivalent

Cleanup, build, bug fixes and documentation

Use nasm as a default assembler and yasm as a fallback
Fix performance regression for systems with multiple processor groups
Enable building SvtAv1ApiTests and SvtAv1E2ETests for ARM
Added variance boost documentation
Added a mailmap file to map duplicate git generated emails to the appropriate author


https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

[BlueSwordM]

SVT-AV1-PSY 2.1.0-A release:
https://github.com/gianni-rosato/svt-av1-psy/releases/tag/v2.1.0-A

-> MAIN CHANGES:
- New parameter: `--max-32-tx-size`. This restricts block transform sizes to a maximum of 32x32 pixels. This can be useful in very specific scenarios for improving overall visual quality where the AV1 spec can allow for bad decisions decided by SAD/SSD/PSNR.

- New option: `--hdr10plus-json`. This parameter, added by quietvoid, allows for HDR10+ HDR support. In order to build a binary with support for HDR10+, see our PSY Development page

- New option: `--adaptive-film-grain`. This parameter which helps remedy perceptually harmful grain patterns caused by extracting grain from blocks that are too large for a given video resolution. This parameter is enabled by default.

-> TUNING:
- Disabled SSIM-cost transform decisions while keeping SSIM-cost mode decisions, generally improving Tune 3's efficiency & consistency. Future changes might contain additional tuning at this level.

-> PERFORMANCE:
- Additional NEON optimizations for ARM platforms, providing a speed increase

-> BUG FIXES:
- Temporarily disabled quantization matrices (--enable qm 0) for presets 5 and higher due to a visual consistency bug: https://github.com/gianni-rosato/svt-av1-psy/issues/56

[oibaf]

It looks like from 2.1.1 they removed the decoder:

[2.1.2] - 2024-06-27
Cleanup, bug fixes:

Fixed profile-guided-optimization build by removing the remaining decoder path


[2.1.1] - 2024-06-25
Cleanup, bug fixes, and documentation improvements:

Removed the SVT-AV1 Decoder portion of the project. The last version containing the decoder is SVT-AV1 v2.1.0.
Updated the folder structure and library build order to reflect the removal of the decoder.
Renamed all files (except for API files) to remove the "Eb" prefix and changed them to camel_case format.
Updated the gtest version to v1.12.1.
Added CI support for ARM-based macOS machines.
Improved documentation for accuracy and completeness.

[oibaf]

It looks like from 2.1.1 they removed the decoder:

Here is the rationale: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2182

[Spyros]

SVT-AV1 2.2.0 was released two days ago. (Release (https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.2.0))

Encoder

Improve the tradeoffs for the random access mode across presets:
Speedup of ~15% across presets M0 - M8 while maintaining similar quality levels (!2253 (https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2253))
Improve the tradeoffs for the low-delay mode across presets (!2260 (https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2260))
Increased temporal resolution setting to 6L for 4k resolutions by default
Added ARM optimizations for functions with c_only equivalent yielding an average speedup of ~13% for 4k10bit

Cleanup Build and bug fixes and documentation

Profile-guided-optimized helper build overhaul
Major cleanup and fixing of Neon unit test suite
Address stylecheck dependence on public repositories

[nakTT]

Version 2.2.1
Changelog

[2.2.1] - 2024-08-23

Cleanup and bug fixes and documentation

- Fixed debug arm macOS builds by removing invalid assert

[ShortKatz]

Version 2.3.0

Versionshinweise
[2.3.0] - 2024-10-28

API updates

Preset shift: M12/M13 mapped to M11, M7-M11 shifted one position down. API does not change, all presets from MR-M13 will still be accepted
svt_av1_enc_get_packet API is now a blocking call for low-delay enforcing a picture in, picture out model
--fast-decode range changed from 0-1 to 0-2 available on all presets
Introducing a new definition of --lp being levels of parallelism with a new field in the config structure level_of_parallelism
logical_processors will be deprecated in the 3.0 release
Encoder

NEW FAST DECODE MODE - (!2280)
New fast-decode (2) to allow for an average AV1 software cycle reduction of 25-50% vs fast-decode 0 with a 1-3% BD-Rate loss across the presets
Improved fast-decode (1) option to increase its AV1 software cycle reduction by ~10% while maintaining the same quality levels
Improved --lp settings for high resolutions, with CRF gaining a ~4% improvement in speed and VBR gaining ~15% (!2323)
Further Arm-based optimizations improving the efficiency of previously written Arm-neon implementations by an average of 30%. See below for more information on specific presets
Address speed regressions for high resolutions first pass encode by tuning the threading parameters, with 1080p showing the biggest gains
Enabled AVX512 by default in cmake allowing for ~2-4% speedup
Enabled LTO by default if using a new enough compiler (!2288, !2305)
If LTO is a problem or causes one, it can be disabled by adding -DSVT_AV1_LTO=OFF to cmake to force it off.
Please report any issues that occur when using it.
Cleanup Build and bug fixes and documentation

third_party: update safestringlib with applicable upstream changes
Improved the unit test coverage for Arm-neon code
Updated documentation
Arm Improvements

Speed comparison was done against v2.2 on AWS Graviton4 instances with Clang 19.1.1
--lp 1 was used for all tests


https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

[ShortKatz]

SVT-AV1 now has support for lossless encoding.

[ShortKatz]

This merge request has a comment about a AV1 spec bug.
https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2343/diffs#53baa26f2ca74120683504dad1c9740c6873cb8b_80_101

And a link to this bug https://aomedia.issues.chromium.org/issues/42302342

But I quite don't understand what this bug actually means for AV1 encoding. Will this interfere with encoding quality? Or performance?

[nevcairiel]

This merge request has a comment about a AV1 spec bug.
https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2343/diffs#53baa26f2ca74120683504dad1c9740c6873cb8b_80_101

And a link to this bug https://aomedia.issues.chromium.org/issues/42302342

But I quite don't understand what this bug actually means for AV1 encoding. Will this interfere with encoding quality? Or performance?

It doesnt cause anything, other then headaches for developers to obey the wrong-way-around values.

[oibaf]

This merge request has a comment about a AV1 spec bug.
https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2343/diffs#53baa26f2ca74120683504dad1c9740c6873cb8b_80_101

And a link to this bug https://aomedia.issues.chromium.org/issues/42302342


But I quite don't understand what this bug actually means for AV1 encoding. Will this interfere with encoding quality? Or performance?

According to the bug link it should impact BDRATE, so the quality, however "change is ~neutral overall":
* Change the encoder logic so that we never select a TRANSLATION
type global motion model. If the global motion search process
produces a TRANSLATION type model, we reset to an IDENTITY
type model.

The impact of this change is ~neutral overall, with no video
changing by more than +/- 0.2% BDRATE.

Overall impact on 150 frames, speed 1, const q mode:

lowres2: -0.002% BDRATE, -0.003% instr count
midres2: +0.005% BDRATE, +0.005% instr count
hdres2: -0.001% BDRATE, -0.035% instr count

[ShortKatz]

OK, thanks. :-)

[ShortKatz]

Interesting, it seems some SVT-AV1-PSY features are getting backported into SVT-AV1 mainline.

[oibaf]

Interesting, it seems some SVT-AV1-PSY features are getting backported into SVT-AV1 mainline.

Nice, here is the link to the MRs: https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/?&search=SVT-AV1-PSY

[Z2697]

Interesting, it seems some SVT-AV1-PSY features are getting backported into SVT-AV1 mainline.

Now they shifted their focus to getting more -psy fork features merged into mainline.

[Kurt.noise]

Hi,

I'm experiencing an issue using svt-av1-psy with any different source files : on windows platform (windows 11 24H2), it seems encoding to 8 bits does not ending correctly within preset < 8 :

svt-av1-psy 2.3.0-A 8 bits :
E:\tools\svtav1psy>SvtAv1EncApp.exe -i "E:\Video\Raw.yuv" -w 1920 -h 1080 --input-depth 8 -n 1200 --fps-num 30000 --fps-denom 1001 --progress 3 --crf 30 --preset 4 -b "E:\Video\output.ivf"
Svt[info]: -------------------------------------------
Svt[info]: SVT [version]: SVT-AV1-PSY Encoder Lib v2.3.0-A-5-gf560b40
Svt[info]: SVT : Clang 18.1.8 64 bit
Svt[info]: LIB Build date: Dec 30 2024 07:49:20
Svt[info]: -------------------------------------------
Svt[info]: Level of Parallelism: 5
Svt[info]: Number of PPCS 140
Svt[info]: [asm level on system : up to avx2]
Svt[info]: [asm level selected : up to avx2]
Svt[info]: -------------------------------------------
Svt[info]: SVT [config]: main profile tier (auto) level (auto)
Svt[info]: SVT [config]: width / height / fps numerator / fps denominator : 1920 / 1080 / 30000 / 1001
Svt[info]: SVT [config]: bit-depth / color format : 8 / YUV420
Svt[info]: SVT [config]: preset / tune / pred struct : 4 / SSIM / random access
Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type : 321 / 32 / key frame
Svt[info]: SVT [config]: BRC mode / rate factor : CRF / 30.00
Svt[info]: SVT [config]: AQ mode / variance boost strength / octile / curve : 2 / 2 / 6 / regular
Svt[info]: SVT [config]: Sharpness / QP scale compress strength / Frame low-luma bias : 1 / 1 / 0
Svt[info]: SVT [config]: Temporal Filtering Strength : 1
Svt[info]: SVT [config]: Keyframe TF Strength : 1
Svt[info]: -------------------------------------------
[B]Encoding: 1/1200 Frames @ 23.60 fpm | 380.05 kb/s | Time: 0:00:03 [-0:00:19] | Size: 0.22 MB [1.90 MB]


svt-av1-psy 2.3.0-A 10 bits:
E:\tools\svtav1psy>SvtAv1EncApp.exe -i "E:\Video\Raw.yuv" -w 1920 -h 1080 --input-depth 10 -n 1200 -
-fps-num 30000 --fps-denom 1001 --progress 3 --crf 30 --preset 4 -b "E:\Video\output.ivf"
Svt[info]: -------------------------------------------
Svt[info]: SVT [version]: SVT-AV1-PSY Encoder Lib v2.3.0-A-5-gf560b40
Svt[info]: SVT : Clang 18.1.8 64 bit
Svt[info]: LIB Build date: Dec 30 2024 07:49:20
Svt[info]: -------------------------------------------
Svt[info]: Level of Parallelism: 5
Svt[info]: Number of PPCS 140
Svt[info]: [asm level on system : up to avx2]
Svt[info]: [asm level selected : up to avx2]
Svt[info]: -------------------------------------------
Svt[info]: SVT [config]: main profile tier (auto) level (auto)
Svt[info]: SVT [config]: width / height / fps numerator / fps denominator : 1920 / 1080 / 30000 / 1001
Svt[info]: SVT [config]: bit-depth / color format : 10 / YUV420
Svt[info]: SVT [config]: preset / tune / pred struct : 4 / SSIM / random access
Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type : 321 / 32 / key frame
Svt[info]: SVT [config]: BRC mode / rate factor : CRF / 30.00
Svt[info]: SVT [config]: AQ mode / variance boost strength / octile / curve : 2 / 2 / 6 / regular
Svt[info]: SVT [config]: Sharpness / QP scale compress strength / Frame low-luma bias : 1 / 1 / 0
Svt[info]: SVT [config]: Temporal Filtering Strength : 1
Svt[info]: SVT [config]: Keyframe TF Strength : 1
Svt[info]: -------------------------------------------
[B]Encoding: 1200/1200 Frames @ 2.48 fps | 51442.81 kb/s | Time: 0:08:04 [-0:00:00] | Size: 257.47 MB [257.47 MB]
SUMMARY --------------------------------- Channel 1 --------------------------------
Total Frames Frame Rate Byte Count Bitrate
1200 29.97 fps 257471283 51442.81 kbps


Channel 1
Average Speed: 2.478 fps
Total Encoding Time: 484198 ms
Total Execution Time: 484534 ms
Average Latency: 58361 ms
Max Latency: 96320 ms


For reference, testing also the current svt-av1 2.3.0 8 bits works fine :
E:\tools\svtav1psy>SvtAv1EncApp.exe -i "E:\Video\Raw.yuv" -w 1920 -h 1080 --input-depth 8 -n 1200 --fps-num 30000 --fps-denom 1001 --progress 3 --crf 30 --preset 4 -b "E:\Video\output.ivf"
Svt[info]: -------------------------------------------
Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v2.3.0
Svt[info]: SVT : Visual Studio 2022 64 bit
Svt[info]: LIB Build date: Jan 5 2025 09:41:32
Svt[info]: -------------------------------------------
Svt[info]: Level of Parallelism: 5
Svt[info]: Number of PPCS 140
Svt[info]: [asm level on system : up to avx2]
Svt[info]: [asm level selected : up to avx2]
Svt[info]: -------------------------------------------
Svt[info]: SVT [config]: main profile tier (auto) level (auto)
Svt[info]: SVT [config]: width / height / fps numerator / fps denominator : 1920 / 1080 / 30000 / 1001
Svt[info]: SVT [config]: bit-depth / color format : 8 / YUV420
Svt[info]: SVT [config]: preset / tune / pred struct : 4 / PSNR / random access
Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type : 161 / 32 / key frame
Svt[info]: SVT [config]: BRC mode / rate factor : CRF / 30
Svt[info]: SVT [config]: AQ mode / variance boost : 2 / 0
Svt[info]: -------------------------------------------
Encoding 1200
SUMMARY --------------------------------- Channel 1 --------------------------------
[B]Total Frames Frame Rate Byte Count Bitrate
1200 29.97 fps 11649088 2327.49 kbps


Channel 1
Average Speed: 20.573 fps
Total Encoding Time: 58328 ms
Total Execution Time: 58618 ms
Average Latency: 6539 ms
Max Latency: 8242 ms


Does anybody also experiment this ?

Same story using also this library through ffmpeg...

[GeoffreyA]

Yes, I had a similar problem with the latest version of SVT-AV1-PSY when using a lower preset. The encoding starts, then ends prematurely. Likely, something got broken recently.

[oibaf]

Check if your issue is already reported at https://github.com/psy-ex/svt-av1-psy/issues (maybe this: https://github.com/psy-ex/svt-av1-psy/issues/115), otherwise open a new issue so that they can fix it.

[Kurt.noise]

Thanks for confirmation. Yeah, it looks like issue #115, as already being reported.

And btw, debugging more deeper : issue occured between 2.3.0 & current releases.

[GeoffreyA]

Same for me. It was the recent A release. Before that, never once crashed.

[oibaf]

Please discuss it at: https://github.com/psy-ex/svt-av1-psy/issues/115 where their developers are working. Posting the details here won't help to fix it...

[GeoffreyA]

Sure.

[Kurt.noise]

A workaround has been found : https://github.com/psy-ex/svt-av1-psy/discussions/118

[MZ/X]

A new AV1 vfw encoder/decoder codec (xAV1vfw) is released on http://mpxplay.sourceforge.net with svt-av1 v2.3.0
(it can be used with VirtualDub2 for example)
You can follow the updates here too:
https://www.facebook.com/mpxplay

[BlueSwordM]

A workaround has been found : https://github.com/psy-ex/svt-av1-psy/discussions/118

It's been fully fixed now.

[Kurt.noise]

It's been fully fixed now.
yes, confirmed. Thank you.

[Kurt.noise]

Guys, could you benchmark 2.3.0-B windows x64 using different compilers please ?

https://www.mediafire.com/file/o7gmmb15mc8lx78/svtav1psy-2.3.0-B_x64__-_clang.7z/file
https://www.mediafire.com/file/almitji4ipgcat2/svtav1psy-2.3.0-B_x64_-_gcc.7z/file
https://www.mediafire.com/file/lzjwrvcqeos0nir/svtav1psy-2.3.0-B_x64_-_intel.7z/file

Seems intel one is sightly faster on my machine.

[oibaf]

Better late than never: SVT-AV1 v2.2.x Deep Dive (https://wiki.x266.mov/blog/svt-av1-third-deep-dive)

[oibaf]

The End of SVT-AV1-PSY (https://giannirosato.com/blog/post/end-of-psy/)

[BlueSwordM]

The End of SVT-AV1-PSY (https://giannirosato.com/blog/post/end-of-psy/)

Yeah, we decided on quite the title to get people to read it.

No need to worry though, as most of the team members are still there and somewhat working hard.

I'm working on a guide on how to best take advantage of svt-av1-psy and its new featureset to best effect, as while `--psy-rd` was modeled like what x264/x265 do it, it was extended further by making it touch many more things overall.

[oibaf]

Yeah, we decided on quite the title to get people to read it.

No need to worry though, as most of the team members are still there and somewhat working hard.

I'm working on a guide on how to best take advantage of svt-av1-psy and its new featureset to best effect, as while `--psy-rd` was modeled like what x264/x265 do it, it was extended further by making it touch many more things overall.

Thanks for the feedback and for all the effort on this!

Also very interesting that the patches are being submitted in SVT-AV1 (so that everyone can benefits)!
Actually, 8 patches out of 9 submitted are already merged:
https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/?search=SVT-AV1-PSY
and will be included in SVT-AV1 version following latest 2.3.0.

[ShortKatz]

The End of SVT-AV1-PSY (https://giannirosato.com/blog/post/end-of-psy/)

Ah, this explains why they started porting features from SVT-AV1-PSY to SVT-AV1, I was already wondering.



Also very interesting that the patches are being submitted in SVT-AV1 (so that everyone can benefits)!
Actually, 8 patches out of 9 submitted are already merged:
https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/?search=SVT-AV1-PSY
and will be included in SVT-AV1 version following latest 2.3.0.

The patch for noise-norm-strength was closed without merging. So it's 7 of 9. Only the sharpening PR is now missing. I am wondering if they are planning to port also other feature in the future.
Edit: Now sharpness is also merged. :-)

[oibaf]

Ah, this explains why they started porting features from SVT-AV1-PSY to SVT-AV1, I was already wondering.
I am wondering if they are planning to port also other feature in the future.

From the blog post:
We've authored over 20 highly effective features, aimed at improving perceptual quality and ease of use

20+ total.
8 merged (+1 discarded, + 1 compiler fix).

So, excluding the compiler fix, 20+ - (8 + 1), there are still 11+ specific features still in SVT-AV1-PSY only?

[Z2697]

What's spy-rd?

[Kurt.noise]

What's spy-rd?
it's a psychovisually-based metric focused on enhancing sharpness and detail retention, with a slight trade-off in blocking and banding artifacts, without deeply affecting RD/RDO decisions like psy-rd. The default is 0 (disabled).

It can be used independently or alongside psy-rd.

[Kurt.noise]

SVT-AV1 3.0.0 has been released.


[3.0.0] - 2025-2-20

API updates


Refreshed API cleaning up unused fields, use stdbool type and cleanup redundant parameter in svt_av1_enc_init_handle
Repositioned the presets and removed one preset resulting in a max preset of M10 in the current version
Added temporal layer and averageQP fields in output picture structure, along with an option to specify a QP offset for the startup gop
The API changes are not backwards compatible, more details about the changes can be found in issue 2217


Encoder


Improved mid and high quality presets quality vs speed tradeoffs for fast-decode 2 mode:
~15-25% speedup for M3-M10 at the same quality levels - (!2376 and !2343)
~1% BD-rate improvement for presets M0-M2 - (!2376 and !2343)
Repositioned the fast-decode 1 mode to produce ~10% decoder cycle reduction vs fast-decode 0 while reducing the BD-rate loss to ~1% (!2376)
Further Arm Neon and SVE2 optimizations that improve high bitdepth encoding by an average of 10-25% for 480p-1080p resolutions beyond the architecture-agnostic algorithmic improvements since v2.3.0
Ported several features from SVT-AV1-SPY fork to further improve the perceptual quality of tune 0 mode
Added an avif mode to reduce resource utilization when encoding still images

Cleanup Build and bug fixes and documentation


third_party: Removed vendored cpuinfo, will attempt to use one provided by the system. For those without cpuinfo, it will be pulled and compiled into the library, similar to before
Improved the unit test coverage for Arm Neon and SVE2 code
Updated documentation


Known issue

Mismatch in bitstreams between Arm and x86 platforms that is known not to be due to Arm or x86 optimizations. (#2247)


https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

Some fresh compiles that I made (only windows x64 plateform) if you need to play with :
- https://www.mediafire.com/file/iuwlxpq9qd5n2qn/SvtAv1EncApp-3.0.0_msvc.7z/file
- https://www.mediafire.com/file/l5vb8cnyinem8jv/SvtAv1EncApp-3.0.0_intel.7z/file
- https://www.mediafire.com/file/bqnmejwo8qrib1j/SvtAv1EncApp-3.0.0_clangCL.7z/file

[ShortKatz]

Thanks. Will also soon be implemented in HandBrake to play with.
Edit: SVT-AV1 3.0 is now in HandBrake master.

[rwill]

What's spy-rd?

In contrast to others I actually looked that one up in the source. When spy-rd is enabled certain modes, those that are suspected to smooth the picture, have their RD cost scaled up. So it is not a metric. It narrows down the available modes for the Mode Decision to pick a Mode from. So a huge intervention to RDO decisions without any analysis.

From my experience this will result in spending more bits for slightly less objective quality.

Just avoid.

[ShortKatz]

I played a bit with the new sharpness parameter and I am not a huge fan of it. For me it makes noise unsteady and emphasises it more. But maybe I need to play with it a bit more to find its benefits.

[oibaf]

Couple of new releases:

[3.0.2] - 2025-3-21
Encoder

More Arm simd improvements (!2401, !2402, !2403, !2405, !2409, !2410)
Fixed mising initalization of lossless and avif (#2255, !2404)

Documentation

Add missing --luminance-qp-bias documentation (!2407)


[3.0.1] - 2025-3-10
Encoder cleanup and bug fixes

Further Arm improvements along with fixing arm vs x86 output mismatches (!2393, !2399, !2400, #2247)
Fixed memory leak in compute_global_motion (!2395, #2248)
Fixed integer overflow in subpel search to prevent an assertion (!2396, #2250)
Clean up some undefined behavior (!2398)
API change fixes now available in FFmpeg and GStreamer (#2249, #2252)

Known issue

Hard to reproduce SIGTRAP being raised on macOS m1 with libavif's avifsvttest (#2251)

[oibaf]

Comparing Video Encoders: https://giannirosato.com/blog/post/comparing-encoders/

https://giannirosato.com/static/images/encoder_efficiency.svg

[rwill]

Comparing Video Encoders: https://giannirosato.com/blog/post/comparing-encoders/

Sorry, I only trust encoder comparisons I have manipulated myself.

[oibaf]

svt-av1-psy v3.0.2: Supernova: https://github.com/psy-ex/svt-av1-psy/releases/tag/v3.0.2

This will be the last BIG release of svt-av1-psy for a long while.

I'll be starting to port over all of the relevant features to mainline svt-av1.

However, even after all relevant features will have been ported, I won't be working on "mainline" svt-av1-psy anymore; all future feature additions, bug fixes and optimizations will be done on an svt-av1-psy "fork".

Some members wish to distance themselves from the project for reasons I won't discuss here; they're not harmful to the svt-av1-psy project, those members just want to leave their work on svt-av1-psy as history.

Getting back on topic, we've decided to release our current coup-de-grâce efforts, svt-av1-psy 3.0.2: Supernova. We're going out with a bang!

[ShortKatz]

There is also a new readme, announcing the real end of the project.

I posted a blog post about this in November of 2024, but on April 20th 2025 I can officially announce the actual end of SVT-AV1-PSY.

I stepped away from SVT-AV1-PSY in December of 2024. Our other amazing team member Julio also left shortly afterwards, and a third awesome team member Clybius began to roll back his efforts as well.

https://github.com/psy-ex/svt-av1-psy/blob/master/README.md

[BlueSwordM]

That is indeed correct, although each one left for different reasons.
I'll start porting svt-av1-psy features to mainline starting from next week.

[GeoffreyA]

That is indeed correct, although each one left for different reasons.
I'll start porting svt-av1-psy features to mainline starting from next week.

Thanks for all the hard work, BlueSwordM. I wonder, will there ever be a post detailing what exactly happened, or was it just personal?

[ShortKatz]

I'll start porting svt-av1-psy features to mainline starting from next week.

Thanks for doing so!

[benwaggoner]

Thanks for all the hard work, BlueSwordM. I wonder, will there ever be a post detailing what exactly happened, or was it just personal?
There was a blog post link a few posts back. It sounds highly amicable, thoughtful, and gradual. Life stuff that made it hard to keep on spending many hours a week coding for free was part of it. And something that sounds something like "I'll be starting a new job working on psychovisual encoding so I can help migrate what I did but can't introduce new algorithms."

[BlueSwordM]

Thanks for all the hard work, BlueSwordM. I wonder, will there ever be a post detailing what exactly happened, or was it just personal?

Well, it was actually related to personal life reasons, nothing bad happened.

Some of us got deeper into AV1 (juliobbv and me), one went another way into AV1 (gianni can't work on svt-av1-psy outside of helping me with PRs) and Clybius just stopped working for whatever reason.

[BlueSwordM]

As for the post detailing svt-av1-psy stuff, it'll come with the massive SVT-AV1-PSY x266 docs writeup that will come in the summer.

I just want to settle the basic R&D for now, especially since after the merges are all done (particularly after modifying svt-av1-psy psy-rd to better suit the project), I want to actually retry getting PSYEX-PSNR into a better metric.

For anyone interested, I did actually manage to get SAD-Psy working, and unlike psy-rd, it's purely frequency adaptive; it works in AC and DC bands, meaning that it should theoretically, perform better more effectively.

[GeoffreyA]

There was a blog post link a few posts back. It sounds highly amicable, thoughtful, and gradual. Life stuff that made it hard to keep on spending many hours a week coding for free was part of it. And something that sounds something like "I'll be starting a new job working on psychovisual encoding so I can help migrate what I did but can't introduce new algorithms."

Thanks for that, Ben.

[GeoffreyA]

Well, it was actually related to personal life reasons, nothing bad happened.

Some of us got deeper into AV1 (juliobbv and me), one went another way into AV1 (gianni can't work on svt-av1-psy outside of helping me with PRs) and Clybius just stopped working for whatever reason.

I understand. C'est la vie. Much thanks.

As for the post detailing svt-av1-psy stuff, it'll come with the massive SVT-AV1-PSY x266 docs writeup that will come in the summer.

I just want to settle the basic R&D for now, especially since after the merges are all done (particularly after modifying svt-av1-psy psy-rd to better suit the project), I want to actually retry getting PSYEX-PSNR into a better metric.

For anyone interested, I did actually manage to get SAD-Psy working, and unlike psy-rd, it's purely frequency adaptive; it works in AC and DC bands, meaning that it should theoretically, perform better more effectively.

For my part, ever since the massive growth of new features, I've lost track of SVT-AV1-PSY, but it seems that fantastic work has been done. Good job! I made an FFmpeg build with 3.0.2 the other day, and it works well. A comparison against other encoders is due; I wouldn't mind doing the encoding.

[oibaf]

Thanks everyone involved for all the efforts on this!
:thanks:

[Z2697]

I understand. C'est la vie. Much thanks.



For my part, ever since the massive growth of new features, I've lost track of SVT-AV1-PSY, but it seems that fantastic work has been done. Good job! I made an FFmpeg build with 3.0.2 the other day, and it works well. A comparison against other encoders is due; I wouldn't mind doing the encoding.

I think it's close enough to x26x serie's "PSY quality" in high bitrate, but close enough means not there yet...
Maybe I'm not doing it right, can anyone suggest a set of parameters for "maximum PSY"?

[GeoffreyA]

I think it's close enough to x26x serie's "PSY quality" in high bitrate, but close enough means not there yet...
Maybe I'm not doing it right, can anyone suggest a set of parameters for "maximum PSY"?

Haven't tested it yet but perhaps -psy-rd >= 0.6, which turns on high-quality psy, and -spy-rd 1 or 2.

EDIT: Also, tune=3 seems to be critical, but doesn't work with 2-pass mode.

[BlueSwordM]

I think it's close enough to x26x serie's "PSY quality" in high bitrate, but close enough means not there yet...
Maybe I'm not doing it right, can anyone suggest a set of parameters for "maximum PSY"?

I recommend trying `--psy-rd 0.8 --tune 0/3 --preset -1/2/4 --noise-norm-strength 3 --qm-min 8 --chroma-qm-min 10 --crf XX` as a conservative start.

I believe this should be quite nice, especially if you're willing to use P2, or if you have the time and want to put steroids into svt-av1-psy, P-1.

<=P4 are the recommended presets for high quality psy-rd, although high-quality psy-rd does work at P6; it just has a relatively high compute cost there since it does undo a lot of pruning because of how psy-rd works and the change from var to frequency assisted SAD, causing more recursion.

[GeoffreyA]

A quick test aiming for roughly 5,000 kbps. I used CRF for most encoders because two passes often lead to inconsistent quality on this clip. The modern encoders, x265 and upwards, were allowed to use 10-bit depth. SVT-AV1-PSY 3.0.2 was used in the FFmpeg build. Of course, a wider range of bitrates should be tested: shifiting towards the lower will favour the modern codecs, and vice versa.

Link: https://we.tl/t-ofMEd0w6bl

ffmpeg -i REF.mp4 -c:v mpeg2video -b:v 5000k -pass 1 -f null -
ffmpeg -i REF.mp4 -c:v mpeg2video -b:v 5000k -pass 2 mpeg2.mp4

ffmpeg -i REF.mp4 -c:v libxvid -q:v 7 xvid.mp4

ffmpeg -i REF.mp4 -c:v libx264 -crf 26 -preset veryslow -tune film x264.mp4

ffmpeg -i REF.mp4 -pix_fmt yuv420p10le -c:v libx265 -crf 25.5 -preset veryslow -x265-params deblock=-1,-1:no-sao=1:no-strong-intra-smoothing=1:rd=4 x265.mp4

ffmpeg -i REF.mp4 -pix_fmt yuv420p10le -c:v libsvtav1 -crf 38 -preset 1 -svtav1-params tune=3:psy-rd=0.8:noise-norm-strength=3:qm-min=8:chroma-qm-min=8 svtav1-psy.mp4

ffmpeg -i REF.mp4 -pix_fmt yuv420p10le -c:v libvvenc -qp 23 -preset medium -vvenc-params SAO=0 vvc.mp4

[rwill]

A quick test aiming for roughly 5,000 kbps. I used CRF for most encoders because two passes often lead to inconsistent quality on this clip. The modern encoders, x265 and upwards, were allowed to use 10-bit depth. SVT-AV1-PSY 3.0.2 was used in the FFmpeg build. Of course, a wider range of bitrates should be tested: shifiting towards the lower will favour the modern codecs, and vice versa.


Anyone else getting severe blurring+blocking in some frames of the AV1 version? Or is my VLC not decoding properly?

[Z2697]

Anyone else getting severe blurring+blocking in some frames of the AV1 version? Or is my VLC not decoding properly?

I think it's really there. But the bitrate is low for such strong noise, I wouldn't blame it for that. And it wasn't super noticeable when you are frame peeking.

Let's have a "better" x265 sample by the way https://workupload.com/file/53cWqkuUy3W
Encoding settings based on "preset slowxx (https://github.com/Mr-Z-2697/x265-Yuuki-Asuna/blob/78439ef3662dfa96882c4f70cbe1faf7f32acd2f/source/common/param.cpp#L645-L675) and tune vq2 (https://github.com/Mr-Z-2697/x265-Yuuki-Asuna/blob/78439ef3662dfa96882c4f70cbe1faf7f32acd2f/source/common/param.cpp#L890-L898)"
I mean, at least the grains don't look like they are twitching like in the "original" x265 sample.

[BlueSwordM]

Anyone else getting severe blurring+blocking in some frames of the AV1 version? Or is my VLC not decoding properly?

Oh, don't worry. That can be fixed with more aggressive settings :)
I just gave a relatively mild recommendation.

But yes, you should use mpv instead of VLC. If there was one sole reason for this, it is because VLC sharpens by default, making it unreliable for comparisons alongside its poor colorspace adherence.

[GeoffreyA]

I think it's really there. But the bitrate is low for such strong noise, I wouldn't blame it for that. And it wasn't super noticeable when you are frame peeking.

It's a bitrate virus with that grain. I was surprised to see even x265 get knocked so hard. VVC takes the easy route of just denoising the whole thing, despite SAO being turned off. Come to think of it, I think there's a MT-something setting that disables the temporal denoising in vvenc. Should try that. As for SVT-AV1-PSY, there is certainly a wider range of settings to adjust these results. Simply changing from one tune to another, for instance, makes a visual difference. All in all, it's a big departure from libaom, though.

[Z2697]

VLC sharpens by default

I don't see any sign of that. But it may subject to video card driver settings.

[benwaggoner]

A quick test aiming for roughly 5,000 kbps. I used CRF for most encoders because two passes often lead to inconsistent quality on this clip. The modern encoders, x265 and upwards, were allowed to use 10-bit depth. SVT-AV1-PSY 3.0.2 was used in the FFmpeg build. Of course, a wider range of bitrates should be tested: shifiting towards the lower will favour the modern codecs, and vice versa.

Link: https://we.tl/t-ofMEd0w6bl

[CODE]ffmpeg -i REF.mp4 -pix_fmt yuv420p10le -c:v libx265 -crf 25.5 -preset veryslow -x265-params deblock=-1,-1:no-sao=1:no-strong-intra-smoothing=1:rd=4 x265.mp4

For x265 you really don't need to reduce deblock like x264's --tune film does. Strong intra smoothing is generally fine too. SAO helps when otherwise ringing artifacts would occur, so it's bitrate dependent, but I expect would be net better at CRF 25.5. x265 is also somewhat more content dependent in tuning. For grainy content --rskip 0 can be a lot better. --aq-mode 4 can be better than the default 2, at least for 8-bit SDR content. 2 seems best for 10-bit HDR. --rd 4 is better for grainy UHD resolutions, but 6 is generally preferable for cleaner and lower resolutions (where the low-pass filter of downscaling improves the signal-to-noise ratio. Fine grain at 2160p can make the image almost all noise with little signal, which can freak out --rd 6).

I don't think you'll get 10-bit encoding in x264 without specifying High10, or in x265 without Main10. But perhaps the behavior changed without my noticing. MediaInfo reveals all.

[rwill]

I think it's really there. But the bitrate is low for such strong noise, I wouldn't blame it for that. And it wasn't super noticeable when you are frame peeking.

I was watching it in somewhat optimal viewing conditions and the blurry frames felt like someone slaps me upside the head each time. Cannot recommend. I am not so sure what is causing it because according to the command line its a CRF encode so quantization should be almost constant within a scene? I cannot work on AV1, otherwise I would investigate.

Let's have a "better" x265 sample by the way https://workupload.com/file/53cWqkuUy3W
Encoding settings based on "preset slowxx (https://github.com/Mr-Z-2697/x265-Yuuki-Asuna/blob/78439ef3662dfa96882c4f70cbe1faf7f32acd2f/source/common/param.cpp#L645-L675) and tune vq2 (https://github.com/Mr-Z-2697/x265-Yuuki-Asuna/blob/78439ef3662dfa96882c4f70cbe1faf7f32acd2f/source/common/param.cpp#L890-L898)"
I mean, at least the grains don't look like they are twitching like in the "original" x265 sample.

For HEVC I cannot get the source any better than this:

https://drive.google.com/file/d/1O8Xoz7hj4nyJ01QfvI_LcQmhKlCVSuge/view?usp=sharing

Looks slightly better than yours I guess, but the source starts to get too low quality for the encoder. Maybe needs a ~150Mbit mezzanine and not the 35mbit rip provided here...

[Z2697]

I was watching it in somewhat optimal viewing conditions and the blurry frames felt like someone slaps me upside the head each time. Cannot recommend. I am not so sure what is causing it because according to the command line its a CRF encode so quantization should be almost constant within a scene? I cannot work on AV1, otherwise I would investigate.



For HEVC I cannot get the source any better than this:

https://drive.google.com/file/d/1O8Xoz7hj4nyJ01QfvI_LcQmhKlCVSuge/view?usp=sharing

Looks slightly better than yours I guess, but the source starts to get too low quality for the encoder. Maybe needs a ~150Mbit mezzanine and not the 35mbit rip provided here...

What is the mysterious SEI in the stream beginning?
This is not x265, right?

[rwill]

What is the mysterious SEI in the stream beginning?
This is not x265, right?

That is a compressed configuration record. Its the HEVC encoder from my employer.

[GeoffreyA]

For x265 you really don't need to reduce deblock like x264's --tune film does. Strong intra smoothing is generally fine too. SAO helps when otherwise ringing artifacts would occur, so it's bitrate dependent, but I expect would be net better at CRF 25.5. x265 is also somewhat more content dependent in tuning. For grainy content --rskip 0 can be a lot better. --aq-mode 4 can be better than the default 2, at least for 8-bit SDR content. 2 seems best for 10-bit HDR. --rd 4 is better for grainy UHD resolutions, but 6 is generally preferable for cleaner and lower resolutions (where the low-pass filter of downscaling improves the signal-to-noise ratio. Fine grain at 2160p can make the image almost all noise with little signal, which can freak out --rd 6).

I don't think you'll get 10-bit encoding in x264 without specifying High10, or in x265 without Main10. But perhaps the behavior changed without my noticing. MediaInfo reveals all.

Thanks for the tips. I'll keep them in mind when encoding x265. Here, I wanted to keep the command as simple and untweaked as possible, apart from SAO, to bring out more of a "default" x265. I set --rd to 4 because I remember 6 creating artefacts in another encode, but yes, some of these settings depend heavily on content.

I was watching it in somewhat optimal viewing conditions and the blurry frames felt like someone slaps me upside the head each time. Cannot recommend. I am not so sure what is causing it because according to the command line its a CRF encode so quantization should be almost constant within a scene? I cannot work on AV1, otherwise I would investigate.

I think the problem is temporal or keyframe filtering, which can get even worse in libaom. SVT-AV1-PSY seems to have largely overcome it, but is, perhaps, still constrained by AV1's nature. VVC, through vvenc, comes out even worse in this regard. It's also disaster for many of these encoders, x264 included, in two-pass mode. x265's rate control was solid in two passes.

[Z2697]

I don't think you'll get 10-bit encoding in x264 without specifying High10, or in x265 without Main10. But perhaps the behavior changed without my noticing. MediaInfo reveals all.

With FFmpeg, that's the default behavior, or maybe the only behavior, as the bitdepth conversion code of x265 is not included in the "core encoding function" that FFmpeg wraps around, it will only try to keep the input pixel format, the profile is automatically determined based on that.
That's probably also how almost all of the encoders in FFmpeg works, when some input formats not supported by an encoder, the pixel format conversion is done by auto-insterted swscale filter.
So if the x265 library that linked to FFmpeg is compiled with 10bit support, Main10 profile will be used in this case. The profile parameter doesn't work, even if you specified Main10, but input 8bit, the result is Main profile.

[Z2697]

That is a compressed configuration record. Its the HEVC encoder from my employer.

The quality is suprising. How's the performance? Is it software or hardware encoder?

[Z2697]

Thanks for the tips. I'll keep them in mind when encoding x265. Here, I wanted to keep the command as simple and untweaked as possible, apart from SAO, to bring out more of a "default" x265. I set --rd to 4 because I remember 6 creating artefacts in another encode, but yes, some of these settings depend heavily on content.



I think the problem is temporal or keyframe filtering, which can get even worse in libaom. SVT-AV1-PSY seems to have largely overcome it, but is, perhaps, still constrained by AV1's nature. VVC, through vvenc, comes out even worse in this regard. It's also disaster for many of these encoders, x264 included, in two-pass mode. x265's rate control was solid in two passes.

I tried disable temporal filter with enable-tf=0 but the blurring (or more appropriately, sudden quality drop?) still occurs.

[rwill]

The quality is suprising. How's the performance? Is it software or hardware encoder?

Its a software encoder. Performance wise, well, the overall architecture goal was to not have one of the fastest software encoders but aims it to be one of the prettiest if one is willing to spend extra compute... but not really slower than x265 'veryslow'.

[GeoffreyA]

I tried disable temporal filter with enable-tf=0 but the blurring (or more appropriately, sudden quality drop?) still occurs.

It's puzzling. I tried mainline SVT-AV1 and libaom but it shows up in one form or another.

[juliobbv]

It's a bitrate virus with that grain. I was surprised to see even x265 get knocked so hard. VVC takes the easy route of just denoising the whole thing, despite SAO being turned off. Come to think of it, I think there's a MT-something setting that disables the temporal denoising in vvenc. Should try that. As for SVT-AV1-PSY, there is certainly a wider range of settings to adjust these results. Simply changing from one tune to another, for instance, makes a visual difference. All in all, it's a big departure from libaom, though.

I tried your clip with SVT-AV1-HDR (https://github.com/juliobbv-p/svt-av1-hdr/)'s new film grain tune (--tune 3): https://drive.google.com/file/d/1G5z1-I7W54eu3jZq2G6S_or5aZ80ajAE/view?usp=sharing

Visual quality is significantly better than the previous AV1 clip.

Edit: another version, with FGS `--film-grain 30`: https://drive.google.com/file/d/1ggp9mcggM5S8gecTkKSbHrXlHZm20wFD/view?usp=sharing

[GeoffreyA]

I tried your clip with SVT-AV1-HDR (https://github.com/juliobbv-p/svt-av1-hdr/)'s new film grain tune (--tune 3): https://drive.google.com/file/d/1G5z1-I7W54eu3jZq2G6S_or5aZ80ajAE/view?usp=sharing

Visual quality is significantly better than the previous AV1 clip.

Edit: another version, with FGS `--film-grain 30`: https://drive.google.com/file/d/1ggp9mcggM5S8gecTkKSbHrXlHZm20wFD/view?usp=sharing

Indeed, stepping through the clip frame by frame, the regular blurring and dropping of quality have been defeated.

Tune 3 is equivalent to setting these parameters: --tune 0 --enable-tf 0 --enable-restoration 0 --enable-cdef 0 --spy-rd 1 --psy-rd 4.00 (SDR), 6.00 (HDR)

Is temporal filtering, the loop-restoration filter, or the CDEF responsible for the artefacts we were seeing; or was it a combination of the three?

[BlueSwordM]

Indeed, stepping through the clip frame by frame, the regular blurring and dropping of quality have been defeated.

Tune 3 is equivalent to setting these parameters: --tune 0 --enable-tf 0 --enable-restoration 0 --enable-cdef 0 --spy-rd 1 --psy-rd 4.00 (SDR), 6.00 (HDR)

Is temporal filtering, the loop-restoration filter, or the CDEF responsible for the artefacts we were seeing; or was it a combination of the three?

Nope. tune 0/3 have a noise detector that disables CDEF/restoration filters if the image is too noisy.

On noisy clips like the one julio linked, the noise detector works quite well at disabling those encoding features; you can test it by enabling/disabling these features with tune 0/3 on small isolated noisy clips and seeing that many of them are bit exact.

Anyway, the main reasons behind why Julio's encode looks much better are that Julio did some fancy HDR stuff regarding chroma and variance boost, and he used much more aggressive settings than what I gave you earlier:
https://github.com/juliobbv-p/svt-av1-hdr/blob/main/Source/Lib/Globals/enc_handle.c#L4641

I gave you --psy-rd 0.8.
He gave you --psy-rd 6.0 --spy-rd 1, so much stronger psy-rd influence and the highest level for spy-rd.

Very aggressive settings for this source.

[Boulder]

Nope. tune 0/3 have a noise detector that disables CDEF/restoration filters if the image is too noisy.

On noisy clips like the one julio linked, the noise detector works quite well at disabling those encoding features; you can test it by enabling/disabling these features with tune 0/3 on small isolated noisy clips and seeing that many of them are bit exact.

Anyway, the main reasons behind why Julio's encode looks much better are that Julio did some fancy HDR stuff regarding chroma and variance boost, and he used much more aggressive settings than what I gave you earlier:
https://github.com/juliobbv-p/svt-av1-hdr/blob/main/Source/Lib/Globals/enc_handle.c#L4641

I gave you --psy-rd 0.8.
He gave you --psy-rd 6.0 --spy-rd 1, so much stronger psy-rd influence and the highest level for spy-rd.

Very aggressive settings for this source.
What puzzles me is that the changes were made into a separate fork and not in the same one by adding a new tune option for grain retention. As you've co-operated already earlier, are you planning to have one encoder with best of both worlds?

[juliobbv]

Is temporal filtering, the loop-restoration filter, or the CDEF responsible for the artefacts we were seeing; or was it a combination of the three?

It can be boiled down to these factors:
- Significantly more aggressive psy-rd strength (4.00)
- Better psy-rd algo in general (modulate strength based on frame temporal layer index)
- Some minor tweaks to rdoq to keep chroma information better

[juliobbv]

What puzzles me is that the changes were made into a separate fork and not in the same one by adding a new tune option for grain retention. As you've co-operated already earlier, are you planning to have one encoder with best of both worlds?

It's not puzzling. As previously mentioned, -PSY is discontinued (and archived on GitHub), so I've been making improvements at my own pace on my personal repo. I have a full-time job, so expect future changes to be much more sporadic.

Think of -HDR as "here are my tweaks that I use to encode AV1 videos that I've found helpful". Development is more relaxed, and there are no expectations on future releases or bug-fixes. I'd still encourage people to try out -HDR because my changes have been obviously helpful though.

I do intend my changes to eventually find their way to mainline SVT-AV1, whether it's me who ports the changes, or another person. But again, a demanding full-time job will necessarily make such port process much slower.

[BlueSwordM]

What puzzles me is that the changes were made into a separate fork and not in the same one by adding a new tune option for grain retention. As you've co-operated already earlier, are you planning to have one encoder with best of both worlds?

Yes of course.

I do have a separate repo called svt-av1-psyex, where I now work as the main "svt-av1-psy" repo for features that are intended to be pushed to mainline.

I'm going to be pushing a few helpful updates before I force myself to work on the PR I submitted since I do have a bit more free time than the last few months.

As Julio helpfully stated, most of the current changes will be pushed to mainline, all fixed and tidied up neatly for mainstream domination.

[Boulder]

Thanks, both of you and let's hope you have the needed time to work on the current and future PRs :)

My question was prompted by the fact that the new "tune grain" feature looks like it could be incorporated to psyex as a new tune method, and the PQ variance boost curve as its own so the users can choose between SDR/HDR and clean/grainy settings without having to change the encoder binary ;)

[juliobbv]

Anyway, the main reasons behind why Julio's encode looks much better are that Julio did some fancy HDR stuff regarding chroma and variance boost...

BTW, this source is SDR, so the HDR Variance Boost and chroma stuff doesn't apply here. psy-rd is set to 4.00, which is the default for SDR content.

[juliobbv]

Thanks, both of you and let's hope you have the needed time to work on the current and future PRs :)

My question was prompted by the fact that the new "tune grain" feature looks like it could be incorporated to psyex as a new tune method, and the PQ variance boost curve as its own so the users can choose between SDR/HDR and clean/grainy settings without having to change the encoder binary ;)

BTW, there will be cross-pollination between PSYEX and HDR, so you can expect features from one repo to be cherry-picked to the other.

[juliobbv]

There was a blog post link a few posts back. It sounds highly amicable, thoughtful, and gradual. Life stuff that made it hard to keep on spending many hours a week coding for free was part of it. And something that sounds something like "I'll be starting a new job working on psychovisual encoding so I can help migrate what I did but can't introduce new algorithms."

This is correct. We're still friends and everything, and we're keeping in touch (on Discord mostly). Gianni is currently working on a non-FOSS encoder, so his involvement on SVT-AV1 is now much more restricted regarding new feature development. I now have a full-time video encoding job, so I have to be more mindful with how I spend my free time.

Anyway, Blue and I now have each our own SVT-AV1-PSY fork. Blue's is -PSYEX (https://github.com/BlueSwordM/svt-av1-psyex), and mine is -HDR (https://github.com/juliobbv-p/svt-av1-hdr). We decided that separate repos made the most sense for us, but new features and improvements can be cherry-picked between them at any time. We just have different expectations on releases, rebase timing onto mainline, and bug-fixing priorities.

[GeoffreyA]

Nope. tune 0/3 have a noise detector that disables CDEF/restoration filters if the image is too noisy.

On noisy clips like the one julio linked, the noise detector works quite well at disabling those encoding features; you can test it by enabling/disabling these features with tune 0/3 on small isolated noisy clips and seeing that many of them are bit exact.

Anyway, the main reasons behind why Julio's encode looks much better are that Julio did some fancy HDR stuff regarding chroma and variance boost, and he used much more aggressive settings than what I gave you earlier:
https://github.com/juliobbv-p/svt-av1-hdr/blob/main/Source/Lib/Globals/enc_handle.c#L4641

I gave you --psy-rd 0.8.
He gave you --psy-rd 6.0 --spy-rd 1, so much stronger psy-rd influence and the highest level for spy-rd.

Very aggressive settings for this source.

It can be boiled down to these factors:
- Significantly more aggressive psy-rd strength (4.00)
- Better psy-rd algo in general (modulate strength based on frame temporal layer index)
- Some minor tweaks to rdoq to keep chroma information better

I appreciate the explanations. Yesterday, I tested this out, and found that disabling TF and the loop filters did not eliminate the temporal "flickering," squaring with your notes that psy-rd was key. Thanks for all the work, Blue and Julio. We hope that time could be found to merge these welcome improvements into mainline so that encoders could use one encoder and call it a day.

I do have a separate repo called svt-av1-psyex, where I now work as the main "svt-av1-psy" repo for features that are intended to be pushed to mainline.

Blue, going forward, should people target your repo for the "main" SVT-AV1-PSY branch, or stick with the archived 3.0.2 version?

[Leo 69]

Guys, is there some kind of zones parameter? How do I encode separate parts of videos with different settings with this codec like it's done with x265 for example? Or is av1an the only option for this?

[benwaggoner]

I think the problem is temporal or keyframe filtering, which can get even worse in libaom. SVT-AV1-PSY seems to have largely overcome it, but is, perhaps, still constrained by AV1's nature. VVC, through vvenc, comes out even worse in this regard. It's also disaster for many of these encoders, x264 included, in two-pass mode. x265's rate control was solid in two passes.
That kind of temporal discontinuity has always been an encoder problem, not a codec problem, in my experience. We even had it working well in WMV9 Advanced Profile/VC-1, where we got interframe delta QP for I-frames enabled (it was only P and B in WMV9 Main; an oversight).

[benwaggoner]

With FFmpeg, that's the default behavior, or maybe the only behavior, as the bitdepth conversion code of x265 is not included in the "core encoding function" that FFmpeg wraps around, it will only try to keep the input pixel format, the profile is automatically determined based on that.
That's probably also how almost all of the encoders in FFmpeg works, when some input formats not supported by an encoder, the pixel format conversion is done by auto-insterted swscale filter.
So if the x265 library that linked to FFmpeg is compiled with 10bit support, Main10 profile will be used in this case. The profile parameter doesn't work, even if you specified Main10, but input 8bit, the result is Main profile.
Oh, that's annoying! I didn't realize as I always pipe to x265 when I am using ffmpeg, so I can use the same x265 syntax regardless of the host app.

[benwaggoner]

IYesterday, I tested this out, and found that disabling TF and the loop filters did not eliminate the temporal "flickering," squaring with your notes that psy-rd was key.
Yeah, all low-moderate bitrate video encoding quality is reliant on having psychovisual rate distortion. Reference encoder style fixed GP at fixed QP is useful for early stage development, but never delivers actual real-world quality @ bitrate improvements compared to what a refined encoder for a prior generation codec can deliver.

Video codecs are psychovisual optimizations all the way down, including such basic elements like sRGB, gamma, and quant/lambda tables. Even an uncompressed .BMP file relies on embedded psychovisual optimization to get an 8-bit value to reasonably map to human visual perception.

[oibaf]

FYI: SVT-AV1-PSY -> SVT-AV1 merge progress report (https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2269).

[ShortKatz]

I wouldn't have thought that the film-grain option would be so computationally intensive. If I encode a movie with film-grain=12, encoding takes twice as long as without. It is clear to me that film-grain is computationally intensive, but my surprise is that it is so extreme that the encoding time doubles.

[ShortKatz]

In recent SVT-AV1 master variance boost is broken: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2273

[oibaf]

In recent SVT-AV1 master variance boost is broken: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2273

Fixed: https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2458

(BTW the issue was just in git, not in any official release)

[benwaggoner]

I wouldn't have thought that the film-grain option would be so computationally intensive. If I encode a movie with film-grain=12, encoding takes twice as long as without. It is clear to me that film-grain is computationally intensive, but my surprise is that it is so extreme that the encoding time doubles.
FGS requires analyzing video, identifying what is grain versus content, parameterizing that content, and removing the grain that the parameters can reproduce. That's all out-of-band of the encoder itself, using quite different algorithms that haven't gotten years of hand-tuned assembly optimization. And isn't based on any previously existing codebase like AV1 had VP9.

FGS is great stuff, but is really orthogonal technology to AV1-the-codec, and in a much earlier stage of refinement and adoption. I'm not aware of any big commercial deployments of FGS due to a variety of encoding and playback challenges.

Once the algorithms themselves have been proven and the playback made sufficiently reliable, real optimization can begin.

[Boulder]

FGS is great stuff, but is really orthogonal technology to AV1-the-codec, and in a much earlier stage of refinement and adoption. I'm not aware of any big commercial deployments of FGS due to a variety of encoding and playback challenges.

Netflix is going to be using FGS.

https://netflixtechblog.com/av1-scale-film-grain-synthesis-the-awakening-ee09cfdff40b

[oibaf]

Also: DVB releases findings from Film Grain Synthesis study mission (https://dvb.org/news/dvb-releases-findings-from-film-grain-synthesis-study-mission/).

[benwaggoner]

Netflix is going to be using FGS.

https://netflixtechblog.com/av1-scale-film-grain-synthesis-the-awakening-ee09cfdff40b
And they list some early titles using it! I'll check it out.

I think everyone doing film content wants to be doing FGS once we get sufficient maturity.

[Z2697]

SVT-AV1 by default doesn't apply denoising to the video when film-grain parameter is set. (for a long time now, it used to)
The change is made because the built in denoiser isn't great, but what is it analyzing against then?
That's an essential part of the FGS process right?
It doesn't seem like it's analyzing against the "coded" image either, you'll still get noises even with lossless encoding.
So, is it just adding arbitrary type and amounts of noise?

There's no option for providing a "FGS reference" input, you'll have to use much more sophicticated method if you want that.
Maybe some encoding script, GUI or anything by AV1 enthusiasts already have done that. IDK.
And I'm sure big companies like Netflix must have that figured out?

Anyway, that's the reason why I just go like @!#%#$&% when I see some people saying "hey just turn on a bit of film-grain for everyhing and it makes everything better" online. No it's not (yet? (hopefully)).

[Boulder]

SVT-AV1 by default doesn't apply denoising to the video when film-grain parameter is set. (for a long time now, it used to)
The change is made because the built in denoiser isn't great, but what is it analyzing against then?
That's an essential part of the FGS process right?
It doesn't seem like it's analyzing against the "coded" image either, you'll still get noises even with lossless encoding.
So, is it just adding arbitrary type and amounts of noise?

There's no option for providing a "FGS reference" input, you'll have to use much more sophicticated method if you want that.
Maybe some encoding script, GUI or anything by AV1 enthusiasts already have done that. IDK.
And I'm sure big companies like Netflix must have that figured out?

Anyway, that's the reason why I just go like @!#%#$&% when I see some people saying "hey just turn on a bit of film-grain for everyhing and it makes everything better" online. No it's not (yet? (hopefully)).
It's doing some kind of denoising for analysis, I've seen someone mention what it does, but it wasn't the same what --film-grain-denoise uses (and yes, it's crap and should never be used).

It definitely does not add any lost details back but creates grain adaptively based on the amount of grain/noise the original clip has. In that sense it's rather safe to use at low levels like 6-10, it won't make a clip super grainy if it's originally clean, but it can hide artifacts like banding and add a touch of fake details in the moving image.

grav1synth can be used to create a grain table based on a diff of two clips. It can also be used to extract, add or remove the FGS data from a clip. Doesn't work with all videos though, there are odd crashes every now and then.

[Z2697]

It's doing some kind of denoising for analysis, I've seen someone mention what it does, but it wasn't the same what --film-grain-denoise uses (and yes, it's crap and should never be used).

Applying FGS header without the original noise being removed is also crap... IMO.

[Boulder]

Applying FGS header without the original noise being removed is also crap... IMO.

The encoder removes a fair amount of noise by default so I don't see a problem there. Without a fork with psy-rd capabilities, the amount of blurring is quite substantial.

[benwaggoner]

Applying FGS header without the original noise being removed is also crap... IMO.
Is anyone doing that?

[benwaggoner]

The encoder removes a fair amount of noise by default so I don't see a problem there. Without a fork with psy-rd capabilities, the amount of blurring is quite substantial.
No one should be making AV1 with an encoder with poor psy-rd! Getting encoders to good psychovisual maturity is a major factor in the delay between a codec spec being released and it being used for real-world content.

But in any case, maintaining creative intent requires putting the same kind of grain back, and real-world grain varies a lot. So you really can't do good classification without developing most of a removal algorithm as well.

[Z2697]

Is anyone doing that?

Anyone using SVT-AV1's built-in FGS feature, without enabling the denoising (which is off by default), is doing that, technically.
But the denoising is crap, which in turn makes whole thing crappier, so who can blame them.

Maybe it makes sense (very little, however) that the encoder "conveniently" blurs the video enough, but what I mean is, this is misuse, this feature should be used more carefully.

Just my 2 cents.

[benwaggoner]

Anyone using SVT-AV1's built-in FGS feature, without enabling the denoising (which is off by default), is doing that, technically.
But the denoising is crap, which in turn makes whole thing crappier, so who can blame them.

Maybe it makes sense (very little, however) that the encoder "conveniently" blurs the video enough, but what I mean is, this is misue, this feature should be used more carefully.

Just my 2 cents.
I personally wouldn't consider mainline SVT-AV1's quality sufficient for premium content in any case. And FGS is orthogonal to the codec itself. I'm not aware of any particularly good open source implementations for FGS parameterization and removal.

[oibaf]

[3.1.0] - 2025-7-24 (https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases#310---2025-7-24)

API updates


Added new flags for --chroma-qm-min and --chroma-qm-max from SVT-AV1-PSY (!2442)
Introducing --rtc flag to set the default parameters for an improved RTC performance (!2443)
Enabled M11 and M12 presets for rtc mode for faster speed levels (!2452)


Encoder


Improved mid and high quality presets quality vs speed tradeoffs for fast-decode 0,1,2 modes in random access (!2443):
~15-25% speedup for M1-M5 at the same quality levels for fast-decode 0
~15-20% speedup for M3-M7 at the same quality levels for fast-decode 1,2
1-1.5% BD-Rate improvement for M0 MR
Significant improvements in Low Delay mode and enabling presets 0-6 by enabling missing coding features
Improved performance of the RTC mode with ~5-10% BD-Rate improvements at similar complexity across presets M7-M10 (!2452)
Further Arm Neon and SVE2 optimizations that improve high bitdepth encoding by an average of ~5% in low resolutions
Added S-Frame support for random access mode (!2451)
Additional improvements / porting of features from SVT-AV1-PSY for variance boost (!2431, !2432)


Cleanup Build and bug fixes and documentation


General testing improvements and fixes (!2406, !2454)
Deprecated unused avx512{er,pf} as they were never used and also removed with GCC 15 (!2415)
Visual console display fixes (!2420, !2423)
Fixed compilation bugs and cleanup with Arm (!2417, #2259, !2427, !2434, !2438, !2439)
Fixed some formulas in the documentation (!2444)
Added new options to slim down SVT-AV1 for RTC use cases (!2456, !2457, !2459)
Fixed some issues with QP handling, vbr stability, and screen content (!2458, #2262, #2272, #2273)
Fixes issue with resize-mode (!2463, #2282, #2260)
Removed cpuinfo dependency and instead use cpu detection code from aom (!2426, !2453)


Arm Improvements


Speed comparison was done against v3.0.2 on AWS Graviton4 instances with Clang 20
Uplits are geometric means across presets 0-10


Landscape video:


1080p: +4%
720p: +6%
480p: +6%
360p: +3%
240p: +4%


Portrait video:


1080p: +8%
720p: +4%
480p: +3%
360p: +7%
240p: +4%

[ShortKatz]

SVT-AV1 has now a tune=4 which is a Multi-Scale Structural Similarity (MS-SSIM) and SSIMULACRA2 optimized mode. Is this only meant for pictures, because it was included in the still image MR? Or can this also be useful for videos?

[benwaggoner]

SVT-AV1 has now a tune=4 which is a Multi-Scale Structural Similarity (MS-SSIM) and SSIMULACRA2 optimized mode. Is this only meant for pictures, because it was included in the still image MR? Or can this also be useful for videos?
They would be more useful that PSNR and SSIM, because they are more perceptually accurate metrics. But those are all still single-frame metrics, which means they'll have a lot of false positives and false negatives when used for moving image content. This can be improved partially but not completely with really good analysis of variations between per-frame quality ratings, but there will still be things like grain strobing that this sort of metric is bad at detecting.

[Z2697]

Use tune 0 for better detail (or just switch to x265/4), use tune 1 for "smoosh eye candy/cer". tune 2 feels like something in between.
tune 3 and 4 are for AVIF.
The metrics name in the tune name mean nothing.

If bitrate is high, always prefer tune 0, with low bitrate, it kinda depends on how you or the audience think about "more detail but more noticeable artefact" versus "less detail but smooth and 'clean'"

[hajj_3]

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v4.0.0

Release notes
[4.0.0] - 2026-1-23

API updates:

Major release with new API updates that are not backwards compatible.
Extended the crf range to 70 reducing the impact or QP scaling allowing the encoder to reach lower bitrates
Added quarter steps between crf increments to allow for further granularity in qp selection
Added support for setting a custom global logger for library consumers (!2570 (merged), !2579 (merged))
Cleaned up public API headers including removal of deprecated macros, structs, and fields (!2565 (merged), !2568 (merged))
Additionally cleaned up anything marked using SVT_AV1_CHECK_VERSION().
Added ability to calculate per-frame PSNR and SSIM metrics (!2521 (merged))
Allow sending more than 1 but less than 4 frames with avif mode (This is not for AVIF image sequence, but for encoding an alpha layer) (!2551 (merged), !2560 (merged))
Added tune IQ and MS-SSIM for Still Image coding mode

Encoder:

Significant improvements in AVIF and still image modes (!2552 (merged),!2567 (merged)):
~5-8x speedup M11-M0 at the same quality levels with tune MS-SSIM
~5-8% BD-Rate improvements at the same complexity with tune MS-SSIM
Tradeoff improvements for the RTC modes (!2558 (merged)):
~5-15% speedup at similar quality levels in --rtc mode across presets 7 - 11
Tradeoff improvements for the Random Access mode (VOD use case) showing a 10-25% speedup across presets M7 down to M0 for --fast-decode 1 and 2 (!2558 (merged))
Major feature updates for the visual quality mode with the completion porting all SVT-AV1-PSY applicable features for --tune vq for video and --tune iq for avif (!2484 (merged), !2489 (merged), !2491 (merged), !2494 (merged), !2496 (merged), !2503 (merged), !2504 (merged), !2507 (merged), !2514 (merged), !2522 (merged) , !2561 (merged), !2562 (merged), !2576 (merged)):
Added AC Bias, a psychovisual feature that improves detail preservation and film grain retention
Update S-Frame support to allow setting it in a specific decode order option and with more qp options (!2477 (merged) !2523 (merged) !2534 (merged))
Further Arm Neon and SVE2 optimizations that improve high bitdepth encoding by an average of ~5% in low resolutions
Cleanup, Build and bug fixes, testing and documentation

General code cleanup, bugfixes, documentation and console output changes:

Bugfixes: Fixed an issue with the encoder hanging when given an input with a height of 24 pixels or less (!2518 (merged))
Bugfixes: Fixed a bug that results in encoding an invalid bitstream when using rtc with a high QP value (!2502 (merged))
Bugfixes: Fixed a hang with VBR encoding (#2300 (closed), !2535 (merged))
Bugfixes: Fixed a hang when using recon output with low delay mode (#2315 (closed), !2544 (merged))
Bugfixes: Fixed an encoder crash when using RTC with resolutions not divisible by 16 and presets >= 11 (#2301 (closed), !2547 (merged))
Bugfixes: Fixed bitstream level tier compliance with AV1 specification (#2332 (closed), !2577 (merged), !2581 (merged), !2587 (merged))
Cleanup: Removed in-tree gstreamer plugin (!2586 (merged))
Cleanup: Code specific cleanup for slimmer binary sizes (!2476 (merged))
Testing: Added CI coverage for compiling FFmpeg on macOS Arm (!2536 (merged))
Testing: Added a python based testing framework for comparing codec performance and quality (!2532 (merged), !2550 (merged), !2556 (merged), !2563 (merged), !2564 (merged), !2566 (merged))

[benwaggoner]

Was that really 5-8x speedup with MS-SSIM, not 5-8%?

[Z2697]

Not impossible I'd say, considering it's AVIF specific, and how video encoder might be (very) unoptimized for single frame encoding before.
Easy to test out but I don't care...

[hajj_3]

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v4.0.1

Release notes [4.0.1] - 2026-01-28:

Fixed a missing version bump for shared library and pkg-config (!2593 (merged))
This is now tied to the CMake project version and should not happen again.
Added a CI check to verify this going forward (!2594 (merged))
Fixed tf-strength's default value in the help output (!2595 (merged))
Cleaned up some old debug prints and fixed some Windows build warnings (!2596 (merged))
Fixed bug in incorrect plane selection in quantize_inv_quantize (!2597 (merged))
Fixed hang caused by incorrect update of looping variable in pic_manager_process (!2600 (merged))

[Z2697]

It's been 6 or 7 years. I wonder how good x264 was when it's 6 or 7 years old.

[Blue_MiSfit]

That's about how old x264 was when it started to get really good (VAQ, Psy RD/RDOQ, MB Tree etc) in the late 00s. Kind of apples to apples though :)

[charliebaby]

new Version SVTAV1APP.EXE 4.0.1

https://www.mediafire.com/file/20qruyh36nwrdrx/SvtAv1EncApp_v4.01.rar/file

[VoodooFX]

It's been 6 or 7 years. I wonder how good x264 was when it's 6 or 7 years old.

I would say it took ~5 years for x264 to surpass XviD in all scenarios.

AV1, with all zilliards backing it, is still struggling against x265 after ~7 years...

[rwill]

I would say it took ~5 years for x264 to surpass XviD in all scenarios.

AV1, with all zilliards backing it, is still struggling against x265 after ~7 years...

It is interesting that recent subjective quality improvements of SVT-AV1 can be traced back to some community forks which copied code and concepts from x264. From what I can tell these even had to fight to get their improvements into the main version. These community forks also tend to weaken or outright disable AV1 tools which gave AV1 that VMAF edge against x265 when YouTube creators pushed the new "patent free" format years ago.

I also start to feel offended by the amount of "just lower CRF" recommendations people get that ask how to improve their detail decimated AV1 encodes....

Rather sad state.

[GeoffreyA]

It is interesting that recent subjective quality improvements of SVT-AV1 can be traced back to some community forks which copied code and concepts from x264. From what I can tell these even had to fight to get their improvements into the main version. These community forks also tend to weaken or outright disable AV1 tools which gave AV1 that VMAF edge against x265 when YouTube creators pushed the new "patent free" format years ago.

I also start to feel offended by the amount of "just lower CRF" recommendations people get that ask how to improve their detail decimated AV1 encodes....

Rather sad state.

They've done good work on the forks, but one gets the feeling that they're up against the format itself. Perhaps there are legacy issues in the design, considering that AV1 descends from On2's TrueMotion and VPx codecs.

[Z2697]

I also start to feel offended by the amount of "just lower CRF" recommendations people get that ask how to improve their detail decimated AV1 encodes....

Lowering CRF is an efficient way to improve quality in x264/5 though.

But current AV1 encoder (mainline ones, at least) can't guarantee that, I mean lowering CRF does increase the quality within this codec, but does not make a difference that's comparable to x264/5.
So maybe the answer should be "just switch to x265". (unless they are somehow forced to use AV1) (and maybe not allowed in an AV1 subreddit or something)

But if one wants something low bitrate and still OK to watch, AV1 it the choice, maybe give some credit to that?
Maybe your private HEVC encoder can do that as well, but that's not available to the public.

[rwill]

So when someone needs smaller streams is "just raise CRF" a valid answer?

[Z2697]

I guess technically yes...
That's one way of doing it. (and the most direct one)

[rwill]

I think I can match AV1 quality with Xvid by "just lowering CRF" and match AV1 file sizes with Xvid by "just raising CRF", but at that point what are we even talking about...

[charliebaby]

this test SVT-AV1 v4.01 + Me Setting :-)

https://i.postimg.cc/3rCCTPF4/Ghost-Rider-mkv-snapshot-00-46-32-790.png

https://i.postimg.cc/5N45NnsN/Ghost-Rider-mkv-snapshot-00-46-42-800.png

https://i.postimg.cc/x1WbHR3W/Ghost-Rider-mkv-snapshot-00-16-10-970.png

[Boulder]

In v4, they did some terrible decisions to make the encoder apparently faster. A lot of quality improving settings were shifted to much lower presets than P2, which has been a sweet spot for a long time. The people working on the forks are actively reverting these changes :devil:

[VoodooFX]

this test SVT-AV1 v4.01 + Me Setting :-)

Here is x264 test using rwill settings:

https://images2.imgbox.com/22/12/ydvFbJaj_o.png


I think I can match AV1 quality with Xvid by "just lowering CRF" and match AV1 file sizes with Xvid by "just raising CRF", but at that point what are we even talking about...

That's ungraspable for lowbrains. :)

[rwill]

Yeah, might just take a screenshot from the original BluRay and state "Here is H.264" ...

[Z2697]

Bro can't even make a proper frame cap, and a proper comparison.
Or do we need comparison at all?
The comparison is just something to distract you from the sheer awesomeness of AV1!

"It can be beautiful or terrible, but we are all transfixed."

[VoodooFX]

The guy thinks he's on reddit.

[OvejaNegra]

which svtAV1 should i use? essential , psyex, hdr or MainLine? (many features are already on mainline, but for example, megui uses essential)

which should i use for general encoding without missing important features? thanks

[Boulder]

which svtAV1 should i use? essential , psyex, hdr or MainLine? (many features are already on mainline, but for example, megui uses essential)

which should i use for general encoding without missing important features? thanks

Essential is a good all purposes fork which only has a knob or two that tweak the multiple parameters under the hood.

HDR is good for live action and also quite easy to master. Either tune 5 for content with lots of detailed texture or grain, or tune 0 for the rest. Preset 2 is the sweet spot for performance/quality.

Psyex is abandoned and mainline is missing several psy related features the forks have.

[OvejaNegra]

thanks!

[oibaf]

[4.1] - 2026-03-23 (https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v4.1.0)

Encoder

Refactor MD, EncDec, and Entropy Coding kernels (!2604 (merged))
Improve Still Image coding efficiency (!2612 (merged), !2614 (merged))
Change Wiener Filter level for chroma for presets M3 and below (!2620 (merged))
Optimize Screen Content coding for Still Image (!2630 (merged))

Arm

Refactor Subpixel Variance kernels (!2608 (merged))
Optimize 16b SAD kernel (!2610 (merged))
Fixed Neoverse V2 unit test detection (!2622 (merged))
Update Arm build guide (!2625 (merged))

Bug fixes and documentation

Fixed a hang caused by improper variable looping (#2338 (closed), !2600 (merged))
Add missing option 2 for --enable-dlf's help output (!2601 (merged))
Depth Refinement algorithmic bug fix (!2602 (merged))
Add mutexes to fix hangs when running multiple instances of the encoder in one process (!2603 (merged), !2605 (merged), !2619 (merged))
Fix motion calculation for cyclic QP refresh (!2613 (merged))
Fixed a Debug vs Release mismatch (!2618 (merged))
Fixed some new warnings with newer GCC versions (!2621 (merged), !2636 (merged))
Changed Temporal Filtering distortion calculation to not include padding (!2623 (merged))
Cleanup some dead unit tests (!2626 (merged))
Benchmark framework improvements (!2627 (merged))
CI/CD improvements (!2628 (merged))
Fixed some niche crashes (!2629 (merged))
Readd missing PredStructure enum without SVT_AV1 prefix (!2635 (merged))
Rename svt_log to prevent conflict with SVT-JPEG-XS (!2634 (merged))
General code and doc cleanup (!2606 (merged), !2607 (merged), !2609 (merged), !2611 (merged), !2616 (merged), !2617 (merged), !2624 (merged), !2631 (merged), !2633 (merged), !2637 (merged))

[BlueSwordM]

Soooo, I finally managed to get --hbd-mds user controls into mainline svt-av1:
https://gitlab.com/AOMediaCodec/SVT-AV1/-/commit/1f21a05614db24ec028f65155161e3a6cdd1fdde

Should finally allow mainline svt-av1 to be quite a bit stronger.

[Z2697]

Nice, but ok wait is ac-bias just the same as psy-rd (as it was in psy-ex fork)?
Just noticed it because it being near the diff lines :) and with that comment.

[GeoffreyA]

Good work. I wonder, BlueSwordM, would implementing 16-bit input help in any way?

[BlueSwordM]

Good work. I wonder, BlueSwordM, would implementing 16-bit input help in any way?

Since 10-bit encoding requires a 16-bit buffer, probably not.

[Selur]

Since I couldn't find how to report an issue over at https://gitlab.com/AOMediaCodec/SVT-AV1.
Is there a way to use named pipes with SVT-AV1?

using:
"F:\Hybrid\64bit\Vapoursynth\Lib\site-packages\vapoursynth\vspipe.exe" "J:\tmp\2026-07-11@20_03_00_0010\encodingTempSynthSkript_2026-07-11@20_03_00_0010_0.vpy" \\.\pipe\2026-07-11@20_03_00_0010_02_video --outputindex 0 -c y4m
and
"F:\Hybrid\64bit\SvtAv1EncApp.exe" --input \\.\pipe\2026-07-11@20_03_00_0010_02_video --width 640 --height 352 --fps-num 25 --fps-denom 1 --input-depth 10 --profile 0 --tile-rows 0 --tile-columns 0 --progress 2 --rc 0 --crf 35 --mbr 0 --aq-mode 2 --tf-strength 3 --luminance-qp-bias 0 --sharpness 0 --ac-bias 0 --preset 13 --matrix-coefficients 5 --color-range 0 --output "J:\tmp\2026-07-11@20_03_00_0010\2026-07-11@20_03_00_0010_02.av1"
I get:
Svt[info]: -------------------------------------------
Svt[info]: SVT [version]: SVT-AV1 Encoder Lib v4.1.0-237-g7b41a3f
Svt[info]: SVT [build] : GCC 16.1.0 64 bit
Svt[info]: LIB Build date: Jun 19 2026 18:30:03
Svt[info]: -------------------------------------------
Error: Invalid parameter '--input' with value '\\.\pipe\2026-07-11@20_03_00_0010_02_video'
Error in configuration, could not begin encoding! ...
Run F:\Hybrid\64bit\SvtAv1EncApp.exe --help for a list of options

Cu Selur

[Z2697]

On Windows it needs to use the specific API, on Linux I'd imagine FIFO files work seamlessly...?

[Selur]

On windows normal pipes work too, in most cases (https://github.com/vapoursynth/vapoursynth/pull/1121).
Problem are those cases were normal pipes do not work. => Couldn't find an issue tracker over at gitlab, so can't report this really,..

[Z2697]

It comes down to this (of course for a real patch we need to #ifdef the platform API)
It can also be done by just detecting the string for that prefix... which is what I did for x265.
x264 fixes their code by reordering API calls involving a WaitNamedPipeW. (for different string type)
So I guess using this is preferable.

diff --git a/Source/App/app_config.c b/Source/App/app_config.c
index fa3ba6608..acd86fcbc 100644
--- a/Source/App/app_config.c
+++ b/Source/App/app_config.c
@@ -2025,7 +2025,7 @@ uint32_t get_passes(int32_t argc, char* const argv[], EncPass enc_pass[MAX_ENC_P

if (find_token(argc, argv, INPUT_FILE_LONG_TOKEN, config_string) == 0 ||
find_token(argc, argv, INPUT_FILE_TOKEN, config_string) == 0) {
- if (!strcmp(config_string, "stdin")) {
+ if (!strcmp(config_string, "stdin") || WaitNamedPipeA(config_string, 0)) {
using_fifo = 1;
} else {
#ifdef _WIN32

[Selur]

Hopefully the SVT-AV1 devs can fix this. => is there some official tracker where to report issues?

[Z2697]

Hopefully the SVT-AV1 devs can fix this. => is there some official tracker where to report issues?

https://gitlab.com/AOMediaCodec/SVT-AV1/-/work_items
I guess
Naming is confusing :rolleyes:

[Selur]

Thanks! I bring the issue up there. :)

[Selur]

That is what I thought,.... Problem is, when I try to create a new task or issue I just get a rotation circle and nothing happens. :(

[oibaf]

[4.2.0] - 2026-07-14

VOD / Random Access

Added TUNE-VMAF mode targeting ~15% VMAF BD-rate improvement at minimal PSNR loss
Implemented single-thread processing mode with RA handling
RA preset tuning and bitrate optimization for M3-M5
New CLI options: --cqp, --enable-intrabc, --hbd-mds, --enable-kf-tf
Added raw OBU output format as an alternative to IVF
Signal initial_display_delay in sequence header to fix A/V sync on seek


RTC / Low Delay

Added CBR rate control with Kalman-filter QP estimation, cyclic refresh, and frame re-encode
Added on-the-fly MG size, preset, bitrate, and frame rate changes
Added reference frame management API with LTR support and two-layer RPS structure
Exposed --max-intra-bitrate-pct and --max-inter-bitrate-pct parameters
Improved compression efficiency vs. cycle tradeoff across RTC presets
Optimized memory footprint for RTC mode with small resolutions
Further speed and quality tuning for RTC


Encoder (general)

Refactored entropy coding: direct tile-buffer writes, arithmetic coder simplifications, coefficient shaving
CDEF optimizations: 8-bit boundary-aware filter, persistent scratch buffers, luma/chroma specialization
MD and ME optimizations (LPD1 early-skip, VLPD0 fast path, static-block ME bypass)
Optimized still-image screen content detection
Optimized TPL dispatch when TPL is disabled
Added ENABLE_STACK_PROTECTOR CMake option to prevent the stack protector flag from being added


Arm

Added lowbd (8-bit) int16 forward transform NEON kernels (4x4 through 32x32)
Added Neon SAD, quantize-matrix, SSIM, VMAF, variance, and pixel projection error kernels
Added SVE2 VMAF kernels and hardware CRC-32C for hash-based ME
Optimized convolution, full distortion, and SAD calculation functions


Bug fixes and documentation

Fixed superres recode crash, RESIZE_DYNAMIC under --rtc, RTC candidate-count overflow, recon output, and memory leak
Fixed signed left-shift UB, OOB reads, and race conditions in rate control
Added NVTX/Nsight Systems profiling hooks, PPC toolchain, and macOS universal binary support
Addressed cppcheck warnings and rewrote affected unit tests
Addressed USAN and MSAN warnings
Reduced OBMC stack usage to fix a crash with PGO
General code cleanup, documentation updates, and test improvements