View Full Version : BD Rebuilder Settings Vs. x264 Presets
DoctorM
24th January 2015, 11:03
I know this has been partially ask in some ways before, but I'm not sure I've seen this complete.
Based on previous discussions I've come up with this:
ENCODE_QUALITY=5 "High-Speed Option (BD-25+)" = X264 setting "--ultrafast"
ENCODE_QUALITY=0 "Good (Very Fast)" = X264 setting "--superfast"
ENCODE_QUALITY=1 "Better (Fast)" = X264 setting "--faster"
ENCODE_QUALITY=2 "High Quality (Default)" = X264 setting "--medium"
ENCODE_QUALITY=3 "Highest (Very Slow)" = X264 setting "--slow"
ENCODE_QUALITY=4 and QUALITY_ULTRA=0 = X264 setting "--slower"
ENCODE_QUALITY=4 and QUALITY_ULTRA=1 = X264 setting "--veryslow"
ENCODE_QUALITY=4 and QUALITY_ULTRA=2 = X264 setting "--placebo"
Is this correct, or does x264's presets have no relationship to BD Rebuilder's settings?
jdobbs
24th January 2015, 17:02
That is correct.
The reason I use a different naming convention is because the name given in X264 aren't representative of the "quality" you'd receive (at a given bitrate). They represent the speed of the encode. For example, saying "medium" doesn't represent well the high quality you receive from that setting (probably as high as you ever need to go if you aren't obsessive-compulsive).
Note that some of the higher options aren't available from the menu, because they aren't recommended -- and can only be manually set by editing the INI file. That's because they represent a huge investment in encoding time for a minimal return (usually none) in quality.
Sharc
24th January 2015, 18:25
....probably as high as you ever need to go if you aren't obsessive-compulsive....
I added this to my English vocabulary.... :)
In fact it's not easy to find the terms for the quality which fits all scenarios. For example "Good (Very fast)" produces Very High Quality when the bitrate is sufficiently high, like on a BD25, I think.
DoctorM
24th January 2015, 20:20
I defer to your experience, jd, but in theory the guys writing x264 intend there to be some trade off of encode time for encode quality with these settings.
I agree though, that you wouldn't call a setting 'Placebo' unless you meant it, but if I was manually encoding a movie to BD5/9, I would definitely want to use '--slow' minimum or '--slower' if quality suffers. For BD25, depending on run time or amount of complexity/grain I would use --medium or --slow.
There's just not enough encode time difference on my PC for me to not take advantage of any quality improvement this brings.
Auto_Bias, even set to 3 doesn't seem to reflect my way of thinking, so I was trying to get a handle on what settings mean what.
jdobbs
24th January 2015, 20:57
I've done a lot of testing. That experience is reflected in the "Automatic" setting. It will choose a speed/quality setting that matches the target based on the source. In many cases you will find that there is absolutely no detectable difference between "Good (Very Fast)" and the "--slower" setting. When there is no difference -- why waste the time?
But the higher settings are there so they can be used -- and if time is no object then it doesn't hurt (in most cases) to set it for overkill.
DoctorM
24th January 2015, 22:38
Does the automatic setting examine the complexity or grain in the source or is it determined based on run time and/or percentage compression?
soneca
24th January 2015, 23:26
The video sources can differ greatly in the level of compressibility.
Sources with grainy video is one of them but there are sources with no granulation and also extremely difficult to compress.
When I want to have an idea of this compressibility make a conversion using the CRF mode and then decide what to use.
I have movies that take up less than half the space showing the same quality!
I only use the preset "slower" for BD5 and usually "slow" for the rest.
With heavier presets that "slower", never noticed differences.
Sharc
25th January 2015, 13:16
Note that --bluray-compat applies some constraints to the presets. Here is what I get for --bluray-compat:
ultrafast cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 mixed_ref=0 me_range=16 trellis=0 8x8dct=0 chroma_qp_offset=0 bframes=0 direct=1 weightp=0 scenecut=0 rc_lookahead=0 mbtree=0 aq=0
superfast cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x3 me=dia subme=1 mixed_ref=0 me_range=16 trellis=0 8x8dct=1 chroma_qp_offset=0 bframes=3 b_adapt=1 direct=1 weightp=1 scenecut=40 rc_lookahead=0 mbtree=0 aq=1:1.00
veryfast cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 mixed_ref=0 me_range=16 trellis=0 8x8dct=1 chroma_qp_offset=0 bframes=3 b_adapt=1 direct=1 weightp=1 scenecut=40 rc_lookahead=10 mbtree=1 aq=1:1.00
faster cabac=1 ref=2 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=4 mixed_ref=0 me_range=16 trellis=1 8x8dct=1 chroma_qp_offset=0 bframes=3 b_adapt=1 direct=1 weightp=1 scenecut=40 rc_lookahead=20 mbtree=1 aq=1:1.00
fast cabac=1 ref=2 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=6 mixed_ref=1 me_range=16 trellis=1 8x8dct=1 chroma_qp_offset=-2 bframes=3 b_adapt=1 direct=1 weightp=1 scenecut=40 rc_lookahead=24 mbtree=1 aq=1:1.00
medium cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 mixed_ref=1 me_range=16 trellis=1 8x8dct=1 chroma_qp_offset=-2 bframes=3 b_adapt=1 direct=1 weightp=1 scenecut=40 rc_lookahead=24 mbtree=1 aq=1:1.00
slow cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=8 mixed_ref=1 me_range=16 trellis=1 8x8dct=1 chroma_qp_offset=-2 bframes=3 b_adapt=2 direct=3 weightp=1 scenecut=40 rc_lookahead=24 mbtree=1 aq=1:1.00
slower cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=9 mixed_ref=1 me_range=16 trellis=2 8x8dct=1 chroma_qp_offset=-2 bframes=3 b_adapt=2 direct=3 weightp=1 scenecut=40 rc_lookahead=24 mbtree=1 aq=1:1.00
veryslow cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=10 mixed_ref=1 me_range=24 trellis=2 8x8dct=1 chroma_qp_offset=-2 bframes=3 b_adapt=2 direct=3 weightp=1 scenecut=40 rc_lookahead=24 mbtree=1 aq=1:1.00
soneca
25th January 2015, 14:54
Cool this table!
Exactly. When I convert using the CRF mode does not restrict in any way the preset used because my media players play all without problems.
But for the blu-ray or avchd such mandatory restrictions hinder some performance x264.
jdobbs
25th January 2015, 16:09
Does the automatic setting examine the complexity or grain in the source or is it determined based on run time and/or percentage compression?No it doesn't. But I've thought about adding an optional step that runs a quick analysis of the source (5% or so) so that it can adjust for detected complexity.
jdobbs
25th January 2015, 16:11
Note that --bluray-compat applies some constraints to the presets. Here is what I get for --bluray-compat:
...
I may also add a setting to remove that option from the command line when running ALTERNATE encodes. My only concern is the impact it will have on various players. Some players (like playstation) seem to be a little finicky.
I'd have to go back and look again, as I can't recall which of those settings would change if "--bluray-compat" was not set. I'm pretty sure the number of b frames and weightp would for some settings. Other than that, I don't think it makes much of a difference.
[Edit] Ok I looked at the table (see here (http://dev.beandog.org/x264_preset_reference.html)) and I think the only things that would change in your post would be b-frames (for very-slow and placebo), weightp (for medium and above), and ref (for slow and above).
soneca
25th January 2015, 19:09
No it doesn't. But I've thought about adding an optional step that runs a quick analysis of the source (5% or so) so that it can adjust for detected complexity.
Cool! And the result of this analysis to encode would be restricted to "Good to Highest" or could reach the preset slower(ENCODE_QUALITY = 4) to encode depending on the complexity?
jdobbs
25th January 2015, 21:59
I could include it... but honestly, I don't think it would ever get hit except for a BD-5.
DoctorM
25th January 2015, 22:38
I like the analysis idea and possibility of ENCODE_QUALITY=4 for BD5. It would mean less things I'd have to do manually.
Edit: The PlayStation limitations are also present in Sony's BD players for media formats like MKV. At least in the model I own.
Sharc
25th January 2015, 22:39
I may also add a setting to remove that option from the command line when running ALTERNATE encodes. My only concern is the impact it will have on various players. Some players (like playstation) seem to be a little finicky.
I'd have to go back and look again, as I can't recall which of those settings would change if "--bluray-compat" was not set. I'm pretty sure the number of b frames and weightp would for some settings. Other than that, I don't think it makes much of a difference.
[Edit] Ok I looked at the table (see here (http://dev.beandog.org/x264_preset_reference.html)) and I think the only things that would change in your post would be b-frames (for very-slow and placebo), weightp (for medium and above), and ref (for slow and above).
Perhaps to add that "--bluray-compat" limits --keyint to 24 (corresponding to 1 or 2 seconds depending on resolution), compared to the default of 250 frames.
For BD5 I used "--preset medium" with the tweaks me=umh and subme=8. It didn't add too much encoding time. Any stronger/higher settings did not really pay off, IMO.
sneaker_ger
25th January 2015, 23:01
--bluray-compat does not limit --keyint in any way. Also, it can not be 100% replaced by combinations of other options, it does change some things internally that are not exposed via cli otherwise.
Sharc
25th January 2015, 23:10
--bluray-compat does not limit --keyint in any way......
Hmm, yes, but the Blu-Ray standard does AFAIK. One has to set --keyint explicitly then to be compliant, right?
jdobbs
25th January 2015, 23:29
Hmm, yes, but the Blu-Ray standard does AFAIK. One has to set --keyint explicitly then to be compliant, right?Probably because it isn't a fixed value. The BD standard's maximum GOP size depends on the resolution and framerate. BD-RB sets it explicitly when the output is to blu-ray. When outputting to ALTERNATE formats it can be set with the "vKeyint" option. If set to "auto" it is 10x the framerate, if not set at all it defaults to 24.
soneca
26th January 2015, 00:30
Perhaps to add that "--bluray-compat" limits --keyint to 24 (corresponding to 1 or 2 seconds depending on resolution), compared to the default of 250 frames.
For BD5 I used "--preset medium" with the tweaks me=umh and subme=8. It didn't add too much encoding time. Any stronger/higher settings did not really pay off, IMO.
I do an adaptation from the preset that interests me, like the one below(slower) to create an AVCHD-720p/24 disk.
"I set up" several presets a few years, I am far from an expert but work very well today.
--preset slower --bluray-compat --level 4.0 --keyint 24 --min-keyint 1 --ipratio 1.2 --vbv-bufsize 15000 --vbv-maxrate 15000 --me umh --b-adapt 2 --ref 6 --bframes 3 --pic-struct --colorprim "bt709" --transfer "bt709" --colormatrix "bt709"
DoctorM
26th January 2015, 08:41
For BD5 I used "--preset medium" with the tweaks me=umh and subme=8. It didn't add too much encoding time. Any stronger/higher settings did not really pay off, IMO.
How much difference in encode time does that really give you from --preset slow (Highest/Very Slow in BDRB)? As far as I can tell you're just using ref=3 instead of ref=4.
Sharc
26th January 2015, 16:00
How much difference in encode time does that really give you from --preset slow (Highest/Very Slow in BDRB)? As far as I can tell you're just using ref=3 instead of ref=4.
I would have to re-test because it's a while ago since I did such tests.
--preset slow would actually add ref=4 (3), b-adapt=2 (1) and direct=3 (1).
Edit:
"--preset slow" takes approx 10% longer and reduces file size (at same --crf) by about 3.5%, compared to my "--preset medium with tweaks".
Edit 2:
When dropping the --bluray-compat constraints, the "--preset slow" takes 45% longer and reduces the file size by 23% compared to my "--preset medium with tweaks".
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.