Faster workflow with Canon T2i??

Take some t2i footage, cross fade a few clips, adjust the contrast and brightness as well, and if it cuts fine on your machine, then go with it, if you get any problems, do prorez. Or avid's free one if your on pc.
 
I would if I could but my camera's out for the time being. I guess I could find some raw stuff out there. Anyone care to donate?
 
A lot depends on what you tell your program to do. You can avoid transcoding to prores and drop h264 files onto a FCP prores timeline. You would have to then render the timeline before playback.
This would be similar to what Shao is suggesting when he says 'drop the h264 file into an AE comp' because AE will do a RAM preview and it sure won't be holding it in memory using the h264 codec.

Transcoding to prores before editing does not remove artefacts in the original file. It does however provide a very space efficient i frame codec for most online edit situations.

Editing h264 on a final cut h264 timeline can introduce artefacts, I have seen this first hand last summer. It happened to me when I was editing a down and dirty job that I didn't care about.
I threw 7D native files to a timeline, did a cross fade and rendered it out. Uploaded it to vimeo and what a mess. The vimeo flv conversion showed a rainfall of green macro blocks during the crossfade.

I went back to the FCP timeline and without transcoding or re editing I flipped the FCP timeline codec to prores. Then rendered the timeline which means FCP transcodes what it needs and stores it on a scratch disk.
Exported the movie. Crossfade worked fine on vimeo.
 
Of note, and just referring back to my example of the green macro blocks on the crossfade.

What was interesting is the h264 export from the FCP h264 timeline played fine, the crossfade was ok.
But hidden away in that file were frames from before and after the crossfade. You couldn't see them in playback.
Once it was on vimeo and I saw the transcode I could see those frames amongst the green macro blocking !

These ghost frames were the i frames that the crossfade depended on to calculate the B & P frames.
 
J Davis said:
You can avoid transcoding to prores and drop h264 files onto a FCP prores timeline.
Click to expand...

Thanks, this is what I've been trying to say but I'm not really fluent in FCP. To say that using a ProRes intermediate improves color accuracy+quality is only half true. What its really doing is defaulting your NLE/Comp to a higher bit depth project which is actually whats giving you that image boost. As J Davis says, you can tell your NLE/Comp to use a higher bit depth project/timeline manually which gets you the same results although much slower if working with H.264 directly.
 
kevinottawa said:
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.
Click to expand...


!

There are no guessed frames, your computer is not guessing anything !!



kevinottawa said:
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.
Click to expand...



!

Really, there is no guessing anywhere, by anyone or anything, certainly not your computer.


:)
 
Last edited:
marlontorres said:
With the amount grading work I do, I HAVE to covert it to H264.
Click to expand...

I think you've missed the point of the current discussion. You can achieve the same results using the out of camera H.264 files directly so long as you keep your timeline/comp at a higher bit depth. However, doing so will be slow for most peoples computers. It boils down to speed and nothing else. Quality can be achieved in both scenarios.
 
This stuff is just so easy to test...

Take 1 second of video.. ANY kind of video, place it on the time line. Apply some color and luma changes, maybe add a chroma effect.

Render it to a lossless codec
Render it to ProRes / DNxHD
Render it to h.264

Put the lossless file on an upper track. Pull the ProRes onto a lower track and do a difference effect between the two. Then remove that and pull the h.264 onto a lower track and look at that.

Difference will be obvious and immediate.
 
Actually if you have an edit job where you know your selected takes and its a matter of jsut stitching them together and export then I would recommend dropping the h264 files directly onto an FCP prores timeline.
The easiest way to do this is drag an drop and FCP will prompt you by asking to convert timeline settings to match the clip. Select YES. At this point the timeline codec is h264.
Once that is done hit Command 0 and you will see the timeline preferences. Switch the timeline codec to prores or whatever you want. You will not be able to playback without rendering.

If you have heavy edits a transcode before hand can make it easier.

Here is a Case scenario.
I'm currently on a huge edit job for a green screen music video I shot on a 7D. 80% of all the shots are green screen. Also to complicate things 70% of all the shots are 720p60 the rest are 1080p24.
So I have ...
1080p24 green screen
1080p24 non green screen
720p60 greenscreen
720p60 non green screen.

Keying will be done in after effects, grading done in color. There is 70 gig of native h264 files from the 7D that will culminate down to a 3 minute video clip. This is a pain in the ass workflow scenario.

My workflow is to leave it overnight transcoding to prores LT. From here I edit leaving all filenames untouched and I rename and sort the files in the FCP project bins. Having an i frame codec to scrub with the
playhead in the viewer, on the timeline is wonderful. Especially when there is a cut every second like in a music clip. Slowly I can sort thru what clips are garbage, what clips contain something useful.
The slo mo stuff stays at normal speed until I need it. If I deem it necessary I use the OS to dupe the relevant prores LT clip adding '_slo' to the end of the fliename then use cinema tools to conform it.
These then get added back to the FCP project bins. This way I have the file at hand at both speeds and I have great flexibility in edit.

I'm almost done with my edit, but when its done I will know exactly what clips I will need to be transcoded to proresHQ and/or sent to AE for keying etc.
Sending all files as proresHQ to color will be final steps.
 
Last edited:
PerroneFord said:
This stuff is just so easy to test...

Take 1 second of video.. ANY kind of video, place it on the time line. Apply some color and luma changes, maybe add a chroma effect.

Render it to a lossless codec
Render it to ProRes / DNxHD
Render it to h.264

Put the lossless file on an upper track. Pull the ProRes onto a lower track and do a difference effect between the two. Then remove that and pull the h.264 onto a lower track and look at that.

Difference will be obvious and immediate.
Click to expand...

You're talking about something totally different. We're not comparing output codecs.

H.264 > ProRes Intermediate > Grade (in ProRes Timeline/Project) > Lossless - should look exactly the same as:
H.264 > Grade (in ProRes Timeline/Project) > Lossless
 
Last edited:
oh ... and here's a sneak preview frame grab from an outtake :)

negSpaceThumb.jpg
 
Lee Wilson said:
!

There are no guessed frames, your computer is not guessing anything !!

Really, there is no guessing anywhere, by anyone or anything, certainly not your computer.


:)
Click to expand...

t2i and 7d are Long GOP cameras
• I-picture (Intra): An individual compressed frame with no relation to other pictures. It is independent and can be decoded without reference to any other frame. An I-picture is compressed using spatial compression but does not rely on temporal compression.
• P-picture (Predictive): These pictures use the previous I or P picture for motion compensation and reference for prediction.
• B-picture (Bi-directionally predictive): These pictures contain the least amount of information and use the previous and next I or P pictures for motion compensation.
Click to expand...

P and B frames are guesses
 
kevinottawa said:
t2i and 7d are Long GOP cameras


P and B frames are guesses
Click to expand...


I would use the term 'calculated' frame rather than 'guessed' frame but I think
we would agree on the fact that B and P frames are not real frames.

As an FYI for everyone else, there are only two I frames (or real frames) per second in h264. So in 24p the other 22 are B + P frames that merely describe
how the groups of pictures (g.o.p) from the I frame are moved around.
 
kevinottawa said:
t2i and 7d are Long GOP cameras

P and B frames are guesses
Click to expand...

Yes but that doesn't have anything to do with the topic at hand. Any calculation used to derive those frames for ProRes transcoding can be used to decode them in realtime. I don't see any disconnect other than speed.
 
shaocaholica said:
I think you've missed the point of the current discussion. You can achieve the same results using the out of camera H.264 files directly so long as you keep your timeline/comp at a higher bit depth. However, doing so will be slow for most peoples computers. It boils down to speed and nothing else. Quality can be achieved in both scenarios.
Click to expand...


Yep !

+1

The only reason everyone is not working with the original files is mainly computer speed (and a little bit of mythology!).
 
kevinottawa said:
t2i and 7d are Long GOP cameras
Click to expand...

H.264 is a long GOP codec, yes.


kevinottawa said:
P and B frames are guesses
Click to expand...


No they are not guesses, nothing is being guessed at all, the codec records a full reference frame (compressed only spatially) and then references this frame (looking for changes (within a threshold)) for the in-between frames - (which render this temporal calculation spatially) - this carries on frame by frame until the next full frame.

The way these in-between frames are calculated is not a guess, but a known and precise calculation.

We might be talking cross purposes here and you might be using the word 'guess' to mean estimate ?
 
You must log in or register to reply here.
Back
Top