Intel SVT-AV1

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