Which processor to encode x265 4K ?

[HD MOVIE SOURCE]

Originally Posted by excellentswordfight

As its seems like you are ignoring a lot o the answers provided to you, but im gonna give it a lost shot.

First of all I answered your CPU question above, with high complexity 4k material no CPU on the market is likely to break 2fps at veryslow, it can be done with chunk encoding if you go for something like a Threadripper 5975WX or 5995WX, if go above the 24h requirement something like a 7950X will probably get you there without chunkencoding, I will guestimate that you might get close to 2fps for preset veryslow.

Secondly, the gains of presets like veryslow are very much in the diminishing returns territory, and when we are talking about such high bitrates its even beyond overkill imo. As I said, if you have issues with the output at 98Mbps at something like slow or slower, I would look at other parameters then going to preset veryslow. All uhd-bluray encodes ive done has been visually lossless at slow and slower at much lower bitrates.

Its still very unclear what the goal is here, complying to the uhd-bd specifications are only limitations, there is no real reason to use those unless you really are authoring for actual physical discs. If the reason is of more academic purpose, I still dont really understand it given the abnormal avrage bitrate that doesnt really have any real world application. Cause again "98Mbps" is not "UHD-BD", the specifications mandates a max bitrate of 100Mbps, and the average bitrate will be based on the size constrains of the physical medium. Close to zero titles will actually have a avrage bitrate that high, so its nothing that represent the uhd-bd format, and a part form that setting 98Mbps togheter with something like 98 for vbv-limitis that you need to have a uhd-bd compliant encode you are pretty much doing CBR-encoding that can have some bitrate distribution sideeffects that could actually hurt quality.

If the interest is more a question of what getting the absolute max out of x265 (i.e. using all the tools in the kitchen sink without caring to much of the practicality of the encoding speed) it makes so much more sense to try to find the limit were it becomes visually transperent instead of just setting a huge abr were most tuning and cpu-consuming tools just becomes irrelevant.

Thank you for the response, I am reading it, I just wanted to make it clear what I'm doing. I'll have to take a look at thread ripper, I've heard a few people talking about it before. Thank you.

The maxed-out spec for 4K-UHD-BD is 100 Mbps, but after authoring I don't believe anyone can make it work. It doesn't mux properly from what I've heard. However, I believe the absolute bleeding edge maxed is 98.5 Mbps, but I just round down to 98 Mbps.

I've only seen a handful of encodes on 4K-UHD-BD that I believe are absolutely perfect, Django being one of them. That was encoded at 96 Mbps average bit-rate, and the grain never broke up or was ever blurred. It was released in 2021 and the transfer still cannot be beaten today.

Originally Posted by benwaggoner

With that bitrate, you can target a lot higher performance without visual loss. With --vbv-maxrate 98000, a simple --crf 14 --preset medium should be pretty well transparent.

Making 4K look good with a 10 Mbps peak is a lot harder, which is where extra tools with extra performance implications kick in. Throwing 9.8x more bits at the problem means the encoder starts out with much, much lower QPs, which is the classic brute force way of improving quality.

Yeah, definitely. Making 10 Mbps content look good, simply requires one serious setup to make it work.

I've encoded Sol Levante from Netflix at 98 Mbs, and optimized the encoding settings to finish the encode with an average QP of 7.60. But, as you say, there's transparent, and then there's different levels of transparency.
I have found that the biggest differences that have a meaningful impact of picture quality and detail is...Obviously having enough bits to make the image look good, but no-sao, no-deblock, no-strong-intra-smoothing, subme=7 (more sharpness), aq-mode=3 with aq-strength=1.7 is the best combination for Sol Levante that I've found, and I've tested a lot of combinations.
I've also found that ipratio=1.00 & pbratio=1.00 allow for a much more consistent image from a QP point of view. They are all just about equal.
I've also found that using b-adapt=0 actually leads to better utilization of bits, because my bframes are higher quality that my I and P frames, and having b frames at 75% cheaper bits is simply better than having the system sometimes use bframes, and then at other times not. I personally think maximizing the use of bframes is extremely important for formats like 4K-UHD-BD because they can only use 3 bframes. I have never found that using b-adapt= (any setting above) leads to better results ever.

Obviously digitally made content is easier to get QP levels down lower. Film grain material will probably be around the 20s for QP, but the biggest issue getting film grain consistency to look perfect.

Just some thoughts I have.

[benwaggoner]

Are you encoding HDR Sol Levante with --aq-mode 3?

[excellentswordfight]

Originally Posted by HD MOVIE SOURCE

The maxed-out spec for 4K-UHD-BD is 100 Mbps, but after authoring I don't believe anyone can make it work. It doesn't mux properly from what I've heard. However, I believe the absolute bleeding edge maxed is 98.5 Mbps, but I just round down to 98 Mbps.

Thats an vbv issue for x265, not a general truth for hevc/uhd-bd, but yes x265 can overshot so its usually best to leave some overhead so setting 98Mbps for vbv if authoring for uhd-bd is fine. I've used other hevc-encoders without this issue.

I've only seen a handful of encodes on 4K-UHD-BD that I believe are absolutely perfect, Django being one of them. That was encoded at 96 Mbps average bit-rate, and the grain never broke up or was ever blurred. It was released in 2021 and the transfer still cannot be beaten today.

Yes, but most movies that get uhd-bd releases are not 90min with mono audio that gets put on 100GB BD-R, so what I dont really understand/the point im trying to make is; if your UHD-BD compatibility requirement is to try to tune x265 for UHD-BD authoring, why not use a more realistic bitrate that is more typical for the format? But if you just wanna burn short test sequences to bluray for playback at the max quality, then I guess its fine to max out bandwidth....

If thats not the case and the goal is quality, why shot yourself in the foot and comply to uhd-bd? Just set level 5.1 high teir and a low crf and tune for that.

You are ofc free to do whatever you want, I'm just trying to understand your use case/rational here, cause I cant really wrap my head around what your trying to achieve.

Obviously having enough bits to make the image look good, but no-sao, no-deblock, no-strong-intra-smoothing, subme=7 (more sharpness), aq-mode=3 with aq-strength=1.7 is the best combination for Sol Levante that I've found, and I've tested a lot of combinations.

Would you mind uploading a sample of your encode?

[benwaggoner]

In particular, it seems really unlikely that --subme 7 would do anything to improve detail at those bitrates. I've not been able to demonstrate any visible improvement using 7 even at <500 Kbps bitrates. Not even --preset placebo goes that high, because MCW didn't find it offered quality/speed improvements valuable even at placebo. --preset veryslow only uses 4.

And all >5 does is add an extra half and quarter pel iteration, which only would matter if the second iteration found something better than the first did. Higher subme values can shave a little of QPs, but at a bitrate where you're already probably getting mean QP around 10, QP could go up or down by 2-3 without any visible change. Getting an extra 0.1 QP isn't visible even at very low bitrates. You'd need individual frames getting at least a 1 QP difference before seeing much.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

In particular, it seems really unlikely that --subme 7 would do anything to improve detail at those bitrates. I've not been able to demonstrate any visible improvement using 7 even at <500 Kbps bitrates. Not even --preset placebo goes that high, because MCW didn't find it offered quality/speed improvements valuable even at placebo. --preset veryslow only uses 4.

And all >5 does is add an extra half and quarter pel iteration, which only would matter if the second iteration found something better than the first did. Higher subme values can shave a little of QPs, but at a bitrate where you're already probably getting mean QP around 10, QP could go up or down by 2-3 without any visible change. Getting an extra 0.1 QP isn't visible even at very low bitrates. You'd need individual frames getting at least a 1 QP difference before seeing much.

For low bit-rate content, I wouldn't use a high subme setting. More detail requires more bits and using more detail with ultra-low bit-rate isn't a good idea in my opinion.
From my understanding of bit-rate distribution, is, you want low detail so the encoders don't have to try and waste bits on the ultra-high detail that it will be picking out. So, using low subme settings, intra smoothing, sao and deblock should give better results for low bit-rate content.
Picking out blades of grass and fine facial detail wouldn't be distributing bits in the best way when you have a very restricted bit-rate. That's how I see it, sounds right to me, unless I'm missing something.

I use aqmode 3 for Sol yes, I found that it improved microbanding. I didn't see improvements in picture quality with aqmode 1 or 2 personally even though they typically should be used for this type of content. As you said, even though minor QP changes will not be seen with the eye, aqmode 3 was the lowest I could get vs mode 1 and 2.

[Asmodian]

Originally Posted by HD MOVIE SOURCE

For low bit-rate content, I wouldn't use a high subme setting. More detail requires more bits and using more detail with ultra-low bit-rate isn't a good idea in my opinion.
From my understanding of bit-rate distribution, is, you want low detail so the encoders don't have to try and waste bits on the ultra-high detail that it will be picking out. So, using low subme settings, intra smoothing, sao and deblock should give better results for low bit-rate content.

This does not make sense. High subme gives the codec better predictions so it takes less data to save that extra detail. You are correct that smoothing the content before sending it to the encoder will be easier to encode well (at least compared to the smoothed source), but once you are in the encoder you always want the best quality options you can afford speed wise.

What happens that is bad when using high subme at low bitrate?

Subme is a pure quality v.s. speed option, using low subme as a way to smooth the video is a terrible idea! All it is doing is using a worse prediction, so the codec has to quantize the differences more to maintain the same bitrate. This raises the QP of all predicted blocks, lowering quality across the board, not only dropping details.

[benwaggoner]

Originally Posted by Asmodian

This does not make sense. High subme gives the codec better predictions so it takes less data to save that extra detail. You are correct that smoothing the content before sending it to the encoder will be easier to encode well (at least compared to the smoothed source), but once you are in the encoder you always want the best quality options you can afford speed wise.

What happens that is bad when using high subme at low bitrate?

Subme is a pure quality v.s. speed option, using low subme as a way to smooth the video is a terrible idea! All it is doing is using a worse prediction, so the codec has to quantize the differences more to maintain the same bitrate. This raises the QP of all predicted blocks, lowering quality across the board, not only dropping details.

++ on this. I can't see any theoretical upside to using less --subme at lower bitrates. I use higher subme at lower resolutions and bitrates, since even slight improvements can make a difference, and the extra compute overhead is proportional to frame area.

There are some exceptions to what seem to be pure speed/quality tradeoffs. For example, grainy content at 4K can look at lot better with --rd 4 than --rd 6 for reasons I've not yet root caused to my satisfaction. It seems to be related to increased QP fluctuation between adjacent CTUs. And I speculate that it's a bigger issue in 4K + grain as the single-to-noise ratio can be a lot worse than lower resolutions, as the grain may be the only highly detailed element in a GOP. 80's/90's Super 35 titles like Ghostbusters or Men in Black have maybe 720p of actual detail with a 4K overly of temporally and spatially random noise.

Downscaling is a powerful low-pass filter, so the same source encoded at 1080p has the same amount of signal but a quarter the noise.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

++ on this. I can't see any theoretical upside to using less --subme at lower bitrates. I use higher subme at lower resolutions and bitrates, since even slight improvements can make a difference, and the extra compute overhead is proportional to frame area.

There are some exceptions to what seem to be pure speed/quality tradeoffs. For example, grainy content at 4K can look at lot better with --rd 4 than --rd 6 for reasons I've not yet root caused to my satisfaction. It seems to be related to increased QP fluctuation between adjacent CTUs. And I speculate that it's a bigger issue in 4K + grain as the single-to-noise ratio can be a lot worse than lower resolutions, as the grain may be the only highly detailed element in a GOP. 80's/90's Super 35 titles like Ghostbusters or Men in Black have maybe 720p of actual detail with a 4K overly of temporally and spatially random noise.

Downscaling is a powerful low-pass filter, so the same source encoded at 1080p has the same amount of signal but a quarter the noise.

Okay, that makes sense, if it's reducing bit-rates also then that's great. I didn't realize it could actually lower data rates also and increase detail.

[HD MOVIE SOURCE]

Originally Posted by excellentswordfight

Thats an vbv issue for x265, not a general truth for hevc/uhd-bd, but yes x265 can overshot so its usually best to leave some overhead so setting 98Mbps for vbv if authoring for uhd-bd is fine. I've used other hevc-encoders without this issue.


Yes, but most movies that get uhd-bd releases are not 90min with mono audio that gets put on 100GB BD-R, so what I dont really understand/the point im trying to make is; if your UHD-BD compatibility requirement is to try to tune x265 for UHD-BD authoring, why not use a more realistic bitrate that is more typical for the format? But if you just wanna burn short test sequences to bluray for playback at the max quality, then I guess its fine to max out bandwidth....

If thats not the case and the goal is quality, why shot yourself in the foot and comply to uhd-bd? Just set level 5.1 high teir and a low crf and tune for that.

You are ofc free to do whatever you want, I'm just trying to understand your use case/rational here, cause I cant really wrap my head around what your trying to achieve.

Would you mind uploading a sample of your encode?

This is the link to my encode of Sol Levante from Netflix it's open source, (just letting others know). https://drive.google.com/file/d/1ySV...ew?usp=sharing

[asarian]

To answer the question for me, definitely the i9 12900K. It does the encoding near twices as fast as my old i9 10700K. But, it's imperative you use P-Cores only! If not, the E-Cores will become all saturated, leaving all P-Cores near idle (as they're all waiting for the E-Cores to finish their chinks). See:

CPU loads

[excellentswordfight]

Originally Posted by HD MOVIE SOURCE

This is the link to my encode of Sol Levante from Netflix it's open source, (just letting others know). https://drive.google.com/file/d/1ySV...ew?usp=sharing

Thank you.

I had a look at that encode, and it displayed what I suspected, a lot of your unorthodox setting really doesnt do you any good.

I compared it to a uhd-bluray encode I did a year ago at about 50Mbps avg bitrate with pretty much just preset slower and some minor teaks.

https://screenshotcomparison.com/comparison/30065

(mouse on for my enocode, no tone mapping applied and cropped to 1080p).

This is ofc just a screenshot, but I couldnt find any improvments with your encode at higher a bitrate. Most of the more easily compressed sections looks fine (as expected at this bitrate), but its quite obvious that your are doing stuff that hurt compression in the though scenes. How exactly did you come to the conclusion to disable strong-intra-smoothing, sao & deblock for this source? Even keeping SAO fully enabled is great for this source (i've played with selective-sao for it, but its a bit of a tradeoff). I have all those turned on, and still my version is sharper...

[HD MOVIE SOURCE]

Originally Posted by excellentswordfight

Thank you.

I had a look at that encode, and it displayed what I suspected, a lot of your unorthodox setting really doesnt do you any good.

I compared it to a uhd-bluray encode I did a year ago at about 50Mbps avg bitrate with pretty much just preset slower and some minor teaks.

https://screenshotcomparison.com/comparison/30065

(mouse on for my enocode, no tone mapping applied and cropped to 1080p).

This is ofc just a screenshot, but I couldnt find any improvments with your encode at higher a bitrate. Most of the more easily compressed sections looks fine (as expected at this bitrate), but its quite obvious that your are doing stuff that hurt compression in the though scenes. How exactly did you come to the conclusion to disable strong-intra-smoothing, sao & deblock for this source? Even keeping SAO fully enabled is great for this source (i've played with selective-sao for it, but its a bit of a tradeoff). I have all those turned on, and still my version is sharper...

Do you have a link to your encode? soa makes the image look too soft for my taste. There's never a point where Id use it for any encode. This may just be personal taste but I really dislike soa and what it does to the image. I don't think at any point in the 4 mins think that adding deblock would be a good idea. If you can show me a point where you see breakup Id like the timestamps. Strong intra-smoothing is something I'm still playing with on digital sources, and I agree it probably does need to be on for this type of content.

I'm happy with the way it looks, but if there are any errors with it I'd like to take a look and see what settings would improve it.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

++ on this. I can't see any theoretical upside to using less --subme at lower bitrates. I use higher subme at lower resolutions and bitrates, since even slight improvements can make a difference, and the extra compute overhead is proportional to frame area.

There are some exceptions to what seem to be pure speed/quality tradeoffs. For example, grainy content at 4K can look at lot better with --rd 4 than --rd 6 for reasons I've not yet root caused to my satisfaction. It seems to be related to increased QP fluctuation between adjacent CTUs. And I speculate that it's a bigger issue in 4K + grain as the single-to-noise ratio can be a lot worse than lower resolutions, as the grain may be the only highly detailed element in a GOP. 80's/90's Super 35 titles like Ghostbusters or Men in Black have maybe 720p of actual detail with a 4K overly of temporally and spatially random noise.

Downscaling is a powerful low-pass filter, so the same source encoded at 1080p has the same amount of signal but a quarter the noise.

You mentioned --rd 4 / --rd 6 and how it affects film grain. From my understanding the rd setting is trying to lower the bit-rate and to get the perceived quality to be exactly the same, is that correct?

If this is the case, would it be true that rd=6 is trying to lower the bit-rate so much it's actually causing it to miss some film grain and cause inconsistencies in the film grain? So for example rd=1 isn't really trying to lower the bit-rates so it's actually retaining much of the image. But, I'm quite new to encoding, and I'm just trying to think why this is happening.
Another similar thought is that the algorithm used by x265 is simply not good enough to attempt to lower the bit-rates on film grain content without loss.

Would --ipratio=1.00 --pbratio=1.00 -- psy-rd=0.00 -- psy-rdoq=0.00 -- rdoq-level=0 help?
The thought process here to use equal QP, and to have zero influence from psy and rdoq, which is typically used on film grain content to increase detail, (from my understanding). I wonder if any of the psy settings are having an effect with the rd setting?
If people are worried about film grain detail, there are other settings that can increase film grain detail without going into psy and rdoq.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

You mentioned --rd 4 / --rd 6 and how it affects film grain. From my understanding the rd setting is trying to lower the bit-rate and to get the perceived quality to be exactly the same, is that correct?

If this is the case, would it be true that rd=6 is trying to lower the bit-rate so much it's actually causing it to miss some film grain and cause inconsistencies in the film grain? So for example rd=1 isn't really trying to lower the bit-rates so it's actually retaining much of the image. But, I'm quite new to encoding, and I'm just trying to think why this is happening.
Another similar thought is that the algorithm used by x265 is simply not good enough to attempt to lower the bit-rates on film grain content without loss.

Good questions. After some rumination, I have a new working theory. The big problem with noisy --rd 6 is increasingly visible differences between CUs in QP and shape. It may not be --rd 6 itself that is doing it, but features of other modes that kick in at --rd >4.

[QUOTE]--amp, --no-amp
Enable analysis of asymmetric motion partitions (75/25 splits, four directions). At RD levels 0 through 4, AMP partitions are only considered at TU sizes 32x32 and below. At RD levels 5 and 6, it will only consider AMP partitions as merge candidates (no motion search) at 64x64, and as merge or inter candidates below 64x64.

Would --ipratio=1.00 --pbratio=1.00 -- psy-rd=0.00 -- psy-rdoq=0.00 -- rdoq-level=0 help?
The thought process here to use equal QP, and to have zero influence from psy and rdoq, which is typically used on film grain content to increase detail, (from my understanding). I wonder if any of the psy settings are having an effect with the rd setting?
If people are worried about film grain detail, there are other settings that can increase film grain detail without going into psy and rdoq.

Those parameters could well help when making a mezzanine encode, where inter- and intra-frame quality variations should be eliminated as much as possible. They would be counterproductive for any kind of rate-limited encode distribution encode, as the required bitrate for a given level of psychovisual quality goes up a lot without psychovisual optimizations. Having lower QPs for frames higher in the reference hierarchy also pays off in bang-for-the-bit as the better quality in referenced frames gets cascaded down to frames that reference those frames. Making an IDR better typically makes the whole GOP look better. With flat per-frame QP, at a given bitrate IDR, I, and P QPs would go up. The lower QPs for B and B frames generally can't make back up the quality lost in the reference frames. After all, if there's an average B frame sequence length of say six frames, that means 1 of 7 frames is IDR, I, or P, and 6/7th of frames are B or b. Lowering QP on 1/7th frames is a lot more bit-efficiency than lowering them for 6/7th frames.

(Yes, lowering QP of an IDR or I takes several times more bits than lowering QP of a P frame, but there's generally only one of those frames per GOP, with all frames of a GOP benefiting from a better IDR)

(And yes, the biggest IDR benefits apply to variable GOP where the whole GOP is a single continuous shot.)

[HD MOVIE SOURCE]

[QUOTE=benwaggoner;1979471]Good questions. After some rumination, I have a new working theory. The big problem with noisy --rd 6 is increasingly visible differences between CUs in QP and shape. It may not be --rd 6 itself that is doing it, but features of other modes that kick in at --rd >4.

--amp, --no-amp
Enable analysis of asymmetric motion partitions (75/25 splits, four directions). At RD levels 0 through 4, AMP partitions are only considered at TU sizes 32x32 and below. At RD levels 5 and 6, it will only consider AMP partitions as merge candidates (no motion search) at 64x64, and as merge or inter candidates below 64x64.


Those parameters could well help when making a mezzanine encode, where inter- and intra-frame quality variations should be eliminated as much as possible. They would be counterproductive for any kind of rate-limited encode distribution encode, as the required bitrate for a given level of psychovisual quality goes up a lot without psychovisual optimizations. Having lower QPs for frames higher in the reference hierarchy also pays off in bang-for-the-bit as the better quality in referenced frames gets cascaded down to frames that reference those frames. Making an IDR better typically makes the whole GOP look better. With flat per-frame QP, at a given bitrate IDR, I, and P QPs would go up. The lower QPs for B and B frames generally can't make back up the quality lost in the reference frames. After all, if there's an average B frame sequence length of say six frames, that means 1 of 7 frames is IDR, I, or P, and 6/7th of frames are B or b. Lowering QP on 1/7th frames is a lot more bit-efficiency than lowering them for 6/7th frames.

(Yes, lowering QP of an IDR or I takes several times more bits than lowering QP of a P frame, but there's generally only one of those frames per GOP, with all frames of a GOP benefiting from a better IDR)

(And yes, the biggest IDR benefits apply to variable GOP where the whole GOP is a single continuous shot.)

Thanks for the response, some really interesting ideas. Referring to the consistent I, P and B frames...Would inconsistencies in those frames from a QP standpoint be one of the reasons why the film grain can look inconsistent? My real question is, if one frame is say QP 25, and a bframe is QP 13 is that alone why odd inconsistencies can be seen?

I think the biggest thing with film grain content is that it's absolutely consistent from a pixel point of view. What I mean is, take an old movie like Django for instance. It's a constant barrage of film grain all the time. There's things moving all of the time. It never ends. When the encoder sees grain it's almost like movement right? Or it's actually worse than movement? At least with movement, if something pans from left to right the encoder can just move the background from one side to the other side and save a good amount of bits on prediction. The issue with film grain is it's completely unpredictable from teh encoder. If we look back from afar at a screen with film grain on it, it looks generally consistent. But to the encoder, every single pixel is always changing.
Having inconsistent QP values is like dialing into a radio station but getting static noise. The I frame is super loud, the P frame is less loud and the B frame is quiet. This is just how I'm picturing this in my head as a way to understand what's happening to the frames. quiet frames would be the b frames and low QPs, and the noisier scenes are louder at higher QPs.

Just another thought, I wonder if certain predictions like amp or rect, rd, and there could be others...that actually hinder film grain or have limited effect. I'm not saying that they are specifically, but as you said, maybe some type of combination could be affecting it.

Another thought and I say this because I always use CRF. My thought is that CRF could actually help with film grain because it always aims for a certain level of quality rather than bit-rate. Now, I know you're going to say, well, you can't control bit-rate with CRF, but you actually can. You can still use bv-maxrate=**** and vbv-bufsize=**** as I do with my encodes. Even if you set the CRF=0 you can still use bv-maxrate=12000 vbv-bufsize=15000 or so to target 12 Mbps.
The biggest issue with this and even 2 pass encoding is available bit-rate. Once you start encoding at really high bit-rates like 90 Mbps film grain really balances out, especially with equal QP. Unfortunately for the streaming world and even people trying to lower the bit-rates of their own movies, it's just not viable to run bit-rates anywhere near that high.

I'd like to try and encode some film grain content. I'd like some that isn't Tears of Steel. TOS has a digital-looking grain that's been applied and is very inconsistent. Even the DCP is blurry at times. You can watch the credits at the end, and the grain looks like blurry noise.
Do you know of any other open-source content that was either shot on film or has film grain that's pretty consistent looking? I'd like to play around with some settings without going heavy into the psy settings, but taking a look at some other settings and just seeing if they have a visible effect on film grain.

Thanks, I really enjoy this conversation, because making film grain look good and consistent with breaking up is a fun challenge, especially with x265, which many say is far harder to make film grain look good vs x264. I wonder, have you run any tests with x265 and found settings that exactly emulate how an image looks vs x264? I wonder if anything could be learned from the way that encoder does things, what settings are good, and applying those ideas to x265?

Thanks.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Thanks for the response, some really interesting ideas. Referring to the consistent I, P and B frames...Would inconsistencies in those frames from a QP standpoint be one of the reasons why the film grain can look inconsistent? My real question is, if one frame is say QP 25, and a bframe is QP 13 is that alone why odd inconsistencies can be seen?

Yes, the noisier the content, the lower --ipratio and --pbratio need to be.

I think the biggest thing with film grain content is that it's absolutely consistent from a pixel point of view. What I mean is, take an old movie like Django for instance. It's a constant barrage of film grain all the time. There's things moving all of the time. It never ends. When the encoder sees grain it's almost like movement right? Or it's actually worse than movement? At least with movement, if something pans from left to right the encoder can just move the background from one side to the other side and save a good amount of bits on prediction. The issue with film grain is it's completely unpredictable from teh encoder. If we look back from afar at a screen with film grain on it, it looks generally consistent. But to the encoder, every single pixel is always changing.

Yeah, grain is nearly the same as random noise. Grain is sharp-edged and both spatially and temporally random. So, high spatial and temporal frequencies, both of which are hard to encode, without any ability to leverage interframe prediction. And there can be lots of false motion matches, where an encoder finds a potential match between two patches of random grain which gets a motion vector. That can cause the "grain swirlies" where there is apparent motion when there shouldn't be. Modern encoders do a lot of stuff to prevent that as much as feasible.

Having inconsistent QP values is like dialing into a radio station but getting static noise. The I frame is super loud, the P frame is less loud and the B frame is quiet. This is just how I'm picturing this in my head as a way to understand what's happening to the frames. quiet frames would be the b frames and low QPs, and the noisier scenes are louder at higher QPs.

Yep, that's exactly what the default --ipratio and --pbratio can yield with very noisy content. Higher --psy-rd and --psy-rdoq values can also help, as does lowering --aq-strength.

Just another thought, I wonder if certain predictions like amp or rect, rd, and there could be others...that actually hinder film grain or have limited effect. I'm not saying that they are specifically, but as you said, maybe some type of combination could be affecting it.

I doubt amp or rect will do much in grainy regions, as the energy is mostly noise versus the underlying structure that amp and rect can help with. As the grain complexity is consistent across all of the area of all frames, anything that causes adjoining TUs to have visibly different QP can cause some very annoying visual distortions. I suspect --rd 6 is doing adaptive CU/TU sizing and adaptive quantization more aggressively which is in general superior but not when the grain single/noise ratio is too high.

Another thought and I say this because I always use CRF. My thought is that CRF could actually help with film grain because it always aims for a certain level of quality rather than bit-rate. Now, I know you're going to say, well, you can't control bit-rate with CRF, but you actually can. You can still use bv-maxrate=**** and vbv-bufsize=**** as I do with my encodes. Even if you set the CRF=0 you can still use bv-maxrate=12000 vbv-bufsize=15000 or so to target 12 Mbps.

If you look at the --csv-log-level 2 of good looking grainy content, you'll see that there's a lot less bitrate variation than with cleaner content. CRF is fine to use, but doesn't offer as much benefit as with other content, and one can wind up spending a lot of time at the VBV cap where CRF doesn't really do anything.

The biggest issue with this and even 2 pass encoding is available bit-rate. Once you start encoding at really high bit-rates like 90 Mbps film grain really balances out, especially with equal QP. Unfortunately for the streaming world and even people trying to lower the bit-rates of their own movies, it's just not viable to run bit-rates anywhere near that high.

Yep. If you take a clean source and then add heavy grain to it, the required bitrate for transparent quality can more than double. This is why the Film Grain Synthesis approach introduced by AV1 is so promising. Instead of trying to replicate the random noise, it gets parameterized and removed, clean frames encoded, and then new random grain of a similar texture gets added after decode. This requires solving several hard problems simultaneous, and I'e not seen any implementations reliable enough to leave on by default. And some real-world AV1 players have defects in their implementation which can yield inconsistent final experiences. But it is fundamentally a sound approach I anticipate will be an assumed part of encoders and decoders 10 years from now.

The FGS decoder module is out of loop of the AV1 decoder, and it appears lots of hardware will make the AV1 FGS it available for other codecs, like VVC. And I think there are some that can do it for HEVC using SEI metadata.

I'd like to try and encode some film grain content. I'd like some that isn't Tears of Steel. TOS has a digital-looking grain that's been applied and is very inconsistent. Even the DCP is blurry at times. You can watch the credits at the end, and the grain looks like blurry noise.
Do you know of any other open-source content that was either shot on film or has film grain that's pretty consistent looking? I'd like to play around with some settings without going heavy into the psy settings, but taking a look at some other settings and just seeing if they have a visible effect on film grain.

Yeah, ToS has good digital grain for its age, but it's not the same as real film grain. Nor is its grain particularly heavy.

I can't think of any broadly available very grainy sources, alas. The lack of good grainy sources in standard test libraries is probably one reason issues in grain handling aren't more directly addressed in reference encoders.

Thanks, I really enjoy this conversation, because making film grain look good and consistent with breaking up is a fun challenge, especially with x265, which many say is far harder to make film grain look good vs x264. I wonder, have you run any tests with x265 and found settings that exactly emulate how an image looks vs x264? I wonder if anything could be learned from the way that encoder does things, what settings are good, and applying those ideas to x265?

Yeah, it's some good nerdy fun. Less fun when trying to deliver the highest quality at the lowest bitrate to millions of customers, but it's certainly a bracing challenge, and a fabulous feeling when executed well.

[excellentswordfight]

Originally Posted by HD MOVIE SOURCE

Thanks, I really enjoy this conversation, because making film grain look good and consistent with breaking up is a fun challenge, especially with x265, which many say is far harder to make film grain look good vs x264. I wonder, have you run any tests with x265 and found settings that exactly emulate how an image looks vs x264? I wonder if anything could be learned from the way that encoder does things, what settings are good, and applying those ideas to x265?

These are my standard settings for 1080p24 SDR standard film encodes, and imo grain characteristic are absolutely similar to normal x264 settings (--preset slower --tune film)

--preset slow --profile main10 --level-idc 41 --keyint 240 --min-keyint 24 --rc-lookahead 48 --aq-mode 1 --no-sao --deblock -1:-1 --psy-rd 2.5 --psy-rdoq 4 --colorprim bt709 --transfer bt709 --colormatrix bt709

https://screenshotcomparison.com/comparison/30156 (mouse on for x265)

Encoded with crf17 with x264, and crf for x265 is set to match average bitrate.

so --aq-mode 1 --no-sao --deblock -1:-1 and a slight psy tweak and you have something similar to x264 with tune film.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

Yes, the noisier the content, the lower --ipratio and --pbratio need to be.


Yeah, grain is nearly the same as random noise. Grain is sharp-edged and both spatially and temporally random. So, high spatial and temporal frequencies, both of which are hard to encode, without any ability to leverage interframe prediction. And there can be lots of false motion matches, where an encoder finds a potential match between two patches of random grain which gets a motion vector. That can cause the "grain swirlies" where there is apparent motion when there shouldn't be. Modern encoders do a lot of stuff to prevent that as much as feasible.


Yep, that's exactly what the default --ipratio and --pbratio can yield with very noisy content. Higher --psy-rd and --psy-rdoq values can also help, as does lowering --aq-strength.


I doubt amp or rect will do much in grainy regions, as the energy is mostly noise versus the underlying structure that amp and rect can help with. As the grain complexity is consistent across all of the area of all frames, anything that causes adjoining TUs to have visibly different QP can cause some very annoying visual distortions. I suspect --rd 6 is doing adaptive CU/TU sizing and adaptive quantization more aggressively which is in general superior but not when the grain single/noise ratio is too high.


If you look at the --csv-log-level 2 of good looking grainy content, you'll see that there's a lot less bitrate variation than with cleaner content. CRF is fine to use, but doesn't offer as much benefit as with other content, and one can wind up spending a lot of time at the VBV cap where CRF doesn't really do anything.


Yep. If you take a clean source and then add heavy grain to it, the required bitrate for transparent quality can more than double. This is why the Film Grain Synthesis approach introduced by AV1 is so promising. Instead of trying to replicate the random noise, it gets parameterized and removed, clean frames encoded, and then new random grain of a similar texture gets added after decode. This requires solving several hard problems simultaneous, and I'e not seen any implementations reliable enough to leave on by default. And some real-world AV1 players have defects in their implementation which can yield inconsistent final experiences. But it is fundamentally a sound approach I anticipate will be an assumed part of encoders and decoders 10 years from now.

The FGS decoder module is out of loop of the AV1 decoder, and it appears lots of hardware will make the AV1 FGS it available for other codecs, like VVC. And I think there are some that can do it for HEVC using SEI metadata.


Yeah, ToS has good digital grain for its age, but it's not the same as real film grain. Nor is its grain particularly heavy.

I can't think of any broadly available very grainy sources, alas. The lack of good grainy sources in standard test libraries is probably one reason issues in grain handling aren't more directly addressed in reference encoders.


Yeah, it's some good nerdy fun. Less fun when trying to deliver the highest quality at the lowest bitrate to millions of customers, but it's certainly a bracing challenge, and a fabulous feeling when executed well.

I encoded just 30 seconds of Django 4K, one at rd=6 and one at rd=4 and yeah...You're right, rd=4 is better than rd=6. That's so weird. It's not by much, but the fact that it's better is certainly odd. I wonder if this is just a bug in the x265 software? Because typically, asking for higher quality should yield higher quality, but the quality goes down?

I running some other tests like rd=3 just to see if rd=4 is the limit of quality when it comes to film grain. Then I might see if there's any other odd interactions with some other settings later.

I wonder if this is something that the software guys could actually update in a future build?

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

I encoded just 30 seconds of Django 4K, one at rd=6 and one at rd=4 and yeah...You're right, rd=4 is better than rd=6. That's so weird. It's not by much, but the fact that it's better is certainly odd. I wonder if this is just a bug in the x265 software? Because typically, asking for higher quality should yield higher quality, but the quality goes down?

Yeah, it's non-intuitive for sure! I presume that some of the extra stuff in other tools that get activated by rd=6 are causing some suboptimal behaviors. I'm also sure that some of the things in rd=6 are beneficial too, so it should be better than 4 if the pathological behaviors could be disabled somehow.

I running some other tests like rd=3 just to see if rd=4 is the limit of quality when it comes to film grain. Then I might see if there's any other odd interactions with some other settings later.

Please do report back!

I wonder if this is something that the software guys could actually update in a future build?

It almost certainly can be fixed. If the tools that are causing problems in rd=6. can be identified, hopefully they can be tweaked to not respond badly to grain. Or at least just deactivated with heavy grain. --tune grain is ancient and terrible, and a refactor that worked well with the modern x265 infrastructure would be welcome, even if it had to be activated manually.

Since the problems are by far the worst at 4K, I suspect there's some threshold of noise detail versus content detail where things go wonky if crossed.

[excellentswordfight]

Finally got a Epyc milan to play with, and its a nice upgrade over Rome.

Amd Epyc "Milan" 7543P - 6,4fps
Amd EPyc "Rome" 7402P - 4,86fps
Intel Xeon "Cascade Lake Refresh" 2x6226R - 3,97fps

All 1u Dell servers in performance mode, doing a 2160p HDR10 transcode of STEM2 with preset slow, CPU utilization is about 50-75%, all system has 64 threads and 8x16GB for Epyc, and 12x8GB RAM for Intel.