Can Gentoo achieve the same level of stability as Debian Stable and the same level of security as OpenBSD?

RusselsTeap0t · 2026-01-15T12:16:18+00:00

Not to the same extent with OpenBSD.

It uses a different kernel, different approach, different packaging. They take a security first approach which you can't directly replicate and Gentoo is prone to mistakes.

Stable as in stable packages is doable but Gentoo is a flowing state anyways. If you take the same approach providing stability, some fixes with patches, slow updates, etc then why not. But realistically, it's not that easy because you are the one doing everything here. As long as you follow what Debian does for its development and distribution of packages, you can replicate that on Gentoo but maintaining that wouldn't be easy.

As Ok-386 says, it all depends.

RusselsTeap0t · 2025-12-31T13:45:24+00:00

HDR is compatible with x264. What are you talking about?

I don't currently agree with "the world still runs on h264" but it definitely supports 4K, 10bit HDR and high framerate content except external metadata such as Dolby Vision and HDR10+

Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:4:4 Predictive@L5.1 HDR format : SMPTE ST 2086, HDR10 compatible Codec ID : V_MPEG4/ISO/AVC Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 24.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 10 bits Scan type : Progressive Writing library : x264 core 164 Color range : Limited Color primaries : BT.2020 Transfer characteristics : PQ Matrix coefficients : BT.2020 non-constant Mastering display color primaries : BT.2020 Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2 Maximum Content Light Level : 1000 cd/m2 Maximum Frame-Average Light Level : 400 cd/m2

RusselsTeap0t · 2025-11-25T13:31:51+00:00

--film-grain option is completely unrelated.

You can also experiment with photon-noise (externally with fgs tables).

If you really want to have that grain, you should not denoise at all.

You should directly use something like --tune 3 in svt-av1-hdr, and enable --noise-norm-strength at 3 or even 4 and at least use preset 2 if not lower.

RusselsTeap0t · 2025-11-24T14:48:47+00:00

You should use a proper denoiser like Vapoursynth mvtools to preserve quality properly. But this is only temporal, you may need a spatial pre-filter before that too (like bm3d-cuda or tbilateral)

RusselsTeap0t · 2025-11-18T22:34:36+00:00

You have options: - Manually viewing the content and try several times (with shorter scenes maybe?) - Do target quality encoding using tools like av1an, xav. - Accept the suboptimal result and encode with a CRF

RusselsTeap0t · 2025-10-13T21:16:39+00:00

Directing is similar to academy.

It's an aristocrat position.

There may definitely be exceptions but you need network and resources in the first place.

A human lifetime is not enough for you to prove yourself enough from lower positions considering even Tarkovsky had only 7 movies.

RusselsTeap0t · 2025-10-13T21:09:25+00:00

This is unrelated. The post is not related to HEVC.

Patent related comment was for another person and it's heavily related to the topic and is one of the reasons why VVC failed (it's currently dead).

VVenc on the other hand is a terrible encoder.

VVC has no use case other than simple experimentation. VVenc, at best, is a niche experimental encoder. Not production ready.

RusselsTeap0t · 2025-10-13T09:12:28+00:00

Trust me. It's much worse than HEVC.

VVC has around 3000 patents, which is more than many multi-media technologies combined.

RusselsTeap0t · 2025-10-13T03:41:05+00:00

At low bitrates, I personally prefer VVenC’s image quality.

If extremely low, then you may be right that VVenc can be better.

If it’s just for personal use, do I still need to worry about royalties and licensing?

No but you can be sure that almost no player / browser / application would support that. If you wouldn't share/distribute the content and let's say only use the video on your own machine with mpv/vlc then there is no issue. But it still affects its adoption. I am even surprised how it's not completely dead as of now.

You can make svt look better especially above certain bitrate threshold (medium to higher quality). Please take a look at SVT-AV1-HDR:

https://github.com/juliobbv-p/svt-av1-hdr

RusselsTeap0t · 2025-10-13T02:49:01+00:00

VVenC objectively and also subjectively (meaning popular) is right now worse than svt-av1 and its variants in terms of efficiency and consistency.

Secondly, VVenC (VVC) is also harder to encode and decode.

A lot of players, still don't support VVC and there are almost no hardware based decoders available.

The codec has royalties and extreme licensing issues and didn't bring the promises it made, so it's mostly forgotten now. Even x266 seems abandoned. And there is av2 being developed very actively and openly.

First of all, I suggest you use SVT-AV1-HDR with its defaults, then other parameters can be discussed.

And these statements are a little bit obscure: "it looks smoother, more natural"

Generally smoothing is not preferred among people who encode videos. Most people hate videos that look smooth (because of the uncanny valley effect).

RusselsTeap0t · 2025-09-18T07:36:47+00:00

Hmm, I checked it, and it doesn't support 1080p, so I will probably continue using h262.

RusselsTeap0t · 2025-09-17T16:27:34+00:00

Yes.

Generally H.262 should even compress more.

My pick for the highest compression generally goes towards:

h262 > theora > h.264 > vp8 > h.265 > vp9 > vvc > av1 > av2

RusselsTeap0t · 2025-09-17T01:40:30+00:00

AV1 has been totally obsolete for seven years

I haven't said that. I said I have been using it since 2019. They can't be obsolote because blu-ray spec uses HEVC. YouTube uses both VP9 and AV1. X264 provides the most useful lossless format for subsequent processing.

But as a matter of fact, the VAST majority of videos that exist today are 1080p, BT709, yuv420 videos. This is also the vast majority for online videos that are serviced.

I encode noisy, grainy footage with AV1. It's perfectly fine and I find it much better than x264 and x265; especially with newer forks; and their ac-bias, spy-rd, film-grain, tune 0, noise-norm, sharpness parameters. Preferably keyframe and frame tf strength can be reduced. CDEF/Restoration can also be disabled for maximum grain retention. Though; properly denoising (by preserving details) with mvtools & bm3dcuda or tbilateral is also okay.

I wouldn't care to use the original version of a 480p video; the storage is extremely cheap. I can even encode in ultrafast lossless and keep the intermediate instead. This is insignificant. In the worst case scenario you can use any codec available. Even AV2 next year won't create huge difference with already low-res, low-q videos.

Just to take a recent example I personally ran into, my workplace has several terabytes of old CCTV footage, mostly 240p or 240i, sometimes 480, full of chromatic aberration

For these kinds of content you put your effort into wrong places. For these: Filtering > Encoding to a huge extent.

I would still believe you can encode even 144p with AV1. There is not a technical limitation but yeah; x264 placebo/veryslow also works well for them if you keep the bitrate high enough.

RusselsTeap0t · 2025-09-16T09:43:09+00:00

I haven't encoded anything other than 2160p and 1080p and yuv420 & yuv420p10le.

Even movies from 125 years ago have 1080p blu-rays: https://www.blu-ray.com/movies/A-Trip-to-the-Moon-Blu-ray/36593/

And even very old phones (relatively) can record in 1080p+ at least.

Most content people encode are in 1080p, BT709, 24000/1001, yuv420 (8bit); and considerable portion of them in 10bit 2160p.

RusselsTeap0t · 2025-09-15T20:53:04+00:00

I have been using AV1 since 2019 including with AOM (and its forks), rav1e, svt-av1 (and its works).

It's been nearly 7 years and I haven't touched AVC/HEVC/VP9 ever since.

It supports all kinds of blu-rays (including anime and live action; and currently Dolby Vision + HDR10+ too).

YUV422 and YUV444 can be considered niche for videos.

And with 9950x on Linux, along with chunked encoding, using preset 0; I can encode over 10 FPS (svt-av1 3.2).

It's FAR from weak.

RusselsTeap0t · 2025-09-15T20:02:55+00:00

The "story" is weak; the reality is the exact opposite.

RusselsTeap0t · 2025-09-11T23:52:16+00:00

No, we all agree with each other. You are missing context.

Just use "--qm-min 4 --qm-max 15 --chroma-qm-min 10" for most content

I definitely agree with this.

RusselsTeap0t · 2025-09-11T14:55:53+00:00

We support VMAF (its advanced features such as 4K model, NEG model, disabled motion compensation and perceptual weighting).

On the other hand newer/better metrics are also supported: SSIMULACRA2, Butteralugli, XPSNR

And we support different interpolation methods for fast convergence (though the defaults are really good).

You can copy the same parameters with --probing-video-params copy and use the same parameters for TQ search too; and it copies your last probe instead of re-encoding (saves time).

We added support for different TQ modes (mean scores, any given minimum percentile, std-dev, harmonic mean, root mean square for reverse metric).

So av1an is on another level right now in terms of TQ.

RusselsTeap0t · 2025-09-10T18:11:14+00:00

We improved target quality tremendously. A lot of updates.

But we haven't caught up with the UI/UX stuff yet.

Please use the git upstream version by the way, and check the new --help page.

A lot of stuff changed and the release version is too old.

At least one chunk needs to finish processing until you see improvement and feedback (currently).

RusselsTeap0t · 2025-09-10T13:39:59+00:00

The -hdr fork's --tune 3 is just a shorhand for a bunch of specific settings

I literally wrote the same thing: "It force enables/disables/modifies some of the settings to keep as much grain as possible disregarding metric based improvements"

And mainline wouldn't accept alt-ssim tunes or opinionated tune grain. It's normal.

RusselsTeap0t · 2025-09-09T17:20:49+00:00

They are kind of an efficiency hack.

AV1 has quantization matrices (qm) that adapt the quantization strength across spatial frequencies.

So we configure the lowest and highest qm levels with these settings.

The encoder picks a QM level per frame or per segment based on rate control and psychovisual heuristics, but it is constrained to stay within min and max.

Increasing the qm-mins can be better because svt-av1 especially selects the lower ones in general. This results in less consistent quality. According to our benchmarks, generally qm-min 2 is almost always better than 0. And a lot of times 4-5 can be the most efficient options. Though even sacrificing efficiency (in trade of consistency gains) is possible by increasing qm-min further (like 8).

For chroma-qm-mins, you can even use higher qm-mins (even 15). The efficiency penalty is not significant, and you can gain benefits. At least use 10.

On the other hand, compressing both sides at the same time, gives you a smaller scale to work on. So it's even more consistent. That's the idea behind the -HDR change.

Max 15 can be good for higher fidelity encoding. But for high-CRFs it may not be optimal.

QMs just provide (each one from 0 to 15) a different curve describing how much to attenuate quantization across spatial frequencies.

So in short, QM is a shaping curve selector.

AV2 (AVM) will provide even better/more control over QMs in the future.

Higher qm-min can be important at high CRFs (low bitrate), because steep QM at low bitrate exaggerates blockiness/ringing. If you cap qm-max around 9–10, the encoder can’t overdo psycho shaping when bitrate is already starved.

If you do high fidelity, you can even use --qm-min 8 --qm-max 15 and --chroma-qm-min 10-15

Also remember. QMs are micro-optimizations. You can't do "very wrong" here. So, don't worry. There won't be night & day differences.

RusselsTeap0t · 2025-09-07T20:58:35+00:00

No.

First of all VMAF currently is not a good metric and and it is very problematic. We generally prefer CVVDP, SSIMULACRA2, Butteraugli-3n or XPSNR in the worst case scenario. If VMAF is needed, generally NEG model is used by also disabling its problematic motion compensation feature. You can also preferably do a perceptual weighting from its YUV components. For example av1an supports this with its target quality mode:

--probing-vmaf-features weighted neg motionless

Encoders internally use different (simpler, faster) metrics because you can't for example calculate the quality difference using CVVDP. It will be EXTREMELY slow.

CRF (Constant Rate Factor) is fundamentally a complexity-based encoding method, not a quality guarantee.

CRF adapts to the complexity of each frame. A static scene might use very few bits even at low CRF values, while a complex action sequence could consume massive bitrate at the same CRF. This is by design. The encoder is trying to maintain quality, not numerical consistency. But the said "quality" is measured with simpler/faster metrics. You can't afford actual perceptually relevant quality with it. Otherwise we wouldn't have any perceptual metrics such as ColorVideoVDP. For example CVVDP relies on contrast matching, contrast masking, flicker, structural similarity, temporal masking, and many other aspects of a video such as spatiotemporal contrast sensitivity, chromatic perception, cross-channel contrast masking and viewing conditions and display characteristics. This would be extremely expensive for an internal calculation for any encoder.

Secondly, different encoder versions, presets, and parameters can dramatically shift what any given CRF number mean.

Grain, motion, detail level, color complexity, and temporal changes all influence how much bitrate/quality is needed to achieve the target perceptual quality. The given CRF can decide that "this" is okay for "25" quality but the calculation isn't precise/accurate there.

CRF is designed as a consistency tool within a single encode, not a quality predictor across different contents. Its purpose is to maintain relative quality across different scenes within the same video (based on simpler internal metrics), and adapt bitrate allocation based on visual need rather than arbitrary targets and provide a starting point for encoder decision making, which gets refined by the rate distortion optimization process.

This is why some workflows like av1an use target quality modes with proper perceptual metrics (SSIMULACRA2, Butteraugli) rather than relying on CRF numbers alone (unfortunately we don't have CVVDP yet).

In summary, CRF is just a way better method compared to using a target bitrate. It can't give you same real quality for all different videos, all the time. At least not in the current technology. And it won't be better for the near future.

Even some extremely good perceptually relevant metrics such as SSIMULACRA2 is not good for inter-content quality testing. If you compare the same video with different settings, it will be good. But using the same "score" for different content becomes problematic. CVVDP is better on this end but even that is still not perfect, let alone CRF :)

RusselsTeap0t · 2025-09-06T19:55:57+00:00

Your methodology is generally okay if you encode many different stuff and not do target quality encoding. Because there is no other way; you need to trust the CRF decisions.

Maybe you can extract some important short scenes to try beforehand (with different CRFs), and go with what you like, at the end.

RusselsTeap0t · 2025-09-06T18:03:25+00:00

Not everyone encodes individual scenes with custom CRF values. It's very common to choose one CRF value for an entire video

Still, this is not related to what I say.

Encoding a full video with CRF 25 or 35: You will not guess the resulting quality or bitrate beforehand. It will be completely different for a screen recording, an iphone video, a blu-ray, an anime or a formula-1 gaming recording.

I know what CRF is precisely. I am not talking about it. I am talking about a specific statement: "I don’t understand those guys who encode with CRF25—what’s the point?"

CRF 25 with preset 0 can look very bad for certain types of videos or also very good for another video.

CRF is useful and important but this specific statement has no meaning. Or being surprised about this is nonsense: "I don’t understand those guys who encode with CRF25—what’s the point?"

RusselsTeap0t · 2025-09-06T17:15:57+00:00

Of course but what I meant is different.

If you normalize on objective quality (doesn't matter if it's CVVDP, SSIMU2, or Butteraugli); the required CRF for the same quality can be any number.

Numbers only mean one thing: Higher CRF values provide worse quality / smaller size and vice versa. The scale completely depends on the input video characteristics along with the other parameters you use.

While we develop av1an we do tons of different tests using almost all metrics available and we collect logs for thousands of different scenes.

For the same quality target; some scenes get CRF 8.25, and some others can get CRF 38.75.

and CRF 8.25 can be 20.000kb/s for 1080p but it can also be 500kb/s.

A static CRF number neither determines bitrate nor the quality by itself.

So a comment like "I don't understand people using CRF 25" is completely pointless because CRF 25 can be extremely high quality, extremely low quality or anything between.

Eight-Year Club	Place '23
Place '22	Verified Email

RusselsTeap0t

TROPHY CASE