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.

[mastrboy]

Does anyone have a example qpfile for svt-av1? The documentation over at https://gitlab.com/AOMediaCodec/SVT-...ontrol-options does not specificy the format...
Can I reuse the same qpfile I use for x264 when specifying keyframes?

[benwaggoner]

Originally Posted by mastrboy

Does anyone have a example qpfile for svt-av1? The documentation over at https://gitlab.com/AOMediaCodec/SVT-...ontrol-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.