All about Transcoding

A number of different things to cover.

First, much if not all of that media is "DSLR" ... which means long-GOP interframe media. This is handy for the camera makers because it compresses so heavily there's less to write to the card ... they can use higher frame sizes/rates and still get fast writing times.

How it works though is by creating one "real" frame every X number of frames, and all other frames are not actually created ... only a data-set of the pixels that have changed since the "I" frame was made. To de-encode this, the CPU first decompresses an I frame ... then passes that along as well as stores it in RAM; then it pulls up the data-set of pixels changed from that last I frame and then pulls the previous I frame back, computes the next frame, passes that along & stores it ... rinse & repeat.

So this media is very demanding of CPU/RAM resources ... cores & threads and such ... especially with 4k and higher frame sizes and/or 50fps & higher frame rates. Long-GOP is "long group of pictures" btw.

So ... you see, there is a solid reason that most anyone handling this media will either want to transcode or use proxies. Even powerful rigs running a project with this sort of media and 4k/60fps sequences is going to choke if you start throwing any of PrPro's heavy effects ... video noise reduction, Lumetri, Warp Stabilizer, tracked masking ... and a host of others. Which are nearly always going to be used with this media.

Two choices: proxies or transcode.

Setting up a proxy preset through AME that you can use in PrPro's Ingest process would allow for using the original material, but doing most of your actual editing while playing the proxies. Once you've ingested the media, PrPro invokes the Adobe Media Encoder to create the proxies, which for a large project can take a bit. Go get some coffee & a bagel.

You then get an icon in the Program monitor to instantly swap between them, PrPro always uses the original media for exports no matter which is "showing" at the moment, it's pretty slick in all. Doesn't work with previously merged clips, in case you've got that.

Transcoding ... you can do either by setting up the Ingest process in PrPro to create transcodes from a preset you've made in AME, or ... my favorite way of doing this ... setting up watchfolders from AME, each with it's own presets ... you then drag/drop media into a specific watch-folder on disc, AME automatically "sees" it, and begins processing the files to the transcode preset set for that folder, placing them in the output folder you've specified in the preset, and renaming if that's part of your chosen steps.

This way, you can have folders set up for different media to different output settings. I do this with my Samsung S7 4k phone footage. Like on our recent train trip over the Rockies & through Glacier park, I had a few gigs of phone-vids that I dropped into a watch-folder in the evening and by next morning had the transcoded media that would play properly in PrPro.

As to disc space ... any codec you would transcribe to for editing that would be an improvement will take a lot more disc-space than the original media. I know of several editors who routinely transcode all media for best editing ... and after they've finished a project, dump the transcodes and re-link the originals prior to archiving the project. They can always re-create new transcodes if they want to do more work with that media or project.

I know others who use the transcodes as a second or backup media ... they use Prelude to do this, having it move the media from the card to the "archive" location after renaming it, and transcode (with the same renaming) to the working drive they'll use for the project. They then archive the entire project folder including the transcoded media to a separate drive system after completion.

Using the proxy workflow of course means you'd just dump the proxies (probably) after you finish the project, with no additional storage space needed.

Neil