x265 HEVC Encoder [Archive] - Page 200

benwaggoner

27th February 2026, 20:23

Uh, I was wrong, the recon (pre-SAO) to source distortion is stored in a variable during initilization.
So I guess it's on par with HM, which I haven't really used.
This precalculated dist won't tell how the post-SAO distortion is compared to the pre-SAO distortion, but HM and x265 SAO look similar if I squint my eyes, I count that as they are doing the same.
HM passes the source YUV to the init function in the "main structure", while x265 accesses source YUV directly in the init function, that's where I stumbled.
Which means both are not good?
My recollection from, sheesh, 7-8 years ago is that x265's SAO is exactly HM's algorithmically. And that MCW hadn't been able to reproduce the SAO errors people were describing at the time, so didn't know how to address it.

But this SAO-specific distortion calculation does result in negative value A LOT, even like it's the majority.
I'm still under the impression that this is what causes it to be so bad.
That I can't speak about. As long as it's all using signed values and not clamping at zero, I don't know that negative would be a problem. Negatives are used all over in encoding, frequency transform on up.

Z2697

28th February 2026, 18:44

Because the "baseline" is always positive.
I could be wrong (again) though.

Determin offset:
int64_t bestCost = calcSaoRdoCost(0, 1, lambda);

Determin SAO type:

// RDO SAO_NA
m_entropyCoder.load(m_rdContexts.temp);
m_entropyCoder.resetBits();
m_entropyCoder.codeSaoType(0);
int64_t costPartBest = calcSaoRdoCost(0, m_entropyCoder.getNumberOfWrittenBits(), lambda[0]);

_Shorty-dammit

9th March 2026, 18:19

I've got a script that does a binary search encode job that attempts to reach a given VMAF score target. My tests with my couch distance and TV size indicates to me that VMAF 97 tends to be transparent for me in that situation. So I rip all my movies and re-encode with ffmpeg x265 -preset slow with CRF values changing according to the binary search, and a VMAF 97 target to save some space on the file server. The savings of which can be rather substantial in a lot of cases. Anyway, I just ran across a weird one that doesn't make any sense to me. Star Wars Episode II Attack Of The Clones is a 28.4 GB file off the Blu-Ray disc for just the video stream. For some reason, when I re-encode it with my script it ends up as a 30.0 GB file from the CRF 4.78 value that the binary search lands on to meet VMAF 97. I don't understand what the nature of the issue might be.

A Google AI search suggested it was because of the digital noise inherent to the Sony digital cameras used behaving like grain, only worse, but Once Upon A Time In Mexico used the same camera model and it behaves typically. I tried with x264 slow and it gave a file 8.42 GB in size from CRF 18.52 for ep2, which I'd call behaving typically. For some reason, x265 seems to be behaving unusually when it comes to ep2. I've tried x265 slow tune grain after the Google AI suspicion, and it lands on CRF 11.16 for a 23.7 GB video stream. That's a bit of an improvement in filesize, but still atypical. (Not to mention, isn't tune grain usually larger?) I also tried no-sao, and turning strong intra smoothing off, but neither seemed to have any drastic effect.

Checking in FFMetrics to also see PSNR and SSIM scores makes it seem like something's just weird with x265 and this title in general. I'm at a loss to explain it. Any guesses or any clues come to mind for anyone? I figured being digital end to end would make it more easily compressible than typical films due to the relative lack of noise, but nope. I don't know what the nature of it might be, but it seems like perhaps it has more noise than you might think. Whatever it is, there's something about that it puts it into outlier territory for x265. VMAF and SSIM are similar, but PSNR is ugly. I haven't tried the entire movie with tune psnr but testing with a 2-minute clip showed it would probably be a waste of time. The 2-minute clip is even worse than the entire movie, as no settings seem to be able to get it to stop the binary search from reaching CRF 0.0, heh.

VMAF
x264 slow: 97.0156
x265 slow: 97.0158
x265 slow grain: 97.0160

PSNR
x264 slow: 49.4331
x265 slow: 41.7823
x265 slow grain: 41.7037

SSIM
x264 slow: 0.9934
x265 slow: 0.9952
x265 slow grain: 0.9942

rwill

9th March 2026, 18:42

Try --tune psnr.

GeoffreyA

9th March 2026, 19:36

If the CRF falls too low, perhaps clamp the value to 14 or 17.

_Shorty-dammit

9th March 2026, 20:55

Try --tune psnr.

As I mentioned, I tried this already with the 2-minute clip and it still reaches CRF 0.0 like every other set of settings I've tried. I am now trying it for the sake of it with the whole movie, but that'll take the better part of the day to run.

If the CRF falls too low, perhaps clamp the value to 14 or 17.

Well, my goal isn't to simply have a smaller file, but one that also still meets my quality goal. In this case it seems I may as well just go with the x264 file, since it is less than 1/3 the original size and still meets that goal. But I'm still interested in learning what it is exactly about this particular file that kind of makes x265 freak out because it seems quite strange to me.

hellgauss

9th March 2026, 22:15

GeoffreyA

9th March 2026, 22:47

Well, my goal isn't to simply have a smaller file, but one that also still meets my quality goal. In this case it seems I may as well just go with the x264 file, since it is less than 1/3 the original size and still meets that goal. But I'm still interested in learning what it is exactly about this particular file that kind of makes x265 freak out because it seems quite strange to me.

VMAF might be misleading in this example.

_Shorty-dammit

9th March 2026, 23:37

@_Shorty-dammit

Looks like a systematic error. It is probably something very simple, perhaps a wrong/unspecified colorspace on the disc or something went wrong e.g. with crop. What is the exact workflow you follow for the encoding? Does the x265 encoding looks good at crf 16/17?

Also check mediainfo of source and rip.

Hmm...

T:\VMAF testing-single-file>ffprobe -v error -select_streams v:0 -show_entries stream=color_space,color_transfer,color_primaries,pix_fmt,width,height -of default=nw=1 starwarsclones-video-only.mkv
width=1920
height=1080
pix_fmt=yuv420p
color_space=unknown
color_transfer=unknown
color_primaries=unknown

Unknown. And my script treats it as bt.709, so you may be on the right track. While still waiting for the tune psnr run of the whole movie to complete I decided to try the 2-minute clip with it set to default to DVD colourspace/transfer/primaries instead, and it landed on 16.94 CRF, which would be a typical result in other cases. Interesting. So it would seem someone made a small error in mastering this movie. Good catch! Thanks! I think I'll let that tune psnr job finish just for the sake of it, and then I'll try it again with the DVD values on the whole movie. I suspect it'll return typical results that time.

VMAF might be misleading in this example.

I had considered this to be a VMAF issue at first, which led me to try x264 and av1 to see what happened there. They both seemed to behave in typical fashion for other movies, so that led me to believe it was something with x265 itself. But now that I've tried the small clip with DVD colourspace/transfer/primaries and it seems to have behaved in better fashion I'm wondering if someone just picked the wrong setting during the making of that Blu-Ray, as I just mentioned.

edit: Or perhaps it should be treated as bt.709 but because the original isn't tagged properly some part of ffmpeg's pipeline is treating it improperly?

hellgauss

10th March 2026, 01:37

Or perhaps it should be treated at bt.709 but because the original isn't tagged properly some part of ffmpeg's pipeline is treating it improperly?

The standard for bluray 1080/720p is bt.709. If it is not specified it should be assumed bt.709, so the tagging is correct. However some softwares or decoders (e.g. virtualdub2) do not honour this convention and if it is unspecified they convert to rgb using DVD standard.

Check the workflow for comparison too, I'm not expert on psnr and vmaf, but how they are calculated in your script? In my opinion you should compare the exact codec input with codec output, without colorspace conversion(s). If you apply pre-processing filters in the encode or post-processing filters in the comparison you should be very careful.

PS: I would also check chromaloc of source and rip.

_Shorty-dammit

10th March 2026, 02:21

The standard for bluray 1080/720p is bt.709. If it is not specified it should be assumed bt.709, so the tagging is correct. However some softwares or decoders (e.g. virtualdub2) do not honour this convention and if it is unspecified they convert to rgb using DVD standard.

Check the workflow for comparison too, I'm not expert on psnr and vmaf, but how they are calculated in your script? In my opinion you should compare the exact codec input with codec output, without colorspace conversion(s). If you apply pre-processing filters in the encode or post-processing filters in the comparison you should be very careful.

PS: I would also check chromaloc of source and rip.

Well, as I said, the tagging of the rip says unknown for colourspace/transfer/primaries. So it seems ffmpeg is making some assumptions that are detrimental in this case. When presented with a 1080p Blu-Ray rip it will usually use a command like this for encoding:

ffmpeg -i input.mkv -c:v libx265 -x265-params scenecut=40:vps-id=0:sps-id=0:pps-id=0:repeat-headers=1:colorprim=bt709:transfer=bt709:colormatrix=bt709
-preset slow -crf 25.5 -an -sn -y split/input.x265.CRF25.5.mkv

and a command like this for getting the VMAF score:

ffmpeg -fflags +genpts -i split/input.x265.CRF25.5.mkv -fflags +genpts -i input.mkv -map 0:v:0 -map 1:v:0 -an -sn -dn
-filter_complex [0:v]setpts=N/FRAME_RATE/TB,fps=<fps>,format=yuv420p[d];[1:v]setpts=N/FRAME_RATE/TB,fps=
<fps>,format=yuv420p[r];[d][r]libvmaf=model=version=vmaf_v0.6.1:n_threads=
<cpu_count>:log_fmt=xml:log_path=split/input.x265.CRF25.5.txt -f null NUL

I only checked PSNR and SSIM in this case with FFMetrics after the fact to try to figure out what was going on. I normally only look at VMAF. Now that I've forced the bt.709 tags onto the original file it seems to be processing the 2-minute clip correctly. So whatever ffmpeg is defaulting to with those bt.709 tags missing seems to be the cause. Manually adding the tags seems to have made it behave. Thanks again for the help, people!

Z2697

10th March 2026, 04:05

Have a understanding of what VMAF is and what it's not.

Boulder

10th March 2026, 05:54

I suggest using CVVDP instead of VMAF.

benwaggoner

10th March 2026, 19:09

benwaggoner

10th March 2026, 19:25

As I mentioned, I tried this already with the 2-minute clip and it still reaches CRF 0.0 like every other set of settings I've tried. I am now trying it for the sake of it with the whole movie, but that'll take the better part of the day to run.
Of course, --tune psnr is a serious debuff for psychovisual tuning. Even if the VMAF scores get better, it will actually look worse at the same bitrate than just leaving --tune at default.

Well, my goal isn't to simply have a smaller file, but one that also still meets my quality goal. In this case it seems I may as well just go with the x264 file, since it is less than 1/3 the original size and still meets that goal. But I'm still interested in learning what it is exactly about this particular file that kind of makes x265 freak out because it seems quite strange to me.
You can't really say as long as as you're using VMAF instead of your eyeballs. VMAF is calibrated to within 3 points. A score of 96 can look worse than a 94 or might look identical to source. And the mean VMAF over an entire title can be misleading. A title where 95% of frames look perfect and 5% look terrible is a worse overall experience than consistent mediocrity. I find it is more useful to look at points where the VMAF drops to its lowest and see how those look.

_Shorty-dammit

10th March 2026, 19:25

Have a understanding of what VMAF is and what it's not.

You'll have to share more than that for me to understand what you're trying to say, so if you'd care to expand that would be great, thank you.

I suggest using CVVDP instead of VMAF.

I hadn't heard of this one before. I'll have to do some reading. Thanks!

You can't really say as long as as you're using VMAF instead of your eyeballs. VMAF is calibrated to within 3 points. A score of 96 can look worse than a 94 or might look identical to source. And the mean VMAF over an entire title can be misleading. A title where 95% of frames look perfect and 5% look terrible is a worse overall experience than consistent mediocrity. I find it is more useful to look at points where the VMAF drops to its lowest and see how those look.

Well, there's definitely something to be said for looking at it in that light. So far I haven't seen anything to complain about with just the mean of 97 for an entire movie. Previously, I had been splitting things up into GOP chunks and performing the same encode job per GOP, but this presented other problems I hadn't even thought about. For example, if you encode the first couple minutes of something like Toy Story in this fashion and look at the result, the GOP for the Pixar jumping lamp gets incredibly mangled. For some reason, perhaps due to the amount of pure black screen surrounding it, it turns into a big macroblock mess. The pure black sections before and after skew the VMAF scoring something awful, and the middle section that actually contains imagery is severely bit-starved. I think with my target of 97 that the CRF mechanism itself is likely doing a good enough job for any challenging sections, at least with all the titles I've processed so far, as I haven't seen anything to complain about.

benwaggoner

10th March 2026, 19:32

You'll have to share more than that for me to understand what you're trying to say, so if you'd care to expand that would be great, thank you.
VMAF is the least-bad broadly available metric, but it still has well less than .8 correlation to actual subjective quality ratings. It has a variety of blind spots where it doesn't detect quality issues, and it is sensitive to using the correct ML model for your scenario (SD/HD/UHD, SDR/HDR, whether you allow contrast enhancement to improve scores (Which you should not)) and the pipeline you use to compare pixels. It's a shortcut for when you need to get a ballpark estimate for more content than you can actually look at, but eyeballs are a lot more accurate. Especially your eyeballs if you're encoding stuff for personal use.

A couple of big VMAF blind spots are detection of blocking in gradients, adaptive quantization optimization in general, and anything to do with chroma; it's a luma only metric. The last can be a particularly big issue with HDR which can be quite finicky with chroma issues.

This is not to dump on VMAF. It was the first popular ML based metric and was a big improvement on SSIM, and a massive on on PSNR. But it is showing its age and all metric have blind spots.

I'm partial to full reference with bitstream analysis p1204.4, if you've got a well trained ML model for the codec and kind of content you are testing with.

_Shorty-dammit

10th March 2026, 19:37

VMAF is the least-bad broadly available metric, but it still has well less than .8 correlation to actual subjective quality ratings. It has a variety of blind spots where it doesn't detect quality issues, and it is sensitive to using the correct ML model for your scenario (SD/HD/UHD, SDR/HDR, whether you allow contrast enhancement to improve scores (Which you should not)) and the pipeline you use to compare pixels. It's a shortcut for when you need to get a ballpark estimate for more content than you can actually look at, but eyeballs are a lot more accurate. Especially your eyeballs if you're encoding stuff for personal use.

A couple of big VMAF blind spots are detection of blocking in gradients, adaptive quantization optimization in general, and anything to do with chroma; it's a luma only metric. The last can be a particularly big issue with HDR which can be quite finicky with chroma issues.

This is not to dump on VMAF. It was the first popular ML based metric and was a big improvement on SSIM, and a massive on on PSNR. But it is showing its age and all metric have blind spots.

I'm partial to full reference with bitstream analysis p1204.4, if you've got a well trained ML model for the codec and kind of content you are testing with.

Yeah, this is just for my home file server and my own viewing, so perhaps it is sufficient with the higher than usual score I'm targeting. VMAF 97 and CRF encoding may be enough to deal with a lot of troublesome examples, perhaps. Like I say, so far I've found it quite satisfactory. For someone else, or for professional settings, perhaps I'd think differently and take a different approach. But it's been basically transparent for me in my viewing scenario and has saved quite a bit of server space.

_Shorty-dammit

11th March 2026, 15:43

A little update. So, I manually added BT.709 tagging to the original AVC file with this:

ffmpeg -i starwarsclones-video-only.mkv -map 0 -c copy -color_primaries bt709 -color_trc bt709 -colorspace bt709 starwarsclones-video-only-bt709.mkv

and ran it through my script with again. This definitely smartened things up, and whatever portion of the pipeline was defaulting to something unhelpful in the absence of those tags would obviously then be doing what it should've been doing. It's now a 2080 Kbps video stream that's 2.07 GB in size, down from the original's 28595 Kbps and 28.4 GB. And the PSNR no longer looks goofy.

PSNR
x264 49.4331
x265 49.5123

SSIM
x264 0.9934
x265 0.9929

VMAF
x264 97.0156
x265 96.9946

That did the trick!

tormento

28th March 2026, 18:07

I'd like to encode video chunks in parallel to be joined later.

Don't want to have multiple "HEVC header" in the final stream, is possibile to strip the initial part that x265 writes at the beginning of every hevc elementary stream?

Any help is welcome.

hellgauss

28th March 2026, 20:46

Do you mean the info header with codec settings? I've written an utility for that:
https://forum.doom9.org/showthread.php?t=186066

---------------------------------------------------

I'd like to encode video chunks in parallel to be joined later.

This is a very interesting issue which I always wanted to accomplish. However it is not trivial... Perhaps I will open it in a separate thread.

Z2697

28th March 2026, 21:29

NAL units are conveniently separated, it's pretty easy.

But I suggest keep them for safety. Except the parameters UDU SEI.

GeoffreyA

28th March 2026, 23:27

Z2697,

I saw that you submitted a fix to x265 for aq-motion. What was going on there?

Z2697

29th March 2026, 00:07

Z2697,

I saw that you submitted a fix to x265 for aq-motion. What was going on there?

If you mean the one merged in the master branch (cfee9638 (https://bitbucket.org/multicoreware/x265_git/commits/cfee9638c82b655c5887cedbdf1aa856f81b906a)),
https://bitbucket.org/multicoreware/x265_git/issues/1001/poor-2-pass-performance-in-recent-41

In short, there's a bug that occurs when "--aq-motion --aq-mode 0 --no-cutree", and a commit meant to fix that bug messed up 2-pass (or more) CUTree, so I submitted that patch to fix the bug without messing up 2-pass.

* the bad commit is not in the release 4.1

GeoffreyA

29th March 2026, 08:18

I see. Thanks for the link and explanation.

tormento

29th March 2026, 20:26

Do you mean the info header with codec settings? I've written an utility for that
Thank you, will try it.
This is a very interesting issue which I always wanted to accomplish. However it is not trivial... Perhaps I will open it in a separate thread.
Actually, I use plain Trim() — when I have time I set cuts on scene changes — and launch multiple encodes.

Hostile_18

29th March 2026, 20:36

Just ordered this bad boy for $300. Looks great for x265 encoding.

https://i.ibb.co/ksLnhzyT/encode-h265.png (https://ibb.co/jPCKLq5Y)

tormento

29th March 2026, 23:37

Just ordered this bad boy for $300. Looks great for x265 encoding.
Problem, now, is memory price.

I will patiently wait for Nova Lake, hoping that the bubble will burst.

Z2697

30th March 2026, 02:13

Multiple headers isn't a problem at all. (when they are legit)
You should not worry about it.
But if you insist, you can use filter_units in FFmpeg.
filter_units=pass_types=0-31
And I don't know, awe at the few kilo bytes you saved?
The params SEI is easy enough to remove, I don't put them into count here.

You should be more worried about the drop in quality in starting I frame(s) ovserved in both x264 and x265.

Hostile_18

30th March 2026, 06:57

Problem, now, is memory price.

I will patiently wait for Nova Lake, hoping that the bubble will burst.

Yeah I feel that. My hard drives have gone from £320 to £580.

I was lucky with RAM as I bought DDR5 for my NAS a couple of months before everything went up. Luckily there are signs the AI demand will subside somewhat recently, so we shall see.

OvejaNegra

10th April 2026, 07:23

hi, how many cores / threads can i give to x265 before it starts loosing quality or efficiency? thanks

LigH

10th April 2026, 07:52

This is a gradual issue. The more threads, the smaller the scope. That means each thread might miss e.g. the furthest motion vectors in predicted frames ... but it is not very likely to find the perfect match in long distances anyway, and a good-enough match and a little difference is still smaller than an an intra block.

I, personally, would not recommend much more than 8 threads up to FullHD. More may still be suitable for UHD. But it's just my guess. Other people with more experience may have more specific values for you, so don't count on me alone. Furthermore, there are different kinds of threading strategies, e.g. WPP or Slices, with a different behaviour, so you may be able to tweak the risk of loss.

OvejaNegra

11th April 2026, 09:41

thanks, 8 th is what i'm using right now.

Z2697

11th April 2026, 18:53

When it comes to pools / frame-threads, the difference in quality is basically only "ON and OFF". (a few percent)

There are multiple "threading options" in x265.
1) pools.
WPP and lookahead-slices depend on this. WPP is on and off, and will not affected by the number of threads in pool. lookahead-slices is a difference but virtually indiscrenible.
Correction: There are 3 stages I think, 0, 1-3, and 4-, apart from that, no difference. But you don't usually wanna use 1-3 because it will often slower than 0.
Correction again: it's because frame-thread is being set to 1 automatically. Or so I think. It's complicated. :(
2) frame-threads.
As long as the number is greater than 1, the number doesn't matter.
3) slices.
Please AVOID. It's buggy when slices and frame-threads are both greater than 1.

If by "efficiency" you mean the multi-therad utilization, it's basically (frame height / ctu).

LigH

19th April 2026, 07:59

How long did we wait for this? Months, years? :eek:

Hello everyone,
We are pleased to announce the release of x265 v4.2. This version includes a new feature, optimizations, and critical bug fixes.
Please note that, starting with this release, we will be adopting a pure Trunk-Based Development (TBD) branching model. All development and release activities will be carried out on the master branch, which will serve as the single source of truth.

Version 4.2
===========

Release date - 19th April, 2026.

New feature
-----------
1. Threaded Motion Estimation (Experimental feature)-It uses a dedicated thread pool to precompute Motion Estimation in parallel. Improves encoding speed up to 1.5x for 1080p & lower resolution on multi core machines with low frequency setting. On high frequency systems or on machines with low number of cores, the overhead of additional Motion estimation work may outweigh parallelism

Enhancements to existing features
-------------

1.Add new Levels 6.3 to 7.2 specified in ITU-T H.265 (V9) (09/2023) and above
2.Improve Slices feature with check zeroMv
3.Enable frame parallelism with MCSTF feature
4.Updated support to signal AOM FGM params
5.Improve quality with SBRC feature
6.Updated DolbyVision P5 VUI defaults

API changes
-----------
1. API Support to enable Threaded Motion Estimation(--threaded-me)

Optimizations
-------------
1. RISC V optimizations including SAD, SATD, DCT, IDCT, block copy, pixel utilities, SAO, loopfilter, transpose kernels resulting in 2x encoding speed.
2. ARM SIMD optimizations including the use of NEON and SVE instruction set extensions. The following algorithms now have optimized SIMD implementations: DST, IDCT, SSE, SSD ,intra_pred_planar, pelFilterLumaStrong, interpolation, planecopy, dequant_normal, blockcopy, pixel variance resulting in 8% faster encoding speed compared to v4.1

Bug fixes
---------
1. Fix memory leaks (no command line option, SEI buffer, analysis save/load)
2. Fix chroma qp offset for non yuv444 inputs
3. Fix max supported input resolution
4. Fix bugs with ARM SIMD optimizations
5. Fix Alpha and Multiview feature flag support in x265_config
6. Fix test harness issues, CMake errors
7. Fix inconsistent output with aq-motion
8. Fix crash with hist-scenecut on high bit-depth builds
9. Fix lookahead concurrency bug
10. Fix shared link issue (R_X86_64_PC32), yuv recon output issue, rd-refine and dynamic-refine issue, inputs for Windows named pipe, weighted prediction delta_chroma_offset, crf and vbv issue in abr-ladder, psnr and ssim reported with MCSTF feature, internally overflowed VBV variables

Known issues
------------
1. Output mismatch between analysis save & load with cutree with reuse level < 10
2. Inconsistent hash mismatch with abr-ladder feature
3. Performance regression observed with threaded-me feature on high frequency systems and for higher resolutions (4k)

Thanks,
Kirithika

rwill

19th April 2026, 08:33

How long did we wait for this? Months, years? :eek:

Wait for what? There is almost nothing of interest in this 4.2 release.

*edit
And still no news about x266.

Hostile_18

19th April 2026, 09:13

LigH

19th April 2026, 09:39

Wait for what?

For a minor version bump. This should reset some issues regarding a buggy counting of the git commit hash related to release+patches versions in the MinGW building workflow in M-AB-S I had because I kept updating for a long time and the CMake script started confusing some git branches. The result was that several people building the exact same commit got different hashes in the version strings of their binaries. So I decided to stop releasing my builds until I get in sync again.

Z2697

19th April 2026, 10:05

Has anyone noticed x265 changing the colour of grain? I'm encoding Black Swan that has orange grain elements and x265 changes a fair amount of it to black/grey. x264 doesn't have this problem. I had a look at other peoples x265 encodes for it and all have the same problem as well.

Maybe it'll be fixed by the correct chroma offset, but who knows
But really, what kind of bitrate are you talking about? Because without it there's no point.

tormento

19th April 2026, 10:10

How long did we wait for this? Months, years? :eek:
Can you link the source of that news?

Hostile_18

19th April 2026, 10:46

Maybe it'll be fixed by the correct chroma offset, but who knows
But really, what kind of bitrate are you talking about? Because without it there's no point.

It was CRF 18 with 14000kpbs cap.

I am having better results with CRF 19 with 20000 cap. So I may need to adjust!

rwill

19th April 2026, 14:47

It was CRF 18 with 14000kpbs cap.

I am having better results with CRF 19 with 20000 cap. So I may need to adjust!

Try not to turn your CRF encodes into CBR only encodes with too low caps then.

Hostile_18

19th April 2026, 14:50

Try not to turn your CRF encodes into CBR only encodes with too low caps then.

Thing is with x264 ive seen encodes that are only 5000kbps and the grain keeps it color, with x265 its taking 17000kbps+ which is a crazy difference unfortunately.

Z2697

19th April 2026, 15:17

Thing is with x264 ive seen encodes that are only 5000kbps and the grain keeps it color, with x265 its taking 17000kbps+ which is a crazy difference unfortunately.

Seen what, same title or not? Same process or not?

Hostile_18

19th April 2026, 16:00

Seen what, same title or not? Same process or not?

Black Swan (same movie). Hard to say the process but the bit rate is 5000kbps in x264 and its beating out x265 at <17000kbps strictly in terms of grain color accuracy.

Black Swan is a rather unique and hard film to encode due to its filming process and also it's one of the only films I've seen with elements of yellow/orange (and chunky) grain. Something x265 codec is doing at lower bit rates is changing the color of the grain. Only at 17000kbps+ in x265 does it match x264.

Z2697

19th April 2026, 19:33

x264N00b

19th April 2026, 20:27

Those screencaps mean nothing when it's not clear which frame typ they are. 10010-1png looks a way to good for 5000kbps. I-Frame?

Z2697

19th April 2026, 21:09

Those screencaps mean nothing when it's not clear which frame typ they are. 10010-1png looks a way to good for 5000kbps. I-Frame?

Both bidir frame.

(BTW I'm wanted to implement "unidir B frames" in x265 for no reason for some time but haven't figure it out LOL)

Hostile_18

19th April 2026, 21:23

https://slow.pics/c/FkM3JcWZ
Can't say I notice any "less colourful" grain with both 5 Mbps 2-pass ABR encoding. (both less than source, though)
Notice I'm not even using chroma offsets in x265.
8bit vs 10bit might be a bit less than ideal, but that's the "standard" right? (well it's a shame that 10bit AVC didn't have it's best time)

ffmpeg -i mkv -vf crop=1920:800 -b:v 5M -pass 2 p2.264
ffmpeg -i mkv -vf crop=1920:800,zscale,format=yuv420p10le -x265-params sao=0:aq-mode=1:ctu=32:slow-firstpass=0 -b:v 5M -pass 2 p2.265

Hate to say, but you are doing it wrong.

00:48:00-00:49:00 is my test video. Specifically 00:48:14 when the camera changes from Natalie Portman is a good example. All the yellow grain at the top half of the frame is muted/dark (against the grey wall).

I did think it may be something I was doing even though I was changing alot of variables. The only thing that worked was 17000> bit rate, and even then its not perfect. I checked against popular x265 groups and theirs exhibited the same problem. I didn't try two pass though as unfortunately Fileflows, the program I am using dosn't support two pass ABR (with advanced commands).