I've used the Sony YUV codec several times to capture from Digital Betacam using the BMD Decklink card. with V7. I believe this functionality is temporarily broken in V8. SCS said in the last 24 hours that this will be fixed and they will support the latest drivers from BMD.
The SonyYUV codec is very good for other things as well.
I guess we should also include the CF codec(s) as well, Cineform are nothing short of brilliant.
Most professional formats have a deck with SDI output... which Vegas will ingest (through an Aja or Blackmagic card).
Digital betacam is pretty ingested via SDI... no system edits it natively as far as I know. HDCAM can be ingested natively, but all the systems that do that are dead/discontinued.
2- In some other workflows, you might be dealing with data formats like DPX, TIFF, openEXR. AFAIK Vegas only supports TIFF... and it may not support 16-bit TIFF so you are limited to 8-bit TIFF.
Cineform does SD resolution really well. The main advantage of it over the regular DV codec is the better colorspace. I personally can see no reason to use uncompressed over Cineform for SD mastering. Cineform looks like uncompressed, suffers no noticable generation loss, and is a lot smaller than uncompressed.
Sony provides an 8 bit and a 10 bit YUV codec. Vegas can also use other codecs, some of which are free. For example, BMD provides a set of free codecs on their web site.
Vegas can work quite well with uncompressed AVI files, the problem is that you need a LOT of storage space and throughput. Uncompressed AVI doesn't require much CPU grunt because there's no decompression work to do.
There's very little reason to do a project entirely in an uncompressed format. Uncompressed can be very useful for compositing where you want to minimize artifacts until the final render, but because it's so demanding in terms of storage space and throughput I think it's not so commonly used for day-to-day editing.
If you are trying to settle on a codec to work with, there's no better way to find out than to run tests. Testing things for yourself is de rigueur in this business.
You need to know:
--What media can be provided to you?
--What can Vegas can open?
--What translating software you might need to open the media (Raylight, for example)?
--What additional hardware Vegas may need
----RAID array
----RAID controller card
----I/O card like BMD or AJA
----Audio card?
----What slots does your mbd need to support all this?)
--How does Vegas perform once you've got the right hardware?
--How are you going to output and deliver the final product?
--Do you intend to send everything out for audio sweetening in Protools? (Most of the human talent for this job is using Protools)
Anyway, you need to test. Vegas can use most codecs that you can install on your system as VFW or Quicktime codecs. That doesn't mean they're all going to be easy to work with.
It looks like VP8 can now read and write 10-bit codecs if you need them, but that might put you on the sharp side of the bleeding edge right now.
Rob you wouldn't happen to know the answers to all those questions would you?? j/k
I'll give a brief description of the project at hand.
We record a 3 camera + line edit shoot of an hour long church service to be later edited down to 30 minutes.
We currently use 5 Macs that capture via SDI into DVCpro50 computers 1-3 are ISOs, 4 is the line edit, and the 5th one serves as a backup that can be patched to replace any computer that fails.
The drives recorded on are removed and taked for post production.
Graphics are made in After Affects
Other segments are done outside, usually on Avid, and rendered to DVCpro50
The video is put together in FCP
I then get an OMF which I convert to AAF in Nuendo, then sweeten in Vegas. I also get a QT of the video as a reference track.
A stereo file is rendered and sent back to be dropped into FCP, then a DVCpro50 is printed for US distribution, and DVcam for Europe.
I am one of those oddball humans that doesn't use protools. I have a very streamlined and efficient audio workflow that PT doesn't support.
My goal is to continue to use the huge investment of MACs to capture, but do all post production in Vegas. Then output via SDI to the DVCpro50 deck
I mentioned uncompressed because it works with both MAC and PC.
To further complicate matters the MACs are G5, not Intel.
I suppose I could capture uncompressed, then as I copy them to the RAID use NEO to create the Cineform file.
Ah! Lot's of good info there. The nice thing about DVCPro50 is that it doesn't have much of a throughput issue. The bad thing is that it's relatively proprietary and if FCP created the DVCPro50 files then as far as I understand it Apple has locked you to their platform. FCP's version of DVCPro50 isn't readable in a lot of other systems, afaik.
Also, I'd think that if you had a Xena card in your Vegas system then you could easily output to the DVCPro deck. That part of the workflow shouldn't be a problem.
Others are going to give you better advice based on real experience. The one thing I can say is that because you bring everything into the machines via SDI you can encode in any codec that both Vegas and FCP will support. This site gives a lot of interesting info about codecs for FCP but it might be out of date: http://www.onerivermedia.com/codecs/
You might need to do a bit of research to find a codec candidate that both Vegas and FCP can work with. Avid has some codecs that are free to download, and so does Blackmagic. Maybe AJA has something you could use in common...In fact I see a mention there of apple's MJPEG-A codec. I just rendered one in Vegas and it seems to play well and it looks fine. I'd try outputting that from your FCP machines and seeing if Vegas can play one that FCP made.
Exactly. In Vegas and in NTSC, use the NTSC Standard (720x486) template for footage captured via SDI.
My shop doesn't use Vegas, but we've been shooting everything in DV and then ingesting over SDI for the last 10 years or so. Everything comes in at 720x486 and is saved in a non-DV format. Very similar to what you're doing.
I think that after you have edited the NTSC Standard project at 720x486 then maybe the way to get the cropped render is to take that final 720x486 render and drop it into an NTSC DV 720x480 timeline. Then you'd do the cropping via track motion<EDIT--That's WRONG. If you have just one rendered file omn the timelinre then you can easily do the cropping with Event Pan/Crop >. I don't see a means of cropping during rendering. If you're running both decks at once from the same SDI stream then maybe the cropping gets handled at the deck, if that's possible. Seems like you're streamlining your workflow at the aquisition end so this wouldn't surprise me.
Also, I compared the render sizes of a DV25 clip and an mjpeg-A render of it (at 100% quality). It didn't really seem to be all that much bigger. Definitely usable on a fairly modest Vegas system (no array), although if you're outputing uncompressed from AEFX (because you want an alpha channel()then you'd want a disc array anyway.
From one river media it looks like the SheerVideo 4:4:4 codec would be awesome. At 12.5MBps it is twice the bandwidth of DVCpro50, but teh qualty is completely lossless. They say it uses very little CPU to decode.
I emailed the SheerVideo people to see if it will work in our situation.
Also I'm glad you guys are helping me wrap my head around the whole 480 vs 486 pixel issue. It's little details like that then when combined can really screw up a video.
That is why I am so baffled by the whole HVX-200 thing. The CCD is one resolution, the file is another oddball resolution and then it finally gets converted to 720p or 1080i. It's amazing that after all that it still looks good.