Intel SVT-AV1

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