I'm going to set this up myself.. so I am interested in getting this working also. Your experience does seem to bring up some questions as to how effective this is.

Out of interest are you running Gigabit ethernet or just 100Mbit? I would imagine that could make a huge difference in the final stitching time.

I am running 100baseT, through a switch, with no other network traffic.

Quite frankly, unless you've got an amazingly fast hard disk, I don't think a 100 mbs network is going to be the bottleneck.

As for stitching, once you get this set up and running, you will find that the "segments" that each render client works on are returned back to the render host and put in the same directory you specified for the rendered file. At the end of the rendering process, for a ten minute video, I had about ninety of these files, each of the same size, totally about two gigabytes. Why it would take so much time to put these together is the mystery that I haven't solved. I believe it should be possible to create the new file simply by changing the directory entry for the files. This could be done in under one second. The next smartest way would be to combine the files to a different physical drive, so that one drive could always be reading, and the other always writing. However, even when it is all done on the same drive, it shouldn't take more than a few minutes (at least on my computer) to read and write two gigabytes of data to the same drive.

Thus, I was hoping someone else who has actually used the network rendering feature could comment on whether it had actually saved them enough time to make it a worthwhile feature, and whether they too had seen the long stitching times.

John

When I heard about Network Rendering for Vegas 5.0 I got very enthusiastic.

The reason for this is that I have used Discreet 3D Studio Max for 3D animation for quite a few years, which uses very powerful network rendering capabilites. As an example, using my two networked PC's (1X Dual 866Mhz Pentium 3, 1X Pentium 4 2.8 Ghz 512 Mb Ram) rendering time is reduced by almost 50% over a 100 Mbit network. You can use as many PC's as you like for network rendering, with no additional licence charges.

Due to my Pentium 4 PC going down, I have not yet been able to get Vegas Network Rendering operational.

Reading your post and others on this subject I would like to make the following observations:

1) I think network rendering, particularly when it relates to Video is possibly a far more complex issue, compared to 3D Animation.

2) Whilst I was personally dissapointed that you cannot render MPEG 2 over a network, I congratulate Sony on taking this first step, and hopefully in future releases they will iron out some of the current constraints (even if we have to pay additional license fees for MPEG 2 rendering nodes, which I would support as a commercial user).

3) From my limited experience, just having networked AVI rending should be a plus for the time being, (if rendering times are reduced) where you wish to render complex FX's, lots of stills etc, prior to rendering to MPEG 2

So in closing, I think this is a like man and his first step on the Moon. We have someway to go yet. Hopefully Sony will persevere, and they will succeed and we the Vegas community will benefit as a result.

I certainly hope so.

My 2 cents worth.

Regards

BrianG

Unless a lot of smarts are applied to network rendering it would for certain be slower. Consider a .veg that actually requires no rendering, just cuts. Now sending any portion of that out to another machine has got to slow things down surely.
As I don't have network rendering setup as yet here's an idea for a simple test. Tale a 10 minute avi and apply some nasty FX to the first sixty seconds, say the median blur. Now for a two machine render the first sixty seconds may benefit from going out to another machine while the other 9 mintues just needs to get split. But if the engine isn't too smart and just splits the thing in half that's far from an optimal solution. I suspect the tricky part to network rendering is load balancing.
One other thing I've noticed, where there's no real rendering involved, just frames being copied, Vegas has always seen very slow to me, MGI Videwave does this much faster. I'd always thought this was because Vegas has much more to check against each frame before it can decide that a frame doesn't need to be rendered compared to MGI. Now if how Vegas does the join is just to put the segments onto an internal TL and render that out through the same engine then firstly that isn't very smart becuase of all the unnecesary overhead and secondly it's going to be very slow.

Bob.

So far, in all the posts on this subject (not just this post), only a handful of people have admitted using this feature. Can this be true? After all the posts in this forum complaining about rendering time, and here is a feature that could provide HUGE decreases in rendering time, and no one seems to be using it!

Is this because it is too complicated to set up? Is it because it doesn't provide the promised benefit? Is it becasue all Vegas users only own one computer, or don't have a network? Is it because people really don't mind waiting twenty hours for a render, and it isn't worth spend ten minutes installing the render client on two computer, just to reduce the render time from twenty hours to ten hours?

Obviously none of these supositions seem correct. Yet, it sure seems like no one is using this feature.

>So far, in all the posts on this subject (not just this post), only a handful of >people have admitted using this feature. Can this be true?

Yes.

>After all the posts in this forum complaining about rendering time, and here >is a feature that could provide HUGE decreases in rendering time, and no >one seems to be using it!

The key word is "could".

Network rendering "could" significantly speed up rendering for people
who are outputing to DV and who use lots of effects/many timeline
layers. If you are not outputting to DV you will be penalized by the
"stitching" time that it takes to collect the workparts and compress them, say
with mainconcept MPEG2. If you don't use many effects the time that
it takes to composite a frame is very small compared to the time it takes
to compress to MPEG2. Using network rendering takes the easy process
(compositing a frame) and makes it slower by spreading across a
network AND it adds a "stitching penalty" which is the time that it takes
to put all of the composited frames together in a form that the MPEG2
encoder can use.

Nothing has been done to speed up the slow process, that is, the MPEG2
encoding.

On the other hand, if your video is an effects laden extravaganza with
fifteen layers of "Light Ray" plugin you will probably benefit from network
rendering because then the time that it takes to composite the frame is
equivalent to or much larger than the MPEG2 compression time.

Also, if you are rendering to DV, the final compression can be split
across all the network renders (yea!) and all you get is the stitching
time penality. Odds are that for effects laden presentations, the time
saved by parallelizing the composite is greater than the stitching
penality and you win time wise.

>Is this because it is too complicated to set up?
It's a little bit challenging but for people who need this feature they
can probably make it work.

>Is it because it doesn't provide the promised benefit?
Well, Sony never promised anything. It does do what it says it does, which
is split the compositing process across many nodes. Nobody claims
officially that this will necessarily make renders faster.

>Is it becasue all Vegas users only own one computer, or don't have a >network?

Good point. It's not worth doing network render between a PIV 3.06
and a 486. You need to have some good hardware sitting around
the office (or house) and not everyone has this. I can muster
2.4GHz, 2.66GHz and 1.5GHz on my network. This is probably
just large enough to show some decent improvements in composite times.

>Is it because people really don't mind waiting twenty hours for a render, >and it isn't worth spend ten minutes installing the render client on two >computer, just to reduce the render time from twenty hours to ten hours?

I think there is another effect going on here. The people who have to wait
twenty hours for a render and (probably) working on long-form projects on
the order of an hour or two, not three minutes. These long form projects
are probably low on effects and hence there isn't much to be gained
by speeding the compositing process. They have no need to set up
the network rendering because it wouldn't help them anyway...

Now if someone had a network rendering MPEG2 compressor that
they could frameserve from Vegas then people might start doing
network rendering.

If one could run Mainconcept on four boxes, and round-robbin chunks
of 15 frames (the distance between MPEG I frames for DVD) out to
them and then stitch together the resulting MPEG2 blocks, the people
complaining about long render times would have something to work
with.

potatophysics,

From reading your post, I take it that you haven't actually tried doing any network rendering? I am not being critical at all. Rather, I am just once again making the point that NO ONE seems to have actually tried it, and I still haven't heard one person come forward and say that it has really made a huge difference for them.

Your points about MPEG are certainly correct, although as I pointed out in another post, Sony called this feature network rendering, whereas the process of converting video to MPEG is usually referred to as encoding. Thus, they delivered exactly what they promised.

I, for one, believe that network rendering should be a feature that anyone who uses fX or composites, etc. MUST use, if they place any value on their time. Even if they can do other things while something renders for twenty hours, it is still taking twenty hours before the project can be delivered to a client. Also, some of the newer capabilities introduced in this release simply will not be viable for most people if they must wait days for a render to complete. (Check out Two Cats for an example of a great use of the new V5 features. That six second clip takes ten minutes to render on my 2.8 GHz P4, or 100x real time. A twenty minute movie containing this level of effects will take over 33 hours to render.)

However, in answer to my own questions in the last post, I think many people haven't tried the feature, or have tried it and haven't been able to make it work because the implementation is WAY too daunting. You have to do drive mappings every time you do a render (unless you use the same directories each time). You have to specify your renderers each time (I haven't been able to get Vegas to reliably re-connect to previously used renderers if all the computers have been shut down and re-booted since the last network render).

Can anyone who actually uses network rendering and has gotten real value from this feature, please speak up??

You guys are way beyond me, but let me interject some general numbers. If you're dealing with 100baseT, that defines a 100Mb/sec channel. That's 12MB/sec. If the channel can faithfully deliver at 50%, that drops it down to 6MB/sec, not a lot faster than realtimeDV. So it seems to me that any process involving shuttling files all over the place would demand the performance of a 1Gb/sec channel. After all, it's not that uncommon to find generic PC drives capable of delivering 50MB/sec. Is my math wrong?

The notion of breaking up a complex render and shipping pieces out to other machines has appeal for complex projects, but I wonder why the next version of Vegas couldn't just emulate what many of us already do--just render in the background on the same machine, but automatically. I see a simple menu that enables/disables background rendering, sets the priority for those processes (default would be idle priority, so there would be absolutely no effect on the foreground processes), and perhaps allows the user to define the number of slices of the project on the timeline that Vegas will render simultaneously. I can see this happening without much programming sweat. As parts are rendered, you'd see the little green segments appear on the timeline, just like now. If you shuttle things around, no sweat if the green segments get wiped out--after all, it's cost you nothing compared to the present case except for a bit more heat coming off the CPU heatsink.

In my case, such a render feature would create an amazing reduction in overall project time, since there are so many wasted CPU cycles as I sit and edit.

The network rendering feature does allows you to render in the
background on your editing machine. It is pretty much as simple as can
be... Just check the "Render using networked computers" box in the
"Render As" dialog and then just click "OK" in the following network render
dialog. No need to set up renderers or file mappings. If needed,
VegSrv will be launched for you. There will be no stitching, you can
use any output format you want, and unaltered video frames will be
passed through just like normal.

However, the priority of the "background" render will not be lowered
as you suggest... a good suggestion.

I thought network rendering could not be used for mpeg2 files. And how come there is no stitching? I guess this only works if the network renderer is the local machine and not a network node? Please let us know, thanks.

I thought network rendering could not be used for mpeg2 files. And how come there is no stitching? I guess this only works if the network renderer is the local machine and not a network node? Please let us know, thanks.

See my answer here:

Network Rendering of MPEG2

Also, see these posts:

No MPEG2 for Network render?

network rendering & mpeg2 confusion

Thanks for the pointers John... but just to summarize:

For the case of non-distributed network renders, the whole process of
breaking up the project into segments and stitching them back together
in the end is bypassed. This is because only one machine is used to
render the project. When you use your editing machine for
non-distributed renders, there's no restriction on file formats. The
restriction only comes into play when a render-only installation is
used.

You can also use MPEG-2 on other machines if you buy an extra copy of
Vegas (they have a different serial number) or if you purchase a
site license.

For the case of non-distributed network renders, the whole process of

I understand that. However, unless I am missing something, I don't think a non-distributed render, using only my local machine, has any advantage compared to what I could already do by simply opening a second instance of Vegas and work on another project while the first instance is rendering. Doing a non-distributed render to a single remote render client would probably make my local machine more responsive, but depending on the speed of the network and the speed of the remote machine, it may, or may not, let me finish the render sooner than just rendering in the background on my local computer.

Your point about actually being able to encode MPEG-2 on the remote computers, if I have separate licenses, is something that I definitely did not fully understand. I think what you are saying is that if I want to render MPEG-2 faster, then I can do this by spending another $400 for a full license and installing the full version on the remote computer (even though I will never use any of the editing features of this second copy, since I can't be in two places at once). Quite frankly, that is a little pricey for just that ability alone, especially since Mainconcept sells their complete standalone encoder for about a quarter of this price.

Here's what I would propose that you do: Approach Mainconcept and tell them that you will be willing to give them a higher percentage royalty for "render-only" licenses. I don't know whether you offer "render-only" licenses, other than through site licensing, but I am sure you could sell quite a few to people here on the forum who don't seem interested in faster AVI rendering (no one has yet responded to this post telling us about how network rendering has completely changed their workflow), but who all seem to want to render MPEG more quickly. I'd suggest about $50 for each license, with Mainconcept getting half. This would, I am sure, be huge compared to the $/copy that they get on the main program.

Just a thought.

The main advantage to using network rendering to do non-distributed
renders on your editing machine would be the ability to queue up
multiple jobs.

One might also argue that the work flow is a bit easier than manually
firing up the second instance of Vegas, opening the project, and
starting the render. And if you want to make changes to the project
while it is being rendered you'd also have to manually make a copy of
it before starting the render... just little things.

The ability to use MPEG-2 as a segment format would only save you disk
space (over DV, YUV, etc.) in distributed renders and it will cost you
a little in quality because stitching will still recompress. Time
would be lost. In my previous message, I was focused on the ability to
use MPEG-2 on remote machines for non-distributed renders.

My understanding is that Mainconcept is working on the ability to
"stitch" MPEG streams without recompression which would be very good
news for us.

My understanding is that Mainconcept is working on the ability to

And "us" users as well. Of course what would be really great is if what you describe above could also be included in some future version of both Vegas and DVDA so that one could place MPEGs on the timeline, do cuts-only editing, and then create a resulting MPEG without recompression. Womble does this, of course, and I would think that such a thing would be close to trivial for a company that already had the MPEG compression libraries. The only real trick is figuring out how handle the recompression at the transition boundaries between each MPEG (a new GOP will have to be created, containing information from both the end of the last MPEG segment and beginning of the next MPEG segment -- some recompression at this boundary might be necessary, but that would be done in a few seconds, and the quality change would be fleeting and therefore not noticeable).

This is something I have long been asking for, so I hope it someday comes to pass ...

John,

I have tested out network rendering, and after getting the File Mapping set up, got it to work correctly. (The key for me was to map the shared render directory AND the source media files) I'm hesitant to comment on render speed improvements, since my second machine is an Athlon 800, which I understand is a bit underpowered.

Although I am still using Ver 4 I am curious about the network rendering features in Ver 5. I recently started doing all of my edits across the network that I have recently upgraded and thought I might share my experience with Gigabit network and Version 4. My current setup is a P4 3 Ghz workstation 1 GB Ram, my file server is a dual Xeon 3 GHz 4GB Ram and 800 GB Raid array. Now both of these had Gigabit NIC's onboard so I bought me a Linksys 5 port gigabit switch from CompUSA for $99.00 and talk about sweet!

I tested it out by moving some of my projects and source media to the file server and after I tweaked it out by disabling SMB Signing on the 2k3 server and XP Pro was playing back full size Best quality settings from across the network real time. Obviously with out any FX ;-) So I started a new project here a couple of weeks ago and I started capturing all my video to the mapped drives over 4 hours of video with out a single dropped frame!

I did some further testing by forcing both Nic's back to 100Mb full duplex and I my previews were pretty much unusable. I watched my CPU time on the file server and it was never peaking more than 5% so just because I have a fast server should not have anything to do with it, also my Network performance monitor never reached 10% during playback on my workstation or server while playing back across the network.

So I really think network rendering can be of use for allot of work with a fast network, Cost wise it is definitely affordable to most anyone considering 2 computers can now be networked together at Gigabit speeds for less than $200 which would cover a 5 port Giga switch and two Gigabit Nic's plus maybe a few bucks for some Cat 5e cabiling if you don’t already have it. BUT like I said I haven't tried it yet since the demo does not allow you to try the network render (well the remote render client software anyways) as far as I know which would be great to try.

I just can't see how for instance a 25-30 min. video that was color corrected or a chroma-keyed clip could not benefit from an additional rendering machine on a fast network which should help out quite a bit. I definitely agree that a strait cut video there would definitely be a penalty by having to move the data around on the network.

Hopefully I will be able to test here soon with the upgrade and give some feedback…

P.S. to the Sony guys was the network render developed in house or was it licensed from a 3rd party Co. just curious what kind of optimizations were made in the render nodes coding?

I will be interested in your results. Based on responses in this and several other threads, I don't think Network Render, in its current implementation, is going to do much for most folks. It is difficult to set up, and the overhead of stitching and moving stuff around the network reduces considerably the gain in doing multiple concurrent renders.

Perhaps if you have more than two really fast machines, and if you have a switched gigabit network, it might work pretty well.

Let us know what you find out.

i DO thnk its worth it .. and it does aid me anyway ,,, only thing that is a real slow down is writing the final file on the same drive as the pieces of that file - that has to change ,,,

B_JM -- That is GREAT to hear that it is helping. Do you have any hard figures on how much faster you are able to render?

I am running 100baseT, through a switch, with no other network traffic.

A 100megabit network is capable of 10 megaBYTES per second. Conisdering network packet overhead, it can usually sustain a bit over 9 megabytes per second. Even the slowest of modern hard drives can sustain transfer rates well beyond 9 megabytes per second. Therefore, under many circumstances, a 100mbps network can be a bottleneck. Now, a gigabit network is a different story altogether, it can easily keep up with most hard drives.

John

i have not compared the same project rendered both ways - as in many cases , a project where i would use network rendering would take a day or more to render and i dont have time to kill like that to do it twice .

I am used to seeing projects take MONTHS to render for film .... so i'm looking at it in a different way ..