When I just export, it uses my GPU, but when I queue and use AME it seems to only use software(CPU).

I have the upgrade from CS4 to CS5.

cpu i7 extreme, quatro fx 4800, 12GB memory raid of ssd's...

IN cs4 i had to get the plug-in from elemental to make rendering on the gpu in AME work. and work it did, very well.

Elemental is not supplying a plug-in for CS5 they told me CS5 AME does rendering on GPU and that they are not making a plug-in.

I'm rendering in H.264 and in cs4 this works just fine, i export, queue with AME then run it and ame will have my 40 min video done in about 12 mins.

CS5 isn't doing this. Looking at my GPU usage and CPU usage, when i do export render in PP it is using the GPU like normal and does it well. However when i Queue to AME it's like it doesn't use the GPU at all only CPU rendering.

As a correction, Jim when you have one of the high end cards such as the FX 4800 the rendering/encoding is taking place on the GPU so long as the program supports doing so such as CS4 with the elemental plugin for use with high-end cards or in CS5 PP export.

"Only certain effects are rendered on the GPU" this is incorrect, none of my videos have ever had any effects applied, in CS4 anyone with a Quadro card has to use the elemental plugin to use GPU encoding/rendering, and mainly for h.264.

In CS5 it is rendering on the GPU __ONLY__ when I do export, which the video shows.(Note: it only renders on the GPU if you have a supported GPU)

My question is, Can / or will AME encode on GPU like PP does or is the only way in CS5 (since elemental isn't making a plug in for cs5) to render on the GPU in a export? If this is the case it renders CS5 completely pointless to anyone who paid the big bux for high end nvidia cards, plus the big bux for CS5.

Where you would be correct is in After effects.

Don't get me wrong, Yes i know the CPU is still used, but not for the bulk of rendering the video.

With CS4, export to AME (using elemental plugin) h.264 in 720p HD video for my 40 min video only takes about 12 - 15 mins. Without the plugin your looking at an hour on my system (specs in 1st post)

CS5 is doing the job just like it should, but only on export, not in AME...

You said there was no plug-in for CS5. According to both Adobe and nVidia employees, CS5 does not use the GPU for decoding or encoding. Only certain effects, blending modes, scaling and such get GPU acceleration. But not encoding.

So it's not there natively, and if there's no plug-in, I'd assume you can't put it there artificially.

Hence, in CS5 encoding is never done on the GPU, only the CPU.

AME uses whatever mode (software or hardware) you have the project set for. (Or at least it should, and does for me.)

I'm seeing the exact same behavior, wstpr111. And regardless of what Adobe's or nVidia's engineers may have said, the GPU is *definitely* used when one does a media export straight from Premiere Pro CS5. I have the "GPU Meter" Windows 7 gadget on my desktop (http://addgadget.com/gpu_meter/) and the GPU utilization spikes to 80-90% on my GTX 580 when I do the export straight from PP, but never gets used at all when I queue the encoding in AME.

Further, CPU utilization (Core i7-970 - 6 physical cores, 12 logical) averages 40-50% combined when exporting straight from PP, but pegs 100% across the board when encoding in AME. Same sequence takes ~2 hrs to encode in AME, but only 23 minutes from PP. Clearly the GPU is doing the bulk of the work on the PP side.

Would be great if the GPU acceleration were enabled the same way in AME as it is in PP.

Fair enough. The original point of this thread still remains - it's unfortunate AME doesn't take advantage of the GPU in the same way as Premiere Pro itself, since there seems to be a significant performance improvement when exporting directly from PP versus queueing the export through AME.

It’s worth mentioning one set of things that Premiere Pro doesn’t process using CUDA: encoding and decoding.

A common misconception is that CUDA processing is only used for rendering for previews. That is not true. CUDA processing can be used for rendering for final output, too. See this page for details about what rendering is.

Pardon my ignorance, but I thought encoding and rendering were basically the same thing? Can someone explain exactly what encoding/decoding is to me in terms of where and how Premiere Pro applies it to? Now as for what's being said here, I've seen lots of others use the direct export via Cuda and it's a lot faster, however, they're not using any FX. It's just... faster rendering/encoding time. But Adobe says encoding via CUDA isn't possible???

Nope. Rendering generally refers to the creation of a new frame of video which includes all added effects and such. Encoding generally means taking that new frame of video and compressing it, as with MPEG2 or H.264. They're two different steps of the process. The former can be accelerated with CUDA. The latter is not.

Encoding and rendering are often, but erroneously, used interchangeably. They're not the same thing, at all.

In general terms, as it applies to the discussion here, "encoding" is the conversion of one video format to another. Typically, it's going from a less-compressed or raw format to a more-compressed delivery format; decoding would be the opposite, where a compressed format would be converted to an uncompressed format for display/playback. As far as Premiere Pro, AME, and hardware-accelerated rendering is concerned, encoding and decoding are done solely by the processor in your computer.

"Rendering" is a different matter. Rendering generally applies a variety of processes that operate on a video image to "render" it to a composited or mixed image--no compression is applied. As the list you posted indicates, there are a number of processes that are accelerated by CUDA/hardware MPE, and certain effects are only the start of that list. What hardware MPE and CUDA do is enable the GPU--a powerful processor in its own right--to render the mix of decompressed video images, effects, scaling processes, and a lot more to an uncompressed chunk of video data. From there, that data is handed off to the encoder and the CPU to compress to some other format. Effectively, with hardware MPE, you have two processors running in parallel to "cook" the final video image: the GPU renders the frame at high-resolution and high bit depth, and then the CPU compresses that frame to something lower than that.

The bottom line is that direct export allows you to use the GPU to accelerate rendering, which frees up the CPU to do just the compression to the final delivery format; that's why it's faster. With AME, the CPU must handle BOTH rendering AND encoding, which can lead to a bottleneck, depending on the complexity of the image to be rendered, and the format that is being encoded. Regardless of the method you choose, never at any point is the GPU/hardware MPE being used to encode--only to render.

I logged back in just to say thanks for the last two posts, especially from Colin. Explained it perfectly!... but now that makes me want to ask the following, but I'll try and make it all short:

1) I know AE/PPro does encoding/decoding for final export, but does AE/PPro do encoding/decoding for the preview window and for rendering previews?

2) If so, does it work where it takes your source file, decodes it (into which uncompressed format btw?), then compresses it to the selected codec, all on the fly? And is it that way for both rendering previews and final export?

3) Does 'editing mode' come into play where if you select to edit in AVCHD/H264/etc mode, that's the codec it'll encode/decode to for previews?

4) If you drag - for example - an h264 file onto the timeline, then export using the exact same codec, is the time actually shorter for final completion since it's the same codec, or does it re-encode the entire thing no matter?

I experienced the same different results between export from Premiere and export via queue. Because the power between my processor and my GPU Card differs much I experience a factor of about 10 for Mpeg2 DVD encoding from an HD422 source. At the latest Adobe presentation I attended the product manager was saying that export and queue are the same. One just runs in the background. Apparently this is not true. There are three major problems: 1) downascaling from HD to SD without GPU uses a weaker algorithm according the the mentioned Adobe blog. The result is not sufficient for many people. 2) dynamic linking to Encore is useless for DVDs, because no GPU is used for transcoding resulting in the same quality problem as 1 3) the time for queue is much slower I'm on the road at the moment. Did somebody check if AME would use GPU if Premiere is closed (so PProHeadlees is used only) Marcus

1) I know AE/PPro does encoding/decoding for final export, but does AE/PPro do encoding/decoding for the preview window and for rendering previews?

I'm going to assume that by "AE" you mean "AME" as in Adobe Media Encoder, and not After Effects. The basic answer is that, in Premiere Pro and in AME, any media that you import or use in a sequence MUST be decoded by the CPU first--it doesn't matter if it's an H.264 DSLR clip, a DV AVI, or anything else--the processor must decompress that original compressed video data. So, yes--anything you see in your PPro Program Monitor is being decoded by the processor. However, when you have a capable GPU, and you're using hardware acceleration, it will take over the rendering (think of it as "drawing" or "displaying") of that image to the Program Monitor. This includes a lot of different processes, which instead of rehashing, you can read about in CUDA, Mercury Playback Engine, and Adobe Premiere Pro and Adobe Premiere Pro CS5.5 improvements in CUDA processing and the Mercury Playback Engine.

So, for both real-time playback in Premiere Pro, for rendering preview files, and for final export directly from Premiere Pro, you are leveraging BOTH the GPU and the CPU together. When you're exporting via AME, however, the GPU-accelerated rendering is not active, so it's up to the CPU to handle the decompression of the source footage, the rendering of the composited image with effects, transformations, etc., and then the final compression to your destination format. The bottom line is that, in most circumstances, you get extremely fast performance in and from Premiere Pro; AME is slower by varying degrees based on the source footage/sequence.

Hope that makes sense, but please ask again if it doesn't

2) If so, does it work where it takes your source file, decodes it (into which uncompressed format btw?), then compresses it to the selected codec, all on the fly? And is it that way for both rendering previews and final export?

I think the above answers this question, as well--please advise if it doesn't.

3) Does 'editing mode' come into play where if you select to edit in AVCHD/H264/etc mode, that's the codec it'll encode/decode to for previews?

I actually wish Adobe would do away with the specific Editing Modes, because they're the source of a lot of confusion. Basically, the Editing Mode options are "shortcuts" to particular source footage parameters, whether that's frame size, frame rate, field order, and so on. Selecting a specific Editing Mode looks certain parameters--probably most significantly is the Preview File Format--but if you select "Custom" you can tweak any or all of the parameters to your heart's content. Practically speaking, you can edit any kind of source footage that you can import into Premiere Pro in any kind of sequence; logic would suggest that you try to match the source footage to the sequence, but that's not a hard-and-fast rule, and I personally break it all the time. I almost never worry about Preview File Format, since I render previews about once in a blue moon--with a fast machine, and limiting yourself to accelerated effects with a CUDA GPU, you'll have no need to render previews! Premiere Pro can do that all in real-time (see the above) for editing purposes. When it comes time to export, the preview file format is largely irrelevant, because even though you can use the preview files (if you created them) for export, you don't usually want to do that--you want to use the original source footage composited with the effects, and rendered in 32-bit color at maximum quality. That's what exporting directly from Premiere Pro with GPU acceleration enabled gives you: the fastest export at the best quality. How can you go wrong?

To answer your question more directly, however: we have a limited set of preview file formats and codecs that can be used. I-Frame MPEG is the most common based on the editing mode, since it's the most flexible in terms of frame size, etc. On Windows, you have Microsoft AVI; on Mac, you have QuickTime. Both of those contain a multitude of codecs that can be selected, with varying characteristics of their own. For example, selecting DV NTSC Editing Mode locks you into NTSC DV as the format with DV NTSC as the codec (yeah, the nomenclature is weird). The reason is that DV has a fixed set of parameters that are not flexible; your preview file format is dictated for you, then. The bottom line is that most of the time, if you select an Editing Mode, the Preview File Format decision is made for you; when you go the Custom route, you'll typically want to pick a format and codec that renders quickly. After all, what you're trying to do is create quick previews so you can see how a complicated sequence plays back. When you export, you're less concerned with speed and more concerned with quality (though both are nice).

4) If you drag - for example - an h264 file onto the timeline, then export using the exact same codec, is the time actually shorter for final completion since it's the same codec, or does it re-encode the entire thing no matter?

No, as a matter fact, it will probably take longer, and yes--the whole thing needs to be re-encoded. At least in this particular case, H.264 is a very processor-intensive standard, so if you're simultaneously decoding and encoding (which is what you'd be doing), you're creating a bit of a bottleneck. Now, in real-world practice, with a capable machine, that's less of an issue than it would seem to be, but it is a consideration, nonetheless. Premiere Pro does not provide "smart encoding" for highly-compressed formats like H.264 or MPEG2; stuff like DV, however, will be "passed through" without recompression so long as no changes have been made to the original footage.

So, for both real-time playback in Premiere Pro, for rendering preview files, and for final export directly from Premiere Pro, you are leveraging BOTH the GPU and the CPU together. When you're exporting via AME, however, the GPU-accelerated rendering is not active, so it's up to the CPU to handle the decompression of the source footage, the rendering of the composited image with effects, transformations, etc., and then the final compression to your destination format. The bottom line is that, in most circumstances, you get extremely fast performance in and from Premiere Pro; AME is slower by varying degrees based on the source footage/sequence.

Thanks for the detailed explanation Colin. Do you know if there are any plans to enable AME to also leverage the GPU in conjunction with the CPU, the same way PPro does?

Do you know if there are any plans to enable AME to also leverage the GPU in conjunction with the CPU, the same way PPro does?

Hi Chris,

No clue, but if I were a bettin' man (and I ain't), I'd imagine that it is somewhere on the roadmap. Premiere Pro and AME are moving in the same direction, in many respects, so it would stand to reason that At Some Time (tm) we'll have GPU-accelerated rendering in AME, as well. This would obviously be the one-two punch to send the PPro/AME combo through the stratosphere. The best way to shake the cage is to file a feature request for this: Adobe Feature Request/Bug Report Form. Third-parties have even dabbled with GPU-accelerated encoding, particularly to H.264, but my understanding is that that's a little hit-or-miss right now. Jeff Bellune did some pretty involved tests with such, comparing AME and Sorenson Squeeze 7; that's somewhere in the Video Lounge if I recall. In any event, both GPU-accelerated rendering and encoding would be fantastic additions to the Adobe platform, across the board.

Haha! With that goofy avatar, I assure you: I am not an Adobe employee. They'd be nuts to have me

I have spent some time communicating with the folks at Adobe, and I do a fair bit of testing of these processes, plus (if I say so myself) I think I've got a pretty good handle on the program. I just like being able to help people understand what's happening with the software they might be inexorably tied to

AFAIK, the wish list process isn't a two-way street. I've gotten feedback on one feature request I filed, but I've made dozens of feature requests and bug reports that haven't garnered a response. I've been assured that the team is listening, though, so make lots of noise frequently and that will likely get their attention. We do have Adobe representatives that drop in on certain threads, particularly when they start heating up, and I know they're functioning as intermediaries on our behalf as well.

Given the great disturbance in the Force that occurred recently, I suspect we're going to be hearing a lot more from Adobe, and vice-versa. Interesting times, no?

Thanks dude, you rule. The info I'm requesting I don't want to know necessarily because I think it'll help with quality or anything, I'm just curious as to how this stuff actually functions.

So let me get this right. Whenver I drag a clip into a bin/project media, it has a dialog box for a few seconds. I'm going to take it that at this time it's not decoding, but just gathering general info about the clip. Now when you're actually scrubbing or doing a preview, I think THAT'S where the media is being decoded. Right?

After selecting a preview file format, I'm going to take it that your processor - when playing a preview back - will have to first decode the original clip's codec, then render the images, then encode it into the selected preview file format, which ultimately gets displayed on your screen, all basically in a flash. No? that seems like a lot of encoding/decoding CPU work, so now I see why you need a powerful system for editing.

About an uncompressed format. When a cpu decodes a video clip, it's decompressing it for display on your screen, I think. I have a two-part question here: 1) which uncompressed format/codec is it actually decompressed into for display? Or if it ultimately goes to the preview file format's codec for preview display, which 'temporary' uncompressed format/codec is used? and 2) I was told that the preview file's frames/images are stored as cache. Is this stored in your ram, or stored on the hard disk?

The Sequence Settings I understand - it's basically just a frame rate and resolution selector and the codec doesn't matter since the timeline has to decode all of it anyway, so it's more of a general guideline thing to choose. The editing mode still confuses me a bit as you say though, since editing mode and preview file format seem kinda like the same thing to me. I'm not in front of my computer so I can't take a look but I think it'll click soon.

My previous post wasn't formatted well after I had to enter if from my iPAD (HTML entry doesn't work at all).

A lot of confusion about exporting from Premiere and using AME queue is that (at least in Germany) the Premiere business managers that were demonstrating GPU playback at the latest roadshow said hat there is no difference between queue and export, except that one is done in the background. I contacted both Adobe representatives. They had no clue about the problem that AME doesn't use GPU. They wanted to investigate and I'm still waiting for an answer sincetwo weeks now.