[Ivan Myles]

[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% magnification

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

[Ivan Myles]

Not necessarily, but the computer might still struggle with the footage. There are a couple of features in Premiere Pro that address this issue. First, the playback resolution can be reduced from Full to 1/2, 1/4, 1/8, or 1/16. The selector is located under the bottom right corner of the video image in the monitor panel. Alternatively, you could generate preview files.

[Ivan Myles]

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.

[Ivan Myles]

Rectangles and other shapes can be inserted manually with the Title Designer. What method are you using to add the subtitles?

[Ivan Myles]

ProRes is a better production codec than MPEG. However, this may or may not be important depending on whether you use smart rendering.

MPEG I-frame is the default choice to generate preview files while editing. These files lessen the load on system resources by alleviating the need to construct frames on-the-fly when playing a sequence. Other preview codecs may also be chosen. Regardless of which preview codec is selected Premiere Pro processes the source files internally with full 4:4:4 chroma sampling and uncompressed bitmaps at a depth up to 32 bpc.

The selection of a preview codec will not impact the quality of NLE output files unless you choose to export the preview files. Adobe calls this Smart Rendering, and it allows the system to process the preview files for export rather than rendering the entire project. The new release of Premiere Pro CC supports smart rendering with ProRes, DNxHD, AVC-Intra, and other codecs.

[Ivan Myles]

I downloaded all three of the Vimeo files and they look fine. There is some light banding in the mobile file within the green background at 00:16-00:19. This is to be expected given the low bitrate. Other than that all three files look good. It seems likely the problem is due to external factors (device hardware, media player, connectivity, host server, etc.) rather than the encoded file.

[Ivan Myles]

It helps to upload a high bitrate file. Ultimately, though, the uploaded file will be transcoded to low bitrate 8 bpc 4:2:0 video. The are a few practices within the workflow that can minimize potential problems. Note that some of the items listed below are overkill if the final output will only be viewed online:

– Your source material is 8 bpc YCC color. Maintain YCC color (Premiere Pro YUV) and/or a high bit depth through the pipeline (32 bpc in Premiere Pro, 16-32 bpc in After Effects). Check the icons for each effect to ensure they meet requirements. Many 8-bit effects have a higher bit-depth alternative that can achieve the same desired results.
– Minimize the possibility of banding by avoiding smooth gradients. Use stripes, textures, overlays, etc. to break-up large areas.
– Add grain to low movement backgrounds to avoid macroblocking. Note that the Noise effect in Premiere Pro is 8-bit, so you would need to encode an intermediate file with the noise to avoid adding an 8-bit effect to the main sequence.
– Use the color scopes in Premiere Pro to check for any potential issues.
– Minimize the number of intermediate file transfers across applications. Use dynamic links as long as your system isn’t getting bogged down. If an intermediate file is needed, select a 10-bit, 422/444, high bitrate, all-intraframe codec like ProRes, DNxHD, AVC-Intra, or, if storage space is not an issue, uncompressed V210 or DPX.
– If exporting to a 10-bit codec enable Maximum Bit Depth in the sequence and export settings, and set Depth to 48- or 64-bit (Premiere Pro) or “Trillions of Colors” (After Effects). Otherwise, the output will be 8-bit regardless of the codec.
– In Premiere Pro use the Export button instead of Queue. For H.264 from After Effects pull the file/composition into AME or Premiere Pro instead of exporting from the AE Render Queue.

[Ivan Myles]

It is also a good idea to regularly empty the media cache. How full is the hard drive?

[Ivan Myles]

I’m not seeing anything significant, either. Before troubleshooting the encoder settings, try viewing the Vimeo movie on a few different devices (preferably with IPS screens). Also download the file and look for problem areas frame-by-frame in Premiere, After Effects, or even QuickTime. If you don’t see any issues in the file, you might have a hardware issue. However, if you see problems please take a screen capture and post here.

[Ivan Myles]

There are a variety of upload strategies such as using an Adobe preset, following the Vimeo compression guidelines, matching Vimeo’s encoding settings, or submitting a high bitrate file. In general HiP@L3.1, 10 mbps, and keyframe distance equal to frame rate should work well. Note that 2-pass encoding is OK (and preferred); you do not need to use 1-pass VBR. Also, in the export settings make sure Multiplexer Stream Compatibility is set to Standard; it defaults to iPod.

Vimeo transcodes files using the x264 codec. Here is some info from your linked file (as per MediaInfo):

Profile: High@L3.1
Keyframe Interval: 72
Minimum Keyframe Interval: 24
Bitrate: 2500 kbps
Max Bitrate: 3750 kbps

The lowest risk approach is to upload a very high bitrate file. Vimeo accepts ProRes and DNxHD, but this might not be practical if you have a 500MB file size limit. You could upload an H.264 file with high bitrate and relatively low key frame distance (2-24 frames). It’s overkill, but you are assured that Vimeo will have the highest quality available for transcoding.