Vegas can edit HDV natively, yes. As busterkeaton points out, it can be quite sluggish to do so, but editing native would avoid any transcoding issues.

Vegas also supports the Cineform intermediate codec. The intermediate codec is something you'd transcode your footage to. The benefit of the intermediate codec is that it's *much* faster to decode and work with. The drawback is that it takes up a lot more space on your hard disk, and necessarily means uncompressing the HDV and recompressing in the intermediate codec ("transcoding"). The intermediate codec is quite good and you shouldn't notice any image degradation, but any time you recompress using a lossy codec, the potential for image degradation (however slight) can arise.

Intermediate codecs will disappear once CPU speeds advance to the point that they can effortlessly handle the native files.

Even after CPU speeds come up, editing native HDV still isn't a good idea, as the format falls apart very quickly, especially when dealing with high-contrast images. You can see this for yourself, just by rendering to the m2t template, and rerendering it, and running a difference mode on it. The CineForm codec, and better still the Sony YUV codec, provide outstanding multi-render quality.
Yes, there is potential for loss during a transcode, but if you use the templates, or other tools available for the conversion, you'll not have issues. It's only when users start pranking with the settings that issues seem to arise.
Your workflow needs to take into account several issus:
1. Hard drive space
2. Machine speed
3. Delivery format

If you're delivering to DVD, right now I'd recommend that you shoot and capture HDV, and use a DV proxy for editing speed if you don't have a fast machine. Keep in mind the colorspace and use appropriate color matrix filter.
Edit, and then replace the proxy with the m2t stream, rendering to a PS stream from the TS HDV files. HDV holds up quite well for a single recompression.
If you're delivering to HDCAM, BetaCam, media server, I'd take a different approach.

Native editing means don't doing any changes to the video and audio signal (except to the length of it). There must be no real render process in a "native" workflow.
Speaking about DV in Vegas we have native DV editing if we only use simple cuts and export a project to DV again. In this case there will be no rendering - it's just a copy process.
Editing HDV in Vegas there must be a render process in the end.

So - no - Vegas don't offer native HDV editing.

Taking a closer look into HDV editing it is impossible to have a "true" native editing at all - no matter which system is used for it. This is because of the GOP structure used for HDV. If a HDV shot is cut into a smaller piece it is very likely the GOP is broken then and this forces at least this one GOP/cut to be rerendered. Cutting midst in a GOP means recalculating a new I-frame. So part of the stream must be recalculated, part will be handled native.

So - in my opinion: There is no real native HDV editing at all.

Marco

I think, what people tend to mix up is to put m2t files in the timeline of a NLE, make cuts and edit the m2t files in the timeline. That seems to be taken for "native editing", compared with render to intermediates/proxys, and edit intermediates/proxys in the timeline.

To edit m2t files in the timeline harms mainly the preview quality - but does not implement any change in the file located at the harddisk. From that perspective, I agree that the wording "native editing" is misleading at the best.

Another - more important - question is, if we gain quality if a final render process uses the original m2t material (either because we use m2t files in the timeline directly; or because we use Gearshift). Compared with the workflow, where we apply intermediates (cineform, canopus HQ codec or whatever).

This later question seems to be not well explored really. Yes, there are some white papers - e.g. by cineform. But I would like to see some independent studies about the loss in quality, if we apply different workflows, where we incorporate also 2nd and 3rd generation intermediate material.

Why 3rd generation? Since a workflow with Vegas could look like as follows:

- capture m2t material in one long piece

- render to Cineform intermediate (1st generation)

- make an automatic scene separtion in AV-Cutty, render each scene to an intermediate file (2nd generation)

- import of scene files in Vegas, edit and cut material, render to final product (3rd generation).



I would like to compare that with a Gearshift based workflow, where we render "m2t --> final product" only, in terms of quality limitatons. Even if that workflow has the main disadvantage, that up to now we are not able to bring back single scenes to the bin-structure of Vegas, and have to organise the material in the timeline only.

> "Even if that workflow has the main disadvantage, that up to now we are not able to bring back single scenes to the bin-structure of Vegas, and have to organise the material in the timeline only."

Not only in the timeline - don't forget that you can create Regions in the Trimmer, give them meaningful names and sort and have access to these in Vegas Explorer.

I've also wondered if I use Gearshift to create WS DV proxies, how different would DVD MPEG2s rendered from the proxies be compared to MPEG2s rendered from the m2t files.

If there's no answers, in a week or so I'll be doing both so I'll report back ...

Wolfgang/Peter, look for significant (no cost) changes to GearShift in the coming days.
We've been working quite hard on yet another optimization method for this tool.

>>Even after CPU speeds come up, editing native HDV still isn't a good idea, as the format falls apart very quickly<<

DOH! Yes, let me clarify -- I totally didn't take into account intermediate renders! If you're compositing and rendering sections separate from the final render, HDV is totally not the codec you want to be using, you'd be much better off with a more robust intermediate codec such as CineForm.

I was thinking of editing where you keep all the original footage on the timeline, and then perform one final render out to whatever the delivery format is. But definitely you wouldn't want to use the HDV native codec for intermediate renders. And taking that into account, I must retract my foolhardy statement that intermediate codecs would disappear.