Drop Frames in Premiere with good PC. What is happening ?

Sorry, there! Yea, t-codes is code for transcodes. Fewer letters for lazy typists!

Long-GOP media just takes more CPU time/hassle whether it's decoding/decompressing for playback or for exporting. So if you are working from transcoded intraframe clips, the CPU has a ton less work when making the exports.

Plus, if the export is the same as your "preview" file settings, it can use any renders you've made in the exports with intraframe media. I know Kevin suggests using the Smart Rendering process like this for making your primary export.

Then for any other deliverables, just go to MediaEncoder, open that exported file, and create the H.264 or whatever you need specifically. Run it overnight, whatever.

This is one of the various ways to get around the hassles of processing different kinds of media.

Neil

With the outrageous size reductions especially in drone media out of the camera, transcoding or even creating proxies often makes files massively larger than the original.

Yea, this is at times scary. But like so many other things, it causes us to look at the total process and figure out a workflow rather than just grab something and go. Takes more time to figure out, test, and setup, no question. But ... you get a much faster and appropriate quality to the editing process and final exports.

Understand, when I fire up the BMPCC4K in BM-RAW mode, I can have maybe 25 minutes of media ... that is over 300GB on disc. If I shoot the same time in ProRes 422, still all intraframe, it's under a quarter of that. If it were long-GOP as a new drone, wouldn't be a tenth of the size on disc.

So choosing whether to go full transcode or "simply" proxy is more complex than it seems. With either process, you will likely get larger files for editing by a high percentage, even with 'small' intraframe proxy presets. Of course, you then dump all the t-codes or proxies when finishing the project as they can be recreated at need from the vastly smaller original media.

Full t-codes to an intraframe will export significantly faster than the computer needing to first decode/decompress the H.264/5 clip before re-encoding it into something else. So the full t-code process is typically faster on the back end.

Using small-frame-size proxy presets is a compromise on disc space in use during the project. Smaller disc space used, but ... longer final export time. This is the prime situation for using the "Smart Rendering" process Kevin talks about and has written so well about.

For one project, full t-codes may be the better option ... for another, small proxies (by frame-size/quality) might be the better option.

As with anything in video post processing, it ... depends.

Neil

Only one problem. QuickSync delivers substandard quality H.264 files. It is far better to export a high quality master to an editing codec and strike H.264 encodes of that. I think QuickSync is good for some users, especially those that have a need to churn out exports faster and don't care about quality as much as the speed of export.

I do have some news: a smart rendering workflow provides the absolute fastest way to export; it's way faster than any H.264 exports and is of high quality, plus you have the option of fixing any errors and have the ability to re-export at high speed, rather than waiting for another H.264 encode.

Only one issue: you need to spend the time to get your DNxHR/HD—ProRes—Cineform files, either as preview files, transcodes, or by shooting them in this codec (some cameras and devices do shoot ProRes). Prepping these files can be done in the overnight hours, just prior to your editing session. Media Encoder can do this for you automatically. Try it.

Regards,
Kevin Monahan

The reporting of test situations and results, especially the expected use implications discussed by both Puget and Safeharbor have gotten really fascinating. AMD is really working to close the gap, and in some ways for some workflows has. In others, some implications still give a nod to Intel. Especially, as you note, many apps are a bit more coded to take advantage of Intel hardware.

This newest generation of AMD CPUs will probably change that. I'm guessing within a year, the difference will be pretty minimal. I would expect to probably be still on an Intel platform later this fall, but ... well, depending on what Puget & Safeharbor have to offer, I do see it might be possible for me to select an AMD rig.

A year ago? Not on my life. Now? ... well, gotta look at things.

Neil

It's all so freaking complicated, right? Sheesh.

I came out of a long career as a pro portrait photographer.We've had our studio over 40 years, but my last six have been nearly totally in video, mainly video post processing. I've learned so blasted much I didn't even know I needed to know! Much of it from the School of Very Blastedly Hard Knocks.

The new AMD gear is for the price starting to look interesting against the Intel use of the QuickSync CPU hardware. As I'm mostly working with BlackMagic Raw and ProRes, some mov, well ... QuickSync isn't as necesary in my workflow as it once was. So getting a new rig, and ... looking through Puget & Safeharbor docs and ideas. Will be interesting to see what I end up with.

Neil

Frango,

Knowing about the files and what sort of  load each type brings to the hardware and to the software is part of the learning curve for any video post-processing app. In the LGG forum, a colorist's hangout, they are constantly checking how many fps Resolve or Avid or Filmlight can process with X nodes in play versus other users with similar media.

The easiest media for any video post app are the 'heavy' intraframe format/codecs, Cineform, ProRes, and DNxHD/R. Next are some of the simpler log formats, then several other formats, and on down through say 8k RED r3d files to long-GOP files.

So for planning out your workflow, it pays to know the media and your hardware/software and how to get the best performance both for editing/corrections and for final exporting. No matter the app.

One of the tools to use is of course MediaEncoder, which installs alongside Premiere. You can use batch processes there that automatically work in the background but suspend operations if you're currently working in Premiere and need all the resources. You can set up "watch folders" with presets so any media dropped into them gets renamed to X process, t-coded to Y format/codec/settings, and placed in Z folder.

And if you use either batch or watched folders, you can have the queue start when you're leaving for lunch or done for the day, so it doesn't interfere with your actual working time.

Organizational details like that are a part of becoming a more efficient post-processing worker. No matter which app, which hardware, which media. I work some also in AfterEffects, which is *very* different mentally than Premiere. And Resolve, again *very* different from Premiere. They all need a different approach to the hardware, app, and media.

Neil

I've seen the different playback reality of different rigs. Some rigs using Premiere do pretty good with most long-GOP, and some rigs don't. My older 6 core actually does pretty decent,  but we've had users on here with much beefier systems that drop far more frames when playing back and stutter a heck of a lot more than mine.

Again, I haven't a clue why. Over the last few years we've had several posters here that did various things to retrim their rigs and got great benefits. Others did exactly the same steps and got no help whatever.

Why? No clue.

Some people get much better playback in 2017 clearly.  I dont. Why? No clue. But I do know these differences aren't fake, they're real. And person that I am, I spend X amount of time gritching then go to figuring out how to just get the work out.

Others spend a lot longer gritching and sometimes can't seem to get back to work in whatever method works. I understand the frustration it's just that at some point I go what the bloody blazes and just get working.

I DO file the bug reports. I DO gritch at the engineers every NAB over many things that other users here have trouble with that I dont. And they still smile when they see me coming.  Knowing they're in for a long detailed earful.

All that said, the DJI drones push the limits of long-GOP in ever new and wondrous ways. I've seen a test report saying there are partial i-frames in use now, so full frames at times are even farther apart. So to show one section of a clip, the CPU/RAM is probably going to have to decode up to 100 frames either side of the clip frames seen on the sequence. That sort of work of course doesn't happen with intraframe codecs. The CPU/RAM only needs to decompress the specific frames used.

• Neil

JPooley ...

I can see no rhyme nor reason on why different rigs get vastly different playback experiences. And wow, the difference between one user's reports with X hardware and another user can be insane. No question.

I've read reports from people who's laptop runs Resolve supposedly remarkably better than my desktop. On my rig, Premiere is easier to edit in, Resolve needs to stop and think occasionally. Why those differences? No clue whatever.

So sure, it would be great if the engineers could nail that down for more users. Although a typical way to get a more consistent performance over a user-base is to place limits on particularly the hardware that is in use. Or with video post, limit the number of formats/codecs you work with. Apple of course chose this route for all their systems, severely limiting user choices in order to get a more consistent experience.

For the OP, well ... as I've said, I just go for what works. On my rig, now. Sometime this fall I'll be springing for a costly new beast. The media I'm working and my production needs have gone "up", so ... my hardware needs to be replaced to meet the new needs. NOT looking forward to the bill, but ... it will be better suited to my current workflow.

Even with that new rig when it comes, if t-codes or proxies test faster with X media, I'll make them without stopping to think about it. Just getting stuff done.

Neil

There's always a huge difference in what different rigs can do. I've seen people who could run Resolve with a number of nodes without any issue on a laptop, but Premiere stuttered. For my gear, Resolve is always more prone to stuttering with media during playback. Why? Heck if I know.

I routinely communicate with a number of people in video post around the world daily. And besides participating here, am on the LGG forum (mainly a colorists hangout) daily. You wanna see monster machines, sheesh ... 20+ cores, 6-8 massive GPUs, several huge RAID arrays, very spendy rigs.

And even there, when they compare say fps rendering tests in Resolve, they can get widely varying rates that often to me don't seem that much dependent on the particular hardware. The hardware is a large part of it, but clearly ... there are other difficult to nail down factors also.

So I deal in Realville. What works on X machine right now? If it handles 8k r3d files without stuttering, great. If not, t-code or probably better proxy. Same concept with any media. If that person is doing 'more', well, dandy for him and ... so what? I have work to get out today, so I just do what I know will work.

Neil

I too am having trouble playing back native H.264 DJI Drone footage on systems that are entirely capible of doing so. 

Posted UserVoice: https://adobe-video.uservoice.com/forums/911233-premiere-pro/suggestions/38660788-fix-h-264-decode-performance-especially-for-dji