Variable FrameRate

[poisondeathray]

Could I ask why the bitrates were different?

I think they were the same (or close enough 81,823 vs 81,839). I think he used CRF, then 2pass VFR with same bitrate - that's what he meant by "except bitrate"

There's other factors that could come into it. Does anyone know if the -keyint setting is based on a fixed timescale when the frame rate is variable or does it apply to a number of frames? I suspect it's more likely to be the former otherwise if you only had a couple of unique frames every ten seconds (the standard gop duration) and that continued for a while, you could theoretically use -keyint 240 and end up with gops spanning minutes.
When you remove duplicates and encode at a constant frame rate though, isn't that the sort of thing that could happen? After the duplicates are removed the encoder would have no way of knowing frames 345 to 361 are eventually going to display for a combined duration of 45 seconds, unless you give it a timecodes file.

Then there's x264 being all clever about putting keyframes at the beginning of each scene, which would help reduce the likelihood of 45 second gops... so many variables.

--keyint is based on frames. You can use --scenecut 0 to disable scenechange detection, and --keyint=infinite if you wanted to . So theoretically it could be 1 keyframe for a 2 hour video.

If you have material where seeking is important, you need to set appropriate --keyint , --scenecut, or better to use use a --qpfile . e.g If you're encoding something like a VFR slideshow presentation, but some of the slides are very similar (eg. similar text, same font, same color), a new slide might be close enough not to elicit a scenechange. But you probably want to "force" an IDR seekpoint there. You might even want closer seekpoints depending on audio content, not video content (speech) .

Filters like dedup have limits on maximum duplicates, but you can use other methods for timecodes if you need to exceed those limits . For things like typical older animations, it won't be a problem (ie. you're typically not going to have runs of few hundred duplicates)

[-Habanero-]

I did not use CRF. I used 2pass for both. 500 kb/s for CFR and 829 kb/s for VFR to get the same filesize.

I'm not sure if specifying timecodes before encoding is any different than encoding the original VFR with an adjusted framerate but I can try that later.

jagabo, I disagree. 8 pixels out of 700,000 with a slightly different hue does not in any circumstance constitute a 400% difference. That's a 0.00001% difference if not less. With SSIM, that frame would've gotten a score of 0.99999 which is far more intuitive than seeing a 26 to 100 spike due to a difference I couldn't fücking see even when magnifying. PSNR is a shit metric, get over it people.
EDIT: Hey, whaddya know, SSIM gave a score of 100% for this same frame. My eyes most certainly agree.

[hello_hello]

--keyint is based on frames. You can use --scenecut 0 to disable scenechange detection, and --keyint=infinite if you wanted to . So theoretically it could be 1 keyframe for a 2 hour video.

Are you sure it's based on frames? The x264 wiki doesn't describe keyint in relation to frames, just interval.
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#keyint
Sets the maximum interval between IDR-frames (aka keyframes) in x264's output. You can specify "infinite" to never insert non-scenecut IDR-frames.

I understand you can make it infinite, but the interval could be infinite, rather than the frame count as such. min-keyint is described in frame-speak:
....limits the minimum length in frames...

It might be just the way each description is worded but if the encoder sets a base timescale, even in VFR mode, could that be the timescale used for -keyint whether frames are following it exactly or not? I'll probably try to test that very soon. Co-incidentally, my other half gave me some DVDs to encode for her and they happen to be NTSC. The live action parts are film but there's CGI all over the place and it's 29.976fps. I've tried a few different ways to convert them to a common frame rate but it's pretty ugly so now.... for the first time ever.... going down the VFR path. I've just figured out how to get TIVTC to generate the required output files to encode as VFR, but what a pain the the bum. I'm almost tempted to use Handbrake....

[poisondeathray]

PSNR is a shit metric, get over it people.

Yes it's bad. But SSIM is bad too. You can pick and choose examples where SSIM "fails" and PSNR is more accurate or vice versa. I can post examples, I'm sure I've posted some before

If you look at the big picture - both PSNR and SSIM tend to "penalize" what viewer "perceives" as details in the source, hence the "moderate" correlation only instead of "high" correlation. Easy to demonstrate this too, especially on typical sources like live action film DVD's or "theatrical" movies

Bottom line - don't rely on 1 metric, interpret everything in context.

--keyint is based on frames. You can use --scenecut 0 to disable scenechange detection, and --keyint=infinite if you wanted to . So theoretically it could be 1 keyframe for a 2 hour video.

Are you sure it's based on frames? The x264 wiki doesn't describe keyint in relation to frames, just interval.
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#keyint
Sets the maximum interval between IDR-frames (aka keyframes) in x264's output. You can specify "infinite" to never insert non-scenecut IDR-frames.

I understand you can make it infinite, but the interval could be infinite, rather than the frame count as such. min-keyint is described in frame-speak:
....limits the minimum length in frames...

Yes it's frames. It's easy to test and verify by disabling scenecut. So you're limited by --keyint only, not prematurely by scenecut. Just change the keyint in a VFR encode and look at the results. An easy way to check frametype is FFVideoSource() and FFInfo()

[hello_hello]

I just tried a quick test. It seems like you're correct. Sending a timecodes file to x264 and setting scenecut 0, the keyframes were at the specified keyint, ie every 300 frames when I used --keyint 300 and changing the time base didn't change that. I did notice....

When I specified a timebase of 1001/30000, the keyframes landed on these frame numbers according to MPC-HC:
320, 670, 980, 1307, 1662 and 2038

When I let x264 pick the timebase it went with 1/1000 and MPC-HC showed these as the keyframes:
256, 536, 784, 1046, 1330 and 1630

They were the same frames, but MPC-HC was counting them differently. It seems to count the frames as though the video is constant frame rate, so it probably pays to get the timebase right.

[-Habanero-]

poisondeathray, I tried the VQMT that you linked and I conducted PSNRHVSM tests like you suggested.
This tool really needs to support AVS because I don't have the space or patience to convert to Y4M. The South Park episode was over 20 GB and I had 3 videos to compare. It was slow as hell and the HDD speed couldn't keep up with the CPU so it ended up taking a little over half an hour to compare each.

Here are the results.

VFR: 63.671305
CFR: 73.498059

Or at least that's what the average would be if I didn't notice that perfect frames are given a score of 10,000 instead of what I assume should be 100 which is what I replaced them with and the result is as follows:

VFR: 53.37286711
CFR: 52.90118301

I guess we've proven that for South Park, VFR is marginally better.

Thanks for bringing this metric to my attention, I shall be comparing it to SSIMPlus if that guy follows thru on his promise to videoconference me next Wednesday and give me a copy.

Btw, I welcome your examples of SSIM's failures or any instance of PSNR beating it. But provide your very best example so we can avoid splitting hairs and pointless bickering. Give your very greatest and not just a random sample from your experimentation archive.

EDIT: I just looked at the numbers of this PSNRHVSM thing and it rated that 99.9999% identical frame at 65 but a preceding frame of a scene with real, actual, visible artifacts with 47.1. And the frame rated as lowest with SSIM that had more visible loss of detail than that one got a....... 47.7. Lmao, this metric is pure garbage.

I won't even bother testing this against SSIMPlus if it can't even compete against conventional SSIM.

[poisondeathray]

I shall be comparing it to SSIMPlus if that guy follows thru on his promise to videoconference me next Wednesday and give me a copy.

Cool, post the results when you test it

Btw, I welcome your examples of SSIM's failures or any instance of PSNR beating it. But provide your very best example so we can avoid splitting hairs and pointless bickering. Give your very greatest and not just a random sample from your experimentation archive.

This should be split off into another thread, because it's not strictly "VFR"

LOL it's not a competition Do you want see "generic" metric fails where SSIM and PSNR suck, or examples where PSNR seems to do better than SSIM, or vice versa?

The first is easy reproduce because it happens quite frequently on almost any random live action sample. The latter 2 cases are more of an outlier because typically PSNR and SSIM move roughly in the same direction - that's the important point. I'm just saying it can happen where they both don't go in the same direction. You just cherrypick where the deviation goes the other way, and you can do the same for the opposite case. 99% of the time when SSIM fails, PSNR fails too.

You probably mostly deal with cartoons /animation, and typically use x264 only with --no-psy --aq-mode 2 (which is equivalent --tune ssim) am I right ? Your observations are going to be skewed unless you take a look at other genres, other tests, other encoders .

Where SSIM tends to do worse in terms of "perception" , is live action, grainy or noisier sources. PSNR tends to do poorly too. But noise and detail are what cause large deviation from perception. That's a large reason why there are those newer metrics with masking and contrast.

Anyways I've posted examples before, the topic in this post below was ssim, but run it through psnr and see what you get. You can look at the sources, encodes in the other referenced thread and cherrypick one way or the other
https://forum.videohelp.com/threads/307154-Encoding-with-higher-resolution-doesn-t-pres...=1#post1916237

Here is another attached (lagarith)

The bottom line is don't rely on 1 metric, take everything into context. If 2 metrics move in the same direction, that's stronger evidence than 1 metric.

[hello_hello]

Does anyone know how the timebase is stored when encoding for a player to use? I ask because I've been playing around a little while encoding some hybrid NTSC DVDs and I've noticed that for MKV at least, the timebase effects the way MPC-HC (and ffdshow when it's decoding) counts frames.

I've been feeding x264 a timecodes file and specifying --timebase 1001/30000 in the command line. Not for any other reason that it seemed like a good idea. When I do, MPC-HC reports the frame rate as 29.970. When I don't, it reports 23.976 (x264 says it using a timebase of 1/1000). It makes a difference to the way MPC-HC counts frames. It counts them on the assumption the frame rate is constant, so when specifying --timebase 1001/30000 it skips frame numbers in the 23.976fps sections so it's counting at a constant/average 29.970fps, no matter how many frames there really are.

Edit: I've deleted much of the original post here as I've worked out what's happening. I'm an idiot.
--timebase 1001/30000 seemed like a good idea because it was getting MPC-HC to report a 29.970fps frame rate, which makes some sense, but....
1001/30000 = 0.0333667
So what I'd done is told the encoder the frames had to be at 33ms intervals. For the 23.976fps sections the frame duration is 41.7ms, so it appears for those the duration is shortened and every so often one is displayed for twice the normal duration. I'm not sure why I'm not seeing it effect smoothness of motion though. With the TV refreshing at 60Hz I guess the same thing happens on playback anyway, but using --timebase 1001/30000 probably isn't a good idea.

[-Habanero-]

I have obtained SSIMPlus but I'm still figuring out the nuances because it has the core algorithm on one hand but a dozen other ones for different devices, phones etc. based on the philosophy that perceived quality will be different on different devices.

The scores are from 0-100 and all the frames on both South Park encodes got mostly 99s. The CFR one got a few 97% frames while they were 98% on the VFR one not to mention a few more frames got a 100 instead of a 99. So the total score of the VFR encode was just 0.1% higher than the CFR.
I would prefer to see a little more precision on each individual frames so it doesn't screw with the average. I'm assuming frames that got a 99.5% would be averaged to 100. I disagree with this completely.
But there's our answer. VFR is definitely better quality but marginally and only saves 5% bitrate for 40% less frames.
The second part of that sentence I'll have to corroborate with another test because quality doesn't linearly correlate with bitrate.

I downloaded your lagarith frames and I don't see the difference between A and B quality-wise so the SSIM score was correct.

No, I don't mostly work with cartoons. South Park is literally the only cartoon that I watch but I have processed many obscure animes for some pocket change.

And it is a competition, god damn it! Some metrics are better than others.

[poisondeathray]

I downloaded your lagarith frames and I don't see the difference between A and B quality-wise so the SSIM score was correct.

But by that logic, the SSIM score should have been the "same" if they looked the "same".

SSIM
A 0.97578
B 0.97590

PSNR
A 44.91469
B 44.74953

But seriously?? Did you download the right sample ? This is a very basic quality difference. Someone that has a bit of experience with codecs should see this type of quantization right away. Banding vs. no banding. This is typical of one of the large differences in what sets x264 apart from other AVC encoders. It's able to retain things like detail, grain, instead of blurring() them all away. For semi-featureless textures like sky, it's able to retain the fine grain pattern w(ith the right settings), so you don't get blocky banding artifacts with high mb quantizers (except in fades and dark scenes ) . In motion, the artifacts are very visible, because you get blocky pattern changes between frames, and that's another complaint about "traditional" metrics which only measure spatial frames without a temporal component

If you can't see the difference, try histogram("luma") , an enhanced view that should make it plainly obvious, and go back to correlate those artifacts with the actual image

I've uploaded the screenshots. If you can't see the difference, or you think they look the "same" , you need your eyes checked. Seriously.

[-Habanero-]

Yes, the score was 0.9758 vs 0.9759. I literally couldn't tell the difference without zooming in 4x to notice that one has distorted gradients while the other has smoothened gradients. There is no visible banding. The score difference is so tiny it's irrelevant, practically the same.

I did ask you to throw your very strongest example in here and this was it? Very weak. I expected better of you.

[poisondeathray]

This is classic "banding" from high qp's. I don't know how you missed it

This is a significant difference , yet the SSIM score says they are close, and B is "closer" .

I've resized to 960x540 so you can use the free MSU test, but it's painfully obvious even at that resolution - one retains a grain pattern, and one is oversmoothed without grain and has banding

If I made a poll, I'd bet money that 9/10 random people will say they do not look the same, 9/10 would say "A" resembles the original closer than "B" . How are you doing these comparisons ? Just flip back and forth between all 3 in tabs in a browser for example









Check the other example posted. If you cannot see the difference there I don't know what to say...It's pretty obvious there too

And even more obvious is when they both fail, but I shouldn't have to post any of those it's so common

[-Habanero-]

I was up late last night, I see it better now. But this banding isn't too bad at all. Without zooming or enhancement I would barely notice. I see your point but it's not a strong one. I was hoping to see a significant fail. I've done 3/4 of 1000 tests since 2008 and the very lowest score I came across that still had good quality was ~0.89000 while I've seen ones as high as 0.98400 that were garbage. But never in the same scene did I see inverse correlations.

[jagabo]

That type of banding shows up much more when in motion and with shallower gradients. Here are some examples.

https://forum.videohelp.com/threads/345427-Handbrake-Should-i-leave-it-on?p=2156674&vie...=1#post2156674

Maybe someone can start with the CRF12 version and recompress with different settings and check the PSNR/SSIM stats.

[poisondeathray]

I call that a significant fail - it's not even in the right direction. They are not even close. People who deal with codecs should see this right away, but nobody, not even a non "video-y" person human would mistake "B" for being more similar. 9/10 was generous, if I did that poll it would be closer to 999/1000. 60-70% of the picture is way off devoid of texture. It's not like a few pixels in a small corner are off. That's pretty significant

Did you see the other example linked to in the other thread ? It might be "easier" to see for some people because the loss is everywhere. Because the textures are blurred away, the entire gamma curve is shifted, brightness changed.

I can post some more where the direction is opposite with less grain, more texture loss

It's easier to show where both PSNR and SSIM fail. It' s more difficult to find where only one fails since they usually go in the same direction

[-Habanero-]

Yes, I saw the difference after zooming but I still didn't find it that much worse than the other reference. Both have slight smearing in more important parts of the frame like the lighthouse, the door etc. The sky is not that important. I acknowledge your point but don't put as much weight on it as you do.

I looked at your ssim.zip just now and you have a stronger case here. SSIM perceives blurring as prettier than distortion I guess. For the record, SSIMPlus gave a lower score to the banded frame. Jagabo is right that it's probably more noticeable in motion and in full 1080p. You didn't have to resize it that much, do it to 1278x718 which is the max that MSU will accept for free.

[poisondeathray]

SSIM perceives blurring as prettier than distortion I guess.

In most tests, BOTH PSNR and SSIM will show higher scores on the "blurry version". They tend to penalize what a typical viewer sees as "detail" . Mainconcept AVC , which is well known for it's blurring and detail destroying was historically tuned for PSNR. Mainconcept was used for one of those encodes in that old ssim.zip example

Important to re-iterate, that those examples are outliers. 99% of the time both PSNR and SSIM correlate in the same direction (You can just as easily pick and choose where SSIM seems to do a better job on a certain frame). But the problem is they are roughly only correct maybe 40-60% of the time on live action content. Only moderate correlation with human perception. For content like simple cartoons (not detailed CGI), they tend to have higher rates of correlation

The "bad" sky example was actually x264 using --tune ssim at the same bitrate , and that should tell you something. aq-mode 2 and especially --no-psy should almost never be used. It's more forgiving to use on content like simple cartoons , but I can't think of a single case with film (or digital film equivalents) where you would use it, unless you have extraordinary high bitrate ranges that you're targeting . When someone sees x264 test results like MSU's battery of tests and thinks it does so well - it ranks high on so and so test....blah blah... most of the time they are using --tune PSNR and --tune SSIM with PSNR and SSIM metrics. But in reality, nobody uses those settings to encode for real - because they look far worse on "typical" content. They are just tuned to score higher number for the test but actually look worse. That's why we need better metrics

[-Habanero-]

That's true, but we got SSIMPlus now that correlates a lot better to subjective tests. I've attached the graphs. PSNR is utterly worthless. The same score rates the actual quality anywhere from good to garbage. SSIM is more consistent which is no surprise but still dodgy. Now look at our self-explanatory winner. It's a small step for man, people.

But anyway, I've reduced the bitrate of the VFR encode so that it matches the SSIM+ score of the CFR encode and I got a 74,515 KB file (454 kb/s) compared to the 81,839 KB one. That's 9% bitrate savings for 40% of frames deduplicated. Not too bad actually, it's worth it considering the lower encode time due to less frames.

So I guess this is the final verdict. The truth is always in the middle. Cornucopia claimed there's no benefit, I claimed there's a 50% benefit. I was half right.

aq-mode 2 and especially --no-psy should almost never be used

Isn't aq-mode 2 recommended for using alongside mb-tree, tho?

[Cornucopia]

Still not worth it if you're creating a file that is less compatible/supported!

Scott

[poisondeathray]

Isn't aq-mode 2 recommended for using alongside mb-tree, tho?

Yes - if you're using CRF encoding, and don't really care about the filesize, aq-mode 2 by itself it will increase the filesize on "typical" non cartoon sources and look good . No problems.

But at a given bitrate, the quality will almost always be noticably worse with --tune ssim (which is --aq-mode 2 --no-psy ) on "typical" non cartoon sources . --no-psy is the real killer. It's almost impossible to retain fine details like fine textures, or grain, or dither - so you are predisposed to that type of quantization banding. The areas hit worst will be shadows, backgrounds, fades, gradients (like the sky) .

[-Habanero-]

Cornucopia, that's true if you're looking to play on anything besides a PC but that same argument has been used against using x264 as late as 2010. It will be compatible eventually, not because of the bitrate benefit but due to the general benefit of having different framerates in the same video.

Isn't aq-mode 2 recommended for using alongside mb-tree, tho?

Yes - if you're using CRF encoding, and don't really care about the filesize, aq-mode 2 by itself it will increase the filesize on "typical" non cartoon sources and look good . No problems.

But at a given bitrate, the quality will almost always be noticably worse with --tune ssim (which is --aq-mode 2 --no-psy ) on "typical" non cartoon sources . --no-psy is the real killer. It's almost impossible to retain fine details like fine textures, or grain, or dither - so you are predisposed to that type of quantization banding. The areas hit worst will be shadows, backgrounds, fades, gradients (like the sky) .

I see, thanks for clearing that up. aq-2 I never questioned but psy-RDO I've rejected from the beginning as it seemed to make things worse. But as SSIM+ doesn't have the same weaknesses as its predecessor, I can test this too as I didn't encode this South Park with any psychovisuals. I'm thinking a non-cartoon would probably be a better choice tho for psy, what do you think?

[poisondeathray]

I'm thinking a non-cartoon would probably be a better choice tho for psy, what do you think?

You're supposed to always use psy, even low amounts, even on cartoons. For example --tune animation has --psy-rd 0.4:0 . One of the developers said something about never using --no-psy a long time ago. So that basically means never using --tune ssim or --tune psnr in real life. Which means all the testing that is typically done with metrics is of limited value. You can test it yourself, very bad things happen , at least on live action sources. I can post some examples, but this is so common and easy to show, nothing needs to be cherry picked , not an outlier. They look much worse at least in those areas I mentioned, very close to a mainconcept encode. But the main complaint about psy and aq on simple cartoon sources is ratty edges with lower bitrates. It's true. You need to adjust the strengths much lower especially at lower bitrates. They take away from edges and borders making simple cartoon lines looking much worse

[-Habanero-]

Ugh... now I remember why I used psy for the first and last time in July 2008. This is the famous distortion I was always sick of seeing, especially around edges.

Here is a high action scene encoded at 1 Mb/s. It's amusing how all the screenshots combined are larger than the entire encode itself.

https://postimg.org/image/rnnqzp5ll/ Source
https://postimg.org/image/luki31kzd/ No psy
https://postimg.org/image/mwu0rt9en/ Psy

Check that out. While some regions have the illusion of looking better, many are distorted and look worse than if they were blurred. Check that square on the second building to the right. Speckles like that come and go and look more annoying than no-psy.

https://postimg.org/image/pcqibhxop/ No psy
https://postimg.org/image/lozz6apg9/ Psy

Not only do things look rougher but it makes this sandstorm scene look banded.

https://postimg.org/image/ef3lbxwgv/ Source
https://postimg.org/image/bmndz10ix/ No psy
https://postimg.org/image/jmpgwd58v/ Psy

The face of the statue of tyranny, I mean liberty looks worse in psy mode. It's all distorted.

So I get that that psy is trying to distort shit in a way that might give an illusion of better quality but it's hit and miss. If it improves things in one region it screws things up elsewhere.

[poisondeathray]

I totally agree - those are good illustrative examples of what is going on, or what x264 is trying to do

But you have to put that into context, a high action scene with sandstorm is going to be difficult to encode at 1Mb/s @ 1280x720 (well 1218x718...for MSU) . It's going to try to preserve fine details, but it's going to be impossible, and it's going to fail in some areas at that bitrate and end up looking worse as you see in the screenshots; but it's going to be way worse in motion. You can't reproduce details, content complexity , motion like that at the bitrate range. The encoding strategy is wrong. What most people would have done if they only had 1Mb/s is prefilter then encode and use appropriate settings for the context. You wouldn't attempt to use those settings with psy for that bitrate range and content unfiltered. For normal usage, people typically don't use 1Mb/s for 720p for action movies / scenes. It's better to use appropriate settings and strategy, and think about what you're encoding than to blindly blur everything with no-psy

In a low bitrate scenario, you're not trying to preserve all the details. That's not the goal. You're actually trying to drop them, especially higher frequencies and fine details, to improve compression to make it more "pleasant" to watch . (By "Low bitrate" I mean relative to content complexity - 1Mb/s might have been appropriate for 720p for some types of simple cartoon content) . So higher psy is counterproductive in the low bitrate scenario. I'm suggesting that you have more control with intelligent filtering than relying solely on the encoder to make those decisions. That's how people optimize for low bitrate encodes , strong filtering and denoising. Earlier when I said you shouldn't use --tune ssim on live action content, the assumption was someone wanted to preserve details, and were using a typical bitrate range as in a "typical" scenario.

Another textbook "fail" is when you have a grainy movie, but you want to try to preserve most of the grain and details but don't give adequate bitrate (or too high crf or bad settings, whatever) , you end up with splotchy grain - that is the absolute worst, fugly IMO . AQ is absolutely horrendous there - you have "halos" of grainless patches around moving objects, like people , cars, etc.. and the frame edges , random spots and uggghh. In that case it is much preferrable IMO to either blur everything for a low bitrate encode, or perhaps filter/ reduce the grain and use a medium bitrate encode

[-Habanero-]

I don't encode at 1278x718, I resize prior to feeding it for MSU. I was gonna copy the original frames but then I'd have to open an instance of virtualdub and browse for them when I already had the copy function in MSU itself.

Anyway, here are new tests at 2 Mb/s this time.

https://postimg.org/image/ll9q7qjnj/ No psy
https://postimg.org/image/uk9jwim0v/ Psy

https://postimg.org/image/j8jcr5ayh/ No psy
https://postimg.org/image/41dc9atqh/ Psy

This is a lot better and the issue in the 2nd example in previous post no longer is one but there's still artificial distorting going on where there shouldn't be. Once again, the now milder improvements it makes in some regions are cancelled by the distortions it causes in others, especially around edges. It's really tough to tell now if it's making any improvement. Overall, it's slightly worse in my opinion. According to SSIM, it's far worse. According to SSIM+ it's a little bit worse (92.5% vs. 94).

I still don't see psy-RD as helpful at all in the long run.

[poisondeathray]

Edge distortions look worse in motion, the still pic doesn't demonstrate the issue fully, because there will be slight fluctuations between frames, a slight flickering noise

But you're still in the "low" bitrate range for that scenario, so you probably wouldn't use high amounts, or you would filter it accordingly or decide what strategy you're actually trying to do. Also, you don't have to use zero. It's not all or none

psy-rd is helpful if you want to preserve fine details with adequate bitrate . If all you do are lower bitrate encodes, you might want to use lower values, but personally I would never use --no-psy-rd, not even on ultra low bitrate encodes.

[-Habanero-]

hxxps://www.sendspace.com/filegroup/XaIeBF6YhKukxeg2QKesfw <-- both videos

I'm using only 1.00, what do you suggest? The quality at 2 Mb/s is not too bad at all though knowing me I'd use 3 Mb/s for this specific scene because of how complex it is. At that bitrate some details would be lost that you'd never notice without a direct comparison that would need perhaps 4 or 5 Mb/s to retain these small details that do add to the crispness once you find out what you're missing out on. But are you telling me that at 3 Mb/s with psy-rd 1.00 that these small details would be retained without that extra megabit?

[poisondeathray]

I guess it depends on what you're trying to do, or what your goals were

Many people don't care for the fine details - a lot of which is either (wanted) grain or (unwanted) noise - it depends on the person and your perception. Lots of people denoise almost by default, especially new BD sources to reduce the bitrate requirements.

And you're right, you can't usually can't see fine details when frames are whipping by, so many people don't care - especially if it' s just for a version for watching

You didn't include the source in the download, but I'm sure you can appreciate the significant details lost in the --no-psy version, even if some edges are worse in the psy version. Try interleave(a,b) and step through the frames in avspmod or vdub (or a,b,c if you include the source) and it will be very clear. The point is they are perceptive details, not necessarily exactly replication of actual details in the source. ie. just looking at the 2 encodes, one seems more detailed, even if those details aren't exactly correct from the source. That's where the subjective perception causes deviation from purely objective measures like PSNR

What I'm saying is --tune ssim requires more bitrate to retain the fine details, largely because of the --no-psy. But psy has side effects too, especially at lower bitrates, such as the edge issues (which are compounded with AQ) . Those are tradeoffs you have to decide on . The other important settings for very high quality replication of fine details are deadzones; you need low values and very high bitrates

There are roughly 2 categories of people, those that prefer details, and those that prefer smoothness. Group A tend to prefer x264 encodes. Group B tend to prefer x265 encodes.

[-Habanero-]

Source https://www.sendspace.com/file/ochbzl

crop(2,0,-2,0)
trim(156,1355)
lanczosresize(1280,720)

My goal is to get better quality, like always. If the benefits trump the side effects then this is a good thing but I'm not convinced of that yet. On lower bitrates it definitely makes things worse. What do you suggest for 1 and 2 Mb/s for this scene? How much psy-rd? What about for 3 Mb/s?

And x265 has been acting weird lately, doing worse than x264 and worse than x265 1.4.

[poisondeathray]

Source https://www.sendspace.com/file/ochbzl

crop(2,0,-2,0)
trim(156,1355)
lanczosresize(1280,720)

My goal is to get better quality, like always. If the benefits trump the side effects then this is a good thing but I'm not convinced of that yet. On lower bitrates it definitely makes things worse. What do you suggest for 1 and 2 Mb/s for this scene? How much psy-rd? What about for 3 Mb/s?

And x265 has been acting weird lately, doing worse than x264 and worse than x265 1.4.

But bBetter" quality is subjective - it's going to be up to personal taste. Some people like "smoother" videos more. Others might like preserving details more (or the perception of details at least). In blind subjective tests, more details usually rate higher as "closer to the source" - Even though those details are not exactly like the source, the perception is that they are, that's what psy modelling attempts to do. (x264 wasn't the first, ateme came out with it long before.) But those same details cause it to rate "lower" on standard tests like PSNR, SSIM . That's why --no-psy is featured in both --tune ssim and --tune psnr. They usually score higher, but look worse in most people's eyes in most scenarios. But you're not necessarily "most people" - Surely you've seen posters that sharpen the hell out of videos, or denoise the hell out of videos, or turn up the saturation so much that everything glows. You're the one that has to watch it so you do what you think is "best" . And your example demonstrates nicely the main trade offs that are being made in terms of --psy-rd . Psy-trellis is the other value that generally gets bumped (from zero), when people have enough bitrate and want to preserve small details. I suspect you're more on the side of favoring "smoother", fewer artifacts.

You can get a rough estimate of "typical" by just running it through a default CRF 18 encode. That will give you a rough estimate of bitrate range for what most people "think" is a decent encode for a given source. In my opinion, that produces something "good enough" for viewing, but too low of a bitrate for what I would call "high quality" . Anyways, your sample/script produced about 5.3Mb/s so that gives you a general idea of where you were at. Of course your custom settings, references, bframes etc... will help increase the compression efficiency, but it's still a good rough estimate



I'm not up to date on x265 development, I should revisit it soon. I'm also looking at AV1 closely now which looks like it should eventually be the next big thing. Key support from major players like google, netflix, amazon, microsoft. Current snapshots are slow as hell, but x265 was too early on