[Jean-pierre Taran]

May I through in a naive question?

Render time strongly depends on the computation done on each frame. For instance, it’s not the same if you just tune brightness and contrast, or if you apply Neat video to enhance definition. Without GPU assistance, the latter will take 10 to 20 times longer for the same job.
Not all contributors to this forum describe what they asking of SVP12, namely source frame format, output frame formats, image processing, etc.

I suggest defining a test case agreed by all, that every one adopts for benchmarking, e.g. HD 1080-50i (1920×1080; 25,000 ips) like the one I use. A 30 sec film could then be proposed by Steve Rhoden or John Rofrano and made available for download and testing to all interested members of the forum. Each then renders it on his machine with and without Neat Video and reports:
1 – his processor type and video board make and serial number
2 – the time spent on render with and without Neat Video sharpening (alternatively Neat Video does compare all CPU/GPU configs and propose an optimal one in “tools/preferences”; just those features are invaluable).

Of course, any other set of parameters can be selected, provided it procures strong discrimination between “with” and “without” GPU

Comparisons and debates are then conducted on firmer foundations, and a robust hardware data base can be built from numerous contributions

jpt

[Jean-pierre Taran]

Thanks Graham, that was a useful tip. Is there a lazy way to control that old settings are properly copied during the upgrade, say when I move over to SVP 13 (assuming I am not superstitious) when it comes out?

It’s pretty tedious to check everything.

JP

[Jean-pierre Taran]

Great, Graham, right on the nose!

Well, almost. It’s “show envelopes” that wasn’t ticked.

Now it workd great

[Jean-pierre Taran]

Right now I have a video of about 15 minutes that has perhaps 60 clips or so in it. Most of the transitions are crossfades, so practically all the clips overlap. How would I carry out your suggestion in this case?

I do have crossfades as well, and they don’t seem to pose any problem. I actually had in mind what you describe in your last paragraph. You should have an integer number of frames (including zero) for spacing between successive clips, whether you position them flush, or overlapped for your crossfade.

It has occurred to me that it might be something related to a particular frame being in a particular position between clips, but I haven’t been able to isolate it.

Sometimes, a funny problem shows up as a result of sliding clips usideways along the time line, such as you will do when you adjust your crossfade: a duplicate of the video is generated exactly superimposed or shifted by a frame or two. I guess this might result, in my case, from a malfunction of the mouse’s left button. To check if this happens to you, open a video track above, mark the suspected videos, drag and drop them up into the new track. If a video clip is left behind, that’s a duplicate and you want to erase it; then drag back everything else into place.

I’m wondering if maybe positioning clips so that their lengths, start/end points, and overlap durations are some special multiple of frames (?). Like maybe if everything aligns on n-frame boundaries, it might work. But I don’t know what n would be, even assuming that this method makes any sense at all.

That problem might appear if you shoot at 29.9 fps (NTSC) and render at 25.

To try and speed up the investigation, have you tried rendering, e.g., the second half of your stream only?
If the problem vanishes, then I see two possible causes, which are not mutually exclusive:
– either you had an orphan image carried over from the first half as discussed up above;
– or you are trying to use too fast a baud rate; you might improve the situation by setting the binary flow rate at 15 or even 14 Mbits/s. I personally had to settle down for 14.6 for my longest films. For me, the default 16 generate instabilities beyond a couple of minutes.

I hope this helps, and that my jargon is intelligible (sorry, English isn’t my mother tongue)

[Jean-pierre Taran]

I have noted similar artefacts with your parameters, namely interlaced 1920x1080x50i if:
1 – the video clips are not positioned flush against one another, or slightly overlap and, at the same time,
2 – I render long videos, e.g. 20-40 min with hundreds of clips.

Then on render I get a characteristic toggle between the first frame of the mismatched clip and the current frame till end of the clip and instabilities propagate to the end of the video.

My remedy: mark last frame of prior clip and first frame of clip concerned and erase that. The clips will then sit flush against each other. Also it helps to reduce the data rate from the nominal 16 MB/s to 15 or less. I use 14.6 for hour-long films.

Hope that helps.

[Jean-pierre Taran]

[The very nature of H.264 is that it is highly compressed and uses interframe compression with a GOP of 15 frames. That means that when you park the timeline cursor on a frame, you have a 1 in 15 chance of hitting a full frame. The other 14 out of 15 are delta and predictive frames containing only partial information about the image. So not only does Vegas have to uncompress the current frame (which is highly compressed), it has to uncompress several frames before it to re-assemble the image from the deltas. This takes a lot of processing power]

Thank you John, this comment of yours was fundamental. It gave me the idea of placing blank images and pictures at regular intervals, typically every 1-3 min. That does solve the render problem for me with PAL format (1440×1080 only, though, but not 1920×1080). The trick allows the software to recover from accumulated errors and to resume the compilation from a clean base. That was using version Vegas 8.c on a dual core machine clocked at 2.7 GHz with 3 GB of RAM.

The drawback is that you break the stream of scenes, but with cross-dissolve and occasionally adding subtitles, nobody notices. I guess that will help a lot of people.

Then yesterday I made the leap over to Win7 X64 and discovered that Sony just released a downloadable version 8.1 that does render the 1440 H264 videos properly on X64 machines. That’s even better.