Overall Bit Rate, Bit Rate with Respect to Quality and Filesize

[jagabo]

One thing I have been meaning to try for quite a while is to test how devices make colorimetry decisions (HD v SD) cause that's an area which annoys me more than TVs which aren't calibrated exactly. I've had a few PC vs standalone player debates in the past (involving which makes a better media player) but nobody's ever been able to tell me which colorimetry their standalone player might use at any particular time, or if it's likely to pay any attention to any colorimetry info in the video itself. I recall reading a few posts in another forum where someone was complaining about the WD media players in respect to colorimetry.

I have a WDTV Live. When it originally came out it had a problem with colorimetry but I forget exactly what it was. Eventually an updated firmware did the most sensible thing: If the colorimetry is flagged it obeys the flag. If it's not flagged it defaults to rec.601 for SD, rec.709 for HD. I don't recall exactly what resolution is the point at which it changes.

[hello_hello]

I think we agreed that it was most likely down to a CPU family related bug (or something similar) as at least one other person has spotted broadly similar behaviour as reported by Makavelli84(?) on Doom9, although I see that he's basically being told that he's imagining it too.

I just got around to reading the thread in question. I assume you didn't read it all given you used it as an example of another poster finding CRF inferior to 2 pass, but Makaveli84 said himself:
"Anyways, CRF is more than suitable most of the time, but in some cases, when editing and applying effects on videos, I'd like to achieve the best possible quality, even for single frames.
But even for that, I am unconvinced that 2-pass always yields better quality."

http://forum.doom9.org/showpost.php?p=1590055&postcount=29

Personally it sounds to me more like Makaveli84 was doing the frame by frame comparison thing and seeing the small compression differences we all do.

[Slipster]

Personally it sounds to me more like Makaveli84 was doing the frame by frame comparison thing and seeing the small compression differences we all do.

Yes. He does go on to say in the same post that he can see a difference at normal playback speed too, but only after 'tuning' himself to spot it in frame-by-frame viewing, so his case is probably different from mine where the differences are blatantly obvious (to me anyway) at normal playback speed, with CRF needing to produce a significantly larger file than 2-pass to reach the same level of transparency when going apples-for-apples with all other settings being equal when using MeGUI.

As there's nothing I can do here to fix the problem (changing GUIs or x264 versions makes no difference), I've given up for now anyway. I'll run the exact same test on the i5 laptop I have occasional access to next time it's available to see if it's a CPU-specific problem, although I'll have to bring the files home with me to check them on this decent monitor as the diabolical panel accompanied by the awful Intel HD graphics implementation on the lappy manages to hide pretty much everything.

[jagabo]

I have noticed that some h.264 decoders are better than others. On my Core i5 system I get very ugly artifacts (deblocking isn't working correctly, obvious keyframe pumping) with DXVA decoding by MPCHC's internal h.264 DXVA decoder, even with sources that are easily within DXVA specs. It happens with both CRF and 2-pass encodings. If anything, the artifacts are worse with 2-pass. When using CoreAVC's DXVA decoding, or with software decoding, the video is much cleaner.

[Hoser Rob]

I have noticed that some h.264 decoders are better than others. On my Core i5 system I get very ugly artifacts (deblocking isn't working correctly, obvious keyframe pumping) with DXVA decoding by MPCHC's internal h.264 DXVA decoder, even with sources that are easily within DXVA specs....

Some are definitely better than others. The best one I've used by far is mplayer. I use smplayer as a front end for it. I've tried every one I can think of and nothing else works as well.

[Hoser Rob]

And I'm finding, though I may be wrong (h.264 settings and all, I'm no expert there), that if you really want small file size xvid may actually be better. It's kind of "softer edged", if that's the right expression. Maybe not technically better but more forgiving of problems / artifacts you get with low bit rate.

[jagabo]

No, x264 is better than Xvid at small sizes (low bitrates). Especially since most Xvid/Divx decoders don't deblock.

[Hoser Rob]

Like I said, I could be wrong. I really don't know all the options.

[hello_hello]

Some are definitely better than others. The best one I've used by far is mplayer. I use smplayer as a front end for it. I've tried every one I can think of and nothing else works as well.

What differences are you seeing in video playback? The popular free media players (and ffdshow) all seem to use libavcodec as their decoding engine, or they're based on ffmpeg.

I'm not saying some players don't work better than others. I'm just wondering what makes mplayer better. I couldn't find any definite info on it. Does smplayer support DXVA?

[hello_hello]

.....so his case is probably different from mine where the differences are blatantly obvious (to me anyway) at normal playback speed, with CRF needing to produce a significantly larger file than 2-pass to reach the same level of transparency when going apples-for-apples with all other settings being equal when using MeGUI.

As there's nothing I can do here to fix the problem (changing GUIs or x264 versions makes no difference), I've given up for now anyway.

I asked a while back but you never said which CPU you're using.
If you've got some samples you can upload of CRF vs 2 pass using MeGUI, including the source, I'd be keen to have a look. Plus if you can upload a section of the source video and the samples were encoded using MeGUI's default settings, it shouldn't be too hard for me to run the same encodes to see if I get the same results at the same CRF value and 2 pass bitrate. That's something we've still not done..... run the same encodes using the same source to see if we get the same results. If I'm still not seeing quality differences I can then upload my encodes of the samples to see if you still do.

I still have your CRF25 vs 2 pass samples on my hard drive (the Firefly encodes) and with a fresh look 2 pass is definitely a little better, but we're still talking about an average bitrate difference of 120Kbps for a 15 second video, which is nothing to be ignored. I'm not sure I could see any differences if I disabled DXVA.
While I don't have the source to compare them to it does appear to me your 1333Kbps 2 pass MediaCoder preset did a pretty average job of it anyway. I'd be intereset to see what the same section of video would look like encoded using CRF 20 or CRF 18 and what sort of bitrates you'd end up with, because the 2 pass encode isn't anything I'd be overly excited about. Hopefully it's just a result of using a poor quality source rather than the 2 pass encode being poor quality.

That's something else looking at your samples made me ponder over when it comes to using a one size fits all average bitrate. If you were to encode a video using your preset, the bits would be shared around where they're needed etc, but what if you split the video in two and encoded each half the same way? And what if the first half was full of static scenes while the second full of action? Wouldn't using the same average bitrate each time cause the video as a whole to be compressed differently to how it'd be compressed if you encoded it one half at a time?

Anyway, if you've got a sample we can both use as a source for encoding......

Is that Firefly DVD interlaced or progressive? Because I'd be thinking seriously about looking at the de-interlacing being used as it seems to be reasonably awful. Lots of jagged lines where there shouldn't be any. The Captain's shirt color is generally the most obvious example.

[hello_hello]

I have noticed that some h.264 decoders are better than others. On my Core i5 system I get very ugly artifacts (deblocking isn't working correctly, obvious keyframe pumping) with DXVA decoding by MPCHC's internal h.264 DXVA decoder, even with sources that are easily within DXVA specs. It happens with both CRF and 2-pass encodings. If anything, the artifacts are worse with 2-pass. When using CoreAVC's DXVA decoding, or with software decoding, the video is much cleaner.

It just occurred to me (after reading your post) I was involved in a similar discussion at doom9 a fair while back. The person with the encoding problem was complaining about artifacts in one particular scene and uploaded a sample of the source. If memory serves me correctly I ran a couple of encodes and uploaded a few screenshots. As a result the original poster changed media players and the problem went away.

I'll have to try to find the thread later as I can't remember which player they were using originally (it was quite a while ago), although I think they switched to MPC-HC, but issues caused by playback probably shouldn't be dismissed. Mind you if CRF and 2 pass are basically the same quality wise, you'd assume if a player makes a mess of one it'd make a similar mess of the other, but I guess anything's possible. If DXVA is being used, disabling it and comparing how video looks on playback might be one place to start.

[jagabo]

I decided to upload a few samples. This is from the tests I mentioned earlier where I took a full Blu-ray rip, trimmed out a 5000 frame section, Cropped black borders, reduced the frame size to 1280x544, and saved as lossless Lagarith AVI (YV12). That gave me a high quality source to start with.

First a decent quality encoding about like I would normally make:

x264.exe --preset=slow --keyint=250 --ref=4 --bframes=3 --crf=18 --aq-mode=2 --aq-strength=1.8 --sar=1:1 --output x264-crf18.mkv lag.avs

Then a CRF 25 encoding (with Slipster's psy-rd settings):

x264.exe --preset=slow --crf=25 --psy-rd 1.0:0.2 --output x264-crf25.mkv lag.avs

A 2-pass encoding at the same bitrate (with Slipster's psy-rd settings):

x264.exe --preset=slow --psy-rd=1.0:0.2 --pass=1 --output x264-2pass.mkv lag.avs
x264.exe --preset=slow --psy-rd=1.0:0.2 --pass=2 --bitrate=880 --output x264-2pass.mkv lag.avs

And just for kicks, a two pass Xvid encoding at the same bitrate (settings compatible with most modern Divx/DVD players).

[hello_hello]

Well I haven't had a chance for a serious look yet, but after a few quick runs.....

Xvid: Obviously a disaster in places.

CRF18: It looked very good. I could see a few things in the earlier, harder to compress scenes where I wondered if I was seeing the results of compression but only minor things, and not having seen the source it's hard to know what's been introduced due to encoding.

CRF25 & 2 pass: Well I'm going to go out on a limb here and say watching the video I think CRF looks better. I'll have to come back to those ones but a few quick plays gave me the impression the CRF version was more "fluid". I can't put my finger on it yet as stopping on a few identical frames I wasn't seeing huge differences, but when the videos were playing I think the CRF version had less (what I call) compression "wobble" and for some reason the blocking seemed less obvious than it was when watching the 2 pass encode. As I said that's more a first impression than anything else. I'll definitely revisit those two. I might find some audio to mux into them so reclock can do it's thing so I know it's not the frame rate effecting the "fluidity".

Slipster's psy-rd settings aren't far from the defaults. Is the difference noticeable? On the other hand, you certainly give aq-strength a fairly decent nudge.

[jagabo]

When I examine them frame-by-frame I can see differences but sometimes one looks better, sometimes the other. The same is true with realtime playback. In the end, the results are close enough that I wouldn't worry about it and just use CRF because it's faster and I know what the quality will be before I encode.

I don't know exactly how all MediaCoder's settings translate into x264 switches. For example, Slipsters' link showed:

<node key="videoenc.x264.aq_strength">Strong</node>

I don't know what "Strong" translates to in x264's --aq-strength option. So I left most of the settings at the defaults of the slow preset. Psy-trellis was an obvious one, and Slipster indicated it made a difference, so I did use that option. I also tried the veryslow preset but didn't see a big difference there either.

You can use MediaInfo to see all the individual x264 options used during the encoding. Unfortunately, Slipster never posted any video samples.

That particular video has a lot of noise in the dark shots. The high aq-strength helps retain that noise and prevent obvious posterization artifacts in those shots. It costs more bitrate (in CRF encoding) though -- 40 percent more in this clip.

When I compare videos frame-by-frame I usually use a script like this:

v0=AviSource("lag.avs").Subtitle("source")
v1=ffVideoSource("x264-crf18.mkv").Subtitle("crf")
v2=ffVideoSource("x264-2pass.mkv").Subtitle("2pass")
Interleave(v0,v1,v2,v0)

The I use VirtualDub to open the script. That way I can easily flip back and forth between frames of the original and the fist video, the first and the second video, or the second video and the source.

[hello_hello]

I'd agree the CRF25 encode and the 2 pass encode are pretty much the same quality, and even if you could pick one over the other realistically it's probably irrelevant given you're not going to encode using that high a CRF value. I wouldn't anyway. There was something about the CRF version though.... I haven't got back to them yet so maybe my eyes were just playing tricks.

Slipster did post a couple of samples earlier on. His encoder settings are below.
Best as I could work out at the time, his preset is pretty much the x264 defaults, using Preset Slower and Tune Film. I'm fairly sure using Tune Film changes Psy-trellis strength to 0.15, Tune Grain takes it to 0.25, so I guess his Psy-trellis of 0.2 sits on the fence between them. Aside from that I'm not sure if I found any other differences, although I didn't look super hard, but now you've mentioned it I checked and it seems he's almost with you on AQ "--aq-mode=2 --aq-strength=1.5". I get when using CRF encoding, increasing --aq-strength potentially increases the bitrate by a fair degree, I'm just not sure what effect it'd have when you're using a fixed average bitrate.

From his sample:

x264 core 125 r2208 d9d2288 
Encoding settings : cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / 
psy_rd=1.00:0.20 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / 
fast_pskip=1 / chroma_qp_offset=-3 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=100 / decimate=1 / 
interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / 
weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=50 / intra_refresh=0 / rc_lookahead=60 / 
rc=abr / mbtree=1 / bitrate=1333 / ratetol=1.0 / qcomp=0.70 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=5000 / 
vbv_bufsize=5000 / nal_hrd=none / ip_ratio=1.40 / aq=2:1.50

[poisondeathray]

Best as I could work out at the time, his preset is pretty much the x264 defaults, using Preset Slower and Tune Film. I'm fairly sure using Tune Film changes Psy-trellis strength to 0.15, Tune Grain takes it to 0.25, so I guess his Psy-trellis of 0.2 sits on the fence between them. Aside from that I'm not sure if I found any other differences, although I didn't look super hard, but now you've mentioned it I checked and it seems he's almost with you on AQ "--aq-mode=2 --aq-strength=1.5".


From his sample:

x264 core 125 r2208 d9d2288 
Encoding settings : cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / 
psy_rd=1.00:0.20 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / 
fast_pskip=1 / chroma_qp_offset=-3 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=100 / decimate=1 / 
interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / 
weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=50 / intra_refresh=0 / rc_lookahead=60 / 
rc=abr / mbtree=1 / bitrate=1333 / ratetol=1.0 / qcomp=0.70 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=5000 / 
vbv_bufsize=5000 / nal_hrd=none / ip_ratio=1.40 / aq=2:1.50

This is more like --preset very slow --ref 8 --deblock -1:-1 --scenecut 50 --vbv-maxrate 5000 --vbv-bufsize 5000 --psy-rd 1:0.2 --aq-mode 2 --aq-strength 1.5
(because subme is 10, merange is 24, bframes 8 , this suggests "very slow")

What stands out here is 1pass ABR , nr=100

IMO, the nr is questionable - for lowish bitrate encodes it can be helpful, but I think you would get better results controlling the nr with filtering

1pass ABR? I though this was a 2pass vs. CRF thread ?? or maybe this was from another test ?

I get when using CRF encoding, increasing --aq-strength potentially increases the bitrate by a fair degree, I'm just not sure what effect it'd have when you're using a fixed average bitrate.

It still redistributes to flat , dark areas like gradients, same as in 2pass.

But using higher aq strengths will take bits away from edges. If bitrate is constrained (such as when you use 1pass ABR, 2pass bitrate or CRF with VBV constraints) , then you will notice deterioration in those areas. Edges will look more ratty and you will see artifacts there. So it's basically a trade off and a balancing act . Yes, you will improve things like dark areas, gradients, but other areas will look worse . With unconstrained CRF encoding, the bitrate balloons up to compensate

[hello_hello]

This is more like --preset very slow --ref 8 --deblock -1:-1 --scenecut 50 --vbv-maxrate 5000 --vbv-bufsize 5000 --psy-rd 1:0.2 --aq-mode 2 --aq-strength 1.5
(because subme is 10, merange is 24, bframes 8 , this suggests "very slow")

Yeah, you're right. I guess I remembered fairly not right.

What stands out here is 1pass ABR , nr=100
IMO, the nr is questionable - for lowish bitrate encodes it can be helpful, but I think you would get better results controlling the nr with filtering

What stands out for me is the "original noise as part of the source is part of the source" lecture I was given at one stage. Had I noticed the nr setting at the time......

1pass ABR? I though this was a 2pass vs. CRF thread ?? or maybe this was from another test ?

I missed that too. Of course I can't check the post as it's been deleted, but I thought the two encodes at the time were CRF25 vs 2 pass, but maybe he switched to ABR instead without telling.... I guess he must have. The actual name of the file Slipster uploaded, and from which the encoder settings came, is "VTS_01_2-2-pass1333.mkv". Does that mean he cheated?

But using higher aq strengths will take bits away from edges. If bitrate is constrained (such as when you use 1pass ABR, 2pass bitrate or CRF with VBV constraints) , then you will notice deterioration in those areas. Edges will look more ratty and you will see artifacts there. So it's basically a trade off and a balancing act . Yes, you will improve things like dark areas, gradients, but other areas will look worse . With unconstrained CRF encoding, the bitrate balloons up to compensate

I'm pretty sure I can see the ratty edges effect in the samples Slipster uploaded. I put most of it down to crappy de-interlacing (I mentioned that a few posts ago), but now I'm not so sure.

[poisondeathray]

I don' t know, it seems some posts were deleted

Here's an idea - why don't you just do some more tests instead of going on a "witch hunt"

Since nobody seems to know what mediacoder is doing (in terms of preprocessing) and how commands are passsed since there is no log - it shouldn't really be used for testing purposes IMO. Unless you know EXACTLY what it's doing, the results cannot be generalized to make conclusions or fuel hypothesis on what x264 is doing - There are too many confounding variables

(There are other reasons to avoid mediacoder, but they are more "political" - it violates GPL and distributes some things "illegally"has been placed on the ffmpeg "hall of shame", and does other things like "calling home")

If you don't want to use the CLI - Megui is fine, because a log is generated and it lists everything that's passed, even pre-processing steps like avisynth scripts and filters . As long as your process is transparent, documented and repeatable then that helps with the validity of the testing

[hello_hello]

I don' t know, it seems some posts were deleted

Here's an idea - why don't you just do some more tests instead of going on a "witch hunt"

Maybe it wouldn't be seen as a witch hunt if one of the original participants was still participating and hadn't deleted most of his posts, but jagabo and I both ran further tests of our own a few days ago. See post #74 for mine. jagabo provided links to his latest test encodes a few posts ago. The rest is a continuation of the discussion, some of which involves particular x264 settings recommended by someone who uploaded samples (now deleted) and who happens to use MediaCoder.

[hello_hello]

That particular video has a lot of noise in the dark shots. The high aq-strength helps retain that noise and prevent obvious posterization artifacts in those shots. It costs more bitrate (in CRF encoding) though -- 40 percent more in this clip.

As invariably happens I now found myself confused by the world......
I was just playing around with some of x264's options in view of running a few test encodes myself, but there's one thing I haven't quite got my head around. According to MeGUI's x264 configuration (and after running a couple of quick test encodes and looking at the encoder settings it seems correct):

Default: deblock=1:0:0, psy_rd=1.00:0.00, aq=1:1.00
Tune Film: deblock=1:-1:-1, psy_rd=1.00:0.15, aq=1:1.00
Tune Animation: deblock=1:1:1, psy_rd=0.40:0.00, aq=1:0.60
Tune Grain: deblock=1:-2:-2, psy_rd=1.00:0.25, aq=1:0.50, no-dct-decimate

If aq-strength helps retain noise etc (and I'm not saying it doesn't) what's the logic behind "Tune Grain" decreasing it rather than increasing it? As "Tune Animation" decreases aq-strength by an almost identical amount it seems counter-intuitive to me, given I assume the objective of "Tune Grain" is pretty much to retain noise.

no-dct-decimate? Have you experimented with it? I'm going to run a few test encodes myself using the default Tune presets and then with adjusting aq-strength manually so I'll be interested to see what the differences are.

[poisondeathray]

If aq-strength helps retain noise etc (and I'm not saying it doesn't) what's the logic behind "Tune Grain" decreasing it rather than increasing it? As "Tune Animation" decreases aq-strength by an almost identical amount it seems counter-intuitive to me, given I assume the objective of "Tune Grain" is pretty much to retain noise.

aq-strength in itself doesn't retain grain. The reason it's reduced in --tune grain is for the reason mentioned above - bits are taken away from edges, and frame edges. You end up with a blank "halo" around a frame and around objects. grain becomes "splotchy"

[poisondeathray]

Your settings are normally dependent on your crf range or bitrate range. Someone put a hypothesis that the percieved 2pass better quality observations were more easily observed in lower bitrate/ higher quantizer ranges

For example, if the goal was lower bitate encodes (e.g. crf 25-26 something like that ) it wouldn't make sense to use grain retaining settings (and you wouldn't do that in real life either). It would actually make more sense as an encoding strategy to denoise, improve compressibility . Obviously a noisy or grainy source will be impossible to compress with high quantizers

no-dct-decimate? Have you experimented with it? I'm going to run a few test encodes myself using the default Tune presets and then with adjusting aq-strength manually so I'll be interested to see what the differences are.

This is a high cost (computation, thus encode time), low benefit option. Very little (if any) observable difference. Free free to share your results if you see anything different

[hello_hello]

I ran some comparison encodes using a source video (720p) which is quite high quality and has some fine background noise (film grain?). CRF18 (2.5 minute) encodes using the veryslow speed preset. I really need to upgrade this PC if I'm going to be using slower encoder settings. Plodding along at around 5fps isn't fun.
The section of video in question wouldn't be overly hard to compress as such. I was just interested to see what would happen to the fine noise. No resizing or filtering etc involved. And for Slipster.... I compared them using the HDMI connected PC.

(The first two as a quality starting point)
CRF16, Medium: 124.0MB
CRF16, VerySlow: 118.8MB

All CRF18, VerySlow
Defaults: 73.2MB
Deblock -3:-3: 74.9MB
Psy-Trellis Strength 0.20: 84.7MB
AQ mode 1, AQ Strength 1.8: 124.5MB
AQ mode 2, AQ Strength 1.8: 125.4MB
Psy-Trellis Strength 0.20, AQ mode 2, AQ Strength 1.8: 137.0MB
Tune Film (includes Psy-Trellis Strength 0.15): 82.9MB
Tune Film, AQ mode 2, AQ Strength 1.8: 134.9MB
Tune Grain (includes Psy-Trellis Strength 0.25): 102.4MB
Tune Grain, AQ mode 2, AQ Strength 1.8: 183.3MB

Seems to disprove my previous assumption it's the deblock setting which increases the file size when using Tune Film/Grain. I guess the resulting increase in Psy-Trellis Strength is responsible for most of it.

CRF16 medium speed preset and CRF16 veryslow would probably require bionic eyes to pick which is which. The differences between CRF16 medium & CRF18 veryslow (defaults) were fairly minor, even frame by frame. I had to compare them to the source to pick which was "better". Naturally CRF16 was. Often I couldn't see anything but tiny differences between CRF16 and the source video, even in the background noise.

To actually start looking more closely I had to switch MPC-HC to a sharper resizer. Then I compared the source video very closely to three encodes and I'd rate them for accuracy in this order:

CRF16, medium speed (blurred some of the fine detail by a very, very, very, very tiny amount) 124.0MB
CRF18, veryslow, AQ mode 2, AQ Strength 1.8 ("sharpened" some of the noise by a very, very, very, very tiny amount) 125.4MB
CRF18, veryslow, Tune Grain, AQ mode 2, AQ Strength 1.8 (most of the time when comparing this to the source frame by frame I virtually couldn't tell them apart) 183.3MB

So after all that if I was to pick an encoding method for this video it'd be either CRF16 or CRF18 using x264's defaults, or maybe CRF18 with Tune Film (I haven't compared every encode pixel for pixel yet). Compared to CRF16, "CRF18, AQ mode 2, AQ Strength 1.8" produced an almost identical file size with the former blurring some fine detail ever so slightly, and the second sharpening it ever so slightly. Adding Tune Grain to the mix seemed to result in the most accurate encode, but not worth the 50% file size increase (or around 2.5x compared to CRF18 defaults). I'd probably defy anyone to pick which of these encodes was which at normal viewing distance anyway. This was sit close to the TV, use a sharper resizer, nitpick over very minor differences stuff. And I can't emphasis that enough. These were frame by frame, almost pixel by pixel comparisons.

If there's any weird CRF encoding anomalies going on I'm definitely not seeing them. For me, a low enough CRF value produces an encode which is almost identical to the source, no matter which frame I look at.

Next encoding tests..... probably not for a day or so because I still want to look at some of today's encodes more closely and I've been staring at the TV for so long now I have no idea what I'm looking at any more.... I'll pick something hard to compress and maybe the results will be different.
I'll be interested to see when it comes to harder to compress video, if encoder "tweaking" in preference to using a lower CRF value will scale to a similar degree as far as file sizes go. One of the arguments for tweaking instead of using a lower CRF value is over an entire encode it won't effect the over-all file size as much etc, but given the source video I used wouldn't be hard to compress I'm fairly skeptical.

[hello_hello]

Your settings are normally dependent on your crf range or bitrate range. Someone put a hypothesis that the percieved 2pass better quality observations were more easily observed in lower bitrate/ higher quantizer ranges

I'd possibly be willing to consider that's not an impossible hypothesis.

For example, if the goal was lower bitate encodes (e.g. crf 25-26 something like that ) it wouldn't make sense to use grain retaining settings (and you wouldn't do that in real life either). It would actually make more sense as an encoding strategy to denoise, improve compressibility . Obviously a noisy or grainy source will be impossible to compress with high quantizers

Agreed.

(re no-dct-decimate)
This is a high cost (computation, thus encode time), low benefit option. Very little (if any) observable difference. Free free to share your results if you see anything different

I forgot to throw it into my encoding mix. At this point, I'm more than happy to take your word for it anyway. I'm fairly over staring at the TV screen from a few feet away at the moment.