[Gerard Tay]

Yea. That card is not supported for OpenCL acceleration. You can try adding this little hack at your own risk.
https://www.steveoakley.net/template_permalink.asp?id=457

[Gerard Tay]

Hi Brook,

Remembering to set the scratch disk is a very important lesson for students. Admittedly, managing PPro preferences in a multi-user environment can be fairly clunky.

You can try teaching the students to use the free Preference Manager from Digital Rebellion. It is a 3rd party application that manages user preferences, hence manages where PPro stores the cache files, it also manages other preferences such as keyboard layouts.

https://www.digitalrebellion.com/prefman/

[Gerard Tay]

Ah. My bad. You’re right. It’s an encoding issue.

[Gerard Tay]

I figured that if renaming the extension forces PPro to bypass QT for the decode, then QuickTime shouldn’t get in the way of the image processing pipeline, thus mitigating QT related issues.

[Gerard Tay]

Good to know. Thanks for sharing.

[Gerard Tay]

You can try this fix to bypass the QT decoder.

https://blogs.adobe.com/VideoRoad/2012/12/premiere-pro-and-quicktime-and-nikon-oh-my.html

[Gerard Tay]

Could ve a corrupt clip. You can try running Corrupt Clip Finder. There’s a free trial period.

https://www.digitalrebellion.com/promaintenance/

[Gerard Tay]

[John-Michael Seng-Wheeler] “Your test was done with ProRes, which is a special case since Premiere can’t encode or decode the file directly. Quicktime does the decode, and passes the frame to Premere. “

I’m not sure if you noticed, but ProRes behaves differently from a bunch of other clips that require a QT decode. Eg. DNxHD in a QT wrapper. QT decodes from Y’CbCr formats have notoriously suffered from the infamous QT gamma shift, as well as prematurely clipped highlights/sub blacks. DNxHD in QT does not seem to preserve Y’CbCr superwhites whereas ProRes does, so in a way ProRes functions similar to the uncompressed QT codecs which are open source. The same gamma shifting issue has plagued Avid editors who were trying to import ProRes into MC in the pre MC6 days before ProRes was “officially supported” by Avid. I suspect Adobe may have a different decode path for ProRes other than asking for a QT RGB decode. But this is pure speculation on my part.

[Gerard Tay]

I repeated the test on another Prores HQ clip and I got the same result. There seems to be some form of smart rendering for clips with effects.

Now, when I export the clips as standard ProRes clips (SQ), and the previews were set to ProRes HQ, I get a generation loss when I check “use previews”. This would be expected, as AME is using the preview files for rendering/encoding and because the exporting format is different, the source clip would effectively have been rendered to ProRes HQ in PPro, then encoded to ProRes Standard (SQ).

The benefit of this behaviour is that if you have some processor intensive formats (eg. R3D), and because you may have rendered these clips during the edit, using preview files on export will save render time if AME didn’t have to go back and decode from the RAW R3D files, render the effect and then encode to H.264. Rendering off a lossy intermediate format (albeit perceptually lossless) would result in a slight drop in quality. So I guess this is what Adobe means.

I did a 3rd test by setting the preview format to ProRes SQ and exported to ProRes SQ, I ended up with the same result as the first test, which indicates smart rendering on clips with filters. Very smart, Premiere! Now if only it will do a “same as source” export like Avid/FCP7 or what PPro calls true “smart rendering”.

My settings so far is maximum bit depth and maximum quality renders, same for output. My source clips are ProRes HQ 720p25.

[Gerard Tay]

Let me rephrase this answer.

The equivalent of an Avid “same as source” export and FCP7’s export “current setting”, is PPro’s “smart render”. But smart renders work for only for very specific formats.

There is the “use preview files” option, which is not the same as “smart render”. “Use Preview files” will use preview files to encode, and according to a differential matte test in AE, use preview files will copy preview files if the export format is the same as the preview files, skipping a double compression on those files, but clips that do not have effects applied will be rendered even if it is the same as the export format. So PPro, although not too intelligent, seems to be a tad smarter than we give it credit for. And you can do your own tests to verify this.