36
Antworten
Regard to math, that was my fault...
I wonder how I was able to indulge myself to be so inattentive to such important point ?.. 
One more chance, please !!!
One minute consists of 60 seconds.
6 minutes equals 360 seconds.
8 minutes equals 480 seconds.
8 minutes 10 seconds equals 490 seconds.
490 seconds divided by 360 seconds equals... 
1.3611111111111111111111111111...
1.3611111111111111111111111111 multiplied by 100% equals... 136.11111111111111111111111111% !!!
Harm, did I pass now?
That's nice, lasvideo. 
Why do you think I put lossless in quotes? If the difference between ProRes and native h.264 is discernible by your eyes, it makes me wonder why you would even be shooting in h.264 in the first place. I posted one image of each. Everyone can decide for themselves.
The fact is it takes a lot more time to render out native h.264 than using ProRes footage if you add up every time you render while working on an entire project. So the argument put forth that it saves time to not transcode is false.
And I'll examine the responsiveness of the app itself while working with native h.264 versus ProRes.
Harm Millaard wrote:
If your system (PC of course, MAC's are a different species) is properly equipped, setup and tuned, you get render times that are only a fraction of the time-line length, often less than 5% rendering time of the time-line. So a 8 minute time-line will normally render in about 24 seconds, depending of course on the number and complexity of the effects in use. That number will not increase over time with multiple renders, unless you have an ill-tuned system. Rendering ten times the same sequence does not show decreased performance results.
The time it takes to render any given project is moot. The difference in time it takes to render h.264 native versus ProRes, multiplied by how many times you render during a project, is what matters.
Whether or not my Mac or PCs are 'setup and tuned' is irrelevant.
I exported with 'Match Sequence Settings' that resulted in MPEG files with 'Use Maximum Render Quality' checked. But I used the same settings for both. You want me to try different settings and see if there is a difference? Thanks.
ExactImage wrote:
tallscot wrote:
I just did a quick test. I took 6 clips from a 5D Mark II totally 3:30 and put them in CS5.5.2, applied a color effect (green tint), rendered it out at match sequence settings. Took 6 minutes to render and CPU was at 650% (I have an 8 core Mac Pro).
I took the same original clips, transcoded into ProRes 422 HQ using Compressor, brought those in, copied and pasted the same color effect onto those clips, exported out using same settings. It took 4 minutes 10 seconds to render, 550% CPU.
It took 4 minutes for Compressor to transcode the footage to ProRes. Because of the hit you take every time you export native h.264, I don't think working with native is a time saver, overall. I guess it depends on how often you export. I'd like to do a test for 'real time' playback speed later today.
Attached are images from the resulting movies. The top is ProRes 422 HQ the bottom is native h.264.
Well, it's really not as simple as that in the real world. It used to take us 12-18 hours to transcode followed by x hours editing (lets call that 40) then perhaps another 2 hours export from FCP after which we still needed to compress for DVD.
Now, with Premiere Pro it takes around 1 hour to ingest and conform + 40 hour edit + 1.5 hours export AND compress for DVD.
So, 18+40+2 = 60
1+40+1.5 = 42.5
Tell again me how transcoding saved us time?
You are comparing an older Mac and FCP to a new machine with Premiere Pro? I'm discussing Premier Pro versus Premiere Pro. Your experience with previous versions of FCP are moot now, BTW, because FCP X can edit the native stuff too, or it can transcode it in the background as you edit while it's doing that.
But the point here is Premiere Pro renders native h.264 much slower than it does ProRes on the same machine. So every single time you render out a sequence or anything from Premiere Pro, it till take longer, and all of that adds up. So I'm saying the 40 hours it takes to edit is not 40 hours with both h.264 and ProRes footage. It should take less time with ProRes.
But besides the extra time it takes to render h.264, the editing software itself is slower and less responsive. It's just a fact that the inter-frame codecs, like h.264, require a lot more processing power to present than the intra-frame codecs, like ProRes. It's having to calculate between the key frames, whereas it does not with intra-frame.
That's why Premiere Pro is less responsive when you are editing h.264 versus ProRes. Heck, just scrubbing the timeline in Premiere Pro is a lot less smooth with the h.264 footage than the same footage in ProRes with no effects or titles or graphics. I'm doing it right now. ProRes is nice and smooth, I can scrub around and I'm getting a lot of frames per second. With the h.264 footage, it's having to do a huge calculation and it's very spotty with how smooth it is. It's much slower. As I add more tracks, gaussian blur, etc., the h.264 sequence is pathetically slow, the ProRes is much more responsive. I literally have to wait for Premiere Pro to bring up the h.264 frame that I just scrubbed to.
I just ran Activity Monitor and watched the CPU Usage while editing in Premiere Pro with h.264 and then ProRes, the h.264 sequence had all 8 of my cores maxed out. The ProRes had all of them at around 5%. It's amazing. I've attached screen grabs of this.
AdChoices