Skip navigation
wstpr111
Currently Being Moderated

AME rendering software only?

Mar 8, 2011 10:40 AM

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.

 

What am I doing wrong?

 
Replies
  • Currently Being Moderated
    Mar 8, 2011 1:19 PM   in reply to wstpr111

    As a point of interest, encoding is never done on the GPU with CS5.  Only certain effects are rendered on the GPU, and then sent to the CPU for final encoding.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 8, 2011 4:43 PM   in reply to wstpr111

    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.)

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 8, 2011 4:44 PM   in reply to wstpr111

    Here's a list of things that Premiere Pro CS5 can process with CUDA:

    - some effects

    - scaling

    - deinterlacing

    - blending modes

    - color space conversions

     

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

     

     

    http://forums.adobe.com/thread/773101?tstart=60

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 9, 2011 4:06 PM   in reply to wstpr111

    I'm not there to make the actual observation.  I'm only passing along the data from those who built the program.  According to them, CS5 does not do any decoding or encoding on the GPU.

     
    |
    Mark as:
  • Currently Being Moderated
    May 10, 2011 1:03 PM   in reply to wstpr111

    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.

     

    -Chris

     
    |
    Mark as:
  • Currently Being Moderated
    May 15, 2011 7:06 PM   in reply to cwilson03
    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.

     

    No one ever said the GPU wasn't used, only that encoding isn't done on the GPU.  Effects and such can be processed on the GPU, but that processed frame is then handed off to the CPU for encoding.

     
    |
    Mark as:
  • Currently Being Moderated
    May 16, 2011 6:15 AM   in reply to Jim Simon

    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.

     

    Best,

     

    Chris

     
    |
    Mark as:
  • Currently Being Moderated
    May 16, 2011 9:18 AM   in reply to cwilson03

    That's because only one program can access the GPU at a time.  If you want realtime performance in PP while editing, you have to sacrifice GPU processing while exporting.

     

    If you shut down PP before encoding, you may see a difference.

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 3:08 PM   in reply to wstpr111

    It's still not very clear.

     

    Let's say I have a few movies I have to resize to a smaller resolution and encode. Normally I would just drag them to AME, no need to use Premiere because it's just a simple batch encoding job.

     

    But according to this discussion I would have a better speed if I would first import the movies in Premiere and then export them to AME.

     

    And not only the speed would be better but the quality also, since in this way they would be resized with Lanczos 2.

     

    Is this true ?

     
    |
    Mark as:
  • Currently Being Moderated
    May 18, 2011 3:34 PM   in reply to sebastian___

    Not sure, since I've not tried that specifically.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 28, 2011 7:55 PM   in reply to wstpr111

    Here's what's confusing me to no end, and it's taken from Adobe's blog:

     

     

    What does Premiere Pro accelerate with CUDA?


    Here’s a list of things that Premiere Pro CS5 and later can process with CUDA:

    • some effects (complete list at the bottom of this post)
    • scaling (details here)
    • deinterlacing
    • blending modes
    • color space conversions

    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???

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 29, 2011 11:59 AM   in reply to thared33

    I thought encoding and rendering were basically the same thing?

     

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 29, 2011 12:09 PM   in reply to thared33

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jun 30, 2011 11:11 PM   in reply to Colin Brougham

    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?

     

    If I can get that answered, I'm 100%.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 1, 2011 4:13 AM   in reply to thared33

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 1, 2011 7:05 AM   in reply to thared33

    You're welcome Let's see what we can do to answer your follow-ups...

     

    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.

     

    Hope this helps!

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 1, 2011 7:37 AM   in reply to Colin Brougham

    Colin Brougham wrote:

     

    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?

     

    Best,

     

    Chris

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 1, 2011 7:59 AM   in reply to cwilson03
    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.

     

    Make that feature request. All the cool kids are doing it

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 1, 2011 8:10 AM   in reply to Colin Brougham

    :-)

     

    I didn't know from your profile if you were Adobe-employed or not, and might have some inside info.  But given your detailed posts, I thought you might be, hence directing the question to you.

     

    I opened a wish-list item way back when I first stumbled on and began contributing to this thread, but never heard anything one way or the other (which may be normal; not sure).

     

    -Chris

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 1, 2011 8:19 AM   in reply to cwilson03

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 1, 2011 2:17 PM   in reply to Colin Brougham

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 2, 2011 4:32 AM   in reply to thared33

    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.

     

    Marcus

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 3, 2011 9:55 AM   in reply to thared33
    1) which uncompressed format/codec is it actually decompressed into for display?

     

    All (color) displays - computer, television, camera viewfinder, etc. - require an Uncompressed RGB signal to send to the individual red, green and blue picture elements.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 3, 2011 9:56 AM   in reply to thared33
    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?

     

    Hard drive.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 4, 2011 2:30 PM   in reply to wstpr111

    Here's your answwer:

     

    http://www.dvinfo.net/forum/adobe-creative-suite/491220-export-vs-queu e-great-difference-performance.html

     

    The secret key to the problem is MRQ. If you're okay with it, turn it off then your GPU will be used.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points