question for x264

[hanoi0411]

hi all, I have a problem with x264, now I'm using vps (16 core) to encode bluray with x264 and avs2yuv. I use 2 pass and problem is pass 1 didn't run with 100% cpu and fps is low (~9fps), pass 2 have same problem but sometimes can use 100% cpu with 20-22fps. I set priority is Realtime but nothing changed.
So I hope some body help me do that with full performance of vps.
thanks you so much :)

[LoRd_MuldeR]

Could be very well that you are bottlenecked by your input Avisynth script! If your Avisynth script is single-threaded and cannot deliver the frames fast enough to keep up with x264, then there is nothing x264 can do about this. This especially shows up during the first pass, because x264 automatically uses much faster settings during the first pass. In the second pass x264 will use the original (slower) settings, so the input bottlenecked won't be relevant anymore...

Last but not least keep in mind that "CPU usage" isn't anything! You may want to read this (https://forum.doom9.org/showpost.php?p=1655710&postcount=15) post ;)

(Also note that process priorities, despite common believe, do absolutely nothing - unless the CPU usage approaches 100%. In the latter case, all available CPU cycles are used up completely, so the processes/threads compete for CPU time. And, in this case, the priorities control which process/thread will be served first. But, as long as the CPU usage remains below 100%, it means that even after any process/thread willing to execute had been served, there still were some "unused" CPU cycles left. Consequently, we actually have more CPU cycles available than what can currently be used by the running processes/threads. Thus there is no competition. And thus priorities don't matter at all).

[sneaker_ger]

Could be very well that you are bottlenecked by your input Avisynth script! If your Avisynth script is single-threaded and cannot deliver the frames fast enough to keep up with x264, then there is nothing x264 can do about this. This especially shows up during the first pass, because x264 automatically uses much faster settings during the first pass. In the second pass x264 will use the original (slower) settings, so the input bottlenecked won't be relevant anymore...
His first pass ran slower than the second one so that can't be the problem.
First pass usually has the problem with the not multithreaded b-frame decision. If he's currently using --preset placebo (implying --slow-firstpass) switching to --preset veryslow might speed up the process a bit without any significant loss.

[LoRd_MuldeR]

His first pass ran slower than the second one so that can't be the problem.

That's actually quite strange.

Since the first pass uses faster or equivalent (with "--slow-firstpass") settings, it should run at least as fast as the second pass (usually faster).

So the first thing to check is whether this behavior really is reproducible...

[hanoi0411]

Could be very well that you are bottlenecked by your input Avisynth script! If your Avisynth script is single-threaded and cannot deliver the frames fast enough to keep up with x264, then there is nothing x264 can do about this. This especially shows up during the first pass, because x264 automatically uses much faster settings during the first pass. In the second pass x264 will use the original (slower) settings, so the input bottlenecked won't be relevant anymore...

Last but not least keep in mind that "CPU usage" isn't anything! You may want to read this (https://forum.doom9.org/showpost.php?p=1655710&postcount=15) post ;)

(Also note that process priorities, despite common believe, do absolutely nothing - unless the CPU usage approaches 100%. In the latter case, all available CPU cycles are used up completely, so the processes/threads compete for CPU time. And, in this case, the priorities control which process/thread will be served first. But, as long as the CPU usage remains below 100%, it means that even after any process/thread willing to execute had been served, there still were some "unused" CPU cycles left. Consequently, we actually have more CPU cycles available than what can currently be used by the running processes/threads. Thus there is no competition. And thus priorities don't matter at all).

thanks for yours help, i was try but nothing changed, may that problem with my cpu of vps.
moderator can close my topic :(