Network rendering can free your main editing station from the rendering process so you can work on another project, or it can speed up the rendering so you have a finished project in less time. This is an exciting prospect if a few computers in your studio are connected on a network. If you have multiple machines in your studio but haven't set them up in a network, or have only one functioning system at your disposal, you may want to weigh the benefits and limitations of network rendering before you rush out to buy the necessary equipment.
In the December issue of EventDV, CLASS ACT columnist Todd Gillespie chose Apple Final Cut Pro 5 as his "Best of 2005" selection for the inclusion of network rendering capability in the latest version of Apple's Compressor rendering engine. In doing so, he expounded on its ability to turn small studios into "instant render farms" that can benefit from the off-loading and time savings as they juggle multiple projects simultaneously. Here, we'll look at the pros and cons of network rendering and test its implementation in Sony Vegas on two different kinds of projects to give event videographers a sense of what it can do for them.
Two of a Kind
There are two kinds of network rendering: distributed rendering and non-distributed rendering. Non-distributed rendering (which would be better named "rendering by proxy") sends your project to another computer to be rendered. This frees up the processor on your local computer, which allows you to work on another project while the other computer does all the work.
The other kind of network rendering, distributed rendering, divides a project into segments that are sent to two or more computers to be rendered individually. After the segments have been rendered separately, they are assembled into a final file by the computer that you designate as the stitch host. Distributed rendering can decrease rendering time, depending on the complexity of the project and the size of the source files.
Non-distributed rendering and distributed rendering are mutually exclusive in Vegas: you can only choose one for each project. Both require Vegas to be running on the host computer and the Vegas Network Render Service application to be running on the other computers. Vegas 6 comes with a license to install a full version of Vegas on one computer and render-only versions on two other computers. All the computers must have access to the Internet so the licenses can be verified while network rendering is taking place. The computers also need to have access to a shared folder that contains your project file and all the source files. Each computer must have permission to read, write, create, and erase files in that folder.
Not Everything You Edit it in Vegas Stays in Vegas
In the second edition of his book, Vegas 5 Editing Workshop, Douglas Spotted Eagle recommends that you enlist a file server if you plan to do a lot of network rendering, but I was able to use the Simple File Sharing feature of Windows XP to test the network rendering features of Vegas.
In EventDV's de facto testing lab (where magazine editing and video editing alternately crowd each other out), we run a ragtag assortment of PCs that probably resemble what many videographers have in their studios. Each machine was a more or less state-of-the-art editing station at one time, and even as new machines have arrived, the old ones haven't been relegated to the trash heap, just used less frequently or assigned to different projects. As mentioned earlier, the time savings of network rendering alone aren't reason enough to go out and buy a fleet of new PCs, but it's a good way to make use of the assorted hardware you have. In our case, that meant PCs ranging from 1.4 to 3.6GHz, some running XP Home and others running XP Pro, variations that can make even the simplest network and distributed rendering setups somewhat more complicated.
Windows XP Home limits file sharing to the contents of a folder called the Shared Files folder, so I had to save my project and all its source files in that folder. If you do not share the source files, only your local computer will be able to render your project. It's important to note that Windows XP Simple File Sharing does not protect your shared folder from outside access, so it probably won't be the best way to share files on your network.
I ran the Windows XP Network Wizard from the Network and Internet Connections control panel on each computer. The computers were already set to receive their IP addresses dynamically from the server of our Internet Service Provider (ISP), so I didn't have to assign any IP addresses. Instead I had to go into System Properties and give each computer a matching Primary DNS Suffix. This allowed each computer to access the Shared Folder on the host computer.
The system requirements for Vegas 6 include an 800MHz processor (2.8GHz for HDV), 200MB of hard drive space (600MB for the optional reference guide), and 256MB RAM. The PC I used as the host was a Gateway 510XL desktop with a 3GHz Intel Pentium 4 processor with hyperthreading, 512MB RAM, and a 233GB internal SATA hard drive. I connected this to a Compaq Evo D310 desktop PC with a 2.66GHz Intel Pentium 4 processor, 512MB RAM, and a 74.5GB hard drive; and a Gateway M360 laptop with a 1.4GHz Intel Celeron M processor, 512MB of RAM, and a 32GB hard drive. I also tried to use a 3.6GHZ Prostar laptop, but it was unable to see the Shared Folder. Both laptops had different types of firewall configurations, so it may be possible that the Prostar's security settings needed to be adjusted to allow file sharing (which would have taken more time than I had).
In addition to hardware, the Vegas 6 system requirements also specify an operating system of Microsoft Windows 2000, Windows XP Home, or Windows XP Professional (with Service Pack 2 for HDV). In my tests, the host PC and the Compaq PC were both running Windows XP Home Edition version 2002 with Service Pack 1, but the Gateway M360 was running Windows XP Professional v. 2002 with Service Pack 2. The different versions did not seem to cause any problems.
I ran our network render tests with Vegas 6 installed on each PC with the latest Vegas upgrade patch, 6c, downloaded and installed from the Sony Web site.
Shipping and Distribution
If you already have a network set up, configuring Vegas for network rendering is easy. Just open the Vegas Network Render Service on each of the computers and enter all the computer names that will be used for rendering. If you're unfamiliar with Windows, you can find the name of a computer by right-clicking on the My Computer icon, choosing Properties from the menu that appears, and then clicking on the Computer Name tab.
The Vegas Network Render Service shows up as an icon in the system tray. Open it by right-clicking on the icon and selecting Show from the menu that appears. When the Network Render Service window opens, click on the tab labeled "Renderers" and type the name of each computer into the rows of the table. The Status column will display "connecting" and then "ready" if your computers are communicating and Vegas Network Render Service is running on each.
To render a project, open the project in Vegas and make sure it is saved in the shared folder. Next open the File menu and select Render As, just as you would render any other Vegas project. The Render As window will appear. Select the shared folder for the location and type a new name for your file.
Next, select the type of file you want to create (we rendered to AVI for writing back to tape or opening in other applications and MPEG-2 for DVD, for example). Then select the checkbox labeled "Render using networked computers." Selecting this checkbox tells the computer to use Network Rendering instead of local rendering. When you click Save, a Network Render window will appear.
The first item in the Network Render window is a checkbox labeled "Distribute Rendering." This checkbox tells the computer if you want to use distributed or non-distributed rendering. Leave the box blank to use non-distributed rendering; select it to use distributed rendering.
The next item in the Network Render window is a drop menu that should contain all the computers that you entered into the Vegas Network Render Service. If you chose non-distributed rendering, select the name of the computer that you want to perform all the rendering. If you chose distributed rendering, select a computer to serve as the stitch host. The stitch host is the computer that will assemble the segments of your project after they have been rendered by the various computers.
Douglas Spotted Eagle recommends choosing a stitch host that is different from the computer you are working on if you want to continue to use it during the rendering. For my tests, I chose the local (or host) PC.
The next item in the Network Render window is the designation of a segment render format. If you are using distributed rendering to do MPEG encoding, each computer must render the segments using an intermediate format first and then the stitch host will convert the segments to MPEG. To select a segment render format, clear the "Use Final Render Template" checkbox and choose a suitable intermediate format (the vice president of technology at Sony Pictures recommends DV or YUV).
When all the settings on the Network Render window are correct, click OK. A status bar will appear on each computer that shows how far the computer has progressed in rendering the segment it has been given. To view the overall progress of the network rendering, click the Progress tab of the Vegas Network Render Service on the host PC. You will see the name you choose for your file at the bottom of the Project column. Scroll all the way to the right to see the progress. The Completed column will show how many segments there are in total and how many have been rendered. After all the segments have been rendered separately, the display will change to show the percentage of the stitching process that has been completed. When this reaches 100%, the network rendering is finished.
One debilitating aspect of rendering that network rendering is supposed to relieve is the way it drains system resources on your main editing PC. After all, it's precisely because rendering and encoding monopolize resources that they bring your work to a standstill and try your patience.
In my tests, rendering a project locally used 98%-100% of the processor's resources. Using non-distributed rendering to send a project to another computer added only a few minutes to the rendering process and dropped the processor activity to 0 on the local PC. Distributed rendering was less consistent. My first distributed rendering experiments used a 20-minute project that took 27 minutes to render locally in AVI format. When distributed between the host PC and the Compaq PC, the rendering time increased to 30 minutes, and when distributed among those two computers and the Gateway laptop, the time increased to 34 minutes.
When rendering to MPEG-2, the results for the same project were 34 minutes locally, 51 minutes with two computers, and 47 minutes with three. I spoke with Sony Pictures VP of technology Dave Hill about these results and found out a major caveat of network rendering: the reason that sending the job to the network resulted in increased, rather than decreased, rendering time was that the level of effects that required rendering in my project was very minor compared to the size of my source files. The time it was taking to copy the footage to the rendering computers was overshadowing the benefit of using multiple processors to render the effects. We were using a 100Mbps network for our tests; a gigabit Ethernet network would likely decrease that transfer time and reduce the impact of the file transfer on the length of the process. The Project 1 table shows the results from this first round of testing.
I tried the tests again with a different project, which ran 20 seconds and contained less footage but more elaborate effects. Local rendering to AVI format took 31 minutes. Distributed rendering between two computers (the host PC and the Compaq) took only 21 minutes, and distributed rendering among all three computers dropped the rendering time to 15 minutes. Rendering to MPEG-2 had similar results: 31 minutes on the local PC, 20 minutes with two computers, and 16 minutes with all three. With that project, distributed rendering showed a distinct advantage because the rendering process was much more time-consuming than the transfer of the source files. The Project 2 table breaks down the results of these tests.
It is important to note that I did not compare the local rendering time in Vegas with the local rendering time in other software. The purpose of this test was to show how much time Vegas users could expect to save by creating a network rendering setup, rather than making claims about how network rendering compares with rendering times in other applications. It is worth noting that one of the traditional knocks against Vegas was significantly longer rendering times than competing tools like Premiere and Final Cut Pro. EventDV's own tests on Vegas vs. the latest versions of Final Cut, Premiere, and Liquid have demonstrated that Vegas 6 really isn't hindered by slower rendering speeds than the competition anymore, but someone using any of these tools could certainly use a reduction in rendering time.
I used very short projects for my tests, but the results do show that rendering time in Vegas can be reduced significantly with distributed rendering. The rendering time using three computers was about half of the rendering time of local rendering in my experiments with the more complex project. With projects that take hours to render, that kind of result would make quite a difference.
I was disappointed to see how much of the processor resources were used on the host PC during distributed rendering. The processing was cyclic instead of steady, but it still kept spiking at 98%-100% percent. Even so, it does leave much more processing power available than when all the rendering is done locally. It would be nice if there were a way to leave the host PC out of the rendering process, but the only option for that is non-distributed rendering.
Besides freeing the processor of the local PC, non-distributed has another benefit—the ability to queue several rendering jobs. Vegas Network Render Service will hold all the jobs in the queue and perform them, one at a time, when the computer becomes available. This allows you send your rendering jobs all at once, saving you the burden of trying to watch for one to end so that you can start the next one. This is particularly valuable if, for example, you're rendering the same project to multiple formats for different distribution media. You can even send each job to a different computer, so that multiple projects are being rendered at the same time, and monitor the status of each from your local PC.
Even though the results of my experiments weren't all positive, they do show that network rendering can be a useful tool for videographers, even if there are only two or three computers on the network, and even if those render-node PCs aren't as fast as your host machine. Distributed rendering won't save time for simple projects if file transfers on your network are slow, but it can save a lot a time on complex projects. Non-distributed rendering lets you continue to use your computer while one or more projects are being rendered.
Network rendering isn't a solution to all your rendering problems, but in the right scenario it can ease your impatience and get you back to editing significantly faster.
Project 1-Large Source Files, Light on Effects
|Render Format||Set Up||Time (minutes:seconds)|
|AVI||Host PC+Compaq+Gateway Laptop||34:02|
|MPEG-2||Host PC+Compaq+Gateway Laptop||47:25|
Project 2- Small Source Files, Heavy Effects
|Final Format||Set Up||Time (minutes:seconds)|
|AVI||Host PC+Compaq+Gateway Laptop||15:51|
|MPEG-2||Host PC+Compaq+Gateway Laptop||16:26|