streamclip files to big
 

i just got my rebel t2i in the mail today and havent got a chance to use it yet, im still tinkering around with the settings and the workflow. i thought i had the transcoding all figured out but i guess not. i used mpeg streamclip and exported to quicktime using the DNxhd codec, and under the options i chose 1080p/24 10 bit for best quality and my files come out more than 3 times the size of the original file. they work nicely in vegas, but i dont want them to be that big. is there anyway of reducing size without sacrificing quality?

That sounds about right.
The T2i files are AVCHD files, which are very compressed h.264 files.
This is normal for most card based cameras.

You are converting the compressed AVCHD codec to an iframe codec. Which is much better for editing but is considerably larger. Keep in mind 3 times the size of AVCHD is't that bad. As some codecs could be 5 times or more the size of the AVCHD files.

So you choice basically is try to edit with native h.264 files and most likely your computer will start choking on the footage. Or convert to an iframe based codec like you've done and edit easily with it, but take the larger file sizes.

oh, so its to be expected to have large files? i did not know that. i thought i would be able to natively edit the files since i have a core i7 quad core with 8gb of ram, but it plays back jittery in vegas

DNxHD has MANY different bitrates. The bitrate selected is DIRECTLY proportional to the file size you get. If you chose a bit rate that was 100Mbps for instance the file it creates would be exactly twice the size of a transcode to 50Mbps. If you intend to work in HD, you had better get used to dealing with large file sizes. This isn't SD, it's a whole new world. And it's the reason that most people who do real work in HD have several terabyte sized drives.

No, there is not.

Yep.

No. The T2I (and the rest of the Canon DSLRs) do not shoot AVCHD. They DO shoot video compressed with H.264. Yes I am being nit-picky, but let's not put a new user down the wrong path.


Exactly

Your i7, especially with Vegas, won't come close to editing these files natively. And editing them in their native format is a bad, bad idea. Volumes have been written about this subject in the past year and a half. I suggest you spend some time researching and soaking it in. But in short, the correct course to follow, is to transcode the files, and prepare to deal with larger files.

hm, well i looked at the transcoded footage and the raw footage side by side and the transcoded footage looks a hair darker, and looks a little less sharp, is there any setting that i can change so the transcoded footage and the raw footage look exactly the same or is that impossible?

Short answer is you can make them look exactly the same.

Long answer is how much pain are you willing to endure to make them look the same. There are a number of things in the mix here.

1. The Canon HDSLRs are shooting in a color space that is greater than what is legal for video broadcast. Most codecs that you transcode to (including DNxHD) are really designed for broadcast purposes. This can be overcome if choosing the right codec.

2. Vegas is well known for making an absolute MESS of colors. And getting it to NOT do that requires some very careful work. In the end, you are probably going to be modifying this stuff during the edit (or at least you should be) so it's not really so imperative that the transcode look EXACTLY like the source, as long as no *significant" information is being lost. And the word significant means different things to different people.

3. Codecs that retain all the fidelity of the original source code are called lossless or visually lossless codecs. There are three popular ways to get there.

3A. Uncompressed. This method will create and exact replica for every pixel in the original source code in the transcode. I believe for 1080p it is about 12 GB per minute versus your source files' 25 GB per hour. Few people choose this option.

3B. Lossless. This option creates an exact replica of the source using some smart compression techniques. Popular codecs for this work are HuffYUV, Lagarith, PNG, lossless Jpeg2000, etc. Expect your file sizes to grow by 500-800%.

3C. Visually lossless. Codecs like Cineform, Matrox i-frame (high bitrate), Jpeg2000 (high bitrate) and some others fall into this category. These are popular because they create files that are larger than the source, but not as huge as the other two categories.

4. Codecs wrapped in the .MOV container tend to shift colors and brightness. This is called gamma shift. DNxHD is popular because it is immune to this phenomenon.

When you add all these factors together, it becomes clear that this is not newbie friendly. I wish it wasn't that way, but it is. Some of this stuff is quite tricky, and demands close attention to workflow. Sometimes it just isn't worth all the hoops you have to jump through for this, especially when you will be color correcting the footage in post anyway. Just let the minor shift happen, and take care of it along with the 999 other things you need to deal with on the timeline.

Best of luck!

Vegas, Cineform & MXF
 

I have a T2i and Vegas 9.0e. I generally transcode to Cineform of Sony MXF. Both offer excellent quality, reasonable files size, and reasonable transcode times. They look slightly different, each has its own character. Test for yourself.

Thanks for the info Perrone, some good insights there. Would you mind clarifying the statement above? How is 4:2:0 greater than what is legal for broadcast? Are you referring to the fact that the compression is greater in 4:2:0 than in 4:2:2?

Sorry, by this I meant that the Canon cameras can shoot in RBG values that are out of range for broadcast. They can also record into the superblack and superwhite that are illegal for broadcast. Some video cameras cannot do this, and many codecs cannot accept those values.

Does this make sense?

hey david, i heard about the mxf format but im not sure what to do to make it there, do you have to use cineform? explain your vegas workflow, im interested in knowing what you do

MXF is not a format. It's a container like AVI or MOV. It can hold many types of "formats". In the case of Sony Vegas, it is encoding an mpeg2 inside that MXF. Depending on what you're starting with, this might be sufficient, but coming from the likes of a 7D/T2i, this is going to be quite lossy and I wouldn't recommend it. If you were starting with HDV maybe. Or perhaps even HDV. But not from the Canon HDSLRs.

One thing is for sure, it will be nice and fast on the timeline and the file sizes will be either 16GB per hour or 20GB per hour depending on which variant of the MXF codec you choose.

James: part of the confusion may come from the terms colour space and colour sampling.

Colour space references the GAMUT (or complete range of colours available given a colour space - RGB, YUV, CMYK etc)

Colour sampling (3:1:1, 4:1:1, 4:2:0, 4:2:2, 4:4:4) references how the colour part of a Y/C separation format (again, YUV but NOT RGB) samples the colours in reference to the luminance. RGB NEEDS no colour sampling because it doesn't separate out the luminance from the chrominance, but will still have bit depth.

Now I'm completely confused. I've got a 920 with 6GB RAM, a GTS250 w 1GB RAM, and a 150GB Velocirapator.. I've been editing straight from the camera with no problems of any kind.

I did a test to see how many layers of effects and transitions I could lay on before getting "jerky." It was about 5 layers of random effects and 3 transitions. My clips are all around 4-5 minutes with not much cutting.

My biggest problem is rendering. The only output that looks decent is wmv and mts. All others are useless. I tried a few transcodes using streamclip to see if it made any difference but there was none I could see. Understand, my vision is from old worn out eyes but I'm not shooting for broadcast, major motion pictures or even DVD. Just me and the web.

Why is editing native bad? I've not seen a single thread anywhere about this...probably cause I'm looking for video in all the wrong places....?

Thanks,
Burt