Intel SVT-AV1

[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.