AV1 -- destroys the texture of the grass

[rgr]

I'm surprised at how terrible AV1 is at preserving grass texture. H265 performs better, but not brilliantly. But I expected an improvement, not a deterioration.

https://www.diffchecker.com/image-compare/ak6jxBiD/
https://www.diffchecker.com/image-compare/POaxSnzn/

[GeoffreyA]

Try SVT-AV1-HDR tune 5.

[charliebaby]

AV1 is the best current encoding codec; here are some test video encoding screenshots.

https://zupimages.net/up/26/13/nfr3.jpg
https://zupimages.net/up/26/13/gyjl.jpg
https://zupimages.net/up/26/13/syim.jpg
https://zupimages.net/up/26/13/1pns.png
https://zupimages.net/up/26/13/g8gw.png

[VoodooFX]

AV1 is the best current encoding codec; here are some test video encoding screenshots.

https://zupimages.net/up/26/13/g8gw.png

Looks worse than H264 codec.

[charliebaby]

https://zupimages.net/up/26/13/kl0y.png
https://zupimages.net/up/26/13/uhsb.png
https://zupimages.net/up/26/13/sgn0.png
https://zupimages.net/up/26/13/1woz.png

[rwill]

AV1 is the best current encoding codec;

Then why does it destroy grass texture?

[charliebaby]

Perhaps he encoded using the GPU and not the CPU; we'll have to see which option he used.

[rgr]

Perhaps he encoded using the GPU and not the CPU; we'll have to see which option he used.

CPU, newest ffmpeg.
Settings are listed on the top bar. Basic (CRF) + optional tuning (e.g. tune=0).

Can you show me in which part of my screenshots "AV1 is the best current encoding codec"?

[Z2697]

For cleaning up artifacts and make low bitrate toleratable...
And unfortunately some detail just goes away as collateral damage.

And I think, the best the forks can do is bring it on par with x265 (probably a tad worse) when it comes to high quality detail preserving encodings.

So my suggestion has been, if you are not absolutely stuck with one codec or another, just switch between them based on your targeting bitrate!

[rgr]

So my suggestion has been, if you are not absolutely stuck with one codec or another, just switch between them based on your targeting bitrate!

Bitrate is above 10M.
I never specify a target bitrate. I base my selection on the CRF (for H264 - 17, for H265 - 19), while maintaining a reasonable bitrate (say, up to 30M). Since I currently have hours of content, I figured I'd keep up with the times and save space. I didn't expect that.

[rgr]

Try SVT-AV1-HDR tune 5.

Sounds interesting, but unfortunately I only found the source code.

[john33]

Sounds interesting, but unfortunately I only found the source code.

Compiled from latest git on March 25,2026:https://www.rarewares.org/john33/svt-av1-hdr-4.0.1-c8bdee3-x64.zip

[GeoffreyA]

Bitrate is above 10M.
I never specify a target bitrate. I base my selection on the CRF (for H264 - 17, for H265 - 19), while maintaining a reasonable bitrate (say, up to 30M). Since I currently have hours of content, I figured I'd keep up with the times and save space. I didn't expect that.

Over 10 Mbps, x264 might be the safest approach for transparency. The tune 5 of SVT-AV1-HDR helps grainy content but makes the picture look coarser than the original.

[Z2697]

...

Just better.
https://thumbs2.imgbox.com/d5/a0/NPjjZAkm_t.png (https://imgbox.com/NPjjZAkm)
https://thumbs2.imgbox.com/46/c6/tV9Q0g06_t.png (https://imgbox.com/tV9Q0g06)
https://thumbs2.imgbox.com/6d/38/Y6oBf8Vd_t.png (https://imgbox.com/Y6oBf8Vd)

Codec ID/Info : High Efficiency Video Coding
Duration : 1 h 46 min
Bit rate : 3 751 kb/s
Width : 1 920 pixels
Height : 1 080 pixels

-x265-params sao=0:aq-mode=1:ctu=32:rdoq=1:slow-firstpass=0
I even used cutree rescale and encoded 1st pass in 960x540 for extra speed LOL.
Still beats AV1.
(I'll admit 2nd image doesn't look promising:))

Bro here can't even make a proper frame cap without the window border of the video player LOL.
And the color seems off. (that's not AV1's problem)

[Z2697]

Bitrate is above 10M.
I never specify a target bitrate. I base my selection on the CRF (for H264 - 17, for H265 - 19), while maintaining a reasonable bitrate (say, up to 30M). Since I currently have hours of content, I figured I'd keep up with the times and save space. I didn't expect that.

Bitrate as a result of CRF is still bitrate, you know.
Somewhere around x265's crf 24 is where the two intersect.

[RanmaCanada]

I tend to agree that getting the fine details in SVT-AV1 is pretty difficult. I have yet to be able to find a command line that can compare with my x265 encode settings. Even with the "new" SVT-AV1-Essentlal 4.0.1 I can't seem to dial things in (maybe because once again they changed options), and as usual, no one in the AV1 community wants to help as they think you're attacking them when you state your encodes look like garbage and you're confused about what switches and or forks to use. You'll notice no one has suggested what switches/commands to use to fix the issue of the grass being destroyed, and instead called the user out for complaining saying "you did it wrong", even after the command line they used was posted..

Why is it every time someone asks for help or mentions that the experience didn't meet expectations, they are attacked by the rabid fanbase or worse, told to join the discord?

I would honestly suggest instead of using community ffmpeg, to use the specially compiled one by nekotrix. https://github.com/nekotrix/FFmpeg-Builds-SVT-AV1-Essential and start from there. The amount of forks and special builds that this codec requires one to test and check out is just insane. I would like to help you by also telling you what commands to use, but none of the guides online have been updated and every single command line I have is months out of date. The last good command line I have is for psyex, which is now dead, and I got it directly from a post from Bluesword.

I wish you luck and if you find a command line that preserves the grass, can you please share it.

[birdie]

I tend to agree that getting the fine details in SVT-AV1 is pretty difficult. I have yet to be able to find a command line that can compare with my x265 encode settings. Even with the "new" SVT-AV1-Essentlal 4.0.1 I can't seem to dial things in (maybe because once again they changed options), and as usual, no one in the AV1 community wants to help as they think you're attacking them when you state your encodes look like garbage and you're confused about what switches and or forks to use. You'll notice no one has suggested what switches/commands to use to fix the issue of the grass being destroyed, and instead called the user out for complaining saying "you did it wrong", even after the command line they used was posted..

Why is it every time someone asks for help or mentions that the experience didn't meet expectations, they are attacked by the rabid fanbase or worse, told to join the discord?

I would honestly suggest instead of using community ffmpeg, to use the specially compiled one by nekotrix. https://github.com/nekotrix/FFmpeg-Builds-SVT-AV1-Essential and start from there. The amount of forks and special builds that this codec requires one to test and check out is just insane. I would like to help you by also telling you what commands to use, but none of the guides online have been updated and every single command line I have is months out of date. The last good command line I have is for psyex, which is now dead, and I got it directly from a post from Bluesword.

I wish you luck and if you find a command line that preserves the grass, can you please share it.

Ah, visually lossless encoding with new codecs strikes again.

Don't bother, H.264/H.265 are already good enough and anything later/newer/fresher/"better" (except for AV2 which I've yet to test) is optimized for whole different use cases:
* Low bitrate streaming
* Massive resolutions with a ton of gradients (4K/8K) and not a lot of fine details (e.g. film grain or noisy videos shot in the darkness)

You do not reencode to save bitrate, you need an uncompressed source and try to compress it with AV1/H.266/AV2/H.267 (yet to be released, postponed to 2030 or something).

[VoodooFX]

Yes, I tested and posted many times, in resoluions <= HD, SVT-AV1 is worse than x265 (in lowish bitrates too). And I think it will never be better there.

[GeoffreyA]

5000 kbps comparison:

https://workupload.com/archive/dAA5fDwPBf

zzffmpeg is a MABS build with SVT-AV1-HDR. I should have marked it clearer in the file names.

setlocal
set src=ref-sub.mp4
set bitrate=5000k

ffmpeg -y -i %src% -pix_fmt yuv420p -c:v libx264 -level 4.1 -preset veryslow -tune film -b:v %bitrate% -pass 1 -f null -
ffmpeg -y -i %src% -pix_fmt yuv420p -c:v libx264 -level 4.1 -preset veryslow -tune film -b:v %bitrate% -pass 2 x264.mp4

zzffmpeg -y -i %src% -pix_fmt yuv420p -c:v libx265 -preset slow -b:v %bitrate% -x265-params sao=0:rdoq=1:aq-mode=1 -pass 1 -f null -
zzffmpeg -y -i %src% -pix_fmt yuv420p -c:v libx265 -preset slow -b:v %bitrate% -x265-params sao=0:rdoq=1:aq-mode=1 -pass 2 x265.mp4

ffmpeg -y -i %src% -pix_fmt yuv420p -c:v libaom-av1 -cpu-used 6 -b:v %bitrate% -pass 1 -f null -
ffmpeg -y -i %src% -pix_fmt yuv420p -c:v libaom-av1 -cpu-used 6 -b:v %bitrate% -pass 2 av1.mp4

zzffmpeg -y -i %src% -pix_fmt yuv420p -c:v libsvtav1 -preset 6 -b:v %bitrate% -svtav1-params tune=0 -pass 1 -f null -
zzffmpeg -y -i %src% -pix_fmt yuv420p -c:v libsvtav1 -preset 6 -b:v %bitrate% -svtav1-params tune=0 -pass 2 svtav1.mp4

endlocal
pause

from vapoursynth import core

filenames = ["ref-sub.mp4", "x264.mp4", "x265.mp4", "av1.mp4", "svtav1.mp4"]
files = []

for i in filenames:
f = core.bs.VideoSource(i)
f = f.text.Text(i, alignment=4, scale=2)
f = f.text.ClipInfo(alignment=6, scale=1)
files.append(f)

core.std.Interleave(files).set_output()

[GeoffreyA]

8000 kbps grain comparison:

https://workupload.com/archive/MgGwFpRjAb

x264 fell flat on its face in 2-pass mode. CRF worked fine, but I removed the encoder from the test.

setlocal
set src=REF.mkv
set bitrate=8000k

ffmpeg -y -i "%src%" -pix_fmt yuv420p10le -c:v libx265 -preset slow -b:v %bitrate% -x265-params sao=0:rdoq=1:aq-mode=1 -pass 1 -f null -
ffmpeg -y -i "%src%" -pix_fmt yuv420p10le -c:v libx265 -preset slow -b:v %bitrate% -x265-params sao=0:rdoq=1:aq-mode=1 -pass 2 x265.mp4

ffmpeg -y -i "%src%" -pix_fmt yuv420p10le -c:v libaom-av1 -cpu-used 6 -b:v %bitrate% -pass 1 -f null -
ffmpeg -y -i "%src%" -pix_fmt yuv420p10le -c:v libaom-av1 -cpu-used 6 -b:v %bitrate% -pass 2 aom.mp4

:: SVT-AV1-HDR 4.0.1
zzffmpeg -y -i "%src%" -pix_fmt yuv420p10le -c:v libsvtav1 -preset 6 -b:v %bitrate% -svtav1-params tune=0 -pass 1 -f null -
zzffmpeg -y -i "%src%" -pix_fmt yuv420p10le -c:v libsvtav1 -preset 6 -b:v %bitrate% -svtav1-params tune=0 -pass 2 svtav1-hdr.mp4

endlocal
pause


from vapoursynth import core

filenames = ["REF.mkv", "x265.mp4", "aom.mp4", "svtav1-hdr.mp4"]
files = []

for i in filenames:
f = core.bs.VideoSource(i).fmtc.bitdepth(bits=8)
f = f.text.Text(i, alignment=4, scale=2)
f = f.text.ClipInfo(alignment=6, scale=1)
files.append(f)

core.std.Interleave(files).set_output()

[Z2697]

zzffmpeg is a MABS build with SVT-AV1-HDR. I should have marked it clearer in the file names.


Mine is called "sav1h-ff" :o

[GeoffreyA]

It has the power to save the declining field of video compression :)

[Blue_MiSfit]

Neat - I think svt-av1-hdr has the best stability here. AOM falls apart and the grain smudges out halfway. To be fair, the average bitrate of that version is only 7.1 Mbps.

[GeoffreyA]

Neat - I think svt-av1-hdr has the best stability here. AOM falls apart and the grain smudges out halfway. To be fair, the average bitrate of that version is only 7.1 Mbps.

AOM can achieve fine sharpness and detail for many frames, but then collapses, perhaps owing to temporal filtering kicking in. An interesting denoising effect occurs if the bitrate is very low. SVT-AV1-HDR has good stability but makes the picture a bit coarser, more so with tune 5. No doubt, it can be adjusted.

[BlueSwordM]

I'm surprised at how terrible AV1 is at preserving grass texture. H265 performs better, but not brilliantly. But I expected an improvement, not a deterioration.


Hello and good evening.

I'm curious to know which encoder and what settings you used in this comparison.

[BlueSwordM]

Sorry if I don't interact much here these days, but I'm more into battery stuff these days.

As for why I stopped worked on svt-av1-psyex, the official reason is that I wanted to stop telling people to go to a specific encoder fork, especially with how much mindshare I seem to implicitly possess.

The second non official reason is that Trix told me to stop advertising svt-av1-psyex, even if it had legitimate advancements, because it was outdated.

Anyway, if you have any questions as always, I'll be here to answer them. If you want to see me ramble about batteries, come to endless sphere lmao.

[GeoffreyA]

Thanks for all the AV1 contributions, Blue. Such passion hasn't been seen since x264.

Much like Linux fragmentation, the proliferation of AV1 forks has been a negative, even though allowing for latitude in experiment. As it stands, there is reference libaom, mainline SVT-AV1, and the forks of the latter. If SVT-AV1-HDR could tighten up picture coarseness, it would have the edge, its temporal stability being close to x264/5.

[rwill]

Well with that short grain clip at 8Mbit you are just testing the bitrate control. What you are calling temporal stability is just quantizer adjustment on the go as the encoders try to meet the short overall bitrate target.

What you need to do is to let the encoder hit the target bitrate from the start on and then let the finer things like in-picture bitrate control distribute its bits in the picture. With such short clips with grain this needs 4-6 passes most of the time. Once you have this worked out you can also do things like target different rates and check how different encoders behave when having to make more and more bitrate constrained coding decisions.

Here, I have made an example Grain Bitrate Ladder:

https://drive.google.com/drive/folders/1XNAEl3qlw7pznVFmdGtYot0pgKBbdmba?usp=sharing

I have chosen HEVC for just the reason that people tend to not look at EVC or VVC streams because the time investment to play that back is quite high. Its not like quality differs much between these formats when 80%+ bits go into the film grain.

[GeoffreyA]

You're right, it's rate control being tested. Ideally, CRF should be used, but that meant manually adjusting each one till the bitrates were about the same (i.e., laziness). Generally, I test a 30-second version of that clip, being my grain test, but kept it short here so that the FFV1 upload/download wouldn't be too big.

Bitrate ladders are the right way. Give me some time, and I'll put together a couple of rungs for these encoders using CRF.

[BlueSwordM]

Thanks for all the AV1 contributions, Blue. Such passion hasn't been seen since x264.

Much like Linux fragmentation, the proliferation of AV1 forks has been a negative, even though allowing for latitude in experiment. As it stands, there is reference libaom, mainline SVT-AV1, and the forks of the latter. If SVT-AV1-HDR could tighten up picture coarseness, it would have the edge, its temporal stability being close to x264/5.

To be fair, one of the reason the svt-av1 forks exist is specifically because of freedom.

Nevertheless, I've finally restarted my short work on the hbd-mds PR since I'll finally have some free time on Friday.

I only need to add input bit depth checking to my PR and it'll be ready to merge to mainline.

By far, hbd-mds is one of the most powerful parameter you can have on slower presets. The difference it makes it magical.

[GeoffreyA]

Here's a ladder test with different bitrates:

https://workupload.com/file/vt7veT5WGuN

To be fair, one of the reason the svt-av1 forks exist is specifically because of freedom.

Nevertheless, I've finally restarted my short work on the hbd-mds PR since I'll finally have some free time on Friday.

I only need to add input bit depth checking to my PR and it'll be ready to merge to mainline.

By far, hbd-mds is one of the most powerful parameter you can have on slower presets. The difference it makes it magical.

Interesting. Is that the feature enabled on preset 2 in SVT-AV1-HDR?

[rwill]

Here's a ladder test with different bitrates:

https://workupload.com/file/vt7veT5WGuN


Oh god ... my eyes. But 4Mbit seems to be the point where one can start to judge where things are going.

In my opinion there SVT-AV1-HDR looks the least bad, followed by x264 which sadly suffers from small 4x4 'shit blocks' (kinda VC-1 style), AOM shifts its few details in and out, tying with vvenc and x265 .. well the grain is frozen but looks kinda nice when watching a single frame in pause.

[GeoffreyA]

Trust me, it was slow torture getting those bitrates right with CRF. I've got a headache :)

Yes, the HDR fork puts up a good showing, as well as our venerable x264.

[BlueSwordM]

Here's a ladder test with different bitrates:

https://workupload.com/file/vt7veT5WGuN



Interesting. Is that the feature enabled on preset 2 in SVT-AV1-HDR?

Yes. By default, in svt-av1-hdr >4.0.0, hbd-mds is fully enabled from Preset 4 and slower. The faster presets have some valance regarding that.

Nevertheless, I always set --hbd-mds 1 no matter the preset, because the visual and coding gains of full HBD mode decision is just too good.

svt-av1-essential does force hbd-mds at all times, but that's more of philosophy difference that aligns more with mine than with juliobbv.

[Z2697]

That x265 encode looks bad because the parameters are bad.
Mine: https://workupload.com/file/3n4MwWSwpGJ
ffmpeg -i REF.mkv -c:v libx265 -pix_fmt yuv420p10le -preset slowxx -tune vq4 -x265-params cbqpoffs=-4:crqpoffs=-4:slow-firstpass=0:ctu=32 -pass 2 -map v -b:v 4M p2.265
Yes I used 2pass because I don't care. Saves me time.
Don't ask me what preset and tune is that, it's easy to find if you know where to look ;)
Didn't bother to find which parameter is the key because I'm sleepy Zzz...

[juliobbv]

Here's a ladder test with different bitrates:

https://workupload.com/file/vt7veT5WGuN

Interesting. Is that the feature enabled on preset 2 in SVT-AV1-HDR?

It is. hbd-md is fully enabled on presets 5 and slower, with faster presets progressively disabling hbd-md for more and more frames.

I was also curious on how SVT-AV1-HDR performs with the film grain tune (tune 5) and the recommended preset 2:

https://drive.google.com/drive/folders/1ij1RtrHlYCA6XAHiu14vD9hQSzXnG4K-?usp=sharing

Note: these clips aren't meant to be directly comparable to the other samples in this thread (slower preset after all), but rather they're more indicative of how SVT-AV1-HDR performs with known-good settings with "bang for the buck" quality/effort tradeoffs.

Also, tune 5 is meant to be opinionated (by prioritizing grain retention over overall fidelity), but oftentimes it's been useful for this kind of grainy content.

I used the latest HandBrake build with SVT-AV1-HDR to generate the clips, but these were the equivalent settings I used for the bitrate ladder:
`preset 2, tune 5 (film grain), CRF 34 (8k), 36.5 (4k), 38.75 (2k), 41.5 (1k), 43.75 (0.5k)`

This also proves the film grain tune tends to not look good with CRF values beyond 40. :D

[Z2697]

Also proves the best one can do when it comes to AV1 and grain is bring it close to x265, currently.
Of course the official presets of both don't perform well.

(I have insomnia)

[GeoffreyA]

Nevertheless, I always set --hbd-mds 1 no matter the preset, because the visual and coding gains of full HBD mode decision is just too good.

Coincidentally, without realising why, I noticed that when I went from tune 6 to tune 5, there was a substantial drop in bitrate.

That x265 encode looks bad because the parameters are bad.

The parameters could have been much improved, but I wanted it "close to default," apart from one or two things such as SAO.

Also proves the best one can do when it comes to AV1 and grain is bring it close to x265, currently.
Of course the official presets of both don't perform well.

It's clear that AOM and VVC stand no chance in content like this. To be fair, I used the fastest VVC preset and didn't disable SAO, but I doubt whether it makes much difference. The mystery is, where does all the compute go?

(I have insomnia)

Drink a bit of chamomile tea. I tend to watch Star Trek: Voyager before going to sleep; it's brilliant and one sleeps well afterwards :)

[GeoffreyA]

It is. hbd-md is fully enabled on presets 5 and slower, with faster presets progressively disabling hbd-md for more and more frames.

I was also curious on how SVT-AV1-HDR performs with the film grain tune (tune 5) and the recommended preset 2:

https://drive.google.com/drive/folders/1ij1RtrHlYCA6XAHiu14vD9hQSzXnG4K-?usp=sharing

Note: these clips aren't meant to be directly comparable to the other samples in this thread (slower preset after all), but rather they're more indicative of how SVT-AV1-HDR performs with known-good settings with "bang for the buck" quality/effort tradeoffs.

Also, tune 5 is meant to be opinionated (by prioritizing grain retention over overall fidelity), but oftentimes it's been useful for this kind of grainy content.

I used the latest HandBrake build with SVT-AV1-HDR to generate the clips, but these were the equivalent settings I used for the bitrate ladder:
`preset 2, tune 5 (film grain), CRF 34 (8k), 36.5 (4k), 38.75 (2k), 41.5 (1k), 43.75 (0.5k)`

This also proves the film grain tune tends to not look good with CRF values beyond 40. :D

What is the feature, or feature disabled, that causes HDR to keep the frames "temporally steady"? In contrast to AOM, where we get blurry ones hidden between the others.

For my part, I prefer tune 0's visual appearance, being finer. However, if we step through it frame by frame using the VapourSynth script, comparing my 4M tune 0 and your 4M tune 5, yours is more consistent, whereas tune 0 does possess blurry frames; it's just not so noticeable as AOM. The trade-off with tune 5 is that the picture becomes "coarser," the grain being more "spread out," for want of better terms. Can that be adjusted whilst keeping the other principles intact?

[juliobbv]

What is the feature, or feature disabled, that causes HDR to keep the frames "temporally steady"? In contrast to AOM, where we get blurry ones hidden between the others.

It's basically a bunch of tweaks that add up together. If you want to have more control over the grain retention/grain size trade-offs, you can de-alias tune 5 into its own individual parameters and tweak each one independently: --tune 0 --enable-tf 0 --enable-restoration 0 --enable-cdef 0 --complex-hvs 1 --tx-bias 1 --ac-bias 4.00

I'd begin with lowering ac-bias and/or adding a bit of temporal filtering: --enable-tf 1 --tf-strength 0

Ideally you wouldn't need the de-aliasing step, but SVT-AV1 doesn't support adjusting per-tune defaults yet.

[rwill]

I was also curious on how SVT-AV1-HDR performs with the film grain tune (tune 5) and the recommended preset 2:

https://drive.google.com/drive/folders/1ij1RtrHlYCA6XAHiu14vD9hQSzXnG4K-?usp=sharing

Note: these clips aren't meant to be directly comparable to the other samples in this thread (slower preset after all), but rather they're more indicative of how SVT-AV1-HDR performs with known-good settings with "bang for the buck" quality/effort tradeoffs.


This doesn't look so bad. At the critical rate of around 4Mbit there are small patches of 'swimming' grain though, where patches of grain float along with the underlying object. Looks like there are some more tweaks in the Mode Decision needed.

For fun I encoded the sequence in VVC, HEVC and EVC Baseline. To me they all look the same given the same rate. Kind of shows subjective quality is down to the encoder implementation and not the video standard:

https://drive.google.com/drive/folders/1R11vDadMMMD1VwMesf1OWzllwUoV6rnW?usp=sharing

If someone knows how to play back EVC Baseline using ffplay reliably please do tell, I have to decode and encode lossless with ffmpeg to watch them in a player...

[rgr]

Hello and good evening.

I'm curious to know which encoder and what settings you used in this comparison.


ffmpeg -hide_banner -avisynth_flags +all -i %1 ^
-c:v libx264 -preset slow -crf 21 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (x264-21).mp4" ^
-c:v libx264 -preset slow -crf 21 -tune film -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (x264-21_film).mp4" ^
-c:v libx265 -preset slow -crf 22 -pix_fmt yuv420p -x265-params tune=grain:aq-mode=3:no-open-gop=1 -c:a aac -b:a 192k "%~n1 (x265-22_grain_aqmode3).mp4" ^
-c:v libx265 -preset slow -crf 22 -pix_fmt yuv420p -x265-params tune=grain:no-open-gop=1 -c:a aac -b:a 192k "%~n1 (x265-22_grain).mp4" ^
-c:v libx265 -preset slow -crf 0 -pix_fmt yuv420p -x265-params no-open-gop=1 -c:a aac -b:a 192k "%~n1 (x265-lossless).mp4" ^
-c:v libaom-av1 -cpu-used 3 -crf 27 -row-mt 1 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (av1aom).mp4" ^
-c:v libsvtav1 -preset 3 -crf 23 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (av1).mp4" ^
-c:v libsvtav1 -preset 3 -crf 30 -svtav1-params tune=0 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (av1-30-tune0).mp4" ^
-c:v libsvtav1 -preset 3 -crf 30 -svtav1-params tune=0:enable-tf=0:film-grain-denoise=0:film-grain=30:enable-overlays=1 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (av1-grain30).mp4"
-c:v libsvtav1 -preset 3 -crf 30 -svtav1-params tune=0:enable-tf=0:film-grain-denoise=0:film-grain=30:enable-overlays=1:lsf-amplify=0.10:lsf-radius=11:lsf-std=12 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (av1-grain30_lsf).mp4"
-c:v librav1e -speed 3 -crf 60 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (av1-rav1e-sp3_60).mp4"
-c:v librav1e -speed 2 -crf 78 -pix_fmt yuv420p -c:a aac -b:a 192k "%~n1 (av1-rav1e-sp2-78).mp4"


Output filesizes are 7-8MB (~10Mbps), except H265 lossless, AV1-CRF23 (11MB) and last 3 disabled settings.

[juliobbv]

Sounds interesting, but unfortunately I only found the source code.

https://github.com/juliobbv-p/svt-av1-hdr?tab=readme-ov-file#downloads

Here you can find links for ffmpeg and HandBrake builds. I'd also recommend reading the Quick Overview to get you started.

[kurkosdr]

(I have insomnia)
Melatonin + valerian root extract supplements works for me.

Or diphenhydramine (aka diphenhydramine hydrochloride) or hydroxyzine for those (rare) worst cases of insomnia for me.

Keep in mind that:

1) Availability varies by country, for example, melatonin is somewhat more regulated in some countries like the UK (you have to book an appointment with a pharmacist and explain your case etc), and diphenhydramine is not sold in some other countries (Greece)

2) Don't use long-term or even medium-term, these remedies are intended to reset your sleeping schedule, not to enable you to surf the internet or watch videos beyond your bedtime

3) This is what worked for me, but I am not a doctor and I can't and don't provide medical advice (for example, some medicines you may take may react badly with any of the substances I mentioned above), consult your doctor or pharmacist before taking anything

(this has got to be the weirdest post I've posted on Doom9, but whatever, you only live once, right?)

[juliobbv]

This doesn't look so bad. At the critical rate of around 4Mbit there are small patches of 'swimming' grain though, where patches of grain float along with the underlying object. Looks like there are some more tweaks in the Mode Decision needed.

Yeah, that's a good observation. I opened the 4 Mbit clip with a bitstream analyzer, and I can see the encoder is under-allocating bits around those areas with swimming grain. There's definitely room for improvement in MD logic.

[RanmaCanada]

Sorry if I don't interact much here these days, but I'm more into battery stuff these days.

As for why I stopped worked on svt-av1-psyex, the official reason is that I wanted to stop telling people to go to a specific encoder fork, especially with how much mindshare I seem to implicitly possess.

The second non official reason is that Trix bullied me for the reason above into stopping advertising svt-av1-psyex as well as other AV1 encoder advancements.

Anyway, if you have any questions as always, I'll be here to answer them. If you want to see me ramble about batteries, come to endless sphere lmao.

I know this is late, but I am sorry to read that Trix did that to you, but I am not surprised. You were very helpful and very open about addressing issues, and it's a shame that you are no longer involved. I do hope for the best for you in the future and that your mental health will be much improved.

Thank you for all your help in the past.

[BlueSwordM]

Nah, don't worry, I'm still involved just fine.

I'm just slower on the subject and prefer to take things slowly, like pushing the hbd-mds patch to mainline so I can finally publish the svt-av1 guide I've had cooking up for months at this point.

As for the bully part, it wasn't anything serious from Trix at all. We're still great friends :)

It's just that Trix knows I have enormous mindshare because of the way I write and interact with everyone, and he thought that I should focus more on bringing my svt-av1-psyex stuff to either svt-av1-hdr or mainline and stop focusing on outdated builds. I should be more responsible overall.

[BlueSwordM]

Also, Clybius and another new person is currently working on some incredible stuff that includes some daala stuff as well some greatly improve photon noise grain synthesis if you've been following the svt-av1-hdr repository.

[Z2697]

I'd more like to consider calling Chroma from Luma, Lapped Transform, Frequency Domain Intra Prediction, etc. as daala stuff.
Which unfortunately are mostly impossible for AV1 at this step. Except CFL, which already exists.

Where's Thor stuff, by the way?
It looks like the absolute majority of featuers are from VP10.

[GeoffreyA]

The CDEF is a blend of filters from Thor and Daala.