It's been a while - but if I remember correctly, it can do the process, I think the hold-up was not technical, but rather licensing. To do it, each machine in the farm has to have a MPEG2 license. Your Vegas serial covers you for 3(?) for this very purpose.

The last time I tried network rendering, it was with Vegas 7 and it was complete pain to set up properly, especially under Vista, which is real finicky about folder permissions. I honestly can't remember whether MPEG-2 files rendered properly or not, but the settings that you select for the network render are very critical to success (like, for example, which computer is the stitch computer). I will try later in the day, because I have V8P set up on two PCs and I can see if it works.

I will say one thing, though. Unless you are adding in one or more fast dual or quad core network PCs, don't expect rendering times to be that much quicker. Adding one network single core CPU to one local single core CPU will not be twice as fast, just because of all the file I/O and other overhead involved.

The Sony implementation is very weak, when compared to other programs that I have used. The 3D modeling program Shade (which is not high end by any means) scales up very nicely over a LAN, so it is possible to write software to do network rendering properly.


What would really be nice is if someone would build a Vegas network rendering server farm, so that you could buy rendering time over the Internet. ;-)

My plan initially is to network 10 dual dual-core Xeon machines together for the sole intent of rendering - possibly dual quad-core machines depending on the price. But if even this will not increase render speeds I wouldn't be too happy. But the real deal-breaker will be if I cannot render to mpeg-2 with this setup. So anyone who has done it and had success, I would really appreciate hearing about it.

Here is your answer:

You can network render ANY format. However, if you want to distribute network rendering (where more than one computer shares the rendering), then only DV AVI is supported. Actually, there may be other formats supported, but it will be a short list, and MPEG-2 is definitely not on that list.

Also, as I have stated in other posts, the feature is called network rendering, not network encoding. Thus, the rendering part is always supported (i.e., doing all the fX, compositing, etc.) but the encoding (to MPEG-2, DV AVI, DivX, MP4, etc.) is not.

I often will send an MPEG-2 render/encode to another computer on the network because my main computer is five years old and I have other computers that can do the render faster. Like others, I wish like heck that I could set up a render farm that would let me distribute this work so I could do both my rendering and encoding in minutes instead of hours. The network render feature is very useful, but with a little work could become a killer competitive feature.

If you need any help getting it to work, you can search on my user name for previous posts. The short version of all those is that it is best to re-boot before you do all your network drive mappings on the host computer and you should do that mapping BEFORE you run the network service. On the remote computers, all you have to do is run the network render service and make sure it is enabled. No mapping or anything else is needed.

To expand on and simplify John's excellent reply..

You render AVI, but you encode MPEG, which is why you can't use a renderfarm on an MPEG encode.

Actually, you can network render MPEG files, but here's what the Vegas 8P documentation says (since the MainConcept encoder has a EULA that allows use on only one computer at a time):

"You can render segments as MPEG-2 only in the following cases:

If you're running multiple instances of the render service on your editing computer and no other instances of the render service are running with the same serial number.

Vegas software is installed with a unique serial number on each computer (editing computer and renderers).

Vegas software is installed with a site license serial number on each computer."

OK. So do we all agree that if I were to purchase Vegas for every component of the farm, that it would be able to encode a single MPEG file using all the machines on the network?

Then what do you think would be quicker - to render an avi file over a network and then encode to MPEG-2 on a single machine, or to encode the MPEG-2 across the network with a separate license for each computer?

OK. So do we all agree that if I were to purchase Vegas for every component of the farm, that it would be able to encode a single MPEG file using all the machines on the network?

No. I don't agree. I wish I coould.

I do not think there is any way to encode to MPEG-2 using more than one computer, no matter what license you purchase. You can send the "job" to another computer that is running Vegas network renderer and it will render and return the result, but you cannot have six renderers each do 1/6 of the job and send the pieces back to the host (the way that you CAN do with DV AVI).

If someone else has done this (use multiple computers on the network to encode a single job to a single MPEG-2 file), I'd sure like to know.

Johnmeyer, I really appreciate all of your help with this, but now I am really confused. I sent an email to Sony asking about this whole network situation, and this is the reponse that I recieved from Support in Madison.

"If you have a number of machines hooked up to perform a network render, this can be very beneficial when it comes to render times. Having more than one machine set up to thread information back and forth will decrease render time. When you set this up, you can render to any of the formats in Vegas without issue."

Am I misunderstanding his reply?

John,

You know what's interesting about the documentation notes that I posted above, is that for the life of me, I can't figure out why you would want multiple instances of the server running on one machine. Would this be a way around the problems some people have had using Vegas with quad core CPUs? You could assign each CPU core to an instance of the server. But to what end, since the non-network rendering in Vegas is multi threaded anyway?

In any case, if multiple instances of the server work on one machine, it might be a way to test whether you actually can network render to MPEG. Like you said, I doubt it's the MainConcept EULA that is the limitation. I think that MPEG network rendering just doesn't work the way that Sony says it does.

When I thought more about this, I remembered that before I abandoned network rendering entirely with Vegas 7, I fiddled around with AVI network rendering using the Morgan MJPEG2K codec and of course that does work, but it wasn't that great an improvement, since my second machine is only a single core machine . The whole unwieldy nature of the Vegas network rendering design made me give up on it.

hi musician,

it does read RENDER only, NOT encoding.

i'm with you though, when i first read it, i thought it covered encoding as well.

leslie

I think a lot of the confusion -- including the confusion within Sony Madison -- stems from this whitepaper they issued back in Vegas 5 when Network Rendering was first introduced:

Network Rendering White Paper

I think some of the things they said about MPEG-2 being renderable (if that is a word) in segments is just simply not true. Also, if you read the third paragraph on page 11, I think it provides the clue:

"Nontemporal video output formats, such as DV or uncompressed AVI, are also well suited for distributed network rendering because segments can be reassembled without re-encoding. When using temporal compression, segments are rendered in an uncompressed or nontemporal format, and temporal compression is applied during the stitching stage."

Thus, since Vegas has never been able to cut/stitch MPEG-2 without recompressing (until V8, and then only in an unsupported way), distributed encoding has not been possible. Now, since V8 apparently does do some sort of smart rendering of MPEG-2, perhaps there is a way to finally do distributed network encoding of MPEG-2 in Vegas 8.

As I stated earlier, if anyone has actually been able to distribute MPEG-2 rendering, speak up.

In fiddling around with this, I just generated an error:

192.168.2.5 The requested address is not valid in its context 255.255.255.255:53704

I've never seen that one before. In TCP lingo that means either the IP address is invalid or the port is being used by another application. Is this a new feature with Vegas 8P?

I have resubmitted questions to this whole issue to Sony Madison. I will update this thread when I recieve a response and fill you all in.

OK, here is the final word on the subject directly from Sony:

"With the .mpeg2 file format, you need to have a licensed installed copy of the software on the machine to use it. In previous versions of Vegas the plug in needed to be registered separately, now the plug in is registered automatically when you register Vegas. So in order for you to render to this format across ten machines, you would need to have the software installed on ten different machines, fully registered, which would give you access to the .mpeg2 plug in. For this type of set up, we do sell what are called "site license" copies of the software for use on multiple machines. Please contact one of the resellers to get a multiple seat license. Then you will be able to set up a render farm that can access the .mpeg2 plug in on all the machines."

So based on this, if you have a multiple seat license, then you could render out to mpeg-2 on a network setup. But it would be cheaper for you to render to AVI and then encode to mpeg2. Hope this helps to clear up the confusion around this issue. Let me know if there are any other concerns around network rendering that you think I should clear up with Sony before I buy. Thanks.

I actually don't think you will be able to use multiple computers to render and encode to MPEG-2. As I've state multiple times in this thread, you can use a remote computer to render/encode MPEG-2 and it will return the result. You can do this with the standard license. However, even with multiple licenses, I am 90% certain that you CANNOT do distributed network rendering with MPEG-2, that is where many computers each do a small portion of both the rendering and encoding, then return their results to the central (host) computer which then stitches them together.

Actually, make that 98% certain.

Once again, if anyone has ever done this, or has a few minutes and is able to do this let me know.

Has anyone actually gotten network rendering to work with V8? Even to just DV?

I get the same error as jabloomf1230:

The requested address is not valid in its context 255.255.255.255:53704

I have had it work fine with Vegas 5,6, and 7. With the same rendering servers.

Have you guys ever submitted these network render problems to support by email to get answers? I am not trying to sound harsh or unappreciative of your efforts in responding to my questions - I am quite thankful. But I am looking for answers. I really think that it would be irresponsible of Sony to send me personal confirmation that you can network render out to mpeg-2 if in actuality you can't, don't you? In my email to them, I told them about the differing opinions brought up here about not being able to render to mpeg-2, if it could be done, and if so what would I need to make it happen. The reply is what I recieved and posted earlier in this thread. Is it possible that you are doing something wrong? Have you ever actually made the effort to send a question to support to try and get it answered regarding your network rendering issues? Let me know because I feel like I have an open line of communication with them and could try and solve some of our issues. Thanks.

I really think that it would be irresponsible of Sony to send me personal confirmation that you can network render out to mpeg-2 if in actuality you can't, don't you?

Not to beat a dead horse (and this will be my last post on this), but I really don't think that's what they said. It may be what you THINK they said. Part of it has to do with asking the question differently. The proper question to have asked would have been, "Can Vegas 8.0b do distributed network rendering to the MPEG-2 format and have the host automatically stitch the results?" The answer in all previous version of Vegas was definitely no.

Johnmeyer, please don't stop posting because I think that this is an important issue that we have waited far too many upgrades to get resolved. I am going to resend them the question re-worded with the language that you used and I will let you know what their reply is when I get it. Thanks for giving me a more specific way to ask the question.

I suspect that the main problem is that the frames in an MPEG file depend on what's in the prior and next frame (temporal compression). Where do you split the file and how does Vegas stitch them back together without a re-encode?

The basic problem with the terminology is that Vegas puts the encoded formats in the "Render As" menu.

You can split a non-temporal file such as AVI anywhere since every frame is a complete, uncompressed image.

I suspect that the main problem is that the frames in an MPEG file depend on what's in the prior and next frame (temporal compression). Where do you split the file and how does Vegas stitch them back together without a re-encode?

Good point, Steve. However, any MPEG-2 file has to begin with an I-frame, so stitching together complete MPEG-2 files will never require any re-compression. The problem you mention only happens if you later try to cut the MPEG-2 file. Since all the remote network renderers are returning complete MPEG-2 files, they can easily be combined (by Womble or, apparently by Vegas 8) without any re-compression. Since earlier versions of Vegas did not have "smart rendering" of MPEG-2 files, I am quite certain they could not do distributed network rendering. And, since the "smart rendering" of MPEG-2 files is apparently an undocumented feature (smart rendering of HDV is documented, but not SD MPEG-2), I don't know how far we can expect the implications of this feature to reach.