-
Major Export/Encoding Discrepancies Revealed! Must Read…
Did you know that with just the following 3 settings; GPU acceleration, Maximum Render Quality, and Queuing in Media Encoder, there are 8 total combinations of how you can setup the export with 8 different quality outputs and render times that range from under 4 minutes to over 48 minutes? What is even more shocking is that the render taking under 4 minutes has the best quality!
We just posted this article that reveals major discrepancies with the Premiere export/encoding. Tests were done with the latest Premiere CC, but are also an issue with previous versions as well. This is a must read.
https://www.precomposed.com/blog/2013/06/ame-vs-premiere/
The information in the article can save you countless hours of render time and allow you to achieve the best quality possible.
Jon Geddes
http://www.precomposed.com -
11 Replies
-
That is interesting.
Though, I read somewhere that when GPU (CUDA) is enabled, MRQ is always turned on, even if you don’t check the box. Your identical times via direct export seems to prove that.
-
That is correct. When GPU is enabled, maximum render quality is on by default, however…
This means that when GPU Acceleration is enabled, there should be no difference in render time whether Direct Export or Queued, and the quality should be the same.
With MRQ turned off (and GPU acceleration on), there is a quality difference between the Direct Export and Queued Export, and it took longer to encode when Queued.
With MRQ turned on, it takes the same amount of time to encode via a direct export, but takes much longer to encode when queued.
If any of this is confusing, just make sure you always do a direct export and use GPU acceleration. MRQ can be disabled. Frame Blending should always be turned off.
Jon Geddes
http://www.precomposed.com -
Thank you for conducting and posting your analysis. It underscores the need to test and characterize the system to better understand different encoding parameters.
I wanted to determine whether your conclusions applied to other encoding scenarios, so I conducted five test runs that included both downscaling upon export and also maintaining the dimensions of the sequence. In addition to rendering and encoding (RE) a Premiere Pro CS6 project using the eight variations conducted in your analysis, I also transcoded a master file (TM) using the same export settings.
GPU-acceleration reduced rendering and encoding time by 79% on average. For all RE tests combined it took 4.8x longer for CPU-only processing compared to GPU-accelerated rendering.
Enabling Maximum Render Quality (MRQ) increased CPU-only RE time by a factor of 1.9x on average, but also produced better image quality. MRQ did not affect processing time as greatly for transcoding from a master file or GPU-accelerated rendering.
Your analysis includes this statement:
“Now when we compare all the GPU Accelerated exports… just by queuing the video in AME and enabling Maximum Render Quality, you are increasing the render time by a multiple of nearly 5 with almost no difference in quality.”
In the tests I conducted RE time was about 1.3x longer on average for RE-GPU-ME-MRQ versus RE-GPU-DE-noMRQ. The difference ranged from 1.8-10.5 minutes per test, or an extra 6.4 minutes on average. These values will be impacted by the nature of the editing project, the capabilities of the user’s computer, and other factors.
The second part of your statement, “with almost no difference in quality,” requires qualification. Rendered image quality was equally good in all GPU-accelerated scenarios (direct export, AME queue, MRQ enabled/disabled) when the files were exported without rescaling. However, in tests where resolution was reduced upon export, the jobs processed via AME queue had lower image quality than the files exported directly from Premiere Pro regardless of whether MRQ was enabled. This suggests users should avoid the AME queue when downscaling and export directly from Premiere Pro instead.
The original discussion also states:
“The CPU only export is complete garbage regardless if Maximum Render Quality is enabled or not (though enabling it certainly makes some improvements).”
I was unable to replicate these results. Image quality of CPU-only renders exported directly from Premiere Pro with MRQ enabled was equivalent or slightly better than any GPU-accelerated output. Processing time was much longer, though, as discussed above.
In addition to rendering and encoding H.264 files directly from Premiere Pro, I also exported an uncompressed DPX image sequence and wav audio file in order to understand how the different encoding parameters affected processing time and image quality when transcoding a master file.
Not surprisingly, transcoding was over six times faster than rendering and encoding excluding the time required to generate the master file. The biggest gains were in CPU-only RE, which took 9.7x longer than transcoding. By comparison, GPU accelerated RE took 2.2 longer than transcoding.
Image quality of the H.264 video derived from the master file was consistently good regardless of the export parameters. For the most part the exported files were exactly the same in all eight set-ups when transcoding without scaling or effects as determined by comparing the video using a Premiere Pro difference matte at zero percent matching tolerance. In two of four examples, for reasons unknown, GPU-accelerated direct exports from Premiere Pro used different macro-blocks for constructing P and B frames. This was not noticeable under normal viewing but can be seen faintly in the gray areas near the centers of the two magnified images linked below:
exporttest-640×480-tm-400_de-vs-me_trim.png
The following short video shows a difference matte comparing the GPU-accelerated direct export of the transcoded master (TM-GPU-DE) to the same job submitted to the media encoder queue (TM-GPU-ME). GOP length is 25 frames, and there are no differences between the files at every I-frame (frames 0, 25, 50, and 75 in this sample). The constructed P and B frames have varying degrees of difference from frame-to-frame.
Difference Matte of Transcoded Master File Direct Export vs AME Queue
This phenomenon only occurred in two of four test runs. Otherwise all files transcoded at 100% scale were the same regardless of direct export versus AME queue, MRQ enabled versus disabled, or GPU acceleration versus CPU-only processing.
When the master file was downscaled the jobs processed through the AME queue did not look as good as the direct exports. This is the same issue as experienced with RE tests. Files should be exported directly from Premiere Pro when the output has smaller dimensions than the master file.
Users without graphics cards that support GPU acceleration might be able to save time by exporting a high quality master file and then transcoding it into multiple video formats as required. Similarly, CPU-only or GPU-accelerated transcoding batches can be submitted to the media encoder queue with no impact on image quality provided there are no additional effects applied or rescaling of the master file.
-
That is an excellent analysis Ivan, complete with charts and all!
All but one of our source files were going through some type of conversion in the master sequence (scaling, 24p to 60i, etc). When doing a straight export with the settings matching the source sequence and footage, it is understandable to have different results.
A direct export with GPU acceleration always has MRQ on, regardless if you enable it or not. It is interesting that you had slightly different render times when enabling/disabling it.
Compare the quality of the fastest export (GPU-DE-noMRQ) to the slowest export (CPU-ME-MRQ) in your sequence that had scaling/effects, and there should be a better quality image in the fastest export. There was in our test sequence.
Jon Geddes
http://www.precomposed.com -
I just realized why your MRQ vs noMRQ encoding times were likely different when GPU acceleration was on…
Not all effects are GPU accelerated. Some must use the CPU, and for those scenes, you want MRQ turned on. Our test did not have any effects applied that required the CPU, which is why our GPU accelerated MRQ vs noMRQ encoding times with a direct export were the same.
Jon Geddes
http://www.precomposed.com -
[Jon Geddes] “Compare the quality of the fastest export (GPU-DE-noMRQ) to the slowest export (CPU-ME-MRQ) in your sequence that had scaling/effects, and there should be a better quality image in the fastest export. There was in our test sequence.”
Downscaled files processed with AME had poor image quality, so from that perspective the GPU-accelerated direct exports were better. However, the AME CPU-only job was not the slowest; the slowest job was the CPU-only direct export with MRQ enabled (RE-CPU-DE-MRQ). It produced comparable quality to RE-GPU-DE-MRQ/noMRQ. (Note: there was no difference between the GPU-DE files with or without MRQ enabled.) Please refer to the images linked below for a comparison.
Test 1 Render & Encode @ 100% magnification
Test 1 Render & Encode @ 400% magnificationThe files of note are shown in the second row. The stars in the U.S. flag are defined slightly better in RE-CPU-DE-MRQ, but the white areas are a little smoother in the RE-GPU-DE files. The choice becomes a no-brainer when processing time is considered: three minutes with GPU acceleration versus 59 minutes for RE-CPU-DE-MRQ.
-
…did you have 2-pass VBR enabled?
There is a persisting bug in AME CS6 that affects 2-pass H264 encodes…if you did use 2-pass VBR, check your actual data rate/file size against your intended setting. Typically it’s smaller than the target…much smaller…hence more aggressively compressed than intended.
TimK,
Director, Consultant
Kolb Productions,Adobe Certified Instructor
-
Absolutely fascinating.
I constantly run into the issue of a tremendous increase in render time from one export of the same sequence to the next. Using identical settings in AME, the first h.264 export finishes a 3 minute Red sequence with minor gpu enabled effects in about 5 minutes, however if I need to re-export that same sequence it takes over 90 minutes. Even after a reboot it struggles. Quite strange
James Drake Films
http://www.jdfnet.com
Video Production based in Denver, Colorado -
Does anyone know if the info in this article is still valid? There have been quite a few updates since it was written.
-
I’ve found that this discrepancy is still true with CC 2019. AME can’t handle downscaling like Pro can.
Reply to this Discussion! Login or Sign Up