The Ultimate Guide to Premiere Pro’s Render Quality Settings

If you’re unsure about Premiere Pro’s Maximum Render Quality (MRQ) and Maximum Bit Depth (MBD) settings, you’re not alone. It’s pretty complicated stuff, and it doesn’t help the official documentation can be hard to find.

So why do we see these in both Sequence Settings and in Export Settings? And how do they affect our video? In this article, we’ll dive into how and when these settings work, so that you can make the best choice for your own projects.

If you don’t have the time to read all the technical details you can skip directly to the conclusion. (TL;DR just turn both settings on in both Sequence Settings and Export Settings.)

At the end of the article, you’ll also find the tests I used to show how these settings affect export times and image quality. These will be referred to during the article.

Where do we find these settings?

You’ll find both the Maximum Render Quality and the Maximum Bit Depth settings in at least three different places in Premiere Pro: In the New Sequence dialog, in the Sequence Settings and in the Export Settings.

If you create a new sequence manually in Premiere Pro (File > New > Sequence), you’ll see this dialog.

If you’ve already created a sequence, and didn’t pay attention to the settings, you can go to Sequence Settings (Sequence > Sequence Settings) and change them there.

When you export your timeline, you’ll see the same settings, one under the Video tab and one in the bottom part of the box.

OK, with that out of the way, let’s see what happens when you enable these settings in your sequence.

You’ll be warned

Yep, if you choose to activate any of these two settings, you’ll get the following warning.

This isn’t as scary as it looks. But if you think it’s a cause for concern, you can go to the Preferences for Memory and set it to Optimize rendering for Memory. Or ignore the message altogether, thinking “I have lots of RAM” like most of us do. Unless you have a high-end computer with a super-high core count you shouldn’t run into memory-related trouble with any of these settings. I always have my memory preferences set to Optimize rendering for Performance.

Even though the warning says that it’s “highly recommended” to set this to Memory, some users have reported that doing this will make their systems less stable. I leave this set to the default, which is Performance.

What does Maximum Bit Depth do?

At first glance, it seems that the Maximum Bit Depth switch simply forces Premiere Pro to render supported effects in 32-bit with floating point accuracy. This is good because it will reduce banding and other artifacts while also keeping overbrights and super-blacks intact, never clipping levels.

The Maximum Bit Depth switch also requests 32-bit float from the importer, which is otherwise only 8-bit.

What does Adobe say?

This is the explanation that Premiere Pro offers you when you hover the pointer over the Render at Maximum Depth button in the Export Settings.

“Rendering at maximum bit depth improves the video’s quality but increases how long encoding takes.”

This can be confusing. What does “Improves the video’s quality” mean? This explanation is also not the full picture: it doesn’t necessarily increase the encoding time. More on this later.

For some reason there is no tooltip for Render at Maximum Depth in Premiere Pro 15.0, so you’re left to your own interpretation for that one.

Why does it matter?

Let’s have a look at the rendering of video frames first. This can be done in 8-bit per channel, or in 32-bit per channel. If you’ve chosen GPU rendering (CUDA, Metal or OpenCL) in the Project Settings, it will always be done in 32-bit unless you’ve used effects that are not GPU-accelerated.  

If Software Only is chosen in the Project Settings, the bit depth depends on the Render at Maximum Depth switch. If it’s on, rendering will be done in 32-bit. If not, it’ll be done in 8-bit.

8-bit means the result of every calculation on the image can only have 256 possible levels per channel (RGB or YUV). That’s not a lot of accuracy. With multiple effects on a clip, this means we’ll get rounding errors for each calculation, with the danger of introducing banding and blocking.

In 32-bit, we’re doing all calculations with results that can have more than 4 billion different levels per channel, so rounding errors with multiple effects are totally eliminated. We can also store levels way beyond 100% white and 0% black.

Here’s a good test to do if you want to see the difference between 32-bit and 8-bit rendering. Use a clip with some highlights close to maximum.

Use the old trusty (and obsolete) RGB Curves effect to force levels way beyond 100% white. (You can’t use Lumetri Color for this because it clips levels when stacked.)

Now let’s add another instance of RGB Curves, where we drag the whites way down again.

Because we’re rendering in 32-bit using the GPU, the overbrights were not clipped, and the image looks normal. Now let’s switch to Software Only in the Project settings and see what we get.

Rendering in 8-bit, the overbrights were simply clipped, and lowering the levels again only makes the clipped levels darker. Lots of detail is lost.

Now let’s activate the Maximum Bit Depth switch in the Sequence Settings.

That’s almost identical to the result we got with GPU rendering. So if you’re working in Software mode, you should definitely tick that Maximum Bit Depth box.

Of course, these were extreme adjustments just to make the difference obvious. You wouldn’t normally do this. But we often end up having more than one adjustment on one clip. For example, you might add a LOG to Rec.709 LUT as a Source Clip effect, then normalize the image in the timeline, and then add an adjustment layer with a look.

That’s three adjustments on one clip, and any intermediate levels that go above 100% would be clipped in 8-bit, losing detail. You can also start to see banding in gradients etc. Make sure you’re rendering in 32-bit, and these problems are non-existent.

How can you tell if a clip is rendered in GPU mode or Software Only mode?

If you’ve activated GPU acceleration (CUDA, Metal or OpenCL) in Project Settings, it’s reasonable to assume that you’ll always get the best algorithm. But that’s not always the case, and it’s more complex than it first appears.

If Software Only is chosen in Project Settings, you’re obviously getting Software rendering. But even when you choose GPU rendering in the Project Settings, some of your clips may be rendered using Software mode. Add a non-accelerated effect or transition, and a part of the rendering of each frame will be done in 8-bit, potentially clipping levels and introducing rounding errors and banding.

Such non-accelerated effects include common tools like Camera Blur and Unsharp Mask. These aren’t written for the GPU, and have to be calculated on the CPU.

Beware of the Red Render Bar

The render bar can give you some clues about what’s going on. Areas of the timeline with no render bar at all don’t have any effects, so what you’re seeing should be what you get. If you’ve chosen GPU rendering in Project Settings and you see a yellow render bar in the timeline, then you also know you’re definitely in GPU mode, and you’re safe.

A red render bar will often be a sign that you’re rendering in Software mode, but it’s not a clear identification. It might also indicate that you’re using a GPU-accelerated effect that needs rendering, like Optical Flow frame blending for Speed, or the Morph Cut transition. Yes, those need to be rendered—hence the red render bar—but they will be rendered on the GPU in 32-bit. So a red render bar doesn’t always mean you’re in Software mode.

It turns out there is no simple or direct way in the timeline to tell if part of your rendering is done in Software mode. So, how can you find out if a clip that triggers a red render bar does so because of Software rendering or not?

First, you need to find out if the clips in the area with a red render bar have effects on them. That’s the easy part. If the fx badge is gray, there are no effects on the clip. If it’s yellow, you should also be good, since that means only the fixed effects (Motion, Opacity etc.) have been changed.

If there’s a red line under the badge, it has a Source Clip effect on it, and if it’s purple you’ve added an effect on the clip in the timeline. When it turns green, that means you’ve used an effect, and that you’ve also changed one or more of the fixed effects. The short version of this is that you only need to worry about clips with green and purple badges, and those with a red line under the badge.

You can check the Effect Controls panel to see if any of your clips have a non-GPU-enabled effect. If the clips have only GPU-accelerated effects, you’re good. If one or more clips do have a non-accelerated effect, then some of the calculations will be done on the CPU.

If you don’t know what effects are GPU accelerated you can find out by looking at the Lego brick icons in the Effects panel.

But the Effect Controls panel only shows effects on one clip at a time, so it will take a while to go through all the clips. Here’s a faster way to see all the effects on all those clips: Select the clips you want to inspect and click Edit > Remove Attributes. This will show all the effects that have been used on those clips.

It won’t show which clip has which effect, but you probably know your timeline well enough to have a good idea of what’s been used where.

What about Preview Renders?

Your sequence settings won’t normally affect your final export, because the Export Settings panel has its own settings for Maximum Bit Depth.

If you plan to use preview renders for export, you’ll be pleased to learn that setting the preview file format to something like ProRes 422 HQ will decode and render your previews in 10-bit, even when the sequence has Maximum Bit Depth set to off. So it’s always safe to use high-quality preview renders.

This is a good thing, but it also means you’ll see a visible change in the image under video overlays like lower thirds if you render that part of the timeline with Maximum Bit Depth set to off in your Sequence Settings.

Maximum Bit Depth affects the decoding of some formats

The Maximum Bit Depth switch also requests 32-bit float from the importer, which is otherwise only 8-bit. So a little-known fact is that MBD also affects the way some video formats are imported/decoded. This means it can impact some video formats more than others—even when you’re in GPU Acceleration mode.

For some formats, like RED, this is required to get HDR pixels. For example, RED RAW is 12-bit, and Maximum Bit Depth chooses between decoding the frames at 8-bit vs using the full 12-bit.

There’s no list of what these formats are, but editors using ProRes should know that without MBD set, ProRes will be decoded in 8-bit, even though the ProRes source is always 10-bit or more.

So when you don’t have this switch enabled in Sequence Settings, your glorious ProRes footage is likely to show banding in the Program Monitor, and in the Lumetri Scopes.

 

Without Maximum Bit Depth set, ProRes will be decoded in 8-bit.

So, if you want your program monitor to show something that resembles the final output while you’re color grading, you definitely want to enable Maximum Bit Depth in Sequence Settings.

The often-overlooked Depth choice in Export Settings

Don’t confuse the Render at Maximum Depth setting with the Depth setting that appears immediately below it in Export Settings for some formats. The Render at Maximum Depth tick box refers to the accuracy of the calculations, while the Depth setting below refers to the bit depth of the encoding.

So the Depth setting decides if the rendered file will have 8-bit video, 10-bit, or more. So even with Render at Maximum Depth ticked, ensuring that calculations are done in 32-bit, you’ll actually be exporting to 8-bit video if you don’t set it to 16-bit!

To ensure high-quality output, always use 16-bit depth when exporting to ProRes

For some strange reason, all the presets default to 8-bit—presumably a choice of performance over quality—but this leaves you open to banding and blocking.

Since the 8-bit vs 16-bit value isn’t stored visibly in the file, the 8-bit file will pretend that it’s 10-bit for all flavors of ProRes 422, and 12/16-bit in ProRes 4444. This will show in Properties in Premiere Pro, and in software like MediaInfo.

It’s lying to you.

Note that when Smart Rendering kicks in, this setting has no effect. But if you have an overlay like a Text layer, or you’ve added effects like Lumetri, Premiere Pro will export in 8-bit if Depth is not set to 16-bit. If you have rendered previews of the segment, and choose Use Previews, the setting will not affect the output.

Also, note that the Match Sequence Settings feature in Export Settings is set to Maximum Bit Depth if your sequence has this enabled, but the Depth is set to 8-bit, making even this feature unusable for high-quality ProRes export.

What does Max Render Quality do?

MRQ, when active, will give you sharper images after scaling because it enables a higher-quality Lanczos interpolation method instead of the default bilinear. This is why it also increases the export time when active.

Sounds pretty simple. But does it affect other things than scaling? You bet. And what kind of algorithms are we looking at here?

OK, but what does “Better Scaling” mean, exactly?

To answer this question, let’s leave Premiere Pro for the moment, and take a look at Photoshop, instead. You may have seen that Photoshop has several scaling algorithms to choose from. Bicubic, Bicubic Sharper, etc. And they all have different pros and cons.

Why do we have so many to choose from? Because sharp isn’t always what you want. Some algorithms are better for graphic elements and text, while others are better for “natural images”. Some work better when scaling up, while some work better when you’re scaling down. Colin Smith at PhotoshopCAFE has a good explanation in his video tutorial.

Back to Premiere Pro, and “better” seemingly equals sharper. So that’s the first slightly inaccurate statement in that tooltip text. The second inaccuracy is that it only mentions Scaling, despite it actually affecting all the Transform options, including Scale, Position, and Rotation—plus any effects that do Scale, Position, and Rotation, like the Warp Stabilizer.

Just like the explanation for Max Bit Depth, the explanation in the tooltip is also wrong: it doesn’t necessarily increase the encoding time. If you have GPU acceleration enabled, it will not increase the encoding time. See Test 7

When does it kick in?

If you’ve used only GPU-accelerated effects and have a yellow timeline render bar, or no bar at all, it will not kick in, as the GPU scaling algorithms are even better—and yet faster—because they’re done on the GPU.

If the render bar is red, it may kick in. Most likely it will, because you’ve used a non-accelerated effect. But there are some exceptions. Just like the Max Bit Depth option, Max Render Quality will not kick in if the render bar is red because you’ve used morph cut and haven’t rendered yet. That transition is rendered on the GPU, so MRQ will not kick in.

And remember—it affects Transforms (even though it only mentions scaling in the Export settings). So if you haven’t scaled, moved, or rotated anything, it won’t do its thing. If you’ve adjusted or keyframed Position, Rotation or Scale (including Scale or Set to Frame Size), you may have triggered these algorithms.

Then again, you might be scaling without realizing it. For example, Warp Stabilizer introduces scaling, rotation and repositioning. And if you’ve used default Set to Frame Size, you may be scaling without knowing it. Of course, if you’re outputting to a different size than your sequence (say, exporting HD from a 4k timeline), then you most definitely are scaling.

Some facts that may surprise you

As you’ve seen, the level of complexity is surprisingly high for such a simple goal: Give me the maximum quality output. Not only is it complex, but the different settings are placed in different corners of the software—and they all need to be set correctly.

Many of us will struggle to find, understand, and correctly apply all these settings.

But there’s more. Here’s some info that may or may not surprise you.

Premiere Pro has several different scaling algorithms

Adobe described how and when the different scaling algorithms work in a blog post from 2010.  

Here’s an overview I made, updated with the algorithms used for High Quality Playback, which wasn’t a thing in 2010.

Algorithm Description When is it used? Nearest neighbor Super fast, but blocky For some formats when you reduce Playback Resolution in the Program Monitor. BilinearVery fast, but not the best quality. Used for playback when High Quality Playback is not enabled. Gaussian low-pass sampled with bilinear Fast, but a bit soft. Used when you export in Software mode with Max Render Quality off. Also used in Software mode when playback is paused. Variable-radius bicubicSlow, but sharper. Similar to the standard bicubic mode in Photoshop. Used for export in Software mode when Max Render Quality is enabled. Lanczos 2 low-pass sampled with bicubic. Also described as modified bicubic with a scale-dependent pre-filter. The best all-round scaling algorithm. Pretty advanced, but since it’s only available in GPU mode it’s still fast. Used in GPU mode for export, and when playback is paused. Also used in GPU mode when High Quality Playback is enabled.

You don’t normally see full quality in the program monitor

As you can see in the table above, Premiere Pro uses a fast, lower-quality algorithm for Playback by default. This makes playback less demanding and may be the only workable choice on less capable systems. To see what you’ll get on export, and accurately judge the results, you’ll have to enable High Quality Playback in the Program Monitor settings menu.

With High Quality Playback enabled, Premiere Pro plays and scrubs the image using the same quality that’s used when the Playhead is paused. So you might find that your system struggles and starts dropping frames. In that’s the case, turn this feature off.

Your choices in Sequence Settings don’t matter that much

As we’ve seen (and to make things more complicated), both settings are available both in the sequence and in the export settings. If you take a look at the tests at the end of this article, you’ll see that your sequence settings have no impact on the quality of the exported file.

But if you want to know what you’re exporting, the sequence settings and the export settings have to match. If they’re set differently, the output won’t be the same as what you saw while editing. So I recommend that you keep MRQ and MBD settings matched.

Max Render Quality also affects the way color is rendered

As you’ll see in the Sequence settings, the Composite in Linear Color setting depends on GPU acceleration or Max Render Quality. So if this is on, as it is by default, activating Max Render Quality will also activate Composite in Linear Color when you’re in Software mode. And this will affect how your compositing, cross-dissolves, and color grading will look.

In Software mode, this also makes Premiere Pro blend in linear color for frame blending when you change Speed/Duration.

Max Render Quality affects how some formats are decoded

As we’ve seen, the Max Render Quality setting normally has no impact on our exports in GPU mode, because a superior scaling algorithm will be used on the GPU. But even with GPU rendering, MRQ can improve quality when working with footage that supports fractional resolution (Wavelet codecs, like RED for example), using full-resolution sources instead of a fractional resolution for the export when the image has been scaled down. See Test 14.

According to engineers and developers from Adobe, MRQ affects decisions made by RED, PNG, JPEG, HIEC, HIEF and WEBP importers. And they mention that this list will change over time, as well as what impact MRQ has on them.

Common Misconceptions

There are some statements that you’ll often see in forums, books and articles—even by Adobe evangelists—that don’t hold up to scrutiny. So let’s clear these up.

“Maximum Render Quality only affects scaling”

There are many versions of this misconception, but it usually goes a bit like this.

“Using Maximum Render Quality will not help unless you’re scaling up or down”.

Wrong. It also kicks in if you’re changing Rotation, Position, and other Transforms, or the Warp Stabilizer, which also does some scaling and other Transforms. But it only affects Software rendering. See Test 9

“Maximum Bit Depth doesn’t help if your source or destination file is 8-bit”

Since a lot of source files are 8-bit and we often export to 8-bit codecs, people tend to think that we don’t have to render effects in 32-bit. Here are two common statements.

“You don’t have to check Maximum Bit Depth, because H.264 and YouTube is 8-bit anyway.”

“You don’t need Maximum Bit Depth if your source material is 8-bit.”

Wrong. Even when the source and export are 8-bit, doing the decoding and all the internal calculations at 32-bit accuracy will make sure your consecutive adjustments (say, Lumetri on the source clip and a LUT or tweak on an added Adjustment Layer) don’t introduce clipping, banding and posterization.

This affects both GPU rendering and Software rendering, as you can see in Tests 3, 4 and 5.

Unfortunately, none of the presets in the new Quick Export have Maximum Bit Depth set. So, to get less banding and blocking when exporting using the standard export method, choose the same preset, you should activate MBD.

“When you have GPU acceleration enabled, the settings don’t matter”

This is true for MRQ, but only if your timeline does not have a red render bar due to non-accelerated effects, which forces you into Software rendering. For Max Bit Depth, it’s only true if you haven’t added any effects. See Test 3, 4, 7 and 8.

“The export will match what you see in the program monitor”

Not entirely true. To get WYSIWYG in the Program Monitor during playback, not just when playback is paused, you’ll have to enable High Quality Playback in the program monitor panel menu.

Effects and transitions like Morph Cut and Optical Flow need to be rendered to see the actual result. Also, when you’re rendering previews, you’ll need to render to a good codec, or else the result will not match your output.

If it’s rendered to the default I-frame Only MPEG-2 codec, you’ll get a bad preview compared to ProRes, DNxHR or CineForm codecs, which provide better-quality previews.

So it’s best to use codecs that are so good you can use them for export, enabling Use Previews in the export settings. Ideally, you should use the exact same format as you’ll use when you export your master file to get super-fast Smart Rendering and eliminate re-transcoding.

Render Previews if you’re editing in Software mode. During playback in Software mode, you’ll not get 32-bit rendering. Effects and compositing can look very different before and after rendering.

For example, graphics might get jagged edges during playback, and Linear compositing won’t be applied, which changes the look of blending modes, etc. By rendering your previews, you’ll get to see them in full quality, which is useful if your system can’t handle High Quality Playback.

Summing up

These MRQ and MBD settings affect the video quality at three different stages in the pipeline. The importer/decoder can be 8-bit or 32-bit, the processing of effects and transforms can be done in 8-bit or 32-bit, and finally the exporter can render to 8-bit, 10-bit, 16-bit, etc.

As we’ve seen, where these settings really matter is in your Export settings. Both Max Render Quality and Max Bit Depth have an impact on your image quality, although Max Render Quality mostly only kicks in when you’re in Software mode (which is entirely possible even with GPU acceleration turned on, see Test 11).

It’s hard to be definitive, but in many (most?) cases, leaving the settings on will not affect the export time.

For some sources, MRQ can make a difference even in GPU mode. MBD in export settings can also affect how some formats are decoded, even in GPU mode, most notably ProRes.

And finally, you should always enable 16-bit Depth for formats where this choice is available.

Unfortunately, in both Sequence Settings and in Export Settings, the defaults don’t have these settings enabled, so you’ll have to intervene to get the best quality video in Premiere Pro. The Quick Export has none of these settings enabled, and there’s no way you can change it.

If you want good quality video, always enable Maximum Bit Depth and Maximum Render Quality, and choose 16-bit instead of 8-bit for formats with a choice for Depth.

With all of this in mind, I recommend that you always have MBD and MRQ enabled in your export settings. If you want WYSIWYG, you should also enable both of them settings in your sequences. If your system struggles you may want to turn them off, and see if the exported files still meet your quality standards, knowing that it’s not top quality.

Most of the time, the settings will do nothing at all, but they will kick in when needed, and ensure the best possible quality.

Here’s what I do

You may be wondering what choices I have made, and how I set up my workflow. Here you go.

• I use Sequence Presets that have both settings activated
• The Sequence Presets use ProRes 422 HQ to get high-quality preview renders
• I’ve made a ProRes 422 HQ Export Preset with both settings activated
• The Export Preset also has Use Previews, and 16-bit Depth activated

The export to a master file is very quick if I’ve rendered parts of the timeline where there’s a red render bar, due to Smart Rendering (see Test 1 and 6). Of course, I don’t always have to render, but I sometimes render during breaks or when I’m on the phone, to save time on final export when Smart Rendering kicks in.

I also use Render & Replace for dynamic link comps, titles, MOGRTs etc.

For longer projects I will set up watch folders in Adobe Media Encoder to automatically take my exported master file and output the h.264 versions, using a preset with Maximum Bit Depth and Maximum Render Quality enabled. But for short-form projects I normally just queue these exports, which is fast and easy.

I hope the info in this article enables you to make qualified choices for these settings for future projects. This should enable you to improve your image quality and yield fewer surprises when you export your films.

 

Testing, testing

In the interests of transparency, here are the tests. (They were run on a 7-year old laptop, so you may laugh at some of the export times.)

Each test was an export of the same timeline with different settings enabled, with MRQ and MBD enabled and disabled, with and without GPU rendering, scaling on/off, etc. Here are the basic sequence settings and export settings.

During each export, I monitored the CPU and GPU usage, and timed every export. After each export, I performed a Difference Mode test, to see if any pixels had different values in the different versions.

My main testing timeline was a minute long and contained a 10-second clip repeated six times. The source file was 1920x1080px, ProRes 422 HQ, 29.97 fps, progressive. (This matched the export, so in the first test, Smart Rendering kicked in, and the export time was very short.) I also did a test with RED RAW footage.

Let me preface this by saying that these tests are not scientific. I had other software running in the background, and I timed the exports using the stopwatch app on my smartphone, so the timing may be off by at least one second, maybe more. But they’re enough for us to see how different settings affect the exported file and the time the export takes.

Test 1: Export to ProRes 422 HQ, No effects

# Sequence Export GPU Export
Time GPU
Usage A MBD off MBD off CUDA 9 sec – B MBD on MBD off CUDA 9 sec – C MBD off MBD on CUDA 9 sec – D MBD on MBD on CUDA 8 sec – E MBD off MBD off Off 9 sec – F MBD on MBD off Off 9 sec – G MBD off MBD on Off 8 sec – H MBD on MBD on Off 9 sec –

Conclusion: When no effects are added, Premiere Pro uses Smart Rendering on this sequence, regardless of the Maximum Bit Depth value in the Sequence and Export settings. This is indicated by the very low CPU usage. Almost zero processing is going on, and the export is super fast.

Test 2: Comparison of exported files from test 1, Difference mode, No effects

# Comparison
(Difference Mode) Program
Monitor Waveform
Scope A Files from A and E in test 1 Black Flat line B Files from A and F in test 1 Black Flat line C Files from A and G in test 1 Black Flat line D Files from A and H in test 1 Black Flat line E Files from A and B in test 1 Black Flat line F Files from A and C in test 1 Black Flat line G Files from A and D in test 1 Black Flat line

Conclusion: All the files are identical. I could see no difference in the program monitor or in the scopes—the waveforms were a straight flat line. They were also exactly the same size, down to the byte.

Test 3: Export to ProRes 422 HQ, with Lumetri effect (RGB Curve), GPU enabled

# Sequence Export GPU Export
Time GPU
Usage A MBD off MBD off CUDA 25 sec 40-90% B MBD on MBD off CUDA 26 sec 40-90% C MBD off MBD on CUDA 38 sec 40-90% D MBD on MBD on CUDA 39 sec 40-90%

The CPU was constantly around 100% on all cores, and GPU usage was between 40-90% for all exports. Only when the export setting is changed does the file size differ, and a fuzzy line shows in the scopes. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is.

Conclusion: Export settings affect export times, and what algorithm is used. Sequence settings do not affect the exported files, unless you enable Use Previews in the export settings.

Test 4: Export to ProRes 422 HQ, with Lumetri effect (RGB Curve), GPU disabled

# Sequence Export GPU Export
Time GPU
Usage A MBD off MBD off Off 2 min 14sec – B MBD on MBD off Off 2 min 16 sec – C MBD off MBD on Off 2 min 30 sec – D MBD on MBD on Off 2 min 28 sec –

The CPU was constantly around 100% on all cores for all exports. When the export setting is changed the file sizes differ, and a fuzzy line also shows in the scopes. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is.

Conclusion: Export settings affect export times, and what algorithm is used, but sequence settings do not, unless you enable Use Previews in the export settings.

Test 5: Difference mode, with Lumetri effect (RGB Curve)

# Comparison
(Difference Mode) Program
Monitor Waveform
Scope A Off-off GPU vs on-off GPU Black Flat line B Off-off GPU vs off-on GPU Black Fuzzy line C Off-off GPU vs on-on GPU Black Fuzzy line D Off-off CPU vs off-on CPU Black Fuzzy line E Off-off CPU vs on-off CPU Black Flat line F Off-off CPU vs on-on CPU Black Fuzzy line G All GPU vs CPU Black Fuzzy line

Conclusion: Premiere Pro uses slightly different algorithms in CPU and GPU mode, so files exported with GPU enabled and GPU disabled are slightly different. The export settings make an impact on the exported file—sequence settings have no influence on the exported file, unless you enable Use Previews in the export settings.

Test 6: Export to ProRes 422 HQ, no scaling

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 8 sec – B MRQ on MRQ off CUDA 8 sec – C MRQ off MRQ on CUDA 8 sec – D MRQ on MRQ on CUDA 8 sec – E MRQ off MRQ off Off 8 sec – F MRQ on MRQ off Off 8 sec – G MRQ off MRQ on Off 8 sec – H MRQ on MRQ on Off 8 sec –

Conclusion: When no scaling is going on, Premiere Pro uses Smart Rendering, and all the exported files are identical.

Test 7: Export to ProRes 422 HQ, with scaling set to 120%

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 25 sec 40-85% B MRQ on MRQ off CUDA 25 sec 40-85% C MRQ off MRQ on CUDA 25 sec 40-85% D MRQ on MRQ on CUDA 25 sec 40-85% E MRQ off MRQ off Off 35 sec – F MRQ on MRQ off Off 35 sec – G MRQ off MRQ on Off 3 min 55sec – H MRQ on MRQ on Off 3 min 55sec –

The CPU was constantly around 100% on all cores for all exports. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is. Files exported with GPU enabled and GPU disabled are slightly different.

Conclusion: Export settings affect export times in Software mode, and what algorithm is used, but Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 8: Difference mode, with scaling

# Comparison
(Difference Mode) Program
Monitor Waveform
Scope A All GPU vs GPU Black Flat line B GPU vs off-off CPU Black Fuzzy line C GPU vs on-off CPU Black Fuzzy line D GPU vs off-on CPU Black Fuzzy line E GPU vs on-on CPU Black Fuzzy line F On-off CPU vs off-off CPU Black Flat line G On-off CPU vs off-on CPU Black Fuzzy line H Off-on CPU vs on-on CPU Black Flat line

Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is. Only when the export setting is changed does the file size differ, and a fuzzy line shows in the scopes.

Conclusion: Premiere Pro uses slightly different algorithms in CPU and GPU mode. Export settings affect export times, and what algorithm is used, but Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 9: Export to ProRes 422 HQ, with rotation set to 10 degrees, no scaling

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 27 sec 40-95% B MRQ on MRQ off CUDA 26 sec 40-95% C MRQ off MRQ on CUDA 25 sec 40-95% D MRQ on MRQ on CUDA 25 sec 40-95% E MRQ off MRQ off Off 37 sec – F MRQ on MRQ off Off 37 sec – G MRQ off MRQ on Off 5 min 26sec – H MRQ on MRQ on Off 5 min 26sec –

CPU was constantly around 100% on all cores for all exports. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is.

Conclusion: Premiere Pro uses slightly different algorithms in CPU and GPU mode. Export settings affect export times, and what algorithm is used, but Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 10: Difference mode, with rotation set to 10 degrees, no scaling

# Comparison
(Sequence Export) Program
Monitor Waveform
Scope A All GPU vs GPU Black Flat line B GPU vs off-off CPU Black Fuzzy line C GPU vs on-off CPU Black Fuzzy line D GPU vs off-on CPU Black Fuzzy line E GPU vs on-on CPU Black Fuzzy line F On-off CPU vs off-off CPU Black Flat line G On-off CPU vs off-on CPU Black Fuzzy line H Off-on CPU vs on-on CPU Black Flat line

All files exported with GPU enabled are identical, no matter what the sequence or export settings are. Files exported with GPU disabled with MRQ off are identical whatever the sequence settings are. Files exported with GPU disabled with MRQ on are identical) whatever the sequence settings are.

Conclusion: Premiere Pro uses slightly different algorithms in CPU and GPU mode. Only when the export settings are changed does the file size differ, and a fuzzy line shows in the scopes. Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 11: Export to ProRes 422 HQ, with scaling at 120% and Unsharp Mask effect at 0%

# Sequence Export GPU Export
Time GPU
Usage A MRQ on MRQ on CUDA 3 min 56 sec – B MRQ on MRQ on Off 3 min 54 sec –

CPU was constantly around 100% on all cores for all exports. The two files are identical, down to the byte. GPU was not used, even though GPU acceleration was enabled.

Conclusion: Adding a non-accelerated effect to a clip forces Premiere into software only mode for the duration of the clip, even when the GPU acceleration is enabled in Project settings.

Test 12: RED source, Export to ProRes 422 HQ, MBD settings

# Sequence Export GPU Export
Time GPU
Usage A MBD off MBD off CUDA 49 sec 0-90% B MBD off MBD on CUDA 50 sec 0-90% C MBD on MBD off CUDA 49 sec 0-90% D MBD on MBD on CUDA 50 sec 0-90% E MBD off MBD off Off 4 min 11 sec – F MBD off MBD on Off 4 min 31 sec – G MBD on MBD off Off 4 min 11 sec – H MBD on MBD on Off 4 min 29 sec –

The test was performed with a 5.5 seconds clip, R3D REDCODE 8:1, 3792x3160px (anamorphic), with Lumetri (RGB Curves), exported to ProRes 422 HQ at the same size. CPU usage was around 50% on all cores for all exports with GPU, and around 30-40% without the GPU.

The four files exported with GPU enabled are identical, down to the byte, and difference mode shows a straight line in the waveform scope. When comparing exports done with and without MBD with GPU disabled, the line is fuzzy. When comparing exports done with MBD with GPU disabled, the line is straight, and the files are identical, down to the byte. When comparing exports done without MBD with GPU disabled, the line is straight, and the files are identical, down to the byte.

Conclusion: The MBD setting in the export settings affects render times and the exported file only in Software mode. The MBD switch in the sequence settings does not affect the final render unless you check Use Previews in the export settings.

Test 13: RED source, Scaled, Export to ProRes 422 HQ, MRQ settings

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 41 sec 0-50% B MRQ off MRQ on CUDA 41 sec 0-50% C MRQ on MRQ off CUDA 41 sec 0-50% D MRQ on MRQ on CUDA 41 sec 0-50% E MRQ off MRQ off Off 1 min 50 sec – F MRQ off MRQ on Off 5 min 55 sec – G MRQ on MRQ off Off 1 min 51 sec – H MRQ on MRQ on Off 5 min 54 sec –

The test was done with a 5.5 seconds clip, R3D REDCODE 8:1, 3792x3160px (anamorphic), scaled to 120%, exported to ProRes 422 HQ at the same size.

CPU usage was around 60% on all cores for all exports with GPU, about 50% for software exports without MRQ, and around 30-40% for software exports with MRQ. That feels kind of backwards, but that’s what the test showed.

All four files exported with GPU enabled are identical, down to the byte. The files exported with MRQ off and GPU acceleration off were identical, down to the byte. The files exported with MRQ on and GPU acceleration off were also identical, down to the byte.

Conclusion: when you’re in GPU mode, this setting does not matter (unless you have source files that support fractional resolutions). When you’re in Software mode, MRQ in export settings does affect the exported clip, while the sequence setting does not, unless you check Use Previews in export settings.

Test 14: RED source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 10 sec 20-30% B MRQ off MRQ on CUDA 14 sec 90-100%

The test was done with a 5.5 seconds clip, R3D REDCODE 8:1, 3792x3160px (anamorphic), scaled to HD size using Set to Frame Size (25.3%) exported to ProRes 422 HQ HD.

CPU usage was 100% on all cores for both exports. The files are not identical at all, and a Difference mode test shows a thick fuzzy line. Surprisingly, the export done without MRQ seems sharper than the one exported with MRQ. But it’s also more pixelated, so leaving MRQ on results in a more pleasant-looking image with less noise.

Conclusion: With MRQ on, Premiere uses the full res image to create the low-res output. Without MRQ, it uses a partial resolution (half-res, quarter-res, etc.) that wavelet-based codecs like RED and some other formats have built-in. Even with GPU enabled, MRQ will affect exports of these formats.

Test 15: Cineform source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 8 sec 50-100% B MRQ off MRQ on CUDA 8 sec 50-100%

The test was done with a 5.5 seconds clip, GoPro Cineform, 3792x1580px made from the RED clip.

The clip was scaled to HD size using Set to Frame Size (50,6%) exported to ProRes 422 HQ HD.CPU usage was 100% on all cores.

The clips are almost identical, but not quite (144 bytes difference in size). In Premiere, the scopes show a perfectly flat line, though, so the image quality is exactly the same.

I ran the test again with scale set to 50%, and the two files were identical.

Conclusion: Premiere Pro is probably not using partial resolutions when scaling Cineform clips without MRQ enabled. It may be using partial resolutions only when scaling to less than 50%.

Test 16: JPEG2k source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 38 sec 20-50% B MRQ off MRQ on CUDA 39 sec 20-50%

The test was done with a 5.5 seconds clip, JPEG2000, 3792×1580, made from the RED clip.

The clip was scaled to HD size using Set to Frame Size (50.6%) exported to ProRes 422 HQ HD. CPU usage was 100% on all cores.

The files are identical, down to the byte. I did the test again with scale set to exactly 50%, and again those two files were identical.

Conclusion: Premiere Pro does not use partial resolutions when scaling JPEG2000 clips, unless it’s only used when scaling to less than 50%.

Test 17: Sony RAW Source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

# Sequence Export GPU Export
Time GPU
Usage A MRQ off MRQ off CUDA 13 sec 50-90% B MRQ off MRQ on CUDA 13 sec 50-90%

The test was done with a 5.5 seconds Sony RAW clip. The clip was scaled to HD size using Set to Frame Size (46.9%) exported to ProRes 422 HQ HD. CPU usage was 100% on all cores.

The files are identical.

Conclusion: Premiere Pro does not use partial resolutions when scaling Sony RAW clips.