I'm rendering a 1-1/2hr performance to SD DVD mpeg using the AME thru PPro CS5. The project contains 1 track of 1080p avchd video from a GH2, and 2 trks of HDV from an FX-1, the 3rd trk rarely used. Most of the final footage, at least 2/3rds, is HDV. Few transitions, a little CC, not much.

I'm rendering on a Intel 9450 quadcore with only 4 gigs of RAM. Mobo is ASUS pk5c and graphics card is Nvidia 280, hacked for the MPE. (It actually chugged along in realtime with 1/2 rez during editing, yeah!)

So, should this take 30-40 hours to render? Is there anything I can do to improve performance?
( BTW, I tried rendering the project in Encore vis-a-vis the link. It worked except the transcode hung on some 'PProHeadless.exe' thing.) So I tried directly out of PPro. Seems to have the quadcore pinned at 100%.

Eric,

To avoid confusion about your terminology, rendering is used for previews of the time line. What you are doing is encoding to MPEG2-DVD.

Encoding is very much a CPU bound process, without the benefits of hardware MPE. Your CPU is running at full speed, partly caused by lack of memory.

The time indicator of AME is not to be trusted. At one moment it may say X hours remaining, then 0.5X and then in an instant goes to 2.0X hours. So the actual figure may be quite different.

Your system is around 20 - 30 times slower than a fast system, so you have to compare your 30 hour figure to a one hour figure on a fast system, which is better than real time.

Harm, thanks for the terminology correction. I wanted to check to make sure that I wasn't doing something odd, it's my first time using AVCHD. With just HDV footage these were encoding 1-1/2 - 4X project length. Big difference! And I knew that using the CS5 w/MPE was a gamble on such an underpowered machine, but it did work for th editing part and got me back to PPro from Speed Edit.

Eric,

I agree with Harm. Your system simply does not have enough CPU muscle or RAM to compete with a fast system. Also, the P35 chipset's memory controller is limited to 2GB modules or 1GB per rank. What's more, the Asus P5KC motherboard that you're using is a hybrid DDR2/DDR3 motherboard, which has its own issues: It has only two DDR3 slots but four DDR2 slots. You cannot run both DDR2 and DDR3 memory on that motherboard simultaneously. You can only expand memory beyond 4GB if you are using DDR2 memory -- but DDR2 memory modules now cost nearly double the price as an equal amount of DDR3 memory. Plus, with a maximum memory capacity of just 8GB and the almost complete lack of PCI-e lanes (in fact, the P35 chipset provides just 20 PCI-e 1.0 lanes plus the four provided by the non-R version of the ICH9 on the P5KC), the P35 chipset isn't well suited for the demands of CS5.

As for GPU acceleration, it is indeed used for resizing and scaling functions if you are encoding directly from the Premiere Pro timeline. Otherwise, in AME alone, this resizing is done entirely with the CPU. This point is moot because the GTX 280 is using only 16 of those 20 lanes -- and running at the lower PCI-e 1.0 bandwidth to boot. This means that the MPE GPU performance will suffer significantly -- in this case, about four to six times slower than a fast system with proper PCI-e 2.0 functions.

Eric,

for GPU assisted rendering try file->export from the premiere timeline and instead of clicking on "queue" after choosing your export settings, select "export". In my experience this results in 2-5x faster rendering.

Luis,

Rendering has nothing to do with exporting. Rendering is only for previewing the time line.

Exporting and thus encoding is a completely different and unrelated thing, just as washing your car and driving it are unrelated and completely different.

Exporting directly or via the queue can result in slight performance differences, but nowhere near 2 - 5 times. Sometimes it is faster, sometimes it is slower, but generally they are about the same, at least that is what Adobe wants it to be. Depending on the export format used you may get slightly better results with one approach, with other export settings it may be the other way around.

Luis,

Rendering has nothing to do with exporting. Rendering is only for previewing the time line.

Exporting and thus encoding is a completely different and unrelated thing, just as washing your car and driving it are unrelated and completely different.

Exporting directly or via the queue can result in slight performance differences, but nowhere near 2 - 5 times. Sometimes it is faster, sometimes it is slower, but generally they are about the same, at least that is what Adobe wants it to be. Depending on the export format used you may get slightly better results with one approach, with other export settings it may be the other way around.

That does not happen in my system. In fact, in my system exporting via the queue took six times longer than exporting directly, when it comes to HD-to-SD encodes from HD AVIs. It could be something wrong with some part of my system.

I havent used Premiere Pro for a while but I have to say IF your "Exporting" Not rendering and IF you project settings are correct. With a quad core I cant see a 1 1/2 project taking more than 6 hours at the most. unless mixing the footage is causing issues. I have a i-7 quad core and I can export to BR and little slower than 1:1 maybe 1.5:1.

Call it what you will.
In my book rendering means taking data, applying mathematical magic to it and saving the resulting modified data.

Anyhow, I remember reading someplace that in CS5, adobe media encoder doesn't use the GPU for encoding but Premiere Pro does so when used by means of the export button instead of sending the project to adobe media encoder by means of the queue button. The encoding times reflect this and I can hear the fan on my gpu spin up when exporting directly from premiere. AFAIK, by means of this method the gpu is not only used for scaling and effects acceleration, but also for encoding GPU supported formats such as h.264 (I can't remember the list of gpu assisted formats, but not all are.)

In any case, I've been getting a lot more sleep ever since I found about this ;)

From the tests I ran Media encoder when exported through Premiere does use the gpu. I only have a GTS-250 but I get about a 30 percent improvement over CPU alone.

I still have 14 hrs to go before my render finishes. So until then, I can't test on a short project. I am VERY aware that my system is 'underpowered', as well as the quirky RAM issues. it will probably be upgraded/replaced this summer.

In the meantime, regardles of terminology conflicts, the final encoding/rendering/export of the project discussion seems to be giving up some different assumptions, both as regard the export/qeue button and the involvement of the GPU. There is a clear order as to how After Effects renders its layers/effects, etc. PPro seems to be a mystery, especially with the MPE. And would/could the preview renders ever be 'applied' to the final 'encoding' assuming that the project sttings were the same through-out?

Luis,

Rendering has nothing to do with exporting. Rendering is only for previewing the time line.

Exporting and thus encoding is a completely different and unrelated thing, just as washing your car and driving it are unrelated and completely different.

Exporting directly or via the queue can result in slight performance differences, but nowhere near 2 - 5 times. Sometimes it is faster, sometimes it is slower, but generally they are about the same, at least that is what Adobe wants it to be. Depending on the export format used you may get slightly better results with one approach, with other export settings it may be the other way around.

Wrong. As other have pointed out, exporting directly is a lot faster than using queue.
I don't know what the correct explanation on this matter is but I've heard that when Premiere encodes timeline, it first renders the said timeline then encodes it. So, when CUDA MPE is used, it boosts overall encoding process as it offers superior rendering process.

Wrong.

Testing with three different export settings, H.264-BR, MPEG2-DVD and AVI, results in these differences,see figure below.

The conclusion is obvious: Exporting is faster than the Queue, only for AVI, for other formats Export is slower than the Queue.

Where is your "a lot faster..." ???? It just is not true.

CUDA is only used for scaling, blending and certain effects. All the encoding is done by the CPU. Of course the CPU hands over to the GPU the scaling, blending and certain effects and waits for the GPU to finish before it can start encoding. This is not normally referred to as rendering. Rendering is used to create preview files, which is not the case here. But that is more a terminology issue.

What matters is that CUDA/MPE only helps reduce the total encoding time if there is scaling, blending or CUDA effects on the timeline.

As you can see from the figure below, total encoding time is positively influenced by the scaling (MPE accelerated) in the MPEG2-DVD encoding, despite the higher quality of the encodes than software MPE.

Harm Millaard, You're wrong.

Premiere's encoding process DOES use CUDA MPE. Look at my test below and test it out yourself.

Computer: i7 860 @ 3.6ghz. 8gb of RAM, GT 240 DDR3 (It's not a DDR5 version so it's around 4-5 slower than DDR version.)
Source: 15.19 sec, 24fps, 1080p, 5d mk2 H.264 clip
Export Setting: 720p, VBR 2pass; 11mbps to 17 mbps h.264 mp4 file. Render at Max. Depth, Use Max. Render Quality On

Result:
Using Premiere's EXPORT: 20 sec. 80-90% GPU usage.
Using QUEUE: 1 min 20 sec. 4-8% GPU usage.

What does it prove? It proves CUDA MPE does get utilized during encoding process whereas Media Encoder does not use CUDA(GPU).

You already knew CUDA MPE gets involved when certain operations are requested so that it could result in great reduction of total encoding time. Given that, how can you also claim "Exporting directly or via the queue can result in slight performance differences, but nowhere near 2 - 5 times."
If you think encoding is only about encoding a native file without applying effects or scaling, your definition on encoding is too narrow and wrong.




32 sec.

Run the PPBM5 Benchmark (http://ppbm5.com/index.html) and you will know. Your claim is utterly untrue, unbelievable, unsubstantiated and lacks all kinds of proof, for others to test.

Run the PPBM5 Benchmark (http://ppbm5.com/index.html) and you will know. Your claim is utterly untrue, unbelievable, unsubstantiated and lacks all kinds of proof, for others to test.

Actually, very short projects (the total length of the project in the PPBM5 benchmark is less than one minute long) will not show much if any performance advantage of direct export over queued. Longer projects are required to see much if any difference between the two (and this difference does not show accurately or consistently in benchmarks).

One hour AVI, 3 minutes MPEG and 1 minute H.264 are all much better than 15 seconds that Tom is talking about.

Premiere's encoding process DOES use CUDA MPE. .

You might want to read this:
Adobe Forums: Mercury, CUDA, and what it all means (http://forums.adobe.com/thread/773101?tstart=60)

I must admit I must have been wrong about terminoloy given that Adobe employee said the following "It's worth mentioning one set of things that Premiere Pro CS5 doesn't process using CUDA: encoding and decoding." This means I was wrong when I said "Premiere's encoding process DOES use CUDA MPE." However, this doesn't not mean I was wrong when I said using export is faster than using queue.
Having said that, let's go back to the root of this confusion.


By Luis de la Cerda

"Eric, for GPU assisted rendering try file->export from the premiere timeline and instead of clicking on "queue" after choosing your export settings, select "export". In my experience this results in 2-5x faster rendering."

------------------------------

By Harm Millaard

"Luis, Rendering has nothing to do with exporting. Rendering is only for previewing the time line.
Exporting and thus encoding is a completely different and unrelated thing, just as washing your car and driving it are unrelated and completely different.
Exporting directly or via the queue can result in slight performance differences, but nowhere near 2 - 5 times. Sometimes it is faster, sometimes it is slower, but generally they are about the same, at least that is what Adobe wants it to be. Depending on the export format used you may get slightly better results with one approach, with other export settings it may be the other way around."

Randall Leong
"That does not happen in my system. In fact, in my system exporting via the queue took six times longer than exporting directly, when it comes to HD-to-SD encodes from HD AVIs. It could be something wrong with some part of my system."
-----------------------

What I argue is that Luis de la Cerda and Randall Leong is right on this case. As illustrated in my test along with others, using 'export' can be a lot faster than using "queue." (After all, this is what people have been saying all around forums since CS5 came along.)

They're only about the same if you're just doing full size to full size transcoding without applying any CUDA accelerated effects. I'm not sure what this process should be called now as using the term 'encoding' doesn't seem to fit in here if we want to be technically accurate.

Now, I learned that CUDA MPE doesn't play a part in the actual encoding process but it handles other processes(resizing, effects...etc.) freeing the CPU so that it(CPU) can work on actual encoding process.
So, while you're right that CUDA MPE doesn't do encoding, you're wrong when you said using 'export' and 'queue' is about the same in terms of encoding speed. And, it's not something I need to prove again. Look around forums and listen to what people have been saying all along. Using CUDA MPE does speed up the encoding process and you know it.

Actually, I agree with Harm because I only used AVIs when I tested the export versus queuing. If the source files brought into Premiere had been already lossy-compressed H.264 files, and especially MPEG-2 files, my results may very well be different.

And yes, exporting to AVI will always be faster than exporting to H.264 or MPEG-2.

The PPBM5 benchmark tests, for what they're worth, actually use already lossy compressed source videos, which are by their very nature more difficult to edit than AVI files. Thus, the longer times for encoding from such sources are due partially to the fact that CS5, like most other "prosumer" NLEs, actually "convert" to uncompressed RGB within the NLE itself - and this eats up some of the CPU's power.

UPDATE: I managed to run the MPEG-2 DVD portion of the PPBM5 benchmark both direct export and queued. I did pretty much confirm Harm's results there - only in my case, it took nearly double the time direct as it did queued. Only part of the reason for the (relatively) worse direct-export result is the lack of a hardware RAID controller (and thus, I'm currently limited to a KISS setup rather than a LOVE setup).

"Actually, I agree with Harm because I only used AVIs when I tested the export versus queuing. If the source files brought into Premiere had been already lossy-compressed H.264 files, and especially MPEG-2 files, my results may very well be different."

By that, are you saying you agree with Harm saying "Exporting directly or via the queue can result in slight performance differences, but nowhere near 2 - 5 times. Sometimes it is faster, sometimes it is slower, but generally they are about the same, at least that is what Adobe wants it to be. Depending on the export format used you may get slightly better results with one approach, with other export settings it may be the other way around."?

If so, why am I and others getting more than 5x times of speed increase when using export function compared to using queue? Why does GPU load stay in 80-90% when using export? And I'm not talking about AVIs here but h.264 files as OP mentioned.

Alright Harm, now I see why you don't see what I see.

The difference is caused by this setting: "use maximum render quality."
With that off, there's no major difference between export and queue. With that on, the difference in speed is as great as 5x and I suspect others' with a faster GPU than mine (I use DDR3 version of GT 240 so it's around 50% slower than DDR5 one) may see around 10x of difference.

So you were wrong when you said "Exporting directly or via the queue can result in slight performance differences, but nowhere near 2 - 5 times. Sometimes it is faster, sometimes it is slower, but generally they are about the same, at least that is what Adobe wants it to be." Just like how I was wrong when I thought CUDA MPE does encoding. It 'helps' encoding but it 'does not do' encoding.

While we were both wrong on certain matters, there's something else that differentiate us: you were being ignorant. Your saying "Run the PPBM5 Benchmark and you will know. Your claim is utterly untrue, unbelievable, unsubstantiated and lacks all kinds of proof, for others to test." proves it.

You knew there're people who witness this type of difference in speed (http://forums.adobe.com/message/2839569#2839569 http://forums.adobe.com/message/2805313#2805313) yet you didn't bother to furture investigate the issue and cause of it. You gave it a try but when you couldn't find an answer, your ignorance took over your intelligence.
When others and I peronally presented findings, you failed to take it into your consideration. Instead, you made nothing but a rant based on your ignorance. Your narrow mind couldn't digest the fact that there're things you still don't understand.
What's somewhat funny is when you said ""I've gotta see it before I believe it, said the blind man."in above mentioned link. Yes, you were being a blind man and because you were blind, you couldn't even see others and my findings. You couldn't even see yourself.

"The difference is caused by this setting: "use maximum render quality."
With that off, there's no major difference between export and queue. With that on, the difference in speed is as great as 5x and I suspect others' with a faster GPU than mine (I use DDR3 version of GT 240 so it's around 50% slower than DDR5 one) may see around 10x of difference."

You are correct. With MRQ on, the export is even slower than the queue. No difference with H.264, but MPEG2-DVD is around 30 seconds slower than without MRQ and nearly twice as slow as the Queue.

The only difference between your opinion and mine is that export is always equal or slower than the queue and you persist in claiming 2 - 5 times faster performance without giving proof.

Example with MRQ on, MPEG2-DVD export is 147 s, queue is 80 s.

I found that when exporting a SD mpeg2 from 1080p xdcam with max quality, doing it directly from premiere is way faster than using media encoder, which is in line with Tom's experience. I see a high GPU utilization vs. very marginal one when encoding in AME.

Just recently I was exporting a multicam edit and did a test render.

57 mins long xdcam 1080p sequence was encoded to mpeg2 SD in around 15 minutes (very high gpu util.)

No color correction, no effects, max qual. render checked.

After that I set the dvd chapters and the sequence went to encore via dynamic link and it was encoded there with AME with exactly the same settigs as the test render. It took around one and a half hour (low gpu util) to finish.

i7 950 @ 4ghz, 24gb, gts450

"The difference is caused by this setting: "use maximum render quality."
With that off, there's no major difference between export and queue. With that on, the difference in speed is as great as 5x and I suspect others' with a faster GPU than mine (I use DDR3 version of GT 240 so it's around 50% slower than DDR5 one) may see around 10x of difference."

You are correct. With MRQ on, the export is even slower than the queue. No difference with H.264, but MPEG2-DVD is around 30 seconds slower than without MRQ and nearly twice as slow as the Queue.

The only difference between your opinion and mine is that export is always equal or slower than the queue and you persist in claiming 2 - 5 times faster performance without giving proof.

Example with MRQ on, MPEG2-DVD export is 147 s, queue is 80 s. Maybe you don't know how to compare two figures and you flunked your math in school. In that case, get a refresher.

Actually, there is a possibility that performance in queued mode might be embarrassingly slow compared to the export mode if the CPU is running overly hot during queuing (this can occur with a heavily overclocked CPU). I will try another clip - this time, an already-compressed AVCHD camcorder clip - for this possibility.

I found that when exporting a SD mpeg2 from 1080p xdcam with max quality, doing it directly from premiere is way faster than using media encoder, which is in line with Tom's experience. I see a high GPU utilization vs. very marginal one when encoding in AME.

Just recently I was exporting a multicam edit and did a test render.

57 mins long xdcam 1080p sequence was encoded to mpeg2 SD in around 15 minutes (very high gpu util.)

No color correction, no effects, max qual. render checked.

After that I set the dvd chapters and the sequence went to encore via dynamic link and it was encoded there with AME with exactly the same settigs as the test render. It took around one and a half hour (low gpu util) to finish.

i7 950 @ 4ghz, 24gb, gts450

Do you realize that XDCAM is not AVC - but MPEG-2? MPEG-2 HD decoders are relatively mature compared to AVC(HD) decoders. Harm's testing (as bourne out both in the PPBM5 benchmark and of his own new tests) involves just one type of HD source - AVC(HD).

I don't think that's the case here. My cpu is watercooled and after few hours of number crunching at it's max the temperatures are lower than with stock cooler at stock frequency.

Moreover, it has nothing to do with different gpu utilization

I don't think that's the case here. My cpu is watercooled and after few hours of number crunching at it's max the temperatures are lower than with stock cooler at stock frequency.

Moreover, it has nothing to do with different gpu utilization

In your case, it has something to do with your source video. As I stated in my previous post, XDCAM (as used by your particular camcorder) is not AVC(HD) - but a variant of MPEG-2 instead.

nevertheless, how would you explain the noticable difference in export times and gpu utilization between premiere and ame with exactly the same settings?

Harm's testing (as bourne out both in the PPBM5 benchmark and of his own new tests) involves just one type of HD source - AVC(HD).

Actually, it comprises DV, HDV, XDCAM and AVCHD, both progressive and interlaced, and at 24, 25 and 29.97 fps, plus some synthetic clips. Both in the PPBM5 test and in the new test.

From the background page on the PPBM site:

The source material is heavily mixed, it comprises DV AVI in PAL, HDV 1080i PAL, XDCAM-EX HQ PAL and AVCHD 1080 NTSC.

Actually, it comprises DV, HDV, XDCAM and AVCHD, both progressive and interlaced, and at 24, 25 and 29.97 fps, plus some synthetic clips. Both in the PPBM5 test and in the new test.

From the background page on the PPBM site:

The source material is heavily mixed, it comprises DV AVI in PAL, HDV 1080i PAL, XDCAM-EX HQ PAL and AVCHD 1080 NTSC.

Thanks for the clarification. It still does not explain why my previous HD-to-SD encodes in queued mode are many times slower than in export mode. This is why I will be using a different type of HD video source format to check it out. Maybe it is my "source" files (Cineform and uncompressed AVIs) to begin with?

And yes, I agree that mixed source files tax the system even more than single-format sources.

UPDATE: I retested my system with a 6-plus-minute AVCHD clip, and my results are pretty much the same as with the AVI: The export speed to MPEG-2 DVD is faster on single layers than queuing. But the, I experimented further with more layers, and the speed advantage of exporting directly diminishes greatly - and often more than completely disappears.

In other words, those that gotten faster results with exporting over queuing obviously is performing simple, single-layer projects -- something that a much cheaper, consumer editing program can easily perform. In this "simple" task, queuing places a much greater load on the CPU than direct exporting does.

On the other hand, if one is getting unbearably slow performance with even simple video transcoding/resizing tasks in queued mode, the system is just too freaking slow overall.

Harm: "Run the PPBM5 Benchmark and you will know"

I just ran a PPBM test. While this test is useful for comparing performance differences on different computers, it just is not a valid test for our discussion: it is not designed to measure the difference between export and queue. It is only designed to use AME(queue) for benchmarking and you're guided to use export function only once with CUDA MPE turned off. In addition, you're supposed to run the test with MRQ off. Thus, whole point of using PPBM is pointless in our case. (Now, Did I really to explain all this to you Harm? Had you known something about this matter, you would've not told me run the test in the first place.)

However, there's one good aspect about this benchmark: we can equally run a modified version of benchmark using exact same project setup so we know the difference is not caused by something like using "single-layer projects."
The modification is simple. Encode the project with export and queue.
For my testing, I applied this setting:

720p. 29.97fps. Squre Pixels. Main Profile 4.2lv. VBR 1 pass, 11-17mbps.
Both of Render at Max. Depth and Use Max. Render Quality ON.


Here's the result:
Export: 2:14 (I used a stopwatch function on my phone for this setting does not inform the time spent.)
Queue: 6:18

*note: I ran two tests when using queue mode. One with Premiere opened and one with Premiere closed. It was because I thought Premiere might be holding CUDA resources thus blocking AME's access to it. It wasn't the case as two test showed similar results regardless of Premiere being on or off.

As you can see, export was 3 TIMES FASTER than queue.


BTW, Randall, my CPU did not "overly hot during queuing" or exporting. CPU temperture was in 56-60c range. Also, I don't think my computer is "just too freaking slow overall." While it isn't a top performer or anything, i7 860 @3.6ghz, 8GB ram, GT 240 DDR3 sure doesn't belong in the ""just too freaking slow overall" category.

BTW, Randall, my CPU did not "overly hot during queuing" or exporting. CPU temperture was in 56-60c range. Also, I don't think my computer is "just too freaking slow overall." While it isn't a top performer or anything, i7 860 @3.6ghz, 8GB ram, GT 240 DDR3 sure doesn't belong in the ""just too freaking slow overall" category.

Actually, I wasn't talking to you about a "too freaking slow overall" PC. I was actually referring to the OP's results. Taking a whopping 30 to 40 hours on a 1.5-hour project.

Here's a simple benchmark showing the difference:
YouTube - Dwm 2011-02-04 01-28-16-52.mp4 (http://www.youtube.com/watch?v=YlsKUIjgcSA)

Though it's a very short clip that has no effect applied (only resizing,) it clearly shows how export is much faster than queue. The result, the difference in speed between queue and export, is the same regardless of project's length, effects, and what-so-ever. The key here is MRQ. With that off, both export and queue shows same performance: they are both fast. With it on, export is much faster than queue. As I mentioned before, same result was acheived using PPBM's complex project file.

Now, Harm, please share your result with us. Don't rely on PPBM's benchmark method as it does NOT test what we're discussing here.

It's be great if other people could conduct a simple benchmark like this one and report back their findings.

720p. 29.97fps. Squre Pixels. Main Profile 4.2lv. VBR 1 pass, 11-17mbps.
Both of Render at Max. Depth and Use Max. Render Quality ON.

Here's the result:
Export: 2:14 (I used a stopwatch function on my phone for this setting does not inform the time spent.)
Queue: 6:18

As you can see, export was 3 TIMES FASTER than queue.


Same test, same settings:

Export: 1:33
Queue: 1:29

Conclusion: about equal.

The fact that you are getting these wide differences, that I can not replicate, are indicative of 'something' in your setup. I'm pretty confident I have a decently balanced system, even though not very fast anymore, so all I can guess is that 'something' in your system is not as balanced as in my system.

Does anyone have an explanation for exactly how/why MRQ plays a role with speeding up cuda exporting?

I'm still a little unclear on some things.

1) If the gpu doesn't handle encoding and decoding, what is it that the gpu is processing that makes exporting so much faster, besides FX?

2) My definition of encoding/decoding in PPro is reading/exporting to a particular compressed format. If you drag in an h264 file for example, then set the project settings and editing template to the same dimensions/format as the source material, does this mean that some of the actual 'encoding' is bypassed when exporting to that same format?