Beyond '--preset placebo' settings for 720p"60" BD-compliant encode

[A.Fenderson]

I'm attempting to encode TallShip.1280x720.ffvhuff.avi (a lossless 720p60 video) into a Blu-ray compatible stream with some specific attributes listed below, and would really appreciate some feedback on my proposed command-line. I've not previously used x264 via command-line, so please be gentle. ;)

Please note that the encode-time, even if insanely lengthy, is the very least of my priorities and practically a non-issue: same also applies to file-size--even at the max video bitrate for Blu-ray, this clip will easily fit on a BD25 as it's only 5 min 35 seconds long.

Here is the full list of my custom specifications for the resulting encode:
* Blu-ray compatible
* 720p59.940 (matches source other than small frame-rate conversion necessary for BD-compliance)
* high-quality across all frames regardless of frame-type and the amount of movement between frames
* as true to the source as possible, per-frame, within the above limitations/specifications

Please feel free to point out any flaws/gaps in my logic behind constructing the settings below in order to achieve the specifications above. Also, while I'm sure the majority of you will already consider the below to be overkill, if anyone has any additional tweaks they'd recommend to further increase quality within these constraints, please do tell. :)

proposed command-line for each pass:

x264 --fps 60000/1001 --force-cfr --bframes 3 --b-pyramid strict --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --level 4.1 --profile high --vbv-maxrate 40000 --slices 4 --ref 6 --keyint 60 --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --bitrate 39500 --open-gop bluray --me tesa --merange 24 --subme 10 --partitions all --trellis 2 --direct auto --no-fast-pskip --rc-lookahead 60 --b-adapt 0 --deblock -2:-1 --psy-rd 0:0 --qpmin 1 --qpstep 1 --ipratio 1.0 --pbratio 1.0 --min-keyint 60 --slow-firstpass --pass 1 -o out1.264 Tallship.avs

x264 --fps 60000/1001 --force-cfr --bframes 3 --b-pyramid strict --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --level 4.1 --profile high --vbv-maxrate 40000 --slices 4 --ref 6 --keyint 60 --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --bitrate 39500 --open-gop bluray --me tesa --merange 24 --subme 10 --partitions all --trellis 2 --direct auto --no-fast-pskip --rc-lookahead 60 --deblock -2:-1 --psy-rd 0:0 --qpmin 1 --qpstep 1 --ipratio 1.0 --pbratio 1.0 --min-keyint 60 --pass 3 -o out2.264 Tallship.avs

Thanks in advance for any and all comments, even the nay-sayers. :p

[nurbs]

--b-adapt 0 and turning off psy-rd is making things worse.
Setting minimum keframe interval same as maximum isn't going to help either.
Level 4.1 at 720p allows 9 reference frames (unless blu-ray restricts that) and you wouldn't need to specify the number manually if you used --preset and --tune instead of doing everything manually, since in that case it is restricted by --level.
Setting --ipratio to 1 is debatable, setting --pbratio doesn't do anything unless you disable mbtree.
I also think you should leave --qpstep at the default.
Setting fps and --force-cfr shouldn't be needed since you input is an avs.

[A.Fenderson]

Thanks for the reply.
According to this post on BD spec compliance (http://forum.doom9.org/showthread.php?t=154533), which is the most comprehensive I've found (and a sticky), 720p @ 4.1 allows for 6 max ref frames--this seems to be one of the BD-specific restrictions above and beyond the profile/level restrictions.
Also, source material is 60/1 fps, and BD allows 720p @ only 23.976, 24.000, 50.000, and 59.940 fps (not true 60p), therefore the --fps setting.

As for the other recommendations and info, I'm doing further research on all your points to try to better understand all the implications and real-world consequences of these settings, as many of those choices were completely theoretical, based on my very noobish understanding of the settings.

Thanks! :)

[nm]

Also, source material is 60/1 fps, and BD allows 720p @ only 23.976, 24.000, 50.000, and 59.940 fps (not true 60p), therefore the --fps setting.

Yep, that source should be 60000/1001 fps anyway since the original interlaced video is 30000/1001 fps. I guess you're using LoRd_MuldeR's encode.

[A.Fenderson]

I believe it was posted somewhere by LoRd_MuldeR, though now I've lost the link and don't recall for sure. What was the original file distributed as, 1080i? I did notice a few minor artifacts in one scene that made it look like it wasn't native to that (720p) resolution, but it still looks really good.

[nm]

I believe it was posted somewhere by LoRd_MuldeR, though now I've lost the link and don't recall for sure. What was the original file distributed as, 1080i?

Yes. Both the original Lagarith file and LoRd's TGMC'd version are available through BitTorrent here:
http://video-test-sequences.hexagon.cc/torrents

[A.Fenderson]

Hmm, that page gives me nothing, and backing up to just http://video-test-sequences.hexagon.cc/ reveals "0 videos 0 discussions 2 members". Know of any other locations for the originals?

[nurbs]

The link nm posted works fine for me (chromium/linux). Three torrents for Tallship are listed.

[A.Fenderson]

Firefox: blank page.
Opera: blank page.
IE 7: 403 Forbidden.
I'm in the USA, is the site accessible from there to your knowledge?

[nurbs]

Firefox works for me too, but I'm in Europe so maybe it's a regional restriction.

720p60 lossless HuffYUV: magnet:?xt=urn:btih:0fa1e89af868c9a380155cbcee4aebbaa0686b2c&dn=Tallship.720p60&tr=http%3A%2F%2F0f.tracker.hexagon.cc%3A2710%2Fannounce&tr=http%3A%2F%2Fdeneb.yi.org%3A6969%2Fannounce&tr=http%3A%2F%2Fdenis.stalker.h3q.com%3A6969%2Fannounce
1080i30 lossless YUY2 Lagarith: magnet:?xt=urn:btih:42fc35ff42fa2ec668cdf4c33881aa1d9e88dcf1&dn=TallShip%5Flag%5FYUY2%5F5.1.avi&tr=http%3A%2F%2F42.tracker.hexagon.cc%3A2710%2Fannounce&tr=http%3A%2F%2Fdeneb.yi.org%3A6969%2Fannounce&tr=http%3A%2F%2Fdenis.stalker.h3q.com%3A6969%2Fannounce
1080i30 Mpeg2 18 Mbps: magnet:?xt=urn:btih:cde4576a45cefb52215bdc2f7de79c11d42233a9&dn=TallShip%5F1080i%5FATSC.ts&tr=http%3A%2F%2Fcd.tracker.hexagon.cc%3A2710%2Fannounce&tr=http%3A%2F%2Fdeneb.yi.org%3A6969%2Fannounce&tr=http%3A%2F%2Fdenis.stalker.h3q.com%3A6969%2Fannounce

[nm]

Firefox: blank page.
Opera: blank page.
IE 7: 403 Forbidden.
I'm in the USA, is the site accessible from there to your knowledge?

Ouch, I tried to pick a torrent indexing site that wouldn't be blacklisted that soon by operators or IT departments, but apparently it didn't work out very well. It should be accessible in general though.

I'll probably set up a web page for my tracker later unless somebody can suggest a good legal site with a tracker service.

[shon3i]

@A.Fenderson i think using --min-keyint 60 with --keyint 60 have no much sense, because this produce very short gop and or lose commpression efficiency, i realy recommend you to don't touch --min-keyint and unset this parameter, or can set it to 1 or 2, but 60 realy unusual.

[A.Fenderson]

Thanks for the responses, everyone.

The most helpful critiques of the command-line options are those which fully explain why mine won't do what I think they will, and explain why the ones offered will serve better for my unusual set of specifications for this encode. Remember--I'm a noob. :)

I thought of another way of expressing my intended goal with this particular encode: I want intra-only quality, without paying the price for that kind of bitrate. ;)

--b-adapt 0 and turning off psy-rd is making things worse.
Setting minimum keframe interval same as maximum isn't going to help either.
Level 4.1 at 720p allows 9 reference frames (unless blu-ray restricts that) and you wouldn't need to specify the number manually if you used --preset and --tune instead of doing everything manually, since in that case it is restricted by --level.
Setting --ipratio to 1 is debatable, setting --pbratio doesn't do anything unless you disable mbtree.
I also think you should leave --qpstep at the default.
Setting fps and --force-cfr shouldn't be needed since you input is an avs.

--b-adapt 0:
Here's my noobish logic on this: since (in my goal, if not my execution) i, p, and b frames will not be given different quantizers based only on which frame type they are, there's no potential harm (quality loss) from using more b-frames than the encoder might otherwise choose to use, and potentially more to gain in that b-frames are more highly compressed (smaller # of bits) than both i and p frames in general. There are likely some factors I'm not considering, though, so please feel free to shoot down my logic and explain what's really going on there.

--psy-rd:
In trying to do as comprehensive research on this as possible, I'm not finding as much info as I'd like. The mewiki page gives almost nothing (http://mewiki.project357.com/wiki/X264_Settings#psy-rd)other than a link to a post that introduced the feature (http://forum.doom9.org/showthread.php?t=138293) without explaining it, and the links on that post are now dead. The changelog (http://x264.nl/x264/changelog.txt)is equally unenlightening. The x264 ffmpeg mapping and options guide (http://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping)gives an obviously over-simplified description. --fullhelp doesn't explain what psy-rd really does either. I scanned through the thread intro-ing the feature, reading posts by Dark Shikari and akupenguin, but I only get a vague feel for what it does from what I glean there, namely, that it biases towards complexity and "detail" in the encode, but not precisely the detail that was in the original picture--more of an artificial type of detail that, while visually pleasing, is only an approximation of the real detail present in the original; I'd prefer to pass on that for this particular application, though it's fine for my Blu-ray backups. :) Is there a canonical full-explanation by the devs out there somewhere (link)?

mbtree / --pbratio:
For my (possibly strange) purposes for this test encode, pbratio does seem to need to be 1.0 so as to give all frame-types equal chance of having the same (higher) quantizer, right? I noticed that mbtree is raising quantizers on high-motion blocks (http://forum.doom9.org/showpost.php?p=1310980&postcount=1), so I'm now considering disabling mbtree and leaving the pbratio (and ipratio) as 1.0. For my given goals with this encode, does this seem to make sense?

--qpstep:
My reason for dropping this from default 4 to effective minimum 1 is to make quality fluctuations between frames as small/granular as possible, with the ultimate goal of keeping overall quality fluctuations between frames in as small a region as possible. Of course I can imagine a scenario wherein this may actually exacerbate the fluctuations rather than keep a tighter clamp on them (less steep curves but with greater peaks from the average)--I guess it all depends on the latency of the rdo algos, if it's not very adaptive/granular on a frame-by-frame basis....?

@A.Fenderson i think using --min-keyint 60 with --keyint 60 have no much sense, because this produce very short gop and or lose commpression efficiency, i realy recommend you to don't touch --min-keyint and unset this parameter, or can set it to 1 or 2, but 60 realy unusual.

--min-keyint:
Based on this description of min-keyint (http://mewiki.project357.com/wiki/X264_Settings#min-keyint), it was my understanding that a value of it as high as the framerate (60 here, what I used) was considered acceptable. But I also had the understanding that larger values of min-keyint led to larger GOPs, not smaller ones: keyint determines the max interval between IDR frames (GOP delimiters), and min-keyint the minimum, so setting them equal as I've done will force GOPs of the maximum-allowed length. Or so I believed....?

[ajp_anton]

--b-adapt 0:
So you're using this to force a larger number of B-frames? B-frames may be more compressed and smaller, but only if they are used where it's good to use them. If you keep extending a chain of B-frames where --b-adapt 1/2 would've not, those B-frames may become much larger. Yes, "those", not only the one B-frame that was misplaced but the whole chain.

--psy-rd:
If your intention is that the final product is viewed by human eyes, you do want to use this.

--min-keyint:
The distance between keyframes varies between --min-keyint and --keyint. By having these equal you are forcing this distance to be a constant and not letting x264 to put keyframes at scenecuts.
edit: read comment below.

[kemuri-_9]

--min-keyint:
Based on this description of min-keyint (http://mewiki.project357.com/wiki/X264_Settings#min-keyint), it was my understanding that a value of it as high as the framerate (60 here, what I used) was considered acceptable. But I also had the understanding that larger values of min-keyint led to larger GOPs, not smaller ones: keyint determines the max interval between IDR frames (GOP delimiters), and min-keyint the minimum, so setting them equal as I've done will force GOPs of the maximum-allowed length. Or so I believed....?

this is a largely incorrect understanding:
min-keyint is capped out internally within libx264 to about 1/2 of max keyint:
when you do --keyint 60 --min-keyint 60, the real value of --min-keyint used by libx264 is actually 31.

if you want to force IDRs at --keyint intervals without the chance of having x264 decide to place IDR/I frames at other locations, then you --scenecut 0

[A.Fenderson]

OK, b-adapt 0 seems to be a "bad thing", so I propose b-adapt 2 instead as it should be the most intelligent b-frame decision method available.

Stupid question: is libx264 interchangeable with x264 or is there an important difference?

The info about min-keyint being capped doesn't seem to appear anywhere in any of the resources that Dark S. and others generally point people to--though I may be getting in over my head rather quickly, where is a good source of information on the hidden internals of the settings, such as this factoid?

My original intention was to allow scenecut to still insert i (non-IDR) frames as it saw fit, while still maximizing GOP size, but I suppose turning scenecut off, given ipratio 1 and pbratio 1, shouldn't (in and of itself) have an adverse affect on quality or bitrate, right?

Can anyone offer or point me in the direction of a good explanation of what psy-rd is really doing behind the scenes?

Thanks, all! :)

[Blue_MiSfit]

libx264 is a library - so for example it's built into applications like AviDemux and ffmpeg.

x264 is an executible encoder. That's what you want :)

If you turn scenecut off, you won't get any adaptive i / IDR decision. In other words, your GOP sizes will be constant. This is very bad for quality!!! Leave scenecut at default.

Keep psy-rd at default also (i.e. set --tune film). Finally, use --b-adapt 2. Why are you adjusing qpstep and ip/pb ratio?

You're overthinking a lot of this. Do you think you're smarter than x264? When it comes to encoding H.264, you're not - I assure you ;)

You're going to see literally no visible differences by even using --preset placebo vs --preset veryslow, and you're kind of on a fool's errand by trying to push things even further..

[kemuri-_9]

Stupid question: is libx264 interchangeable with x264 or is there an important difference?

I generally use the terms 'libx264' to denote the actual h.264 encoding library and
'x264cli' to denote the command-line interface to said library that is supplied along with it in the repository.


The info about min-keyint being capped doesn't seem to appear anywhere in any of the resources that Dark S. and others generally point people to--though I may be getting in over my head rather quickly, where is a good source of information on the hidden internals of the settings, such as this factoid?

I'll update mewiki for this, but since I occasionally do work on x264 (though i mostly specialize in x264cli) I usually refer to the source code itself.

My original intention was to allow scenecut to still insert i (non-IDR) frames as it saw fit, while still maximizing GOP size, but I suppose turning scenecut off, given ipratio 1 and pbratio 1, shouldn't (in and of itself) have an adverse affect on quality or bitrate, right?

turning it off will affect quality with respect to how many scenecuts would have been there with it on that would cause I/IDR frame insertion.

[G_M_C]

I'm thinking --b-bias might help lowering the likelihood a b-frame is chosen. There will be more p-frames in stead of b-frames, theoretically resulting in higher quality (if measured in over-all compression ;) ). Combine this with setting QP-min, qp/pbratio and qpstep lower, as you have done, is enough i'd say (i wouldnt go to the low values you use, but its up to you)..

Remember that when you change settings like min keyint and open-gop you might end up with a non-BD-compliant encode, your TS suggest you want it to be compliant, so reflect on the settings you want to use.

x264 --fps 60000/1001 --force-cfr --keyint 60 --min-keyint 2 --open-gop bluray --slices 4 --aud --nal-hrd vbr --pic-struct --bitrate 39500 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --profile high --me tesa --subme 10 --merange 24 --mvrange 511 --direct auto --no-fast-pskip --partitions all --qpmin 4 --qpstep 2 --ipratio 1.2 --pbratio 1.1 --deblock -3:-3 --bframes 3 --b-pyramid strict --ref 6 --b-bias -40 --rc-lookahead 60 --b-adapt 2 --trellis 2 --psy-rd 0.9:0.1 --aq-mode 2 --aq-strength 0.9 --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --slow-firstpass --pass 1 -o out1.264 Tallship.avs

x264 --fps 60000/1001 --force-cfr --keyint 60 --min-keyint 2 --open-gop bluray --slices 4 --aud --nal-hrd vbr --pic-struct --bitrate 39500 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --profile high --me tesa --subme 10 --merange 24 --mvrange 511 --direct auto --no-fast-pskip --partitions all --qpmin 4 --qpstep 2 --ipratio 1.2 --pbratio 1.1 --deblock -3:-3 --bframes 3 --b-pyramid strict --ref 6 --b-bias -40 --rc-lookahead 60 --b-adapt 2 --trellis 2 --psy-rd 0.9:0.1 --aq-mode 2 --aq-strength 0.9 --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --pass 3 -o out2.264 Tallship.avs

Is more than enough imho

[nurbs]

--psy-rd:
...
I scanned through the thread intro-ing the feature, reading posts by Dark Shikari and akupenguin, but I only get a vague feel for what it does from what I glean there, namely, that it biases towards complexity and "detail" in the encode, but not precisely the detail that was in the original picture--more of an artificial type of detail that, while visually pleasing, is only an approximation of the real detail present in the original; I'd prefer to pass on that for this particular application, though it's fine for my Blu-ray backups. :) Is there a canonical full-explanation by the devs out there somewhere (link)?
Unless you encode lossless the blocks will always be an approximation of the actual detail. RD usually prefers blurry approximations (http://x264dev.multimedia.cx/?p=164), that's why psy-rd was added so we can have sharper, better looking ones. You apparently want sharpness or else you wouldn't have touched the --deblock setting.


mbtree / --pbratio:
For my (possibly strange) purposes for this test encode, pbratio does seem to need to be 1.0 so as to give all frame-types equal chance of having the same (higher) quantizer, right? I noticed that mbtree is raising quantizers on high-motion blocks, so I'm now considering disabling mbtree and leaving the pbratio (and ipratio) as 1.0. For my given goals with this encode, does this seem to make sense?

--qpstep:
My reason for dropping this from default 4 to effective minimum 1 is to make quality fluctuations between frames as small/granular as possible, with the ultimate goal of keeping overall quality fluctuations between frames in as small a region as possible. Of course I can imagine a scenario wherein this may actually exacerbate the fluctuations rather than keep a tighter clamp on them (less steep curves but with greater peaks from the average)--I guess it all depends on the latency of the rdo algos, if it's not very adaptive/granular on a frame-by-frame basis....?
Mbtree (http://x264dev.multimedia.cx/?p=98) as well as the old ratecontrol will raise quantizer in certain scenes in order to improve the overall quality of the video, mbtree just uses a better analysis method. The reason why --pbratio won't work with it is that it will automatically pick the optimal ratio depending on content.
Clamping qpstep will lead to scenarios where bits are wasted on some frames with no visual gain because the quantizer can't be raised enough, while on other frames you'll potentially have visual degradation because the quantizer can't be lowered enough.
That you want to screw with the settings basically means that you do not trust ratecontrol. This seems to stem from the believe that quantizer is quality, which it isn't. A constant quantizer encode will not give you "high quality across all frames" and won't be "as true to the source as possible" at a given bitrate, You can have frames that will look perfect at quantizer 24 and others that will look crap at 16 depending on the content of those frames. You are trying to restrict the quantizers that can be chosen because you believe that this will increase the quality.

There will be more p-frames in stead of b-frames, theoretically resulting in higher quality (if measured in over-all compression ).
Following that line of thought when using --bframes 0 there will be even more p-frames and thus even higher quality. So why do we use b-frames at all? :confused: Oh, I remember. We use them because they can give better compression efficiency and therefore better overall quality at a given bitrate.

[G_M_C]

[...]
Following that line of thought when using --bframes 0 there will be even more p-frames and thus even higher quality. So why do we use b-frames at all? :confused: Oh, I remember. We use them because they can give better compression efficiency and therefore better overall quality at a given bitrate.

You give the answer yourself; That why i suggest using b-bias in stead of using no b-frames at all.

[nurbs]

So you think x264 frametype decision generally uses too many b-frames for an optimum compression efficiency.
Might be, I never tested it. Some evidence to support the claim would be nice.

[G_M_C]

So you think x264 frametype decision generally uses too many b-frames for an optimum compression efficiency.
Might be, I never tested it. Some evidence to support the claim would be nice.

Dunno, i've always assumed p-frames had, on average, higher quality than b-frames.

Using slightly more of them, and simultaneously making them of slightly better quality themselves (ipratio, qp-min) is the hypothesis behind this. The b-frames themselves reference these slightly better quality p-frames, and also have more to reference. The secondary hypothesis beeing that the b-frames also go up in average quality.

It all leads to much (?) lower compression offcourse, but compression wasnt the problem in this tread as per TS.
But ... hey, i'm no expert, i just hypothesize ;)

[Blue_MiSfit]

This is all very hypothetical... I find it hard to believe that x264 does things sub-optimally.

Do some metric tests with this source and various settings (no psy of course, since that screws up metrics)..

B-frames help overall quality because they have the ability to be smaller than P-frames, thus saving bits which can be allocated to those pesky p-frames and I-frames :devil:. The optimal placement of them is the tricky bit, and --b-adapt 2 does a good job of this. In fact, most content seldom benefits from more than 3 consecutive b-frames.

Feel free to prove otherwise :)

Derek

[kemuri-_9]

In fact, most content seldom benefits from more than 3 consecutive b-frames.

Feel free to prove otherwise :)

Derek

It would be wise to stay away from making stray/random generalizations like this that are too heavily content dependent.

I have encoded content that gets significant usage of bframes all the way through 16 with b-adapt 2

[Blue_MiSfit]

Indeed you're correct. I'll modify my statement to say that most live action content rarely uses from more than 3-5 consecutive b-frames ;) Generic enough? ;)

I know anime tends to use more b-frames on average. I've encoded a _ton_ of movies though, so my knowledge isn't totally imaginary :)

Derek

[ajp_anton]

Dunno, i've always assumed p-frames had, on average, higher quality than b-frames.

Using slightly more of them, and simultaneously making them of slightly better quality themselves (ipratio, qp-min) is the hypothesis behind this. The b-frames themselves reference these slightly better quality p-frames, and also have more to reference. The secondary hypothesis beeing that the b-frames also go up in average quality.

It all leads to much (?) lower compression offcourse, but compression wasnt the problem in this tread as per TS.
But ... hey, i'm no expert, i just hypothesize ;)

P-frames are higher quality, but they are also bigger, so using too many of them wastes bitrate.
Using more small B-frames allows you to increase the quality of P-frames (in bitrate mode), which in turn increases the quality of B-frames.

[Forteen88]

I heard --aq-mode 2 isn't good at dark areas of frames, so I would use default aq-mode but --aq-strength 0.8 on HD-material.

[AnonCrow]

Given how you override many options that change quantizers between frames and within a frame, you might as well do an encode with a low (6-12) constant quantizer with a slow preset, omitting all options that make it blu-ray compatible (even VBV), and see what kind of average/peak bitrates you get - and if you see any difference between Q6 , Q10 and Q12. Then do a final encode with a slower (or even veryslow) preset , with all the necessary options to make it blu-ray compatible added back.

[A.Fenderson]

Again, thank you all for your responses, I think I'm learning something here. :)

I now see, however, that I've probably misnamed the title of my thread and possibly failed to precisely verbalize my intent--I've thought of yet another way of attempting to express my goals with this encode:
I'm not trying to maximize visual perceptive quality when the video is viewed at its native framerate (1x playback) and resolution: I am instead attempting to firstly (#1 priority) create an encode wherein every single frame (Priority 1A) and all blocks of each frame (priority 1B) is given equal weight/quality regardless of factors such as frame-type, amount of movement in the video, etc, and secondly (and subject to the conditions imposed by the first priority) to maximize the perceptual quality of the resulting encode. I'm attempting, firstly, to impose frame-type egalitarianism, and only thereafter maximize quality such that a freeze-frame of any given frame-type will yield a frame which is visually as close to the original frame as possible, given the constraints (Blu-ray compliance and frame-type egalitarianism) placed on the encode. I do realize there's a very real probability that by imposing this constraint, I'm actually adversely affecting the perceptible quality of the overall resulting encode, were it watched as normal (at it's native resolution and 1x playback speed). In fact I'm guessing that were I to achieve my goal of equal quality across all frames (and all portions of each frame), that the resulting encode would exhibit an overall perceptual quality loss under normal viewing conditions, because bits would be "wasted" on encoding high-detail in the high-movement (etc) areas of scenes (and/or in p/b frames) where bitrate is usually "borrowed" from the perceptual dead-zones and redistributed to the areas where the increased quality will be more noticeable. But for this particular encode, so be it: for all practical purposes, I'm basically attempting to determine the level of perceptual quality loss under normal viewing conditions after having conformed to the "every frame is sacred, every frame is great" constraints. :) Is this a fool's errand? Very likely yes, but it will help me answer a question that I need answered.


If you turn scenecut off, you won't get any adaptive i / IDR decision. In other words, your GOP sizes will be constant. This is very bad for quality!!! Leave scenecut at default.

I understand why this would be the case under normal circumstances, with mbtree on, and ipratio and pbratio at their defaults, but given the above conditions I've laid out (and my current belief that I'll have to turn mbtree off and set ipratio and pbratio both to 1.0), do you still believe having scenecut off will still result in wasted bandwidth/reduced quality? If so, please explain the mechanism by which this might occur so that I'll better understand the logic behind it.

Keep psy-rd at default also (i.e. set --tune film).
I noticed there's not a tuning whose name would make it the obvious choice for high frame-rate material shot as digital video and not subjected to post-processing intended to give a film-like look, as is the case with this material. Is --tune film generally considered the best of the tunings for maintaining sharpness on grain-free, high-fps, digital video material?

I'll update mewiki for this, but since I occasionally do work on x264 (though i mostly specialize in x264cli) I usually refer to the source code itself.

Cool, thanks. Mewiki is probably the most useful page I've found for getting some idea of what all these settings do.

turning it [scenecut] off will affect quality with respect to how many scenecuts would have been there with it on that would cause I/IDR frame insertion.

Affect it adversely? I'm having trouble conceptually seeing why, could you explain briefly?

Remember that when you change settings like min keyint and open-gop you might end up with a non-BD-compliant encode, your TS suggest you want it to be compliant, so reflect on the settings you want to use.
If open-gop is set to bluray, there's still a chance that this setting alone can result in an encode that is not BD-spec compliant, or merely just not playable on certain/some/most BD players? As for --min-keyint/(max)--keyint, I haven't seen any constraints placed on that by BD spec mentioned anywhere, apart from the GOP size constraints, which for this encode would seem to allow a range (for either/both so long as min-keyint <= keyint) of 60 down to zero (assuming a defacto intra-only stream is compliant for high@L4.1 in the first place).

...--mvrange 511...
What's the benefit of specifying 511 here where the default is already set to 511.75 (H264 max) and the --merange (24) is so much lower anyway? Does the encoder flag this in the stream and some BD decoders look for it and expect a max of 511.00?

...--aq-mode 2...
So as to maintain a constant quality level within each frame (Priority 1, part B), I believe I need to set aq to 0 (disable it completely).

Clamping qpstep will lead to scenarios where bits are wasted on some frames with no visual gain because the quantizer can't be raised enough, while on other frames you'll potentially have visual degradation because the quantizer can't be lowered enough....This seems to stem from the believe that quantizer is quality, which it isn't. A constant quantizer encode will not give you "high quality across all frames" and won't be "as true to the source as possible" at a given bitrate, You can have frames that will look perfect at quantizer 24 and others that will look crap at 16 depending on the content of those frames.
Point taken. I'm now considering leaving qpstep at default 4, but still maintaining qp-min as 1, unless someone can explain how this would be a bad idea.

Given how you override many options that change quantizers between frames and within a frame, you might as well do an encode with a low (6-12) constant quantizer with a slow preset, omitting all options that make it blu-ray compatible (even VBV), and see what kind of average/peak bitrates you get - and if you see any difference between Q6 , Q10 and Q12. Then do a final encode with a slower (or even veryslow) preset , with all the necessary options to make it blu-ray compatible added back.
Given my ultimate goal/first-priority, this seems like a reasonable suggestion for some initial tests. Thanks. :)

As always, thanks for taking the time to respond or just chime in, and keep 'em coming! :D

[nurbs]

I understand why this would be the case under normal circumstances, with mbtree on, and ipratio and pbratio at their defaults, but given the above conditions I've laid out (and my current belief that I'll have to turn mbtree off and set ipratio and pbratio both to 1.0), do you still believe having scenecut off will still result in wasted bandwidth/reduced quality? If so, please explain the mechanism by which this might occur so that I'll better understand the logic behind it.
Why is it so hard to understand that not letting the encoder put an I frame where it belongs is bad for quality? The encoder will put an I frame when there is a scenecut. When there is a scenecut you can't predict the picture from previous frames, because they are completely different. If you force the encoder not to use an I frame it will probably put a P frame there instead. Since it can't be properly predicted most if not all of the blocks in the frame will still be coded intra which comes at a certain overhead compared to just coding an I frame to begin with. Therefore you are wasting bits on that frame that could otherwise be used to increase the quality of the video.

Is --tune film generally considered the best of the tunings for maintaining sharpness on grain-free, high-fps, digital video material?
--tune film is for normal content that is neither a Simpsons-like cartoon nor a grainfest like 300 and you are not desperately trying to keep most of the grain. It doesn't matter if it was shot on actual film or digital as long as it's "normal" content.

What's the benefit of specifying 511 here where the default is already set to 511.75 (H264 max) and the --merange (24) is so much lower anyway? Does the encoder flag this in the stream and some BD decoders look for it and expect a max of 511.00?
--merange has nothing to do with --mvrange. --merange determines the search range around the best predictor for the motion, so if the best predictor is 200 pixels and merange is 24 it will result in mvs between 176 and 224 pixels (simplified in 1D).

So as to maintain a constant quality level within each frame (Priority 1, part B), I believe I need to set aq to 0 (disable it completely).
The reason AQ exists is to maintain a constant quality level within each frame. As I said before quantizer isn't quality. Encoding frames at a constant quantizer (= turning AQ off) will often result in blurry backgrounds and blocky skies, because depending on the content of the blocks some will need a much lower quantizer than the rest of the frame to keep a decent quality. Compare these screenshots with (http://doom10.org/compare/parkrun_ssim.png) and without (http://doom10.org/compare/parkrun_psnr.png) AQ.

[A.Fenderson]

Why is it so hard to understand that not letting the encoder put an I frame where it belongs is bad for quality? ... P frame there instead. Since it can't be properly predicted most if not all of the blocks in the frame will still be coded intra which comes at a certain overhead compared to just coding an I frame to begin with.

That's why it was hard to understand--I had never heard that intra-coded blocks within P-frames cost comparatively more than within i-frames. It's kinda counter-intuitive, in my admittedly uninformed opinion, but now that I know that, it makes perfect sense. Thanks! :)

--merange has nothing to do with --mvrange. --merange determines the search range around the best predictor for the motion, so if the best predictor is 200 pixels and merange is 24 it will result in mvs between 176 and 224 pixels (simplified in 1D).

Ah, thanks. This made me realize I had incorrect understanding of what each of these represented. But I still wonder the benefit of explicitly setting --mvrange to 511....anyone?

The reason AQ exists is to maintain a constant quality level within each frame. As I said before quantizer isn't quality. Encoding frames at a constant quantizer (= turning AQ off) will often result in blurry backgrounds and blocky skies, because depending on the content of the blocks some will need a much lower quantizer than the rest of the frame to keep a decent quality. Compare these screenshots with and without AQ.

Point taken. Other than dark areas, are there other types of material/scenes wherein anyone thinks aq-mode 2 is generally inferior to aq-mode 1? Also, can aq-mode 2 and aq-strength be used in combination, since aq2 itself "attempts to adapt strength per-frame" as per mewiki?

My continued thanks to all who post in reply to my noob questions. :D

New proposed (first-pass) command line:
x264 --fps 60000/1001 --force-cfr --bframes 3 --b-pyramid strict --aud --nal-hrd vbr --pic-struct --vbv-bufsize 30000 --level 4.1 --profile high --vbv-maxrate 40000 --slices 4 --ref 6 --keyint 60 --sar 1:1 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --bitrate 39500 --open-gop bluray --me tesa --merange 24 --subme 10 --partitions all --trellis 2 --direct auto --no-fast-pskip --rc-lookahead 60 --b-adapt 2 --aq-mode 2 --tune film --qpmin 4 --ipratio 1.0 --slow-firstpass --pass 1 -o out1.264 Tallship.avs
Still-pending questions:
1. --mvrange 511: is this accomplishing anything? Is it there for better Blu-ray compliance (and if so, why/how)?
2. can open-gop bluray being set still result in encodes that are not Blu-ray compliant (or problematic for some BD hardware decoders)?
3. same as above but for min-keyint (which I'm no longer tweaking, but still...)?
4. since it looks now like it was neither mbtree nor psy-rd that takes bits from the high-motion portions of frames to redistribute to the other parts, what, if anything, does this--or did I dream it? ;)
Thanks

[ajp_anton]

4. qcomp?

Also, your command line can be compressed into:
x264 --pass 1 --bitrate 39500 --preset placebo --tune film --aq-mode 2 --bframes 3 --ref 6 --level 4.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --keyint 60 --open-gop bluray --qpmin 4 --ipratio 1.0 --slices 4 --fps 60000/1001 --force-cfr --b-pyramid strict --aud --nal-hrd vbr --pic-struct --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 -o out1.264 Tallship.avsedit: --sar defaults to 1:1, right?

[kemuri-_9]

edit: --sar defaults to 1:1, right?

no, --sar defaults to unspecified.

[ajp_anton]

So keep your --sar 1:1 =)

[shon3i]

2. can open-gop bluray being set still result in encodes that are not Blu-ray compliant (or problematic for some BD hardware decoders)?
3. same as above but for min-keyint (which I'm no longer tweaking, but still...)?No. OpenGOP is part of Blu-Ray specification, so players BD certificate players must support it, and you don't need to touch min-keyint, default "auto" work fine.

[mandarinka]

I would try using --maxqp before messing with all the other options blindly. Oh and raised --qcomp too I guess, as people suggested. That is how I owuld try to go after that goal of yours.