x265 HEVC Encoder

[Sagittaire]

Yes, but at least half job is done, so it's easier than starting from scratch.
Even so x265 is very disappointing in preserving details and grain.

20mbit to have same details as 5mbit x264? Looks like room for improvements is huuuuge :)
H265 is designed to “make money“, not deliver good quality, but this is standard these days :)
4K Blu-ray will delivery relatively waaay worse video than current HD Blu-ray. At the moment it's not looking promising at all for those who want to watch movies at very good quality at home. If 4K BD standard would be released today I don't see a single h265 encoder which could deliver reference encodes- you would be way better with x264 :) This is not about x265 itself, but h265 standard overall.

Well it's completely false. I heard the same crap when the x264 started vs XviD (from Koepi for exemple). And today x264 outperform XviD and all the other MPEG4 ASP codec even for detail and noise. Kolak, your judgment is completely wrong because you can do with H265, stream really close to H264, in compliance term. H265 codec is an H264 codec with additional functionality. Detail and noise retention are purely an HVS problem approch and many H264 implemetation fails today with that.

[kolak]

Almost no A class BD titles are done with x264- it's mainly Cinemacraft HDe, which at BD bitrates outperforms x264- better bitrate distribution between frames and over the frame.

I'm going to have a nice material for x265- some Samsung 4K TVs showcase. Last time I've done it x265 lost against x264- I hope this time it will be x265. These will be 10bit x265 files encode from prestine sources.

[benwaggoner]

Err, if I'm not wrong that "9.12" should be the minimum number of bits to display all those values, so it isn't "10 bit YCbCr holds only ~9 bit of valid RGB data" but "To holds all valid RGB data in YCbCr at least > 9.12 bits are needed" (w/o put into that should be added ~0.66 bit cos 16/235 restrictions).
Also I don't get the chroma downsample part (booth of them are 420, and bitdepth or reproducible values aren't related to chroma downscaling).

And yep a 10bit1080p and a 8bit2160p display can be comparable but only regarding how many colors can be archieved (10bit vs 8bit+dither), a 2160p display is better on many other aspects.
Finally those banded pics show only the fail of not to dither when converting to 8

It's also dangerous to assume that the 8-bits of a display match the 8-bits of whatever gamma or PQ is curve is being used in the video. Because they aren't, not since the CRT era.



-Ben Waggoner (via TapaTalk)

[benwaggoner]

Not a programmer, but you can apply the same ideas or adjust them. Saves years of development- exactly. Looks like many ideas have been already adjusted and put into x256, but even so it's disappointing in some scenarios.



You've convinced me -you are not a programmer :).

Seriously, some algorithms match up well,smoke don't. X264 doesn't have any code for 16x16 and 32x32 blocks, let alone how to make good. Sure, you could say "just don't DO >8x8 blocks." But those are critical to get good efficiency at UHD frame sizes, which is a core scenario for x265, but wasn't something that x264 ever got much specific tuning for.

It's most important at this stage for x265 to be better than x264 at SOME important things than for it to be as good at everything. We still have x264 for the stuff x264 is exceptionally good at!



-Ben Waggoner (via TapaTalk)

[huhn]

It's also dangerous to assume that the 8-bits of a display match the 8-bits of whatever gamma or PQ is curve is being used in the video. Because they aren't, not since the CRT era.



-Ben Waggoner (via TapaTalk)


we have BT 1886 for this.

[vivan]

True. But that still takes time. So many commits on the repo everyday and I believe they will (eventually) port these to x265 when they are happy with the speed optimization.;)And don't forget who they are - they are not couple guys doing it in their free time, they're they are the company that works fulltime one it and getting payed.
How many commits there're so far? How many years it took x264 to get to that number of commits? That would be a good estimate.

Seriously, some algorithms match up well,smoke don't. X264 doesn't have any code for 16x16 and 32x32 blocks, let alone how to make good. Sure, you could say "just don't DO >8x8 blocks." But those are critical to get good efficiency at UHD frame sizes, which is a core scenario for x265, but wasn't something that x264 ever got much specific tuning for.Maybe that's why http://forum.doom9.org/showthread.php?p=1710496#post1710496 this happens? ;)

[MeteorRain]

Almost no A class BD titles are done with x264- it's mainly Cinemacraft HDe, which at BD bitrates outperform x264- better bitrate distribution between frames and over the frame.

At BD bitrate - Yes.
At Internet streaming bitrate - No.

[Ma]

Anyone else is worried about where is Ma? His latest build is 1.6+3 and which is more important he misses oportunity with bench comparison of 1.6 vs 1.5 on AVX CPU. That is disturbing.

I've watched the movie which I encoded with parameters "--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709" with 10-bit x265 ver. 1.5+365. Result line "encoded 207826 frames in 504048.14s (0.41 fps), 6272.50 kb/s".

Quality was surprisingly good -- source BD movie was high quality without grain. I'm so shocked that I found an older movie with little/medium grain, I've changed parameters to "--crf 17.5" (the rest without change) and now I encode with 10-bit x265 ver. 1.6+3. I want to check if x265 is already good quality codec or if there is only good source (without grain) effect.

My build procedure is time-consuming (profiling) so the new builds I will update Tuesdays and Fridays.

[benwaggoner]

Okay all, anyone who's made it to Page 106 of this thread is definitely enough a Compression Nerd to deserve and invite to the 15th Annual Ben Waggoner Compressionist's Party at NAB on April 14th. If you're going to be at the show and have time, sign up here:

http://www.evite.com/event/02C7DOTVASHSEA5G2EPE3PFAAV7EHU

I imagine HEVC and HDR are going to be the two biggest topics around the myriad tables.

[jlpsvk]

I've watched the movie which I encoded with parameters "--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709" with 10-bit x265 ver. 1.5+365. Result line "encoded 207826 frames in 504048.14s (0.41 fps), 6272.50 kb/s".

Quality was surprisingly good -- source BD movie was high quality without grain. I'm so shocked that I found an older movie with little/medium grain, I've changed parameters to "--crf 17.5" (the rest without change) and now I encode with 10-bit x265 ver. 1.6+3. I want to check if x265 is already good quality codec or if there is only good source (without grain) effect.

My build procedure is time-consuming (profiling) so the new builds I will update Tuesdays and Fridays.


Ma, I am using CRF 20 with 10-bit x265 and I am completely satisfied. :) Settings:
--crf 20 --preset slow --tu-intra-depth 2 --rdoq-level 1 --bframes 5 --rc-lookahead 60 --min-keyint 23 --keyint 240 --merange 25 --max-merge 5 --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rd 0.5

[kolak]

Well it's completely false. I heard the same crap when the x264 started vs XviD (from Koepi for exemple). And today x264 outperform XviD and all the other MPEG4 ASP codec even for detail and noise. Kolak, your judgment is completely wrong because you can do with H265, stream really close to H264, in compliance term. H265 codec is an H264 codec with additional functionality. Detail and noise retention are purely an HVS problem approch and many H264 implemetation fails today with that.

Sounds convincing. I will know more next week when I try it in real project on high quality footage. Last time x265 was no near x264 (50mbit UHD)- it was 6 months or so ago.

[BadFrame]

Yes, but x264 code is out there and can be 'applied' to x265. Still disappointed about x265 and grain/details retention.

Yes, it's better at very low bitrates, but if we think about 4K Blu-ray it may end up that using x264 may give better quality, which would be 'crazy ':)

Yes they have access to the x264 code, but that obviously it only gets them so far.

HEVC is aimed at being very efficient at very large resolutions, so I really doubt x264 would end up being better there, however I could certainly imagine x264 remaining very competitive at lower resolutions (720, 480).

It took x264 some ten years or so to show us the best h264 had to offer, given that x265 can build on x264 to some extent it shouldn't take ten years for it to show us the best HEVC can offer, but as we can see it will take more than two years.

[kolak]

I don't think it was ten years. Last years didn't bring anything special- just small tweaks. x264 was already very good few years ago, so maybe it was 6 years or so.
It will take whatever is needed, I don't think many other companies are any further in h265 implementation, so everyone has to wait. It's just 'bit funny' to read that it's 2x more efficient, as at the moment it's clearly not.
It should say- potentially/theoretically 2x more efficient. There may be implementation which will be 2x more efficient, but in the same time this may never happen. At the moment x265 started matching x264 for random sources and with low bitrate cases it's clearly better.
As I said- it's designed for broadcast to deliver 2x more channels at even relatively lower quality than current h264 transmission.

[Ajvar]

1. At some point it is even good how it clears noise. It's like aWarsharp filter but light.
2. Yeah, in many cases it overblurrs a lot, like bad focus.

For future: let's compare 2pass vs 2pass because crf looks different (your cap) and default profiles, no tune grain. It's marazm to compare something with case where better compression codeck is worse destination quality (crf 22) but same bitrate as less compression one but with higher destination quality (crf 18). That means something already.

[Boulder]

CRF is not constant quality. Using a 2-pass to match the same bitrate that some certain CRF encode produces is unnecessary at least with x264. The quality should be the same, that's what the x264 devs have confirmed a long time ago.

[Ma]

Ma, I am using CRF 20 with 10-bit x265 and I am completely satisfied. :) Settings:
--crf 20 --preset slow --tu-intra-depth 2 --rdoq-level 1 --bframes 5 --rc-lookahead 60 --min-keyint 23 --keyint 240 --merange 25 --max-merge 5 --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rd 0.5

I decide to compare your options with my two:
SR: --preset slower --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288
VS: --preset veryslow --rdoq-level 1 --psy-rd 0.5 --deblock -1 --keyint 288

Your | SR | VS | comment
--tu-intra-depth 2 | 2 | 3 | I leave as is in presets
--rdoq-level 1 | 1 | 1 | we both want more details
--bframes 5 | 8 | 8 | I leave as is in presets
--rc-lookahead 60 | 30 | 40 | I think this not affect quality but only efficiency
--min-keyint 23 | 23 | 23
--keyint 240 | 288 | 288 | not affect quality
--merange 25 | 57 | 57 | my gives better quality (theoretically)
--max-merge 5 | 3 | 4 | TODO: I will try this "--max-merge 5"
--pme | no | no | my gives better quality (theoretically)
--deblock -3:-3 | -1:-1 | -1:-1 | TODO: I will try "--deblock -2" (-3 is too extreme for me)
--psy-rd 0.5 | 0.4 | 0.5

So there are no big differences, I will try update my VS settings with "--max-merge 5" or/and "--deblock -2".

[BadFrame]

It's just 'bit funny' to read that it's 2x more efficient, as at the moment it's clearly not.
It should say- potentially/theoretically 2x more efficient. There may be implementation which will be 2x more efficient, but in the same time this may never happen

I've always taken any '2x more efficient' statements with a large grain of salt, as it most likely pertains to video clips tailored to the strengths of the HEVC algorithms.

As such I'm not expecting 'miracles' :)

[jlpsvk]

I decide to compare your options with my two:
SR: --preset slower --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288
VS: --preset veryslow --rdoq-level 1 --psy-rd 0.5 --deblock -1 --keyint 288

Your | SR | VS | comment
--tu-intra-depth 2 | 2 | 3 | I leave as is in presets
--rdoq-level 1 | 1 | 1 | we both want more details
--bframes 5 | 8 | 8 | I leave as is in presets
--rc-lookahead 60 | 30 | 40 | I think this not affect quality but only efficiency
--min-keyint 23 | 23 | 23
--keyint 240 | 288 | 288 | not affect quality
--merange 25 | 57 | 57 | my gives better quality (theoretically)
--max-merge 5 | 3 | 4 | TODO: I will try this "--max-merge 5"
--pme | no | no | my gives better quality (theoretically)
--deblock -3:-3 | -1:-1 | -1:-1 | TODO: I will try "--deblock -2" (-3 is too extreme for me)
--psy-rd 0.5 | 0.4 | 0.5

So there are no big differences, I will try update my VS settings with "--max-merge 5" or/and "--deblock -2".

Higher --merange is giving better efficiency (aka compression), not quality, I believe. And higher than 25 slows down encoding with no big bitrate difference. 25 shoud be OK for 1080p, 57 would be for UHD. Also try -3 deblock. Preserves sharpness and maybe details also better???

[divxmaster]

Ma, I am using CRF 20 with 10-bit x265 and I am completely satisfied. :) Settings:
--crf 20 --preset slow --tu-intra-depth 2 --rdoq-level 1 --bframes 5 --rc-lookahead 60 --min-keyint 23 --keyint 240 --merange 25 --max-merge 5 --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rd 0.5

I certainly agree with jlpsvk re crf 20, on 1080p sources anyway. Testing with Iron Man 3, frame by frame stacked comparison: (code added for newbies)

video1=FFVideoSource("d:\h265\x265\ironman3.m2ts",fps=23.976).crop(0,260,0,560)
video2=FFVideoSource("d:\h265\x265\ironman3.crf20.mp4",fps=23.976).crop(0,120,0,560)
StackVertical(video1,video2)

For this source anyway, the x265 and source bluray are indistinguishable. However my tests on 576p dvd are very different, extreme blur at even crf20. Crf10 loses no detail, must get around to
testing the interim from crf10 up to crf20 to see what it needs.

Cheers,
Divxmaster

(although this is my first post, I have been encoding a long, long time - anyone remember flaskmpeg, m4c and idm4c? :) )

[LigH]

Belated Happy Easter:

x265 1.6+85-e0523096bb21 (https://www.mediafire.com/download/8l565eqahaxs99b/x265_1.6+85-e0523096bb21.7z) (stable merge)
x265 1.6+117-095ed87526e5 (https://www.mediafire.com/download/hikaauhtfu6aa6a/x265_1.6+117-095ed87526e5.7z) (with "implementation of fine grained adaptive quantization")

Furthermore, some spring-cleaning (removing v1.3 archives).

[jlpsvk]

@LigH
What "implementation of fine grained adaptive quantization" means? :)

[LigH]

I am no developer ... but as described for patch b66b0e32d2ff:

Currently adaptive quantization adjusts the QP values on 64x64 pixel CodingTree units (CTUs) across a video frame. The new param option --qg-size will enable QP to be adjusted to individual quantization groups (QGs) of size 64/32/16

Means, you may allow x265 now to vary the quantization also for smaller CTUs than 64×64 pixels only. I can't tell you if that shall enhance detail retention or avoid banding, or has a different expected purpose, though.

[Ajvar]

CRF is not constant quality. Using a 2-pass to match the same bitrate that some certain CRF encode produces is unnecessary at least with x264. The quality should be the same, that's what the x264 devs have confirmed a long time ago.

"Should be" doesn't mean "is". If we compare something then it is better to do it with more science.
Just my 2c.

[Boulder]

"Should be" means "is" with x264. I don't recall any confirmation regarding the rate control of x265 but I am assuming that it is very close to what x264 does.

[LigH]

Apropos "should be": trying to add --qgsize 16 to the parameter set, I get only a syntax help page as error result, instead of an encode.

P.S.: My fault, insert another hyphen: --qg-size

[Ajvar]

"Should be" means "is" with x264. I don't recall any confirmation regarding the rate control of x265 but I am assuming that it is very close to what x264 does.

One man told very good phraze: "You see no difference between rumor/educated guess and a fact."
What you say is educated guess, no more. x265's rc lookahead is 20-30 on different presets while x264's is twice as that. Which may lead to something. This is my educated guess.
So unless you know something for the fact, why not to decrease specter of fluctuation's reasons?

[Boulder]

Believe me, I have also made a 2-pass encode compare between the codecs. The result is still the same, x265 doesn't retain the details like x264 does. Besides, I will not be doing multipass encodes for my own purposes so there's little use for me to test them.

[Boulder]

I also wouldn't say that the ratecontrol is the key to solving the issue. It might be if the problem appeared only in some frames but it is rather constant.

[Ajvar]

Believe me, I have also made a 2-pass encode compare between the codecs. The result is still the same, x265 doesn't retain the details like x264 does. Besides, I will not be doing multipass encodes for my own purposes so there's little use for me to test them.

Believe me, I don't thing than x265 retains as much details, I just think that it would be just right thing to do. You never encode 2 samples for comparison and 3-rd with CRF14 for example to use it as source comparison. You actually use source file instead, right?
Well, someone could tell you smth like "Believe me, CRF14 has no visible difference...". Source file is source file. Comparison should be as much identical settings too.

[Boulder]

Believe me, I don't thing than x265 retains as much details, I just think that it would be just right thing to do. You never encode 2 samples for comparison and 3-rd with CRF14 for example to use it as source comparison. You actually use source file instead, right?
Well, someone could tell you smth like "Believe me, CRF14 has no visible difference...". Source file is source file. Comparison should be as much identical settings too.Why would I compare to anything else than the source? My goal is to make my encodes look as close to the original as possible while consuming as little diskspace as possible. If you are looking for something else, even better because the devs can then have a different point of view of the performance of their codec.

The x265 devs had no problems with my samples with CRF encodes for both codecs, they just asked me to try without --tune grain which I of course did. I expect that they know their codecs behaviour very well and would have asked for a 2-pass if it made any real difference.

[Ajvar]

- Why would I compare to anything else than the source?
- The x265 devs had no problems with my samples with CRF encodes for both codecs, they just asked me to try without --tune grain which I of course did. I expect that they know their codecs behaviour very well and would have asked for a 2-pass if it made any real difference.

- That was analogy. Why you compare to something else than same settings?
- Devs would ask you if that would made major or meaningful difference in comparison to the difference/detail retain flaws between x264 and x265. I see that there are easily seen difference in picture anyway.
But tell me. When devs asked you to delete key --tune-grain, when you had to encode anyways once more time, why not to encode same 2-pass then?
And call me ignorant if you want but I doubt that devs know exact percentage or percentile of difference between CRF and 2pass. I mean they surely know how it should be but I doubt that they did additional all over videos type tests - they are too busy for that I believe.
P.S. Just to be clear because you look too defensive. I don't say you must reencode something. What I say is that 2pass vs 2pass comparison is the best by all ways than crf vs 2pass even if it has tiny effect. And that this should be meaningful in the future like for cases where you need to reencode anyways..

[Boulder]

Well, I really do not like being told how to test if I have many times stated that I test as if I was going to replace x264 by x265. Simple as that :)

I have one question regarding this issue and then I shall not argue it anymore:

Why is a 2-pass vs. 2-pass better than CRF vs. CRF? Both utilize a certain kind of ratecontrol and a bitrate distribution method.

[benwaggoner]

Why is a 2-pass vs. 2-pass better than CRF vs. CRF? Both utilize a certain kind of ratecontrol and a bitrate distribution method.
Because bits==bits but x264 CRF~x265 CRF. Testing with crf is comparing both rate control AND internal quality metrics at the same time.

[sneaker_ger]

You're assuming he did comparison at identical CRF which he didn't. He chose CRF values so bitrate matches.

[Boulder]

I'd like to hear what the devs say about the differences - is x265's CRF model built upon x264's? I would expect that they are not trying to reinvent the wheel. Using 2-pass to produce the same final bitrate as a CRF encode results in causes negligible quality differences in x264 according to Dark Shikari.

EDIT: just for the heck of it, I encoded an x265 clip in CRF mode with "--preset slow --rdoq-level 1 --qg-size 16 --merange 24 --rc-lookahead 125". The CRF required in x265 is almost the same as what x264 used (18.25 for x265, 18.5 for x264). I don't have any visual comparisons yet.

EDIT2: Heavy smoothing still visible :(

x264 : https://drive.google.com/open?id=0BzeF_1syecQwLWJnMjZ0VXhwVm8&authuser=0
x265 : https://drive.google.com/open?id=0BzeF_1syecQwUFgycndfTlRPUVU&authuser=0

[STaRGaZeR]

Can we get any info on the "aq: implementation of fine-grained adaptive quantization" patch? Does it improve anything?

[Motenai Yoda]

--gp-size 16 or not I get no difference at all for grain retention, but some improvements(?) between 16.0.64 and 16+133, only on non-keyframes(?)...

070 http://www.imagebam.com/image/018f88402334515
203 http://www.imagebam.com/image/24bf89402334654
329 http://www.imagebam.com/image/47177c402334836

+64 --crf 22.0
070 http://www.imagebam.com/image/e639cd402333258
203 http://www.imagebam.com/image/0a643b402333353
329 http://www.imagebam.com/image/041f5c402333496
+133 --crf 22.0
070 http://www.imagebam.com/image/11733f402333645
203 http://www.imagebam.com/image/527536402333736
329 http://www.imagebam.com/image/6af60b402333801
+133 --crf 22.0 --gp-size 16
070 http://www.imagebam.com/image/58f7ca402333879
203 http://www.imagebam.com/image/c01af1402333962
329 http://www.imagebam.com/image/499b9d402334043

[LigH]

This patch will probably be revoked for a while, it seems that it broke something else (unexpected output change); just read a remark in the mailing list...

[Ajvar]

Well, I really do not like being told how to test if I have many times stated that I test as if I was going to replace x264 by x265. Simple as that :)

I have one question regarding this issue and then I shall not argue it anymore:

Why is a 2-pass vs. 2-pass better than CRF vs. CRF? Both utilize a certain kind of ratecontrol and a bitrate distribution method.

Because CRF-CRF is "comparing both rate control AND internal quality metrics " unless you do "chose CRF values so bitrate matches" where actually it can't match bit per bit so we come back here again: 2pass-2pass is the best by all means (no matter how small advantages) which I gave as feedback in general: not bringing as a wishlist workload for you personal but for general comparing methodologies:sly:
This patch will probably be revoked for a while, it seems that it broke something else (unexpected output change); just read a remark in the mailing list...

Sad. In pictures comparison above I liked 133 way more.

[MeteorRain]

Sad. In pictures comparison above I liked 133 way more.

Be patient. After they solve the problem it will come back.

[x265_Project]

This patch will probably be revoked for a while, it seems that it broke something else (unexpected output change); just read a remark in the mailing list...
We hope to have the improved AQ integrated this week.

[x265_Project]

Can we get any info on the "aq: implementation of fine-grained adaptive quantization" patch? Does it improve anything?
Sure. Adaptive Quantization allows x265 to change the quantization parameter (QP) on a block-by-block basis in each video frame. All blocks aren't equal - some contain very little visual detail, and some contain more detail. Without AQ, the QP value would be the same for every block in a frame. When you change the QP, you change 2 things; the lambda value - a constant that is used in the basic rdcost equation (which determines the best encoding method for the CU, weighing the bits used against the measured distortion); and the amount of quantization (reduction) of frequency components in the residual error after prediction. By raising the QP value for certain blocks, x265 can reduce the number of bits needed to encode that block with minimal impact to visual quality. By reducing the QP value for some blocks, x265 can reduce distortion (improve quality), with some additional cost in bits.

Until now, x265's adaptive quantization would change the quantization parameter on a CTU by CTU basis (64x64 pixel blocks, or whatever --ctu is set to... 32x32 pixel blocks for the fastest presets). The HEVC specifications allow us to adapt quantization with finer granularity - at the CU level (the sub-partitions within a CTU). There is a cost (in bits) to signaling a change in QP, and so our improved AQ must determine when the benefits outweigh the cost. But this improvement has the potential to further improve visual quality at any target bit rate.

[Motenai Yoda]

Also, if I'm not wrong, different CTU size has different frequency domain, so 64x64 get rid of low freq. (edges), 32x32 refine for mid freq. (detail) and 16x16 for hi freq. (noise/grain), but I'm not sure if, when there is/are 32x32 or 16x16 CTUs, freq. covered by small CTU will be skipped/ignored/zeroed in larger CTU (a sort of tri-band quantization) or maintained and just refined later by smaller CTU...

[x265_Project]

Also, if I'm not wrong, different CTU size has different frequency domain, so 64x64 get rid of low freq. (edges), 32x32 refine for mid freq. (detail) and 16x16 for hi freq. (noise/grain), but I'm not sure if, when there is/are 32x32 or 16x16 CTUs, freq. covered by small CTU will be skipped/ignored/zeroed in larger CTU (a sort of tri-band quantization) or maintained and just refined later by smaller CTU...

I think you meant to say CUs instead of CTUs. Blocks of pixels are encoded in a structure called a Coding Tree Unit (https://en.wikipedia.org/wiki/Coding_tree_unit), or CTU. As a CTU is analyzed in the motion compensated prediction phase, it is partitioned into one or more CUs. Prediction is encoded in PUs, residual error is encoded in TUs.

So, typically, x265 uses 64x64 CTUs, and these are partitioned into smaller CUs according to what produces the most efficient encode. I don't think that you can think of each CU size as having a particular spatial frequency domain.

Video quality mainly depends on the ability of the encoder to do accurate motion compensated prediction. If the video source is high quality, with a steady camera, low noise, and not too much motion + detail (confetti dropping, ripples on water, trees with millions of leaves blowing in the wind) in the scene, video encoders can work efficiently. If the source video has too much spatial detail which changes from frame to frame, motion compensated prediction doesn't produce a good predicted picture, and there will be a lot of residual error with a lot of spatial detail left to encode after prediction.

Residual error is first transformed (using discrete cosine transform, or DCT), and the strongest spatial frequencies are encoded in the TU. The less dominant frequencies are dropped in the quantization process. If the residual error is low enough, it won't be encoded at all (the TU is skipped with certain merge and skip modes).

Certainly there are differences in how larger CUs might look when the residual error is heavily quantized or skipped, versus smaller CUs. But the analysis process must choose wisely when partitioning the CTU, to only use larger CUs when it makes sense.

[Ajvar]

@x265_Project, I have a question about CRF in x265. With CRF value X --vbv-maxrate at some scenes may be overflow which brings to a very good picture at first and then very blocky/blurred picture next second at some scene. I saw that you just set vbv-buffer to a double of maxrate in x265 Upgrade but will 2pass CRF decrease maxrate overflows or CRF encodes just don't use stats information at all?
Thank you.

P.S. I deleted that video where was high bitrate scene so can't test it for now.

[x265_Project]

@x265_Project, I have a question about CRF in x265. With CRF value X --vbv-maxrate at some scenes may be overflow which brings to a very good picture at first and then very blocky/blurred picture next second at some scene. I saw that you just set vbv-buffer to a double of maxrate in x265 Upgrade but will 2pass CRF decrease maxrate overflows or CRF encodes just don't use stats information at all?
Thank you.

P.S. I deleted that video where was high bitrate scene so can't test it for now.
There's no such thing as 2 pass CRF (there is only 2 pass ABR).

CRF is a rate control mode that doesn't care about the bit rate... it only cares about the quality level. So, when you encounter complex content, the bit rate can soar. Some people use VBV with CRF (a combination known as capped VBR) to cap the bit rate at some reasonable maximum during periods of complex content. This is tricky, as you first have to have some idea of the average bit rate you will get from your CRF setting with your content, and then set the VBV maxrate at a level that is reasonably higher than the average bit rate you will get from your CRF value. Setting a reasonably large VBV bufsize just gives VBV more memory to do it's thing without difficult constraints. I think that 2x the maxrate is a good value to use.

[LigH]

A VBV controlled cap is not a certain limit for the bitrate, as it is related to a filling level and filling/freeing speed of a decoding buffer. It is possible that a bitrate limit is exceeded for a brief time, and bitrate may be reduced over a slightly longer time to compensate for that. Even a large lookahead may not avoid that certainly, I believe... but developers of the rate control will know that better.

[nevcairiel]

Bitrate is always defined over time, unless you go for extremely strict CBR where every frame has the exact same size. VBV just lets you configure the bitrate fluctuation over a defined period.

[LigH]

This period is probably related to the allowed GOP length, because decoding buffers need to store at least all surrounding referenced frames to decode each predicted frame in it. On DVD Video, it used to be at most half a second (with attempts to expand that); on Blu-ray, it may be up to one or even two seconds (with different specified constraints).

[benwaggoner]

This period is probably related to the allowed GOP length, because decoding buffers need to store at least all surrounding referenced frames to decode each predicted frame in it. On DVD Video, it used to be at most half a second (with attempts to expand that); on Blu-ray, it may be up to one or even two seconds (with different specified constraints).
These days the VBV period (VBV/maxrate) can be pretty different than GOP duration. 2 sec GOP 5 sec VBV and 5 sec GOP 1 sec VBV are both things I've seen recently.

All things being equal, it's good to have buffer duration>=GOP duration, so that a IDR frames's higher bitrate can be spread over the buffer. Otherwise you can get bit starvation at the start of each GOP.