RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY

[Ryushin]

Originally Posted by rlev11

I only ever run 1 encoding server per PC. Regardless of what shows in the encoding server usage graph, in Windows task manager I am showing over 90% usage for the Ripbot processes. My thing is also especially running distributed encoding is if you are essentially running 2 servers at half speed (or just a tick more), are we really saving anything on the total time. You could end up with the last 2 chunks both running at half speed on the same machine, while a faster machine sits idle.

Now like I said, a 32 physical core machine may be a totally different animal than my experience is with setting up how best to utilize it to it's full potential.

My thinking is that you may end up in the end the best setup may be to essentially cut that in half, and run dual encoding servers on the new Epyc as dual 16 core 32 thread machines. This would be easy to setup reverting back to using an affinity mask to setup each machine as a 16core 32 thread server for ripbot. That would also probably eliminate the need to play with the prefetch memory cache. I did some tests doing that on the 7950x back a bit running essentially as a dual 7700x, and in some limited runs, 4k was a touch faster with dual servers, and 1080p was a few fps slower, but close to similar.

This is good to know. Since I pass through the cores from Linux to the RB virtual machine, I can mix and match. Since my server does other work other then just encoding, I'm thinking of just passing 24 cores (48 threads) to the VM and reserving 8 cores for server work. This still will give the VM 48 CPUs. If I can get it to run 90% then that will be ideal. I'll see what happens.

Originally Posted by Retired@55

There is also a very important setting that needs to be changed when using any SMDegrain script, and I'm not sure if this has been mentioned.

Also, @Ryushin, does the EPYC have "numa" ?? if so that might be able to be used with DE to some advantage.

I've added instructions in the SMDegrain_Lite package to disable "Limit to the following threads".

EPYC absolutely has NUMA.
Motherboard: https://www.supermicro.com/en/produc...oard/h13ssl-nt
Processor: https://www.amd.com/en/products/proc...pyc-9355p.html
Memory: 6 x Micron MTC20F2085S1RC64BD2 Memory 32GB DDR5 6400MHz RDIMM

My testing with NUMA with RB showed no real performance gains compared to using threads. Since I'm using a virtual machine and my server is doing other workloads, using NUMA would not give me the flexibility to fully utilize the resources of the server. So threaded is what I'll need to use.

[Atak_Snajpera]

Would be a problem for you guys using Distributed Encoding mode if I replaced PC name to IP address in UNC paths?

\\192.168.0.1\Ripbot264temp instead of \\MY-PC\Ripbot264temp

Is there any disadvantage of using IP address in path? What are your thoughts?

ChatGPT4 gives this answer

When deciding whether to use an IP address or a local computer name in a UNC (Universal Naming Convention) path, consider the following:

Local Computer Name:
Using the computer name (e.g., \\ComputerName\SharedFolder) is generally preferred because it is more readable and easier to remember.
It allows for easier management, especially in environments where IP addresses may change (e.g., DHCP environments).

IP Address:
Using an IP address (e.g., \\192.168.1.10\SharedFolder) can be useful in situations where the computer name cannot be resolved (e.g., DNS issues).
It may be necessary in some network configurations or when dealing with legacy systems.

In most cases, using the local computer name is recommended for its simplicity and ease of use. However, if you encounter issues with name resolution, using the IP address can be a good alternative.

[rlev11]

Originally Posted by Atak_Snajpera

Would be a problem for you guys using Distributed Encoding mode if I replaced PC name to IP address in UNC paths?

\\192.168.0.1\Ripbot264temp instead of \\MY-PC\Ripbot264temp

Is there any disadvantage of using IP address in path? What are your thoughts?

ChatGPT4 gives this answer

I don't see any disadvantage in making that change.
In fact I used to have a machine I wanted to add to the mix, but I kept an active vpn connection on that one, and I had issues with the name resolution back to the client. \\ip\share would have connected back just fine. I don't remember if I found a work around or not.

I say go for it!!

[Emulgator]

Go for direct IP addressing +1, as soon as I adressed storage servers manually here: even for control, not bulk data the whole rig became snappier.

@ Ryushin,

So why an EPYC, and not Threadripper or Xeon ?

@ rlev11,

Yes, that last chunk is the worst thing with DE, and inevitably the last is is always the biggest, and 99% of the time ends up being on the slowest PC in the "pool"
And what exacerbates the situation more, is if the slowest PC is way slower than the rest
In a perfect world all the PC's need to be the same.
It would be nice if the last chunk was the smallest.

@ Atak_Snajpera,

Actually shocked that you're asking the "community" about a possible change to DE, you generally make changes, release them without much or any explanation or instruction, and the user has to figure it out for themselves.
If this change is implemented, and provides better stability & connectivity, then by all means.

I just updated RB on my 7950X, and I noticed that this setting doesn't change depending on the PC used, or the video that's loaded...

SetCacheMode(CACHE_FAST_START)
SetMemoryMax(8192)
#PREFETCH_LIMIT=12

So if this call is in the custom script, which settings are used ??

SetCacheMode()
SetMemoryMax(20480)

So now this seems to be uneditable, could it be made to be ??

The Prefetch_Limit setting can be changed, so why not the SetMemoryMax, on the same page.

[Boulder]

Originally Posted by Atak_Snajpera

Is there any disadvantage of using IP address in path? What are your thoughts?

IP addresses are always the best option. For example, I cannot access my media player over the local network using anything else than the static IP address. It took me one evening to figure it out

[Ryushin]

Originally Posted by Atak_Snajpera

Would be a problem for you guys using Distributed Encoding mode if I replaced PC name to IP address in UNC paths?

\\192.168.0.1\Ripbot264temp instead of \\MY-PC\Ripbot264temp

Is there any disadvantage of using IP address in path? What are your thoughts?

IP Addresses are strongly preferred. Though it would be nice to have something like a hosts file that you can associate a name with the IP address.

[rlev11]

Originally Posted by Ryushin

IP Addresses are strongly preferred. Though it would be nice to have something like a hosts file that you can associate a name with the IP address.

I would think that the only visible change would be in the encoding server window, the ffmpeg command line would show call backs to \\client ip instead of \\client name

[stryker412]

Originally Posted by rlev11

Remembered I had made backup copies of all my folders since the bunch of updates that took place earlier this year.

This has all from 1.27.1 and 1.26.2 RipBot264.exe's along with the associated encoding server and encoding client exe's. Was all I could find on my systems.

https://drive.google.com/file/d/1VKN...ew?usp=sharing

Awesome, thank you!

[rlev11]

Originally Posted by Atak_Snajpera

Would be a problem for you guys using Distributed Encoding mode if I replaced PC name to IP address in UNC paths?

\\192.168.0.1\Ripbot264temp instead of \\MY-PC\Ripbot264temp

Is there any disadvantage of using IP address in path? What are your thoughts?

ChatGPT4 gives this answer

No issues so far with the new encodignclient.exe which uses ip address instead of hostname for the callback from the encoding servers

[Ryushin]

I set up a new job to run and it failed. I got an error about info.txt missing. Went into the job and found info1.txt. Renamed it to info.txt and the job ran fine form that point on. Could be a new bug from the recent changes.

[rlev11]

Originally Posted by Ryushin

I set up a new job to run and it failed. I got an error about info.txt missing. Went into the job and found info1.txt. Renamed it to info.txt and the job ran fine form that point on. Could be a new bug from the recent changes.

Anytime I have had that info.txt error (and i have talked about this in the past) was if I did a crop and using smdegrain and the aspect ratio was just a little off of a standard. Usually adjusting the horizontal pixels just a bit clears it up. I have found that once you do the crop, if you hit preview script, and the mediaplayer window at least opens without an error, the encode will go through

I only did a few quick encodes so far with the updated encodingclient with no issues. will be able to fire up the whole farm in a couple days to do a more thorough test.

Pretty sure the only file that changed was encodingclient.exe. Looked like everything else remained at the same version number.

I would try the same video again and just use mdegrain and see if it at least starts encoding as a test.

[stryker412]

I know the topic came up earlier. I now have a 5700X3D CPU. When running Ripbot my CPU temps are around 70-73c. Is there anything I can do to bring temps down a bit without sacrificing too much speed on encodes?

[rlev11]

Originally Posted by stryker412

I know the topic came up earlier. I now have a 5700X3D CPU. When running Ripbot my CPU temps are around 70-73c. Is there anything I can do to bring temps down a bit without sacrificing too much speed on encodes?

See my post from 27 November about adding in the boost setting to the control panel power settings
https://forum.doom9.org/showthread.p...72#post2010572

[Ryushin]

Originally Posted by rlev11

Anytime I have had that info.txt error (and i have talked about this in the past) was if I did a crop and using smdegrain and the aspect ratio was just a little off of a standard. Usually adjusting the horizontal pixels just a bit clears it up. I have found that once you do the crop, if you hit preview script, and the mediaplayer window at least opens without an error, the encode will go through

I only did a few quick encodes so far with the updated encodingclient with no issues. will be able to fire up the whole farm in a couple days to do a more thorough test.

Pretty sure the only file that changed was encodingclient.exe. Looked like everything else remained at the same version number.

I would try the same video again and just use mdegrain and see if it at least starts encoding as a test.

Odd then. Never saw RB make a info<jobnumber>.txt file before, it was always info.txt. Didn't do any cropping this time. Mediaplayer played it fine as well as I was debugging the problem. So that is what led me to believe it was a code change.

[stryker412]

Originally Posted by rlev11

See my post from 27 November about adding in the boost setting to the control panel power settings
https://forum.doom9.org/showthread.p...72#post2010572

Thanks, my temps dropped by 20 degrees when disabling it. I'll have to enable/reenable each time as I do use this machine to game as well.

[rlev11]

Originally Posted by stryker412

Thanks, my temps dropped by 20 degrees when disabling it. I'll have to enable/reenable each time as I do use this machine to game as well.

So what I did on all my machines was make the balanced power plan setup for boost disabled, then make the power plan for high performance setup the way I want it for regular use (I'll set minimum processor speed to whatever it is on the balanced plan either 0 or 5%).

then I made two .bat files on my desktop, balanced.bat and highperf.bat. for balanced.bat I used this command
powercfg /s 381b4222-f694-41f0-9685-ff5bb260df2e

For Highperf I used this command:
powercfg /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

These worked on all my machines, so the strings should be the same. A cmd of powercfg /l will list all your power plans along with the string to use if there is a difference.

Now I can switch on the fly at anytime just by double clicking the power plan i need at the time.

[Ryushin]

Originally Posted by rlev11

I only ever run 1 encoding server per PC. Regardless of what shows in the encoding server usage graph, in Windows task manager I am showing over 90% usage for the Ripbot processes. My thing is also especially running distributed encoding is if you are essentially running 2 servers at half speed (or just a tick more), are we really saving anything on the total time. You could end up with the last 2 chunks both running at half speed on the same machine, while a faster machine sits idle.

Now like I said, a 32 physical core machine may be a totally different animal than my experience is with setting up how best to utilize it to it's full potential.

My thinking is that you may end up in the end the best setup may be to essentially cut that in half, and run dual encoding servers on the new Epyc as dual 16 core 32 thread machines. This would be easy to setup reverting back to using an affinity mask to setup each machine as a 16core 32 thread server for ripbot. That would also probably eliminate the need to play with the prefetch memory cache. I did some tests doing that on the 7950x back a bit running essentially as a dual 7700x, and in some limited runs, 4k was a touch faster with dual servers, and 1080p was a few fps slower, but close to similar.

I've been doing some testing and it is indeed possible to just have a single encoding server which is nice with high CPU core processors. I gave 24 cores and 48 threads to my VM. I found that having 24 avisynth threads and 48 x265 threads I would have some threads being starved for data. Changing avisynth threads to 32 kept the 48 x265 threads fully loaded and I was seeing about 90-95% processor usage.

So everything is happy now. Full speed ahead.

[rlev11]

Originally Posted by Ryushin

I've been doing some testing and it is indeed possible to just have a single encoding server which is nice with high CPU core processors. I gave 24 cores and 48 threads to my VM. I found that having 24 avisynth threads and 48 x265 threads I would have some threads being starved for data. Changing avisynth threads to 32 kept the 48 x265 threads fully loaded and I was seeing about 90-95% processor usage.

So everything is happy now. Full speed ahead.

My only real question was if the cache value that is set now by default to 8096 to fix the 16 cores 4k encoding, was if that would be enough when you threw a bunch more cores into the mix. I am assuming you did not or you would have mentioned that??