Faster workflow with Canon T2i??

N.E.S.

Carbonite Member
I have shot my footage for today and have about 40+ 2 minute takes. I dump all of the .mov files in Mpeg Stream clip and convert to Pro Res 422.


Problem is this easily takes about an hour if not more, is there any way around this?


Thanks
 
As far as I know, about the only thing you can do is get a faster computer. An hour doesn't seem bad at all though. If you had been shooting on tape you would have had to wait 80 minutes just for capturing.
 
Well I guess that's a no..... Since I add FX and many transitions the general rule of thumb is to convert to Pro Res. Thank you people for the replies.
 
I'll second Lee's comment. I too work with H.264 files directly with Vegas Pro. No transcoding, no duplication of files, no wasted drive space.

Sometimes breaking "the general rule of thumb" can prove the rule unfounded.
 
I still don't get why this is better for image quality. I'd love for someone to make a side by side.

It depends on what you're doing. As always. Heavy color correcting and effects seem to render faster in ProRes than h264. Perhaps I ought to do a definitive test.

If you're not really doing anything other than trimming the ends of stuff and just exporting, then sure, don't convert.

Also, my Macbook Pro is 2 1/2 years old gen and simply cannot play h264 files at full fps inside FCP when I go full screen...full screen, they play fine in Quicktime 7 Pro. Something about FCP or my settings maybe. Anyways, ProRes plays fine, even full screen. Larger file, but less processing for playback.

Also, in FCP, you pick the "Compressor" codec for the timeline. I'd prefer to have stuff crunch into ProRes than h264, BEFORE I even get to the export compression.

Pick your poison.
 
Last edited:
Pro res isn't better for image quality, its better to edit with. When you start to do fancy things to the footage it breaks up and makes weird artifacts in its native form.
 
This is the part I don't understand how an intermediate codec can alleviate. Artifacts just don't go away when you transcode it.

No one says that they go away. Main reason is for a smoother editing experience. If you can't tell a difference, by all means, use the native files.
 
It seems to me there could be 2 benefits to transcoding to ProRES:

First off, as people have mentioned, ProRes is a more CPU-friendly codec, less work for the CPU means quicker effects

Secondly, transcoding will never create data where it didn't exist before, but color correcting, for example, in a broader, less compressed color space and codec should allow you to make greater adjustments without all of the added artifacting of repeated 264 compression steps. I agree that a test would make all of this more clear.
 
This is the part I don't understand how an intermediate codec can alleviate. Artifacts just don't go away when you transcode it.

Agreed, I think ProRes has it uses (its a good near lossless codec for play back on old machines) - but beyond that no real advantage if your machine can handle the native H.264 files.
 
It seems to me there could be 2 benefits to transcoding to ProRES:

First off, as people have mentioned, ProRes is a more CPU-friendly codec, less work for the CPU means quicker effects

Secondly, transcoding will never create data where it didn't exist before, but color correcting, for example, in a broader, less compressed color space and codec should allow you to make greater adjustments without all of the added artifacting of repeated 264 compression steps. I agree that a test would make all of this more clear.

?

What are these repeated 264 compression steps that add artefacting ?
 
...but color correcting, for example, in a broader, less compressed color space and codec should allow you to make greater adjustments without all of the added artifacting of repeated 264 compression steps. I agree that a test would make all of this more clear.

But the input codec doesn't define the color space. Your NLE/Compositor project works in a specified color depth and space independent of the input codec. You can perform 32bit floating point color math on a 8bit 4:2:0 H.264 input without using a 32bit 4:4:4 intermediate. You just need to set your project accordingly. Once your NLE/Compositor has decoded a frame, it could care less what the restrictions are of the input codec.

Take this easy example. Drop a H.264 straight from camera file into an After Effects comp. Set that comp's color depth to 32bit and apply some color effects and transitions. That should NOT look any different in final output than if you used a higher bit depth input derived from the same H.264 source. Sure it might scrub slower with the H.264 but thats purely speed and not image quality.'

I think people are thinking that the color depth of their projects is locked into whatever the source codec is which is incorrect. Most NLEs and Compositors can convert 8bit sources into 16bit and 32bit on-the-fly if set correctly. Thats the same as using a higher bit depth intermediate only without the extra disk usage.
 
Last edited:
This is the part I don't understand how an intermediate codec can alleviate. Artifacts just don't go away when you transcode it.

Most of the frames right from the camera are guesses, so when you tell your computer to guess what two guesses would look like if they were mixed together there is a lot of room for error, and that's where new stuff creeps in.
When you put it to prorez, your taking a snapshot of the guessing frames, so its better to mix those then to mix guesses.

Its like if you had 2 photos, one with a man on the left side and one with a girl on the right side, and someone asks you to draw what would it look like if they were combined in the middle?
Now you have an apple on the left and photo of an orange on the right. And they ask you what would it look like if you combined those in the middle.

Now here is where they tricky part comes in, they ask you to combine both the man/woman and apple/orange pictures, with just looking at the 4 original pictures and not at the combined pictures.
So you take your wild guess and there is room for you to be so wrong.

Converting to prorez keeps the picture of what they look combined, so it has a better shot and combining more mutant pictures.

So its not about artifacts going away, its about not bringing new ones in.
 
Most of the frames right from the camera are guesses, so when you tell your computer to guess what two guesses would look like if they were mixed together there is a lot of room for error, and that's where new stuff creeps in.
When you put it to prorez, your taking a snapshot of the guessing frames, so its better to mix those then to mix guesses.

Its like if you had 2 photos, one with a man on the left side and one with a girl on the right side, and someone asks you to draw what would it look like if they were combined in the middle?
Now you have an apple on the left and photo of an orange on the right. And they ask you what would it look like if you combined those in the middle.

Now here is where they tricky part comes in, they ask you to combine both the man/woman and apple/orange pictures, with just looking at the 4 original pictures and not at the combined pictures.
So you take your wild guess and there is room for you to be so wrong.

Converting to prorez keeps the picture of what they look combined, so it has a better shot and combining more mutant pictures.

So its not about artifacts going away, its about not bringing new ones in.

This is about the most complex analogy I've read:happy:

Think about it digitally. Any digital transform (with respect to video) can be performed at any stage in the pipe. Theres no reason why the prores specific algorithm for converting to a higher bit depth can't be performed in real time without the need to actually write out the intermediate file. This is exactly what many NLEs, compositors and image editors do when the project bit depth differs from the source bit depth. Nothing I've read so far justifies the use of intermediate files other than speed. I still haven't been convinced on color depth fidelity when its already possible to do it on the fly. And what you've just said doesn't really prove that on the fly algorithms are worse because technically they can be the same.
 
Back
Top