MEGUI + x264 settings

[Cunhambebe]

Hi everybody. I'm trying to go from x264 to x264 (for cropping purposes) using MEGUI, an AviSynth script and x264. The master file plays ok using Media Player Classic HC. That means you can point the cursor on the timeline wherever you want and you can see the result immediately. Same thing is not happening with the newly encoded file. It is perfect as the master file (crystal clear) and plays great on my Samsung HDTV, but using Media Player Classic HC, as you move the cursor, it does take a bit of time (some seconds) to respond. My question is: what am I doing wrong? Here are some screenshots. Maybe there's something wrong with the Misc Guide: V.U.I.>Range>auto/tv or pc... Help will be greatly appreciated. Thanks in advance.

[LigH.de]

"The master file" has a more or less uncompressed or key-frame only format? Then the player can seek to every frame directly.

But AVC video has GOPs (Groups of Pictures; simplified). That means: Only once in a while, the video contains an independent frame (I or even IDR frame in AVC), all the other frames only contain a kind of difference to the last previous I-frame or up to several other frames. That means: The player can only seek directly to the few GOP start I frames. So it either seeks not accurately, or it has to start decoding the video from the last previous I frame to the frame you wanted to seek to, which takes some time, depending on the complexity of the encoding.

To speed it up, you could reduce the maximum GOP size; Blu-ray compatible results may have at most a GOP duration of 1 or 2 seconds (depending on some constraints). But that will reduce the efficiency of the encoding: More I frames need more bitrate.

[Cunhambebe]

Thanks for taking time to respond, LigH.de.

"The master file" has a more or less uncompressed or key-frame only format? Then the player can seek to every frame directly.

-That's a very interesting question. The file is also x264 (AVC); here's what MediaInfo shows:

Anyway, I really appreciate your guide on how to reduce the maximum GOP size.
Any other suggestions?
Thanks in advance.
Cheers,
Mark

[hello_hello]

When you encode, are you outputting directly to MKV, and are you trying to play the re-encoded version without remuxing it? If you open the re-encoded version with MKVMergeGUI, or with MeGUI's MKV/MP4 muxer and resave it, does the saved version play better using MPC-HC?

If you output directly to MKV, the resulting MKV isn't indexed, so MPC-HC indexes it when you try to play it which can make opening/seeking really slow (something like that). If the output is MKV and I'm correct, remuxing the output MKV should fix it. Normally you'd remux it to add additional streams such as audio and subtitles etc anyway.

I doubt the settings you're using are the problem, but are you using AVCHD as the target playback device for a particular reason? If you're not creating AVCHD complaint video and just converting to MKV or MP4 etc to play the encodes via USB, none of that Bluray compatibility stuff is necessary. Even if you're using a Bluray player. Via USB, support for High Profile, Level 4.1 is pretty standard. Selecting DXVA as the target playback device should do.

[hello_hello]

PS. When you use the bluray compatibility option, the keyint settings (GOP size) are automatically set to 24 and 1, or 25 and 1 etc, depending on the frame rate (Edit: I got that a little wrong. See post #9). That means the maximum GOP size is one second. The defaults are 250 and 24 (or something similar, depending on the frame rate) when means the maximum GOP size is 10 seconds and 1 second is the minimum. The defaults will probably increase the quality a bit for a given bitrate.

The default GOP settings might make seeking using a standalone player a bit less smooth, but when it comes to seeking using a software player such as MPC-HC the difference in seeking time would probably be on the edge of human perception.
Plus by defaut, MPC-HC seeks to the nearest keyframe, so it doesn't do any of the "decoding around the seek point" stuff. It just jumps to the nearest keyframe. The setting to enable/disable that is under Options/Tweaks and it's labelled "fast seek". I disable it myself, but enabled it shouldn't slow seeking down by much at all.

PPS. For MediaInfo, try selecting View/HTML or View/Text. You're only seeing the bare minimum of info with the default view.

PPPS. The stuff under V.U.I in the x264 encoder configuration doesn't change the way the video is encoded, it just causes x264 to write info to the video stream. Unless you understand it, it's probably best just to leave it all at the default settings.
http://mewiki.project357.com/wiki/X264_Settings#Video_Usability_Info

[Cunhambebe]

Thanks for taking time to respond, hello_hello!

When you encode, are you outputting directly to MKV, and are you trying to play the re-encoded version without remuxing it? If you open the re-encoded version with MKVMergeGUI, or with MeGUI's MKV/MP4 muxer and resave it, does the saved version play better using MPC-HC?

- Yes, I am outputting it directly to MKV and again, yes, I'm trying to play it without remuxing it. But even after remuxing the whole thing using MKVMergueGUI, as you move the cursor using MPC-HC, there's still a delay (BUT not as long as before) when playing the desired position.

I doubt the settings you're using are the problem, but are you using AVCHD as the target playback device for a particular reason?

- Since the "master file" was encoded this way @High Profile, Level 4.1 ACVHD, Bitrate 14,000) I was just trying to keep the same settings and quality.

If you're not creating AVCHD complaint video and just converting to MKV or MP4 etc to play the encodes via USB, none of that Bluray compatibility stuff is necessary. Even if you're using a Bluray player. Via USB, support for High Profile, Level 4.1 is pretty standard. Selecting DXVA as the target playback device should do.

-That's my case (play the encoded version via USB). Thanks for suggesting DXVA as the target playback. Will it work great? I had chosen before PS3 and Xbox360 and got a file full of blocks. That's why I've chosen AVCHD (also to keep the same original file config).

Now, about your second response (and thanks for that)...

Plus by defaut, MPC-HC seeks to the nearest keyframe, so it doesn't do any of the "decoding around the seek point" stuff. It just jumps to the nearest keyframe. The setting to enable/disable that is under Options/Tweaks and it's labelled "fast seek". I disable it myself, but enabled it shouldn't slow seeking down by much at all. PPS. For MediaInfo, try selecting View/HTML or View/Text. You're only seeing the bare minimum of info with the default view. PPPS. The stuff under V.U.I in the x264 encoder configuration doesn't change the way the video is encoded, it just causes x264 to write info to the video stream. Unless you understand it, it's probably best just to leave it all at the default settings.

- Thanks for all the tips. Enabling the MPC-HC option "fast seek" seems to do the trick I'll try to encode the file once again choosing DXVA (it takes a long time to encode it - last time it took 16 hours). Finally, heere's MediaInfo info (the way you have suggested) - thanks again and please keep in touch

Cheers!
Mark

Original Master File

General
Unique ID : 242460461513684540577714514517439102934 (0xB6682FB2665B5EB3ADA9B65D34B53FD6)
Complete name : C:\my_movie_master.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 11.5 GiB
Duration : 1h 57mn
Overall bit rate mode : Variable
Overall bit rate : 14.0 Mbps
Encoded date : UTC 2014-03-29 12:46:37
Writing application : mkvmerge v6.8.0 ('Theme for Great Cities') 32bit built on Mar 2 2014 21:27:07
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 57mn
Bit rate mode : Variable
Bit rate : 14.0 Mbps
Maximum bit rate : 30.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.282
Stream size : 11.3 GiB (98%)
Writing library : x264 core 133 r2334 a3ac64b
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=1 / keyint=24 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 / bitrate=14020 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=30000 / vbv_bufsize=30000 / nal_hrd=vbr / ip_ratio=1.10 / aq=1:1.00
Default : Yes
Forced : No


My file
General
Unique ID : 250564475346279522991141975024116182823 (0xBC80F66D68037F389311FF0DF4C82F27)
Complete name : C:\Documents and Settings\Marco\Desktop\my_movie_cropped.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 11.6 GiB
Duration : 1h 57mn
Overall bit rate mode : Variable
Overall bit rate : 14.1 Mbps
Encoded date : UTC 2014-03-31 19:37:44
Writing application : mkvmerge v6.8.0 ('Theme for Great Cities') 32bit built on Mar 2 2014 21:27:07
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 57mn
Bit rate mode : Variable
Bit rate : 13.2 Mbps
Nominal bit rate : 14.0 Mbps
Maximum bit rate : 14.0 Mbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.358
Stream size : 10.8 GiB (93%)
Writing library : x264 core 138 r2358 9e941d1
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=240 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=14000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=14000 / vbv_bufsize=14000 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 1h 57mn
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 538 MiB (5%)
Language : English
Default : Yes
Forced : No

Menu
00:00:00.000 : en:00:00:00.000
00:02:58.177 : en:00:02:58.177
00:04:31.980 : en:00:04:31.980
00:07:26.112 : en:00:07:26.112
00:11:18.260 : en:00:11:18.260
00:12:58.569 : en:00:12:58.569
00:16:58.183 : en:00:16:58.183
00:22:38.815 : en:00:22:38.815
00:25:04.878 : en:00:25:04.878
00:27:58.343 : en:00:27:58.343
00:30:21.486 : en:00:30:21.486
00:36:19.177 : en:00:36:19.177
00:41:30.321 : en:00:41:30.321
00:42:23.999 : en:00:42:23.999
00:45:56.336 : en:00:45:56.336
00:48:44.463 : en:00:48:44.463
00:55:18.898 : en:00:55:18.898
00:57:27.277 : en:00:57:27.277
00:59:44.998 : en:00:59:44.998
01:01:49.414 : en:01:01:49.414
01:03:18.002 : en:01:03:18.002
01:07:44.393 : en:01:07:44.393
01:12:39.521 : en:01:12:39.521
01:16:13.527 : en:01:16:13.527
01:20:12.474 : en:01:20:12.474
01:22:34.532 : en:01:22:34.532
01:27:07.513 : en:01:27:07.513
01:28:45.236 : en:01:28:45.236
01:34:02.219 : en:01:34:02.219
01:36:54.308 : en:01:36:54.308
01:41:12.316 : en:01:41:12.316
01:42:37.276 : en:01:42:37.276
01:44:31.807 : en:01:44:31.807
01:45:56.266 : en:01:45:56.266
01:49:04.496 : en:01:49:04.496
01:52:21.734 : en:01:52:21.734
01:57:36.591 : en:01:57:36.591

[LigH.de]

As suspected...

Original: keyint=24
Copy: keyint=240

[hello_hello]

Yes, I am outputting it directly to MKV and again, yes, I'm trying to play it without remuxing it. But even after remuxing the whole thing using MKVMergueGUI, as you move the cursor using MPC-HC, there's still a delay (BUT not as long as before) when playing the desired position.

How much of a delay are we talking about? For me, once the MKV has been remuxed, even with "fast seek" disabled, it's usually very small. Under 1 second. A little longer does happen at times, but probably not by much.

Edit: I just happened to be watching a 1080p video so I tested it, and at that resolution, the delay in seeking probably averaged somewhere between almost none and two seconds using MPC-HC, with "fast seek" disabled. That wasn't a particularly high bitrate video. I guess I'm just used to the slight delay and don't think about it.

Since the "master file" was encoded this way @High Profile, Level 4.1 ACVHD, Bitrate 14,000) I was just trying to keep the same settings and quality.

There's no need to do that as such. The encoder just sees uncompressed video which it re-compresses. There's no point duplicating the settings used when encoding the original file unless they're the settings you want to use.
The "master" wasn't encoded using any type of ACVHD setting. You might be confusing the average bitrate and VBV settings. The bitrate you specify is just an average bitrate, which varies considerably. The VBV settings limit it (they actually apply limits to the decoding buffer).
http://mewiki.project357.com/wiki/X264_Settings#vbv-maxrate

That's my case (play the encoded version via USB). Thanks for suggesting DXVA as the target playback. Will it work great? I had chosen before PS3 and Xbox360 and got a file full of blocks. That's why I've chosen AVCHD (also to keep the same original file config).

I've not met a TV with a built-in media player or a Bluray player which won't play High Profile, Level 4.1 using the default settings (in MP4 or MKV). No Bluray compatibility required. My other half has an old Sony S360 (I think) Bluray player. It doesn't even have a USB input, but it'll play my encoded MKV/MP4 files if I burn them to disc. I pretty much always use CRF (quality) based encoding myself. Unless you need a particular file size for some reason, it's probably the better way to do it. That way, quality relative to the original should be the same each time (for a given CRF value). File sizes will vary quite a bit. I just select a CRF value, an appropriate tuning and the slowest speed preset I can stand (usually just Medium or Slow in my case) and encode that way. My MeGUI command line (in the x264 encoder configuration) would generally just look like this:

program --level 4.1 --preset slow --tune film --crf 18.0 --vbv-bufsize 78125 --vbv-maxrate 62500 --output "output" "input"

If you wanted to be paranoid about something, you could probably pick the VBV values. I recently tested my Samsung TV's media player and my Sony Bluray player while re-encoding a video with an unusually high bitrate (it had sections at 100,000kbps). I re-encoded it using a low CRF value to increase the average bitrate a bit ,while applying various VBV settings. The Sony Bluray player didn't seem to care and happily played the original file. The Samsung TV stuttered until I re-encoded it using --vbv-bufsize 58000 --vbv-maxrate 58000. Normally bitrates wouldn't get that high anyway, but the "worst case scenario" might be to use the "DivX HD" target playback device settings:

--level 4.0 --vbv-bufsize 25000 --vbv-maxrate 20000

I don't bother myself, but I know some people use lower VBV settings to make sure the bitrates don't get too high for some devices. Something like this (they're the VBV values displayed by MediaInfo for your "original" video):

--level 4.1 --vbv-bufsize 30000 --vbv-maxrate 30000

For Bluray I think it's officially --vbv-bufsize 30000 and --vbv-maxrate 40000

Thanks for all the tips. Enabling the MPC-HC option "fast seek" seems to do the trick I'll try to encode the file once again choosing DXVA (it takes a long time to encode it - last time it took 16 hours)

There's no need to encode the whole thing just to test it. Once you've created a script, open it with the AVS Cutter under the Tools menu. Set your start and end points for encoding (or multiple start and end points if you want to). Save the "cuts" to the script. You can also save a "cuts file" to load into the audio section so it's encoded to match. Or the Audio Cutter under the Tools menu can use the cuts file to split and rejoin the audio without re-encoding it. Anyway.... using the AVS cutter you can encode just a minute or so of the video for playback testing. No need to encode the whole thing each time.

PS From the MediaInfo stuff you posted your original video has an average bitrate of 14000kbps and a maximum bitrate of 30000kbps. When you re-encoded it, it appears your VBV settings limited the maximum bitrate to around 14000kbps. You also specified 14000kbps as the average bitrate in the x264 encoder configuration. As a result, the VBV settings seem to have caused the final average bitrate to end up at around 13200kbps. Instead of the bitrate being able to vary a fair bit, you've squished it down to something closer to a constant bitrate. The bitrate needs to vary as required for a consistent quality, so use the VBV settings a little less enthusiastically Or don't use AVCHD as the target playback device.

[hello_hello]

As suspected...

Original: keyint=24
Copy: keyint=240

I thought that was a little odd so I ran a few quick test encodes.
Turns out --bluray-compat reduces --keyint_min to 1 but doesn't change the --keyint value. I'm not sure why.....

When you select Bluray as the target playback device, MeGUI adds the following to the commandline.
Behind the scenes it changes --keyint to 24, 25, or 30 etc, depending on the frame rate.

--level 4.1 --bluray-compat --open-gop --slices 4 --vbv-bufsize 30000 --vbv-maxrate 40000

Some of those settings do seem to have an effect on compressibility, especially --keyint. My three little test encodes, CRF18 each time:

With just --bluray-compat in the commandline: 5.4MB file size.
With Bluray as the target playback device: 6.8MB file size.
Default x264 settings: 5.3MB file size.

It was only standard definition video and the average bitrates were under 1000kbps, so the VBV settings wouldn't have made any difference.

[Cunhambebe]

Thanks again you guys, but really, I guess I have missed something.

As suspected...
Original: keyint=24
Copy: keyint=240

So what? What can I do to change that value to 24? Is there any way to do that?

BTW, I have modified the AViSynth script adding Trim(0,8700) so this way render times were reduced for testing purposes. Without modifying anything at all but only targeting AVCHD and DXVA, and lowering the bitrate to 1970, I got files with the same size, excellent quality but same results described in the beginning of this topic (delay to reach parts of the movie when watching with MPC-HC). So where do I wind up with this?

Thanks in advance.

[LigH.de]

@ hello_hello:

The parameter "--bluray-compat" handles several basic options, but there are also more parameters one has to add to a complete command line to make the result really Blu-ray compatible, like VBV and GOP limits. There are constraints related to the VBV and Profile@Level if a maximum of 1 or 2 seconds per GOP is allowed; x264 is probably unable to consider them in every case, especially if not all parameters required to calculate these constraints are explicitly given.

@ Cunhambebe:

MeGUI - x264 configuration dialog, tab "Frame-Type", control group "GOP size"

[hello_hello]

Thanks again you guys, but really, I guess I have missed something.

As suspected...
Original: keyint=24
Copy: keyint=240

So what? What can I do to change that value to 24? Is there any way to do that?

BTW, I have modified the AViSynth script adding Trim(0,8700) so this way render times were reduced for testing purposes. Without modifying anything at all but only targeting AVCHD and DXVA, and lowering the bitrate to 1970, I got files with the same size, excellent quality but same results described in the beginning of this topic (delay to reach parts of the movie when watching with MPC-HC). So where do I wind up with this?

Thanks in advance.

I wouldn't change the GOP parameters (keyint values). The keyint values are set by the GOP parameters in MeGUI's configuration. You'll see MeGUI adding keyint values to the commandline when you change the GOP settings. You'll probably also need to change the GOP calculation setting to "fixed" if you want to set it yourself.

The way x264 works by default, it generally puts a keyframe at the beginning of a scene change. The maximum distance to the next keyframe is ten seconds. --keyint 240, or --keyint 250 etc, depending on the frame rate (24 or 25 frames per second etc). The beginning of a scene is a good place to put them. If you force the encoder to use a keyframe every second you'll effect how efficiently it can compress the video. For a given bitrate it'll probably reduce the quality. For a given CRF value it'll increase the file size. Whether it's a quality difference you can see is another story.... it probably depends on the bitrate/quality being used.

What I wrote in an earlier post was wrong (I've corrected it). --bluray-compat own it's own doesn't reduce the maximum GOP size. Selecting Bluray as the target playback device will cause MeGUI to reduce it according to the bitrate (--keyint 24 or --keyint 25 etc). You won't see it in the commandline in the x264 encoder configuration, but you'll see it when displaying the encoder settings with MediaInfo.

How long is this seeking delay you're referring to? If it's just a second or two, it's a small price to pay for more efficient compression. If you enable "fast seek" in MPC-HC, then seeking will be virtually instantaneous anyway.
As I said (added) to my earlier post. I tested a 1080p video and seeking delay seemed to be anywhere between almost nothing and a couple of seconds with fast seek disabled. I'm so used to it I don't even notice.

[Cunhambebe]

Thanks again for taking time to respond.
I found out this at Wikibooks:

keyint Integer: 250 (...) Lower settings can reduce the time needed to seek to a certain frame. Recommendation: Default, or 10x whatever your framerate is. On HD encodes which will be CPU challenging you may want to use smaller values (say 2x - 5x fps).

-Great! I guess 24 would do the trick (since the video is at 23,976) - I'll try the same value here as the one shown for the "master file".

min-keyint Integer: 25 Sets the minimum length between IDR frames. See keyint for an explanation of IDR frames. Very small IDR ranges can reduce 'incorrect' frame placement (for example, a strobing scene). This option limits the minimum length after each IDR frame before another can be placed. Recommendation: Default, or whatever your framerate is.

-I have chosen default and encoded again a new test file. The result is great. The problem is gone. Now you can move the cursor and reach the chosen part of the movie with no delay at all.

Here's the guide:


Now let's see what MediaInfo says:

General
Complete name : C:\my_movue_test_2.mkv
Format : Matroska
Format version : Version 2
File size : 382 MiB
Duration : 6mn 2s
Overall bit rate mode : Variable
Overall bit rate : 8 837 Kbps
Writing application : x264 r2358 9e941d1
Writing library : Haali Matroska Writer b0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 6mn 2s
Bit rate mode : Variable
Bit rate : 8 661 Kbps
Nominal bit rate : 14.0 Mbps
Maximum bit rate : 14.0 Mbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.235
Stream size : 375 MiB (98%)
Writing library : x264 core 138 r2358 9e941d1
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=1 / keyint=23 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=23 / rc=2pass / mbtree=1 / bitrate=14000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=14000 / vbv_bufsize=14000 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No

Conclusion: maybe MEGUI needs to be fixed because the values seems not to be the same as the chosen ones. Anyway, it works, would only like to know if other x264 GUIs have the same "problem" if it is a real problem.

Thanks you guys...
Cheers
Mark

PS: to hello_hello: I didn't see your answer as I was typing my response. Thanks for your help.

How long is this seeking delay you're referring to? If it's just a second or two, it's a small price to pay for more efficient compression. If you enable "fast seek" in MPC-HC, then seeking will be virtually instantaneous anyway.

-How long? Just a couple of seconds using MPC-HC. Anyway, I guess you're right, since the file plays very well on my Full HD TV, but what would you do? Would you leave it the way it is (keyint 240; keyint min. 1) or change those values? Thanks in advance. Please I would like to know your advice.

[hello_hello]

keyint Integer: 250 (...) Lower settings can reduce the time needed to seek to a certain frame. Recommendation: Default, or 10x whatever your framerate is. On HD encodes which will be CPU challenging you may want to use smaller values (say 2x - 5x fps).

-Great! I guess 24 would do the trick (since the video is at 23,976) - I'll try the same value here as the one shown for the "master file".

The recommended setting is the default of keyint 250 or 10x the frame rate. 24fps x 10 = 240

min-keyint Integer: 25 Sets the minimum length between IDR frames. See keyint for an explanation of IDR frames. Very small IDR ranges can reduce 'incorrect' frame placement (for example, a strobing scene). This option limits the minimum length after each IDR frame before another can be placed. Recommendation: Default, or whatever your framerate is.

-I have chosen default and encoded again a new test file. The result is great. The problem is gone. Now you can move the cursor and reach the chosen part of the movie with no delay at all.

Here's the guide:

[Attachment 24358 - Click to enlarge]

That's not the default. Not to mention, you've set the minimum GOP size to 25 and the maximum to 24.

I explained the idea behind having a maximum keyint of 250 in a previous post. The idea of having a minimum of 25 would be to stop x264 from using a lot of keyframes in a very short space of time because it's detecting scene changes (for example, a strobing scene). I think you're misinterpreting the wiki. It says in the part you quoted the recommended keyint_min setting is the same as the frame rate. There's a reason why keyint=240/250 and keyint_min=25/24 are the defaults.

Now let's see what MediaInfo says:

keyint=23 / keyint_min=1

Conclusion: maybe MEGUI needs to be fixed because the values seems not to be the same as the chosen ones. Anyway, it works, would only like to know if other x264 GUIs have the same "problem" if it is a real problem.

You selected keyint=24 and keyint_min=25 which doesn't really make any sense and you ended up with keyint=23 and keyint_min=1 which is at least logical. It looks like you're still using the AVCHD preset which is why you got the keyframe settings you did.
x264 seems to automatically set keyint_min=1 when you use --bluray-compat, and you selected --keyint=24 yourself. MeGUI may have changed it to 23 because of the GOP "FPS Based" setting. Hover your mouse over it and read the tooltip.

-How long? Just a couple of seconds using MPC-HC. Anyway, I guess you're right, since the file plays very well on my Full HD TV, but what would you do? Would you leave it the way it is (keyint 240; keyint min. 1) or change those values? Thanks in advance. Please I would like to know your advice.

I don't touch the default keyint settings myself. I leave them and the result is keyint=250/240 and keyint_min=25/24 etc, depending on the frame rate (keyint=24 and keyint_min=1 are not the x264 defaults, they're only the defaults for Bluray and AVCHD). With fast seeking disabled in MPC-HC there's a slight seeking delay using keyint=250/240 and keyint_min=25/24. If it bothers you, why not just enable fast seeking?
Did you read the info in my earlier post regarding the VBV values you're using? I'd get rid of them (I think I edited the post to add it to the end so maybe you missed it.... post #8).

[Cunhambebe]

Thanks hello_hello.

The recommended setting is the default of keyint 250 or 10x the frame rate. 24fps x 10 = 240. (...) I think you're misinterpreting the wiki.

- I know that. You are absolutely right. I was just testing using the same AVCHD profile. I've set those values after reading what MediaInfo said about another MKV file.

Not to mention, you've set the minimum GOP size to 25 and the maximum to 24.

- At least the minimum is correct (I've read the tooltip).

I don't touch the default keyint settings myself. I leave them and the result is keyint=250/240 and keyint_min=25/24 etc, depending on the frame rate (keyint=24 and keyint_min=1 are not the x264 defaults, they're only the defaults for Bluray and AVCHD). With fast seeking disabled in MPC-HC there's a slight seeking delay using keyint=250/240 and keyint_min=25/24. If it bothers you, why not just enable fast seeking?

-You're right again. I'll start encoding using 2 profiles (bitrate: 1970 or above):
1) AVCHD and leaving all that stuff as default ,or;
2) DXVA, setting keyint=240 and keint_min=24 (for those 23,976 sources), leaving bluray-compat unchecked and as you have mentioned, getting rid of those VBV values.
I'll encode a couple of files tomorrow and post the results back here as soon as possible. Thanks so much for your help.

PS:

Did you read the info in my earlier post regarding the VBV values you're using? I'd get rid of them (I think I edited the post to add it to the end so maybe you missed it.... post #8).

-No, I didn't because I was typing my response. Thanks for those tips.
The first time is always difficult, but I'll get it.

I hope you understand I'm not a total newbie. I've been encoding MPEG2 and XVID (this one not anymore) for almost 10 years but x264 seems a bit more tricky.

For instance, when you mention the given bitrate at post #8, that it needs to vary when using VBV settings (between a maximum and an average value), I already know that because the same happens with MPEG2.

But maybe because of x264 profiles (AVCHD), after setting a certain bitrate (example, 30,000) that according to the proggie would be the average, I can't change the values for Buffer size and Maximum bitrate since a value of 14,000 seems to be already given (in this particular case). What can only be done is to decrease it but not the contrary.

What I'm trying to say is that I'm a bit confused with those settings and I am still trying to figure out the relation between those profiles (being Blu-Ray or not; CBR/VBR) and possibility to increase / decrease bitrates. Another example, choosing DXVA, you can set an average bitrate of 14000 and on the Rate Control Guide, set a maximum value of 30,000. That makes sense, but then the CBR and VBR are gone since they are only Blu-Ray. I know it is not that difficult. I'll keep trying it.

Thanks so much. Cheers!

[hello_hello]

2) DXVA, setting keyint=240 and keint_min=24 (for those 23,976 sources), leaving bluray-compat unchecked and as you have mentioned, getting rid of those VBV values.

If you leave the GOP settings as the defaults in the MeGUI encoder configuration. Without --bluray-compat, MeGUI will set the GOP parameters according to the frame rate. keyint should always be 10 times the frame rate.
For high frame rate video (ie 50fps or 60fps) you'll end up with keyint=500 or keyint=600 etc. If that causes seeking to be too slow or gives you problems with a standalone player you might want to limit it to something like 250 yourself. I think you'd need to change the GOP Calculation setting to "Fixed". Either that or leave it on "FPS Based" and set the maximum to 125 and minimum to 12. I think that'll halve the keint setting for a given frame rate, based on the formula MeGUI uses to calculate it.

If you set max GOP to 125 for 60 fps video, MeGUI should calculate it this way ("FPS Based" GOP calculation enabled):
125/25 x 60fps = keyint 300.
If you set min GOP to 12 for 60fps video:
12/25 x 60fps = keyint_min 28.

To be honest that's something I'd not thought about myself until now. I just checked a few 50fps encodes and they all used keyint=500 and keyint_min=50. I've had no problem playing them using MPC-HC, which I guess is why I hadn't thought about it before. I'm pretty sure I've used the media player in the TV to play some of them and didn't have a problem. I'll test one shortly just to make sure.
Thinking about it, that might help explain why when I de-interlace to 50fps the resulting file size for a given CRF value isn't all that much larger then if I de-interlace the same video to 25fps. For the former the max/min GOP sizes are doubled, so even though it has twice as many frames, it'd still have a similar number of keyframes.
Now you've got me wondering about it I'll have to run a test encode at 50fps while reducing the keyint settings to 250 and 25, just to see how much difference it makes.....

[LigH.de]

Well, actually, a GOP of ~10 seconds used to be a convenient value, but there is no need to have a different maximum for every frame rate. Longer GOPs compress better. Shorter GOPs seek better. There is no really relevant relation to the framerate.

Furthermore, the minimum GOP length cannot be longer than the maximum. It doesn't make sense. Use your imagination to select sensible values. The lookahead should be able to spread GOPs between scene changes.

[hello_hello]

I know using keyint=25 and keyint_min=1 decreases compressibility compared to keyint=250 and keyint_min=25, but I ran a couple of test encodes while de-interlacing to 50fps to see what sort of difference a larger GOP would make. The video in question was just an episode of a TV series off a DVD. Same encoder settings (aside from keyint) and CRF value each time.

keyint=250 and keyint_min=25 gave me an output file size of 506.8MB
keyint=500 and keyint_min=50 gave me an output file size of 501.0MB

I guess after a certain point, increasing GOP size provides diminishing returns.
I'd been using keyint=500 and keyint_min=50 simply because that's what MeGUI set for 50fps without me interfering (ie without me having thought about it). I think from now on I might keep the settings fixed at keyint=250 and keyint_min=25 for everything. I'll have to think about that one.....

[Selur]

I guess after a certain point, increasing GOP size provides diminishing returns.

a. crf isn't a good choice for comparisons since it changes the way it works when other setting change (2pass or 1pass constant quantizer or normally better choices)
b. the gain and loss of using larger or smaller GOPs depends a lot on the choice of material and (assuming closed GOPs are used) ten times the fps seemed to be a good choice for the average content

[Cunhambebe]

You see guys.. it is a little tricky. Now I don't know if it's MEGUI or the Codec itself. For instance, back to the AVCHD profile, it doesn't do any good to choose any figure for the bitrate on the Main Guide since on Rate Control Guide, VBV Buffer Size and VBV Maximum bitrate values are always set to 14000. You can never increase them, but you can decrease them. So this might clear to hello_hello his remarks on the values I have chosen for the bitrate (at the end of post #8).

[hello_hello]

So this might clear to hello_hello his remarks on the values I have chosen for the bitrate (at the end of post #8).

Not really.
Normally the bitrate would be variable, the VBV settings are ways of limiting it to stop it getting too high. It's so the video can be decoded without stuttering when using a particular device. You'd set the VBV restrictions according to the device.

Another example, choosing DXVA, you can set an average bitrate of 14000 and on the Rate Control Guide, set a maximum value of 30,000. That makes sense, but then the CBR and VBR are gone since they are only Blu-Ray. I know it is not that difficult. I'll keep trying it.

I'm not sure what you mean by "then the CBR and VBR are gone since they are only Blu-Ray".
If you're referring to the stuff under "Bluray" such as "HRD Info" etc in the encoder configuration, that's nothing to do with the bitrate being variable as such. They're just parameters which need to be set when encoding for Bluray. If you're not trying to make a compliant Bluray video disc, then you don't need to worry about them. If you are, check the Bluray compatibility option or use Bluray as the target playback device.

You see guys.. it is a little tricky. Now I don't know if it's MEGUI or the Codec itself. For instance, back to the AVCHD profile, it doesn't do any good to choose any figure for the bitrate on the Main Guide since on Rate Control Guide, VBV Buffer Size and VBV Maximum bitrate values are always set to 14000. You can never increase them, but you can decrease them. So this might clear to hello_hello his remarks on the values I have chosen for the bitrate (at the end of post #8).

If you select AVCHD as the profile, MeGUI automatically sets the VBV restrictions required for AVCHD. It won't let you increase them in the GUI because they're the restrictions required. The same applies to setting other target playback devices. If you need higher VBV restrictions then the AVCHD profile can't be what you want.
You can over-ride (increase) the VBV restrictions MeGUI automatically uses if you manually choose the AVC profile and level (ie High Profile, Level 3.2 etc) but you can't over-ride them when a target playback device is selected, because it'd defeat the purpose of selecting a target playback device. When a target playback device is selected you can reduce them, but not increase them.

If you're just encoding to create MKV or MP4 files, choose DXVA as the target playback device, (or select High Profile, Level 4.1 as that's all DXVA does) and pick a tuning, speed preset and bitrate (well choosing a quality would be better, but pick a bitrate instead if you need to). Don't worry about the advanced settings.
If you want to make sure your encodes are playable using older players you could use a lower AVC level. If you went down to Level 3.1 your encodes should be playable using pretty much any standalone player. I wouldn't bother myself as my players all cope with Level 4.1. Or you could pick an older device from the target playback device list if you're likely to use one to play your encodes.
Other than that.... well I just stick with High Profile Level 4.1 and an appropriate x264 speed preset and tuning.

[Cunhambebe]

If you're just encoding to create MKV or MP4 files, choose DXVA as the target playback device, (or select High Profile, Level 4.1 as that's all DXVA does) and pick a tuning, speed preset and bitrate (well choosing a quality would be better, but pick a bitrate instead if you need to). Don't worry about the advanced settings.

-Thanks for you help. I understand. Otherwise I'll leave the whole thing exactly as it was at the very beginning of this thread; who'd bother with a little delay on MPC-HC? I hope you understand I'm not an advanced x264 user as you are, but I'd like you to know that it doesn't matter how many times I try and change the settings, I never get values such as 240 and 24 respectively for keyint and keyint_min. I mean, the figures obtained at the end of the encoding process seem to be given at random such as 230, 23, etc, but never the same settings configured.

Thanks for your help.
Cheers!

[hello_hello]

It's all a learning process. You don't learn if you don't ask. One of the reasons I post here is even when I'm answering a question I often learn something as a result.

If you select "fixed" for the GOP calculation, MeGUI should give you the exact max and min GOP sizes you specify. Well if you don't specify a minimum other than 25, MeGUI doesn't add keyint_min to the commandline so x264 probably decides on the minimum setting based on the frame rate. It seems to round down (if memory serves me correctly) so a frame rate of 23.976 would probably give you keyint_min=23.

If you leave the GOP calculation setting on "FPS based" MeGUI uses a formula to calculate the max and min settings. If you change them it means you probably won't get what you asked for. The values you specify are used in the formula instead. Hover the mouse over the GOP calculation area and the Tooltip should explain it.

If you want to specify exact max and min keyint values without MeGUI or x264 making any decisions, you can add them to the custom commandline in the x264 encoder configuration, under the miscellaneous tab. Whatever you put there should be used. Add them like this:

--keyint 268 --min-keyint 31

When you do they should appear in the commandline section at the bottom of the x264 encoder configuration window, over-riding anything set in the GUI. The only exception might be when using a target playback device which requires different keyint values. MeGUI might ignore what you add to the commandline in some cases.



I'd just leave it at the defaults. You should end up with a keyint value of 10x the frame rate and a keyint_min value the same as the frame rate, give or take.... I guess it depends how it's rounded when it's calculated.

[Cunhambebe]

HI hello_hello and thanks again for your help.

It's all a learning process. You don't learn if you don't ask. One of the reasons I post here is even when I'm answering a question I often learn something as a result.

- I agree. But since you had remarked to leave all the config. the way it was, I thought that'd be a good idea not to change anything on those guides. Anyway, thanks so much for the screenshot AND to tell me that I could edit the command line there or at the bottom of the guides. Now I fully understand (a little lololol) what I have to do. Here's what's MediaInfo says about my last encoding yesterday night:

General
Unique ID : 230679402189765957777408967831128830078 (0xAD8B3CA06FA8D6A98FF61EDB8AA2F07E)
Complete name : C:\Documents and Settings\Marco\Desktop\my_video.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 638 MiB
Duration : 40mn 59s
Overall bit rate mode : Variable
Overall bit rate : 2 174 Kbps
Encoded date : UTC 2014-04-06 23:03:43
Writing application : mkvmerge v6.8.0 ('Theme for Great Cities') 32bit built on Mar 2 2014 21:27:07
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 40mn 59s
Bit rate mode : Variable
Nominal bit rate : 1 980 Kbps
Maximum bit rate : 8 500 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.090
Writing library : x264 core 138 r2358 9e941d1
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=240 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=1980 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=8500 / vbv_bufsize=20000 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No


As you can notice it, values for keyint and keyint_min are respectively 240 and 1 (I hadn't changed anything, that means both were respectively the default: 250 and 25). I guess MEGUI and X264 corrected them. Changing those figures to 240 and 24 (my video is 23,976 FPS), because of the formula you've mentioned, would give me weird results such as 230 and 1.

I agree that the learning curve is difficult, even though it is very compelling. I would like to thank you again for your help and being so patient. Now let's see if I learn how to edit the command line at the bottom of the guides, I guess that's much better (or using DOS - nah lolol).

Cheers,
Mark

[hello_hello]

You ended up with keyint_min=1 because you used bluray_compat=1. When you use bluray_compat it forces x264 to use particular settings and it'll probably ignore anything different. I'm not sure why you're still using it. Here's what bluray_compat=1 does:

--bluray-compat

- min-CR + level 4.1 hack
- Special b-pyramid SEI
- B-frames cannot reference frames outside their minigop
- Open-GOP keyframe interval hack

renders '--open-gop' parameters obsolete:
- now: --bluray-compat + --open-gop <> old version: --open-gop bluray
- now: --open-gop without --bluray-compat <> old version: --open-gop cbrHD

enforces:
- aud=1 (-> not needed in the command line when using '--bluray-compat')

restricts:
- nalhrd to >= vbr (-> not needed in the command line when using '--bluray-compat')
- bframes to: 3 or less
- bpyramid to: strict or none
- max references to: 6 or less
- weightp to: 1 or 0

http://mewiki.project357.com/wiki/X264_Settings#bluray-compat

vbv_maxrate=8500 and vbv_bufsize=20000 seem a bit unusual. How did you decide on those?

[Cunhambebe]

Hi there. I've decided checking blu-ray thinking about compatibility. Maybe it is my stubborn stupidity. About the bitrate I've decided myself, since 20000 seemed to be enough; same for 8500, even though I guess 3200 for a fixed bitrate would be more than enough. Anyway, what do you think of copying what MediaInfo says on any other "successfully compressed file" and pasting on that screen at the bottom of x264's guide? Would that make a good new profile? Thanks in advance!
Mark

[LigH.de]

VBV limits are not the average bitrate over the whole playtime, they are neither the absolute maximum bitrate over one whole GOP. These values are based on the decoder speed and the decoding buffer size, so you really have to know hardware specifications to select matching values.

Entering values below the hardware limits may lead to more compatible results. But it will certainly reduce the available quality. And I would not try to guess other side effects.

[hello_hello]

--bluray-compat doesn't set everything required for 100% Bluray compatibility. Selecting Bluray as the target playback device does.

About the bitrate I've decided myself, since 20000 seemed to be enough; same for 8500, even though I guess 3200 for a fixed bitrate would be more than enough

How you pull those bitrates out of thin air, I'm not sure. Do they apply regardless of resolution and quality of the video?
I pretty much always use CRF encoding myself, so the average bitrate varies quite bit in order to produce the same quality each time, but I checked a couple of recent 720p encodes with Bitrate Viewer and they had peak bitrates ranging from around 15000kbps to 40000kbps. My last DVD encode had an average bitrate of a little over 3000kbps.

Anyway, what do you think of copying what MediaInfo says on any other "successfully compressed file" and pasting on that screen at the bottom of x264's guide? Would that make a good new profile?

If you're referring to pasting it into MeGUI's command line section for the x264 encoder configuration, it wouldn't work.

[Cunhambebe]

Hi

LigH.de

Re: MEGUI + x264 settings
VBV limits are not the average bitrate over the whole playtime, they are neither the absolute maximum bitrate over one whole GOP. These values are based on the decoder speed and the decoding buffer size, so you really have to know hardware specifications to select matching values.

Entering values below the hardware limits may lead to more compatible results. But it will certainly reduce the available quality. And I would not try to guess other side effects.

-Thank you for your explanation. I may leave the values the way they are.

hello_hello

Re: MEGUI + x264 settings
--bluray-compat doesn't set everything required for 100% Bluray compatibility. Selecting Bluray as the target playback device does.

-Thanks again, buddy.

How you pull those bitrates out of thin air, I'm not sure. Do they apply regardless of resolution and quality of the video?

-I guess so. Video is 1280x720. I guess that bitrate would be enough, even though videos encoded at a bitrate of 3200 seem perfect. If I'm wrong, please tell me the right way to do it (calculating it). Thanks.

I pretty much always use CRF encoding myself, so the average bitrate varies quite bit in order to produce the same quality each time, but I checked a couple of recent 720p encodes with Bitrate Viewer and they had peak bitrates ranging from around 15000kbps to 40000kbps. My last DVD encode had an average bitrate of a little over 3000kbps.

- I as have remarked it right above, 3000 seems to be enough. About CRF or Constant Ratefactor (on the Rate Control Guide), where do you configure it, please?

If you're referring to pasting it into MeGUI's command line section for the x264 encoder configuration, it wouldn't work.

-What a pity, isn't it! BTW, if possible, could you please leave here some configuration options you use? For compatibility, size and quality (720 and 1080)? Thanks in advance!

Cheers

[hello_hello]

BTW, if possible, could you please leave here some configuration options you use? For compatibility, size and quality (720 and 1080)? Thanks in advance!Cheers

If you open MeGUI's x264 encoder configuration, load the defaults, select the Slow speed peset, Tune Film, a Target Quality of 18 (CRF18) and DXVA as the target playback device, you'll have the settings I use.

About CRF or Constant Ratefactor (on the Rate Control Guide), where do you configure it, please?

CRF is the "target quality" or "constant quality" encoding mode in MeGUI's x264 encoder configuration.

No two videos can be compressed by the same amount so it's hard to pick a "one size fits all" bitrate. I just finished re-encoding a bunch of episodes of a TV show at 720p. Fairly clean, easy to compress video, not a lot of action. The final file sizes were very similar with average bitrates of around 2000kbps. An episode of a different TV show I encoded a couple of days ago had an average bitrate of around 3800kbps. The last 720p movie averaged 6900kbps. All using CRF18.

x264 has a true quality based encoding method so there's no need for 2 passes unless you need a particular bitrate. If you encoded a video using CRF18 (for example), made a note of the resulting bitrate, then used that bitrate for a 2 pass encode, the result would be virtually identical. So.....
2 pass encoding: you choose the bitrate and the quality is unknown.
CRF encoding: you choose the quality and the bitrate is unknown.

I prefer the quality based method while letting the file sizes be whatever they need to be. As a general rule I use CRF18 for 720p or lower and CRF20 for 1080p as they also give me file sizes I'm happy with, on average, but it's all personal preference.