Intel SVT-AV1

[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://www.phoronix.com/scan.php?pa...tem=svt-av1-09

[benwaggoner]

Originally Posted by marcomsousa

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/do...tegard/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]

Originally Posted by 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 .

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]

Originally Posted by wswartzendruber

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.