I’ve been using Ripbot264 to encode DVDs and, more recently, Blu-rays for a few years now. I won’t call myself an expert or anything, but I am well versed in it by now. Despite Ripbot’s progressions and increasing features, I’ve pretty much maintained the same simplified usage of it as I did in its initial releases. After all, if you just want good quality at smaller file sizes, it does that well with little configuration. Well, my lack of tinkering with it ceased a couple of releases ago as an exciting new feature was included – Distributed Encoding.
Ripbot264 Distributed Encoding allows us to benefit from having multiple systems around the house by harnessing those extra CPU cycles and putting them to use – distributing the workload and allowing those extra systems to join in on the encode party! So far, I’ve done around a half-dozen DVDs using a single client and single server (two systems) and the performance increase has been quite substantial to me. This post is to act as a guide to help you set up your own distributed encoding network using the Ripbot264 engine.
The reason that I felt it necessary to create a guide is because there is no real documentation on how to set it all up. There is a YouTube video tutorial, but it is set to music, and there is absolutely no real direction to the video. I’m sure if you’re technically-minded enough, you could figure out how to set this all up using the video (I did, afterall), but it took me some trial and error to figure out a few steps. I hope to walk you through it all – beginning to end.
First of all, I’m not going to walk you through installing Ripbot264. I believe you are all competent enough for that. I’ll explain a few of my specific configurations as they pertain to distributed encoding, but that’s about it for Ripbot264 usage. I will begin the guide assuming you currently have a working install of Ripbot264 and now I will explain my specific install as it pertains to the distributed encoding feature:
- My Ripbot264 installation directory resides in C:\Program Files (x86)\Ripbot264 as I’m on a Windows 7 64-bit system.
- My Ripbot264.ini file has the TEMP directory set to X; therefore my true temp directory path is X:\Temp\Ripbot264temp. This is important as you will need to correlate my directions to your own true temp directory path.
- All systems used within the distributed encoding network MUST USE THE SAME VERSION of Ripbot264. I also highly suggest you use the same versions of ffdshow, Java, AviSynth, etc. that the application requires.
Now, let’s move on with our guide with that out of the way. The first thing we want to do is begin on our client system. This is the system where you will initiate the encodes…it should also probably be where the files you want to encode reside. Locate your Ripbot264 installation folder and open the Ripbot264.ini file contained within using Notepad or something. At the very bottom of the file, you should see the entry
You will want to change that “0″ to a “1″ and then save and close the ini file (you may need administrative permissions for this if you use UAC, but I’ll let you figure that out). That is the initial step to enable the distributed encoding client for use. All the other stuff in the ini file can be changed also, but that’s outside the scope of this guide. They are for setting default values within the application and are not necessary to modify…I do, but I digress.
Leave your Ripbot264 installation directory open, but minimize it…we will visit it later. Now we have to change some advanced sharing options, so let’s visit the Network and Sharing Center (remember, I’m on Win7). In the left-hand column, we want to visit the Change advanced sharing settings link, so do that. We have a single option to change, so scroll towards the bottom. We’re looking for the Password protected sharing section and we’re going to turn it off. Now, let me also say, Ripbot264 does include provisions for using password protected shares, but I’m not covering that. My home network doesn’t need them, so I don’t care so much about disabling this. If you require them, I don’t think it will take much work for you to figure out how to do it with the supplied options in the ini files. If you want to dig around in that client ini, you will also see there are accommodations for Wake On LAN support of target servers. Nice! Anyway, disable the password protected sharing and save your changes.
Next, we will need to create the temp directory as it currently doesn’t exist if you’re on a new install. If you left your default temp directory alone, then you are using the system specified temp directory. Let’s go there by typing %TEMP% in the Windows run box. You should get a directory similar to C:\Users\<USERNAME>\AppData\Local\Temp open up in Explorer. Within this directory, create a new directory named Ripbot264temp. Again, you may need admin privileges for this…figure it out. What we want to do now is share this directory out since this is where our work files go when creating a new job. So, right click your new directory and choose Share with > Specific people…
Now we need to share this directory with specified users. If you know what you’re doing, you can make this a bit more secure than this by adding specific users (this can also go along with the password protected sharing), but I have to assume you don’t in order to avoid answering a billion questions in the comments later. So, click the drop down and add Everyone to the shared users list.
We’re not done yet though…the permissions are no good. Our additional servers will need Read/Write access to this directory, so change that also before clicking the Share button.
Click the Share button and you should have a successfully shared Ripbot264temp directory in your default, or specified, location. You should have something similar to this:
Cool, now for the fun stuff. If you don’t run Windows Firewall, this will be pretty easy as you won’t get any prompts. If you do run Windows Firewall, you will get some prompts, so just pay attention and things won’t be difficult. If you run any other type of desktop firewall, you may be in for a time if it’s not interactive with newly detected connections. Anyway, let’s move along and get this part out of the way. The system(s) we want to go to first are our additional encoding servers. These should already have a properly installed and working Ripbot264 installation. It doesn’t have to be configured…just detected as a working installation (launch it and make sure all prerequisites are met). Now, for each server, go to the installation directory and find the EncodingServer.exe executable. Launch it. My server is running Windows 2008 Server R2, so my firewall notification box looks different than Win 7, but you will get something similar to this:
You will want toAllow access to this so that it can be added to the firewall exception list. For Win 7, the box looks like this:
Leave the encoding server running on all systems. It will probably be residing in your system tray…just make note of it for later.
Now, let’s go to our primary system – the encoding client. Locate the Ripbot264.exe in your install directory (we left it open) and launch it. Surprise! If you are running Windows Firewall, you will have received another notice of the encoding server needing access…it will look just like one of the two images above (2008 Server R2 or Win 7), so grant it access. You are now faced with the standard Ripbot264 application and it’s ready for you to add a new job. As I said, I’m not detailing that, so go ahead and add whatever it is you want to encode and get it ready until you have a new job listed in your queue.
Great..click Start and wait for it…
As with the encoding server application, the encoding client needs firewall access also, so allow it. If everything else went well, your encoding client will copy files to the share and start working. Unfortunately, it’s flying solo right now as we have not defined any of our servers yet.
So, let’s add our servers…remember, the encoding server MUST be running on all systems that will be aiding here or the connection will fail. It’s a graceful failure though, so it won’t ruin your job. Under Server 2 on the encoding client interface, type in the IP address of the first encoding server system and click the ON button. After a few seconds, you should see it take off:
For each running server you have, just enter the IP and hit that ON button…new chunks will be sent out and you will enjoy the extra time saved. From the server side, you should see something similar to this:
One other little nice feature I happened upon while doing this guide was what happens when you click the Abort button. It allows you to save your spot!
Well, that’s about it. Of course, the time saved depends on things such as how powerful your systems are and how many you have working. I haven’t run any comparison tests yet, but I use a 3.2GHz quad-core Core2Quad and a 2.4Ghz Core2Duo system and have seen very significant decreases in encoding time needed to completion. The quality of the results are just as they have been expected in the years I have used Ripbot264 – excellent.
Anyway, hope this helps some of you. Below is the YouTube tutorial I used to drive myself insane while figuring all this out. Maybe the two in conjunction will make it even easier for you.