Am I bottlenecked? x264 encoding

[Amaze]

So, I recently upgraded my CPU from R5 2600 to 3600X. I know it's not a massive upgrade but it has decent gains.
So I expected my encoding times to improve but they really didn't. I'm sitting at around 9-11 fps for the 2nd pass.

So this is what I do. I edit in Vegas Pro, then I frameserve it to Avisynth+. The only thing I do here is convert back to PC.709 and adjust the colors a bit:
avisource("d:\source.avi").convertToYV12(matrix="P C.709").Tweak(hue=0.0, sat=1.05, bright=1, cont=1.0, coring=false)

Then I open the script in MeGUI and convert to x264 with these settings:
--preset veryslow --pass 2 --bitrate 40000 --stats ".stats" --threads 12 --deblock -1:-1 --keyint 300 --bframes 2 --scenecut 60 --ref 6 --rc-lookahead 40 --merange 16 --partitions p8x8,b8x8,i8x8i4x4 --no-dct-decimate --no-fast-pskip --colormatrix bt709

I'm seeing ok CPU usage but with this type of workload I would expect it running at 100% load and it does not.

Any ideas on how I can find bottleneck and if there's anything I can do about it?

[jagabo]

What does "I would expect it running at 100% load and it does not" mean? 99 percent? 15 percent?

Try adding prefetch(6) to the end of your AviSynth script. Any improvement?

[KarMa]

If you are not get 100% usage with very slow then it's probably something to do with your avisynth chain, or something as simple as a decoding bottleneck.

I'm seeing ok CPU usage but with this type of workload I would expect it running at 100% load and it does not.

That doesn't tell me much other than it's not 100% usage.

[Amaze]

Yeah sorry that was really unspecific.
Here's a screenshot of usage after 90 secs into 2nd pass:

[Attachment 49796 - Click to enlarge]

What does "I would expect it running at 100% load and it does not" mean? 99 percent? 15 percent?

Try adding prefetch(6) to the end of your AviSynth script. Any improvement?

My first thought was Avisynth. Using this command doubled the speed on 1st pass. Every thread hitting 99-100%.
But 2nd pass still pretty low. Usage is basically the same as without Prefetch:

[Attachment 49797 - Click to enlarge]

FPS without Prefetch:
1s tpass, 29.28
2nd pass, 10.49

With Prefetch:
1st pass, 50,53
2nd pass, 10.50

[jagabo]

With the first pass running at 50 fps AviSynth and Vegas aren't the bottleneck*. The 3900X is a 6 core, 12 thread CPU. Try increasing the number of x264 threads to 18 (1.5x the number of CPU threads is the default for x264 for a reason).

* There's one possible exception I can see though: If your source is a long GOP codec out-of-order requests from x264 could cause Vegas to seek back and forth through the video, slowing it down.

[Amaze]

With the first pass running at 50 fps AviSynth and Vegas aren't the bottleneck*. The 3900X is a 6 core, 12 thread CPU. Try increasing the number of x264 threads to 18 (1.5x the number of CPU threads is the default for x264 for a reason).

It wouldn't let me go higher than 16. This did bump the fps to 11.89 and at least parts of the video saw near max usage on all threads while it still dipped quite low at times.

* There's one possible exception I can see though: If your source is a long GOP codec out-of-order requests from x264 could cause Vegas to seek back and forth through the video, slowing it down.

My source is video game footage recorded with the NVENC codec:

ID : 1 
Format : AVC 
Format/Info : Advanced Video Codec 
Format profile : High@L5.1 
Format settings : CABAC / 1 Ref Frames 
Format settings, CABAC : Yes 
Format settings, RefFrames : 1 frame 
Format settings, GOP : M=1, N=30 
Codec ID : avc1 
Codec ID/Info : Advanced Video Coding 
Duration : 17 min 25 s 
Source duration : 17 min 25 s 
Bit rate : 48.9 Mb/s 
Width : 2 560 pixels 
Height : 1 440 pixels 
Display aspect ratio : 16:9 
Frame rate mode : Variable 
Frame rate : 60.000 FPS 
Minimum frame rate : 50.392 FPS 
Maximum frame rate : 70.588 FPS 
Standard : PAL 
Color space : YUV 
Chroma subsampling : 4:2:0 
Bit depth : 8 bits 
Scan type : Progressive 
Bits/(Pixel*Frame) : 0.221 
Stream size : 5.95 GiB (100%) 
Source stream size : 5.95 GiB (100%) 
Title : VideoHandle 
Encoded date : UTC 2019-08-11 16:04:14 
Tagged date : UTC 2019-08-11 16:04:14 
Color range : Limited 
Color primaries : BT.601 NTSC 
Transfer characteristics : BT.470 System M 
Matrix coefficients : BT.601 
mdhd_Duration : 1045500 
Codec configuration box : avcC

[Atak_Snajpera]

Run multiple instances of x264 like I do

[jagabo]

Going up to 18 (or more) will probably get you a few percent better performance (and higher CPU usage). But it's hardly worth worrying about. FYI, on my quad core system going from 4 to 5 threads gets about 25 percent more performance. Going from 5 to 6 threads gets only an additional 5 percent.

I don't know why MeGUI limits you to 16 threads. I've used the x264 command line encoder with 64 threads (in testing, I only have a quad core CPU) without problems.

[Amaze]

Perhaps I should try the command line encoder. Can I make it use the .xml profile that I have saved with MeGUI?

[jagabo]

The options you gave in the first post are all native x264 CLI format. You just need to add source and output options.

x264 --preset veryslow --pass 2 --bitrate 40000 --stats ".stats" --threads 12 --deblock -1:-1 --keyint 300 --bframes 2 --scenecut 60 --ref 6 --rc-lookahead 40 --merange 16 --partitions p8x8,b8x8,i8x8i4x4 --no-dct-decimate --no-fast-pskip --colormatrix bt709 --output "OUTPUT.MKV" INPUT.AVS

[Amaze]

Yes of course

Got this error though, using the latest .exe
x264 [error]: not compiled with MP4 output support

So I tried changing it to .mkv and got this error:
avs [error]: AVISource: couldn't locate a decompressor for fourcc DFSC
(D:\Avisynth scripts\source.avs, line 5)
x264 [error]: could not open input file `D:\Avisynth scripts\source.avs'

[jagabo]

For the MP4 problem you just need to find a build with mp4 support. The problem is an AviSynth error, not an x264 error. AviSynth can't find a VFW decoder for the fourcc "DFSC". It's not likely that same command line would work with MeGUI. You must have changed something else in Vegas. Or maybe you used DirecShowSource() instead of AVISource() before. DirectShowSource() uses DirectShow codecs, AviSource uses VFW codecs.

[Amaze]

I've always used AviSource.

Changing to DirectShowSource gave this error:
avs [error]: DirectShowSource: Could not open as video or audio.

Video returned: "DirectShowSource: couldn't open file d:\video.avi:
Cannot play back the video stream: no suitable decompressor could be found."

Audio returned: "DirectShowSource: couldn't open file d:\video.avi:
Cannot play back the video stream: no suitable decompressor could be found."

(D:\Avisynth scripts\source.avs, line 5)
x264 [error]: could not open input file `D:\Avisynth scripts\source.avs'

[jagabo]

If AviSource() in your AVS script worked with MeGUI it should work with x264 too. Make sure your x264 is the same bitness as MeGUI. If MeGUI is 64 bit x264 should be 64 bit too.

[Amaze]

Yep both 64bit. I guess MeGUI has something built-in?

This is the info from the frameserver:

Video
ID                                       : 0
Format                                   : VFW
Codec ID                                 : DFSC
Codec ID/Info                            : DebugMode FrameServer VFW
Duration                                 : 59 s 900 ms
Bit rate                                 : 3 840 b/s
Width                                    : 2 560 pixels
Height                                   : 1 440 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 60.000 FPS
Bits/(Pixel*Frame)                       : 0.000
Stream size                              : 28.1 KiB (9%)

Ok, I so I went and checked Debugmode Frameserver website and they have a new release after god knows how many years.
So now I'm getting a little bit further:
avs [info]: 2560x1440p 0:0 @ 60/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [error]: ratecontrol_init: can't open stats file
x264 [error]: x264_encoder_open failed

I guess I have to run a 1st pass first? What bitrate should I use for 1st pass?

Ok I figured out you just leave it at 40k.
So here are the results:

16 threads:
1st pass - encoded 3607 frames, 70.44 fps, 40828.21 kb/s
2nd pass - encoded 3607 frames, 12.62 fps, 40137.13 kb/s

18 threads:
1st pass - encoded 3607 frames, 69.79 fps, 40821.97 kb/s
2nd pass - encoded 3607 frames, 12.87 fps, 40136.69 kb/s

24 threads:
1st pass - encoded 3607 frames, 69.32 fps, 40827.80 kb/s
2nd pass - encoded 3607 frames, 13.30 fps, 40117.43 kb/s

Will test even more threads later. But so far it seems to be working

[Amaze]

Ok had to do a few more.

32 threads:
2nd pass - encoded 3607 frames, 13.96 fps, 40101.22 kb/s

36 threads:
2nd pass - encoded 3607 frames, 14.01 fps, 40103.25 kb/s

Looks like diminishing returns are really kicking in here. So I'm looking at a 33% increase in 2nd pass from MeGUI which is really good.

I did see something about increasing thread count could result in worse quality, but the filesize is exactly the same.

[jagabo]

Using too many threads will reduce quality (a bit) and will eventually slow the encoding.

[Amaze]

I will have to look over the videos to see if I notice anything. Do you know what I'm specifically looking for quality wise?

I'm also guessing memory speed don't really affect encoding? It's not like I'm moving 4k video here so no real point in overclocking?

I'm also wondering if it's possible to make the x264 cli spit out time elapsed when it's finished?

[_Al_]

that latest DMFS introduced 64bit handling, so you can load it now to 64bit aplications

before it was managed behind the scenes by MeGui with some pipe or something from that 32bit to 64bit, so when you put it directly to 64bit x264 it could not work


you can make a batch script to see times:
@echo off
echo starting time:
echo %date% %time%
x264 --preset veryslow etc. ....... x264 cmd line .......
echo encoding finished:
echo %date% %time%
pause

[Amaze]

Excellent thanks.

I also remembered now that AVsP let's you interleave video. So I opened my 16 thread video and compared to a 48 thread video and the 48 video clearly looks worse at 400% zoom.
But when it comes to 24, 32 and 36 thread I'm having a tough time telling which is worse. I can tell that they are not 100% same, but literally in one frame the 16 bit looks better and in another frame the 36, 24 etc. looks better. The variance is so tiny that I feel I can say 36 and below won't have noticeable quality impact.

I'll have another look tomorrow when I'm not this sleepy.

[Amaze]

Ok, after a bit of testing I've settled back down to 12 threads. I don't particularly like how more threads seem to add "smudge" to edges.
Will it be noticeable in fullscreen, maybe not, but the more clean a picture is the better.

I've made a few changes to my settings, but I honestly know very little about them. Is there anything here you would change for video game footage?

x264 --preset veryslow --pass 1 --bitrate 40000 --stats ".stats" --threads 12 --deblock -2:-1 --keyint 300 --bframes 2 --ref 4 --qcomp 0.9 --merange 20 --partitions p8x8,b8x8,i8x8i4x4 --psy-rd 1.0:1.00 --no-dct-decimate --no-fast-pskip --colormatrix bt709 --output NUL --fps 60 --input-res 2560x1440 "D:\Avisynth scripts\test.avs"


Went back to old settings, this actually looked worse.

[TimA-C]

Went back to old settings, this actually looked worse.

Yes, it's annoying when that happens, isn't it?