The media created by the crafty drone merchants is amazing for how slickly they can compress data while also cutting down time to write that data in the drone.
Because they have a specialized chip that does the encoding ... that drone does NOT "compute" the file through a CPU type device.
However, unless you have the exact opposite device to decode it within your computer, decoding that data is a right bear. Sometimes, if you have the right gear in your computer, using the Premiere preferences to "enable hardware decoding" can help with playback.
That isn't anything whatever to do with the GPU use, btw ... it's simply telling Premiere that if there is an H.264/5 decoder chip in the computer, make sure to find and use that for playback.
Not all computers by any means have the right bits for various H.264/long-GOP encoding/decoding needs. I work with and teach a lot of pro colorists ... who have computers running typically $15,000 and UP for cost ... monster machines. Most of their machines don't handle much of the drone/mirrorless/DSLR H.264/5 clips well.
At that point, one accepts the lousy playback, or one makes proxies that DO play back decently of say Cineform or ProRes or a DNx variant. The proxy files will be much larger on disc but typically play back much better.
Or the other option ... simply to do the time-honored video-post practice of making digital intermediate files. Transcodes ... to an intraframe codec like Cineform, ProRes, or DNx, at a high enough Q that you don't lose any visual quality. And use the t-codes/DI files for the edit.
You should be able to go several generations of DI files if done properly before seeing any degradation ... this is used in the "long-form" major movie business all the time. In fact, many colorists when getting mirrorless/drone/DSLR files routinely t-code those to a better DI/editing file as part of the conform process taking the project into their grading app.
And as the files are much larger than the originals, and can be recreated from the originals at any time, there's no need to keep the t-codes/DI files after the project is completed.
So it's the type of task that MediaEncoder is built for, either using the queue to 'hold' the encoding until you're leaving for lunch or overnight so it doesn't interrupt your workflow. Or using watch folders ... you have a folder system set for this in Me. Drag/drop files into a watched folder, Me auto-starts, makes the t-codes/DI files, and puts them in the specificed output folder.
Then when you are ready, you drag/drop the files from the output folder to the project media folder. You don't waste time on it either way.
Neil
15
Replies
AdChoices