AV1 -- destroys the texture of the grass

[GeoffreyA]

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.

Thanks for the tips. I'll try them.

When piping to SvtAv1EncApp, it says at the end, despite successfully encoding:

Failed to read y4m frame delimeter. Read broken. EOF: 16

Is this a glitch or expected? And, are there any downsides to using FFmpeg to encode the IVF?

[BlueSwordM]

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.

The feature that is being written is mainly the original daala metric, daala_dist, originally used for CDEF.

It's one of the reasons actively got worse in aomenc: CDEF switch from daala_dist to MSE. Not exactly the best idea for perceptual reasons.

Right now, Clybius et al. are working, successfully, on bringing it back to CDEF with excellent results, as well as extending its usage in mode decisions.

[Z2697]

BTW the "pulsating grain" problem is still there, although not quite as noticeable, in this example.

[juliobbv]

Thanks for the tips. I'll try them.

When piping to SvtAv1EncApp, it says at the end, despite successfully encoding:

Failed to read y4m frame delimeter. Read broken. EOF: 16

Is this a glitch or expected? And, are there any downsides to using FFmpeg to encode the IVF?

It's a benign (although admittedly not useful) message -- your video will be fully encoded.

There are a few niche SVT-AV1 features that aren't exposed by the ffmpeg wrapper, but otherwise ffmpeg is fine to encode IVFs.

[GeoffreyA]

I appreciate the help, Julio.

The reason I asked is that sometimes, the FFmpeg muxers and wrappers are a bit shaky, and piping to the reference CLIs are often preferred.

[rgr]

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.

Thanks, I found it and downloaded this ffmpeg.
But the most important information is missing -- what is the codec id for av1--hdr??

[GeoffreyA]

-c:v libsvtav1

[rgr]

Try SVT-AV1-HDR tune 5.

I have to admit that SVT-AV1-HDR produces MUCH better results (I used tune 0).

So why does ffmpeg output what it does and look like it does -- when it could be so much better?

On the other hand: SVT-AV1-HDR looks just like H265 (but the file is 15% larger).

org vs AV1(30_tune0):
https://www.diffchecker.com/image-compare/rYYGyM5L/

AV1(30_tune0) vs H265(22_grain):
https://www.diffchecker.com/image-compare/ILQRvbMT/

[GeoffreyA]

So why does ffmpeg output what it does and look like it does -- when it could be so much better?

An ordinary build of FFmpeg uses the "mainline" version of Intel's SVT-AV1. When this encoder first came out, it was characterised by its speed but low quality. In contrast, the reference encoder, libaom, was slow but high quality, the caveat being that details were lost.

Over time, SVT-AV1's quality improved considerably. Gianni Rosato, BlueSwordM, juliobbv, and others worked on the celebrated SVT-AV1-PSY fork, whose aim was perceptual quality and freedom to experiment. Many improvements, such as Variance Boost, found their way back into the mainline encoder, but one needed the PSY fork to get all the benefit.

The original PSY fork closed shop. BlueSwordM then worked on PSYEX and juliobbv on HDR, each fork having slightly different aims, expectations, and release cadence. PSYEX continued in the tradition of the PSY fork; HDR aimed to preserve detail and grain.

Long story short: the forks have had more extensive tuning to improve quality, putting them some steps ahead of ordinary SVT-AV1. As x264's development showed, tuning takes an encoder to excellence.

[RanmaCanada]

An ordinary build of FFmpeg uses the "mainline" version of Intel's SVT-AV1. When this encoder first came out, it was characterised by its speed but low quality. In contrast, the reference encoder, libaom, was slow but high quality, the caveat being that details were lost.

Over time, SVT-AV1's quality improved considerably. Gianni Rosato, BlueSwordM, juliobbv, and others worked on the celebrated SVT-AV1-PSY fork, whose aim was perceptual quality and freedom to experiment. Many improvements, such as Variance Boost, found their way back into the mainline encoder, but one needed the PSY fork to get all the benefit.

The original PSY fork closed shop. BlueSwordM then worked on PSYEX and juliobbv on HDR, each fork having slightly different aims, expectations, and release cadence. PSYEX continued in the tradition of the PSY fork; HDR aimed to preserve detail and grain.

Long story short: the forks have had more extensive tuning to improve quality, putting them some steps ahead of ordinary SVT-AV1. As x264's development showed, tuning takes an encoder to excellence.

Tuning does take an encoder to excellence, but when you have a multitude number of forks to choose from and the core development teams hide on discord and tell you that "you're basically stupid if you don't know what fork to use" then there is a serious problem with the codec and the team. There have been discussions on reddit in the av1 sub where anyone who says they are confused on what fork to use Trix and the community has called them stupid, ignorant, etc. The community also downvotes anyone with legitimate questions and any criticism, as we've seen in this thread where the OP was told they were "encoding it wrong" even after they were told that they were using a CPU and not a GPU. Heck it took BlueSword coming in here to help push things in the right direction.

[Blue_MiSfit]

Welcome to literally every obscure hobby on the Internet :)

[Z2697]

Tuning does take an encoder to excellence, but when you have a multitude number of forks to choose from and the core development teams hide on discord and tell you that "you're basically stupid if you don't know what fork to use" then there is a serious problem with the codec and the team. There have been discussions on reddit in the av1 sub where anyone who says they are confused on what fork to use Trix and the community has called them stupid, ignorant, etc. The community also downvotes anyone with legitimate questions and any criticism, as we've seen in this thread where the OP was told they were "encoding it wrong" even after they were told that they were using a CPU and not a GPU. Heck it took BlueSword coming in here to help push things in the right direction.

I think the suggestion in first reply is good enough.
By the way it seems OP is using x265 tune grain. That's bad.

[juliobbv]

I think the suggestion in first reply is good enough.
By the way it seems OP is using x265 tune grain. That's bad.

It looks like OP prefers the look of extreme detail retention (or at least the perception of it) over the presence of other artifacts (like ringing). I suppose that's why GeoffreyA suggested trying out SVT-AV1-HDR's tune 5 (the "film grain" tune) first. Some people do seem to like it more over tune 0 (VQ) even on non-grainy content, which I find interesting but hey it's different strokes for different folks.

It's worth keeping in mind that although SVT-AV1-HDR's tune 5 is opinionated, it's not as opinionated as x265's tune grain (e.g. no aggressive RDOQ tuning or disabling temporal AQ).

[rgr]

I think the suggestion in first reply is good enough.
By the way it seems OP is using x265 tune grain. That's bad.

I don't prefer any setting, I was just checking the available options. I ended up leaving a clean libx265 with a slow preset (CRF19 or 22 for longer recordings).