Intel SVT-AV1

[GeoffreyA]

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

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]

Originally Posted by BlueSwordM

I'll start porting svt-av1-psy features to mainline starting from next week.

Thanks for doing so!

[benwaggoner]

Originally Posted by GeoffreyA

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]

Originally Posted by GeoffreyA

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]

Originally Posted by benwaggoner

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]

Originally Posted by BlueSwordM

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.

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

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!

[Z2697]

Originally Posted by GeoffreyA

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]

Originally Posted by Z2697

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]

Originally Posted by Z2697

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]

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

Anyone else getting severe blurring+blocking in some frames of the AV1 version? Or is my VLC not decoding properly?

[Z2697]

Originally Posted by rwill

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 and tune vq2"
I mean, at least the grains don't look like they are twitching like in the "original" x265 sample.

[BlueSwordM]

Originally Posted by rwill

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]

Originally Posted by Z2697

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]

Originally Posted by BlueSwordM

VLC sharpens by default

I don't see any sign of that. But it may subject to video card driver settings.

[benwaggoner]

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

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

Originally Posted by Z2697

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.

Originally Posted by Z2697

Let's have a "better" x265 sample by the way https://workupload.com/file/53cWqkuUy3W
Encoding settings based on "preset slowxx and tune vq2"
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/1O8X...ew?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]

Originally Posted by rwill

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/1O8X...ew?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?