Vegas 10 crashes 10x daily

[and]

Several new issues to complicate the edit.
AVCHD uses only 3 MB/s at 1x play. Cineform uses 10 to 24 MB/s at 1x play speed. A typical internal hard drive can handle ~60 MB/s.

But going back to the scrub example, a 4x speed scrub will bring a 60 MB/s hard disk to its knees. If your video sources are layered or in a transition, the hard drive will have difficulty at lower scrub speeds. This is where an SSD or simple RAID will help when you layer up sources.

So you can see editing layers requires a balance of disk speed and CPU loading. A good digital intermediate allows performance`optimization. Cineform goes further by using all I frames with 4:2:2 wavelet compression for greater processing precision.

...

Since AVCHD requires only 3 MB/s (24 Mb/s) at 1x speed, 4 layers only demand 12 MB/s from the drive. You can even scrub at 5x and only demand 60 MB/s.

A digital intermediate will reduce the decode load on the CPU but will load the drive with more bitrate demand. This is where a Raptor, SSD or simple RAID can improve scrub performance.

The concern I have about using digital intermediates on a ssd is a size limitation, to edit an hour show shot with 5 cameras I have 5 15GB .mts files right now. That's 75GB of data. That data will fit on a 120 GB SSD for under $200.

If I start using MXF XDCAM 35Mb/s files as an intermediate format the amount of data triples (original files, plus 2x size MXF files to edit with), so I need two 120gb ssd's (or would a single 240gb ssd still handle the throughput just as well?) and leave the original AVCHD files on my existing USB2.0 hdds and spend another day re-converting if I need to use a back-up or do a re-edit... starting to sound like using cineform codecs may really be worth the $129 for neoscene on future projects.

I would like to understand a bit more about how the 10-bit and 12-bit cineform options would compare and/or effect the 32-bit floating point pixel format option in vegas that makes the video I export after editing really look right color-wise.

[edDV]

Several new issues to complicate the edit.
AVCHD uses only 3 MB/s at 1x play. Cineform uses 10 to 24 MB/s at 1x play speed. A typical internal hard drive can handle ~60 MB/s.

But going back to the scrub example, a 4x speed scrub will bring a 60 MB/s hard disk to its knees. If your video sources are layered or in a transition, the hard drive will have difficulty at lower scrub speeds. This is where an SSD or simple RAID will help when you layer up sources.

So you can see editing layers requires a balance of disk speed and CPU loading. A good digital intermediate allows performance`optimization. Cineform goes further by using all I frames with 4:2:2 wavelet compression for greater processing precision.

...

Since AVCHD requires only 3 MB/s (24 Mb/s) at 1x speed, 4 layers only demand 12 MB/s from the drive. You can even scrub at 5x and only demand 60 MB/s.

A digital intermediate will reduce the decode load on the CPU but will load the drive with more bitrate demand. This is where a Raptor, SSD or simple RAID can improve scrub performance.

The concern I have about using digital intermediates on a ssd is a size limitation, to edit an hour show shot with 5 cameras I have 5 15GB .mts files right now. That's 75GB of data. That data will fit on a 120 GB SSD for under $200.

If I start using MXF XDCAM 35Mb/s files as an intermediate format the amount of data triples (original files, plus 2x size MXF files to edit with), so I need two 120gb ssd's (or would a single 240gb ssd still handle the throughput just as well?) and leave the original AVCHD files on my existing USB2.0 hdds and spend another day re-converting if I need to use a back-up or do a re-edit... starting to sound like using cineform codecs may really be worth the $129 for neoscene on future projects.

Ideally you would have enough disk/SSD space to handle the project. If not you need to work in segments (e.g. songs).

The way I would do it (Cineform or MPeg2 MXF) is encode one or two songs at a time to the digital intermediate. These should fit on a small SSD. After you edit the cut points (the most demanding for scrubbing the timeline), you can combine the project segments on a second hard drive or back to the SSD for finishing*. It would be easiest to just drop a generation. The losses won't be bad with Cineform.


* After you finalize your cut points, the needed disk space for that segment drops by 5x.

[edDV]

I would like to understand a bit more about how the 10-bit and 12-bit cineform options would compare and/or effect the 32-bit floating point pixel format option in vegas that makes the video I export after editing really look right color-wise.

As far as I'm aware, Vegas will only use the most significant 8 bits per component of Cineform's 10 bits. Maybe this has changed in version 11. Premiere has a 10 bit mode.

For processing, Vegas will convert 10 bit Cineform to 8 bit per component RGB. The three components add to 24 bits. Alpha adds another 8 bit component for a total of 32 bits.

Color will be fine. On export Vegas combines processed RGB segments with unprocessed Cineform frames.

[budwzr]

Bingo! The raw files probably have timecode errors. What kind of cameras do you have?

[and]

This shoot was:
3x Canon HF-S20
2x Sony HDR-XR200
1x Sony HXR-MC2000
1x Sony HXR-NX5U

[budwzr]

So do these cameras have any stitch software? That puts the files together for you?

Also, are you just showing head, middle, and tail stills?

[and]

The cameras all divide video streams into 2GB .mts files as is typical of AVCHD cams. I currently use Vegas to recombine, but I may try cineform on the next project.

If I keep my processor monitor on top of vegas and go from playing one stream to 7 it goes from using some of 4 cores and average RAM to all of 8 cores and all ram, maxing at 100% when I stop or pause the video during editing (this is also the point at which Vegas will often Freeze if I am unlucky).

I don't know what you mean by head, middle and tail stills... but I keep the preview window at Draft Half or Draft Quarter resolution while editing.

[budwzr]

Head,middle,tail is a setting for how much of the video is shown on each event in the timeline. It's to help from having to show every frame.

But anyway, I notice you want to use the floating point processing, but I don't think that helps the video itself, only the generated media, especially interpolated effects.

So looks like we're at a dead end, and back to using an intermediary. In that case I have to defer to edDV, because it sounds like you need to take it to the pro level.

[and]

Right. Head, Center, Tail, in Options>Preferences>Video [Tab] (4th item down) I wondered if there was a way to show more/less video thumbnails/stills in Vegas' Timeline. Thanks for drawing my attention to it.

For now I can go through footage from the best roving camera first, cut out all the junk, then mute the video track and look at the next 2 best cams, and finally go back over one song at a time adding close-ups from static cams etc. I just turn on the 32 bit float at the very end. Like noise reduction, color correction etc, it just slows things down to much.

I guess I just wish the selective pre-render function in vegas was useful for this type of work - but I have to get over it and START using a pro workflow with a couple extra steps right from the beginning of post.

Thanks budwzr, Thanks edDV! I'm off to eat a turkey.

[budwzr]

Something else you can ponder is that Vegas is "resolution independent". In other words, you can edit a lowres proxy file on the timeline, then replace it with the master at render time.

So my point is that you can create a proxy at half the pixel resolution, and it will display at the project setting. The AR needs to be the same though.

Example: 640X360 will display at 1280X720, like an upsample.

So you can process the masters into low bitrate MXF Mpeg2's, for example, and Vegas will fly through them.

Basically, that's what "Preview Auto" does. It progressively shrinks the resolution until it can playback smoothly. To see this in action, create a looping selection and let it loop a few times, and you'll see it get faster after each loop.

You see, in your case, heavy compression AND high bitrate are the enemy. 17 Mbps is quite high for H.264, and my Canon DSLR is even worse, at 50 Mbps. That's way overkill. So a lowres proxy addresses BOTH issues, and you'll get amazing editing speed.