T2i Transcoding troubles with premiere CS5 and Vegas 9

[skatethrasher]

So I got my T2i yesterday and have taken plenty of pictures, but the main reason I got it was for video as well. I'm having trouble editing in both Premiere CS5 and Vegas 9.
I have transcoded to DNxHD 220 10 and a default Avid setting. Both are lagging quite a bit, especially in Premiere, even without CC.

My computer specs are:
Windows 7x64
Intel Core 2 Duo E5300 @ 2.6 gHz
4 GB Ram
500GB Hard Drive, with another one coming soon

Vegas seems to be working better when I change the project settings to 8 bit, from 32. Its somewhat bearable editing one clip, but it could be better, I must be doing something wrong.

EDIT: I'm filming in 720p 60fps, I like the look of 60fps and I'm mainly filming skateboarding so far

 

[deltoidjohn]

I've never used DNxHD so I can't compare it directly, but I can say that Cineform works nicely on my laptop which is a Core 2 duo 2ghz with 4gb ram, using CS3 & Vegas Pro 8.

I know it's not free, unlike DNxHD, but so far I've had no troubles or complaints about it.

Given that you have a faster processor and newer software, I'd expect your performance would be alot better than mine.

 

[skatethrasher]

I downloaded a trial of it, but i cant remember what settings i used, i looked on a website for help.
What settings do you use for Vegas?

 

[PerroneFord]

Well,

First, DNxHD 220 10bit is WAY overkill here. DNxHD 115 is far more suitable to what you are doing. And actually DNxHD 175x is the top bandwidth used for 24p material, so I am surprised it's working at all since 220 is for interlaced 60i material.

Second, your machine is a bit on the slow side to be cutting big HD files. It should work, but don't expect blazing speed out of it.

Third, if you only have a single drive, forget it. Your machines is trying to read and write to the same drive, AND you have your OS on their two, so performance is going to stink.

Cineform is nice, but it's only real advantage at the lowest price point is smaller files. If you were buying the more upscale Cineform, then that's a different story.

 

[steventimothy]

Your computer's not well spec'd for HD video. Adobe recommends a minimum of 8GB of RAM, for example, and your processor is on the slow side.

Also, with CS5, why transcode when you can work in the native codec? Just select one of the DSLR settings, matching your footage.

 

[PerroneFord]

Also, with CS5, why transcode when you can work in the native codec?

Because the native codec breaks down, is 8-bit, and causes a performance hit. Testing continues to show that transcoding to a 10-bit, robust editing codec increase performance and provides better color and dynamic range.

Why transcode? Because it makes your work better. Of course, some people aren't interested in better. Just faster.

 

[skatethrasher]

Oh good thing i ordered another hard drive today, whew. I figure my computer wouldnt be super fast, but at least workable.

So should i transcode to the lower DNxHD format at 10bit? I think its 115. Should I start saving up for Cineform as well or is this going to do the job?

 

[PerroneFord]

115 is JUST fine. In regards to Cineform... I tried it for a week or so. Found the free DNxHD codec just as good, and better in some regards. Cineform has two significant advantages:

1. It makes slightly smaller files.

2. It puts that 10bit codec in a .AVI container. The .MOV container has been a problem on some PCs in terms of performance. I am hearing reports that Vegas 9.0e and the newest quicktime are playing nicely though.

I wouldn't concern myself with Cineform unless you absolutely NEED to go that way. At one time it was a near necessity to work with these HD files, but that is fading quickly. Especially in the .MOV container.

 

[steventimothy]

Because the native codec breaks down, is 8-bit, and causes a performance hit. Testing continues to show that transcoding to a 10-bit, robust editing codec increase performance and provides better color and dynamic range.

Why transcode? Because it makes your work better. Of course, some people aren't interested in better. Just faster.

It's a little presumptuous to presuppose that people that don't transcode aren't interested in better and/or faster.

I haven't heard of any CS5 PPro users transcoding their footage. For myself, with the Cuda technology there's no performance hit.

Could you point me to some tests comparing transcoded, processed footage to native codec, processed footage? I haven't seen that yet.

You'd take a hit in the quality of the footage on the first transcode (unless it's uncompressed), so I don't see how you'd magically gain quality in the footage. If you're processing the hell out of it, you might be in after effects or composite, in which case you can work in a float mode anyway.

Also, although you might gain some speed in working with non-GOP footage, why duplicate your footage, eat up drive space, spend time and CPU cycles transcoding, etc. etc. when there's no need?

 

[PerroneFord]

It's a little presumptuous to presuppose that people that don't transcode aren't interested in better and/or faster.

Doesn't apply to all, but applies to a great proportion of the people I've spoken to about it. Quality has never been a part of the conversation. It's always been the fact that transcoding takes too long, or uses disk space, or some other convenience factor.

I haven't heard of any CS5 PPro users transcoding their footage. For myself, with the Cuda technology there's no performance hit.

That doesn't surprise me.

Could you point me to some tests comparing transcoded, processed footage to native codec, processed footage? I haven't seen that yet.

http://www.zacuto.com/shootout (Episode 3). But this merely confirmed what I'd seen for myself.

You'd take a hit in the quality of the footage on the first transcode (unless it's uncompressed), so I don't see how you'd magically gain quality in the footage. If you're processing the hell out of it, you might be in after effects or composite, in which case you can work in a float mode anyway.

As soon as the footage is manipulated (color changes, contrast, etc.) the 8-bit color space will start to show it's limitations. This is precisely why people want 10-12 bit sources, and for color grading, people are moving into 12-14 bit color spaces. Getting out of that 8-bit color space absolutely makes a difference.

Also, although you might gain some speed in working with non-GOP footage, why duplicate your footage, eat up drive space, spend time and CPU cycles transcoding, etc. etc. when there's no need?

Well, the issue of "need" is subjective. Why do people scan film at 4k when they are going to release at 1080? Why do people color on 10 or 12bit files when they are going to finish to BluRay or DVD? Why are people so interested in high bandwidth acquisition from DSLRs when they are just going into 8-bit 4:2:0 codecs?

Your "needs" may well be different from mine, and that's fine. But I prefer the results I get from moving my material to a better codec.

 

[steventimothy]

Doesn't apply to all, but applies to a great proportion of the people I've spoken to about it. Quality has never been a part of the conversation. It's always been the fact that transcoding takes too long, or uses disk space, or some other convenience factor.

That doesn't surprise me.

The problem is that you may be convincing people that they will get better results by transcoding, instead of using the footage native in Premiere Pro CS5 for their work. That, IMO, is incorrect.

As for your points:

http://www.zacuto.com/shootout (Episode 3). But this merely confirmed what I'd seen for myself.

The shootout is null because they had to transcode, they weren't using CS5. If you have to transcode, of course it's better to upconvert. Also, their colourists were probably working with apple colour, 3rd party hardware (davinci) or Autodesk stuff, all of which require transcoding (because it's not Premiere CS5 or other Adobe sw). The colourists could produce similar results from CS5, probably, which would have resulted in a better image I think.

As soon as the footage is manipulated (color changes, contrast, etc.) the 8-bit color space will start to show it's limitations. This is precisely why people want 10-12 bit sources, and for color grading, people are moving into 12-14 bit color spaces. Getting out of that 8-bit color space absolutely makes a difference.

Upconverting footage doesn't mean you'll get better results in a grade, necessarily. Also, CS5 works internally with some of its tools (like cc) at 32 bit float, even if the footage is only 8 bit. Other than colour correction, what are filmmakers really doing in the timeline of their editing software? If you've got motion tracking, keying, roto, etc., OK, I grant you, you have to transcode. But most users, I venture to say, aren't doing those things.

Well, the issue of "need" is subjective. Why do people scan film at 4k when they are going to release at 1080? Why do people color on 10 or 12bit files when they are going to finish to BluRay or DVD? Why are people so interested in high bandwidth acquisition from DSLRs when they are just going into 8-bit 4:2:0 codecs?

IMO, if you know you're only releasing something at 1080p (NOT theatrically), but you scan your film at 4K anyway, that's folly, but it's your money. The scanning and handling of those images can cost millions. Anyway, it's NA to most of the users here, I think.

Your "needs" may well be different from mine, and that's fine. But I prefer the results I get from moving my material to a better codec.

Just as a fun example, give me any workflow you'd like, and I'll give you two stills, one from CS5 in native and one in a transcoded format of your choice. Give me any effect you want that you'd do inside an editing program that someone here would use (ie, not Smoke).

Upconverting is great in a complex workflow where the footage gets touched by lots of different people, but I don't think that applies to the original poster or most other people here. I think that, if you have CS5, doing it just wastes time and hard drive space, and doesn't give a better result.

 

[chromatic]

I would just like to say Steve is correct about the shootout and Premiere Pro CS5 handling native Canon DSLR video. PP CS5 was not released and not tested during the shootout. Also, as stated above, Adobe claims that once DSLR footage is in the timeline it is no longer really 8-bit and being manipulated by a 32-bit floating point process.

I personally would like to see a fair direct comparison of native Canon DSLR video in Premiere CS5 versus transcoded to Apple ProRes, Cineform Neoscene, DNxHD, and the new Matrox vfw codec.

Until we see a real test like that it's all speculation as to which is better.

This is a question and answer from Gary Adcock in the comments about the shootout test.


"Does converting to newer codecs (Cineform, DnxHD or ProRes, as mentioned) have any advantage over editing natively for example with Premiere Pro CS5 (and soon AVID)..?

Release versions of Adobe CS5 nor the AVID importer for h.264 existed when the tests were being shot and compiled- I only do tests with released real world tools as not to violate my Non-dislosure status with any of the companies involved. So no there is no info on those workflows at that time-

I have mentioned the CS5 workflow for h.264 format content is the most sophisticated that currently exists, thanks in part due to the AE conversion engine. What Avid will do may change and the v5 software has not yet been publicly released to test."

 

[chromatic]

skatethasher, I've found Premiere Pro CS5 works well with the native Canon footage, why don't you give it a try and don't bother with transcoding.

 

[PerroneFord]

Vegas has had a 32bit float engine for several years, and I've colored at least 4 films using it over that period of time. Vegas 9, released last summer has handled native 5D/7D footage since it's release and I have colored one film shot on a 5D in that time.

Perhaps CS5's 32bit float engine is magically better than Sony's. And perhaps you guys are right.. there is no need to transcode. The original poster asked about CS5 *AND* Vegas. So I will defer to you guys on the CS5 side.. but I absolutely stand by what I've said if he is planning to take his work through Vegas.

Further, if the OP said he is having struggles with this HD footage in it's current DCT based i-frame codec, are you thinking he'll get BETTER performance using highly compressed H.264 on the timeline? Especially since it seems he doesn't have the hardware spec to meet the Mercury Playback engine needs?

 

[skatethrasher]

Okay, so I transcoded the same file twice.
Once to 720p 59.94 DNxHD 220 10bit
Once to 720p 59.94 DNxHD 145 8bit (Theres only 8 or 10 bit choice when using 220)

I imported Raw file and both transcoded files onto a Vegas timeline with same Color Correction on each.
The Project Settings are
Custom (1280x720, 59.940 fps) at 8 bit Pixel Format

The two transcodes seem to be exactly the same when playing back, they are okay to edit with, but the Raw is choppy and laggy.

I changed the Pixel Format to 32 bit FP full range and all are extremely laggy and choppy.

EDIT: On the video playback display I get about 35 frames per second for the transcodes, and the Raw starts at 20 and drops to 5 in 6 seconds.

EDIT EDIT: Its the opposite for Premiere CS5. The transcodes are horrible and the Raw is workable (With and Without CC)

 

[steventimothy]

Try outputting a still on each one (original codec and transcode) from CS5, and see which one has better quality. Do a little CC on each clip (chose one of the 32bpp effects).

You can output a still by clicking on the icon that looks like a camera below the program viewer.

Also, maybe call the camera format "original file" or something as it's not a raw image.

 

[skatethrasher]

I looked at the Original File and a DNxHD file of the same video still (the last frame) on just quicktime, and the image is much different.
There is no difference between 145 and 220, however.

The same thing happened when I exported the last frame from each of the 3 files.
145 and 220 were exactly the same, but much different than Original (Without CC)

And again, the same thing when 32 Bit RGB curves were applied.

First Image is Original File, 2nd is DNxHD 145 8 Bit, NO CC.

 

[steventimothy]

Neither of those images was colour corrected, right? If so, the converter is creating quite a gamma shift... might want to check the settings.

 

[skatethrasher]

Neither of those images was colour corrected, right? If so, the converter is creating quite a gamma shift... might want to check the settings.

No CC. Nothing is changed in MPEG streamclips "Adjustments"
I changed the color levels to the "RGB" Button from "709"
Same thing. I looked for other adjustments, but didn't find anything that would change it.

 

[PerroneFord]

Yep, that's linear gamma vs. 2.22... seen it a billion times. Whites are identical, but all the grays and blacks are pushed up. Fortunately, it only takes like 10 seconds to correct, but it's still a pain.