Glitching frames during GPU Acceleration

Report · Dec 26, 2020

Does anyone have a solution for this problem?

I've been having problems in Adobe Premiere where random frames in my sequence appear glitched and broken, and sometimes even render out in that state.

I've attached three pictures of the problem occuring, note how they look suspiciously like a typical "bad frame" on a corrupt H264 video. While my source footage is AVCHD format (and therefore actually H264 under the hood), I can confirm they aren't the result of corrupt files or an actual part of the footage - these glitched frames appear at different points in the sequence each time I open Premiere, do not appear in other programs and sometimes "fix themselves" after a while.

I have confirmed that turning off GPU Acceleration fixes the issue, but for a couple of reasons I would prefer to find a better solution that this. I can also confirm that the GPU Hardware itself is not at fault, as I tried other GPUs and the problem remained.

I am using the latest version of Premiere Pro (14.7) and the latest NVIDIA Studio Graphics driver (460.89).

Here are my specs:
Ryzen 7 3700X
MSI Tomahawk X570 Motherboard

NVIDIA RTX 3070 (the issue also occured with two different RTX 2060 SUPER cards I borrowed for testing)
Samsung 1TB 970 Evo Plus M.2 NVMe SSD (Boot Drive, Adobe Installation and Media Cache)

ADATA 1TB M.2 NVMe SSD (for source footage)
Seagate 2TB SATA 7200RPM HDD (for project files, Auto Saves and Preview Renders)

Report · Jan 08, 2021

I have a few tips for you to try, I read the whoel thread, but there is a ton of details in it, if I am repeating something apologies in advance;

First, do not use this drive for previews:

Seagate 2TB SATA 7200RPM HDD (for project files, Auto Saves and Preview Renders)

Previews, generates lots of drive fragmentation, which is the enemy of video files.

Basicaly, I would ONLY use this drive for exported projects.

The other thing you want to do, is run the trim command on all your SSD/NVME drives. When you do this, also run the defragment command on the SATA drive I noted above. If you are not sure what Trim/Defrag are its best to google it, but run these commands.

Second, depending on what version of windows / build number, you may have the version with the issues with the trim command, that wasnt working proper. If you can, upgrade to the latest Windows Builds, also, look for option drivers while you update, windows 10 update doesnt make it very clear when it offers options updates, but look for them on the update page.

Also, if you have not downloaded the samsung magition software, down it, and check to ensure firmware is up to date on those drives. They also offer a NVME enhanced driver (I use it) and it will help.

Turn off the MSI game mode boost. Often, game mode boost stuff disables certain things that can allows errors to show up in the math it does. Your driver / Bios setup should be focused on quality, not speed.

I dont know if you have screen recording software installed, but sometimes, driver packages etc can offer OBS install ot specific tunning, please ensure thats all off/unistalled (unless you use it, in which case try it as trouble shooting).

Do your mother board bios updates, if you have any. Thats a very new Chip, and they may have updates that you need. I have nto run AMD before, but for intel, there is often a 'chipset' driver package for the operating systems that match the Bios update path. AMD might have a simular path.

What your seeing on that screen appears to be envenc decode issues. I suspected that your root issue has to do with the overclock of video card at first, but it appears to me that your issue progressed from none, to increase in occurances. This leads me to belive that 7200RPM drive fragmentation and possible TRIM and firmware for the SSD/NVME might be playing a role.

I had a issue with the NVME driver causing me all sorts of issues in the late fall, I had to install the driver again as a windows update appeared to damage the driver, but device manager was reporting it was current. You might have the same issues, so best to install the NVME driver again (full install/overwrite).

Here is a half decent link for the driver details, but download it from samsung direct, I never trust these 3rd party sites for links to drivers:

Samsung NVMe SSD Driver Download v3.3 (guru3d.com)

And please, stop using that 7200RPM SATA drive for preview files, between the speed of the drive and the fragmention issues with that type of drive, it will cause you greif at some point. (run the defrag also as noted earlier).

And last thing, if you have antivirus software installed, remove it for at least testing. I have used windows defender and have had no issues, but if your running other scanners, they tend to be very agressive, and when you create/read/move a file (such as block of preview video) the anti virus wants to read the block first, and this gets in the way of playing it back.

Hopefully one of these steps gets you further along, if you have not tried them already. I am interested in your feedback on this topic.

as a side note, I run the multiple 970, 960 drives, an RTX 3090, with the current studio driver and current premier CC, with no play back issues. The GPU is NEVER busy enough in playback to give me any reason to think that a 3070 would have issues (I do note you tried multiple other video cards).

As a side note, I am not a big fan of the ADATA brand, I would suggest if you can (not already) for your testing, try putting your source footage on a the samsung for testing. If you open task Manager, you will see that the disk actrivity for all those drives, and those NVME's are not very busy at all, so for testing using the samsung for source is fine. The reason why dont have an good opnion of ADATA is mostly because I dont trust thier specs. I dont know which version you have, but its possible they are using QLC (slower) memory, and often they dont include cache on the drive, or too little cache, and this creates challanges for writting data mostly, but can for reading data also. However, ven the worst NVME drive should be okay for 4k video, but if not already, try to exclude the ADATA and the SATA for testing purposes.

Apologies for the long response, hopefully somethign that can help you will be found within it.

Report · Jan 10, 2021

Oh don't worry about long responses - I love how you've gone into detail and broken everything down! It really gives me some insight.

Unfortunately, I still haven't found a solution so far. I've tried:
- Disabling MSI Game Boost
- Shifting everything onto the Samsung SSD
- Updating Ryzen Master (which it turns out I badly needed to do, actually!)

- Deleting my media cache several times

- Disabling antivirus realtime protection

- Uninstalling and reinstalling Samsung NVMe driver

- TRIMming and Defragging my drives

On a side note, I noticed some interesting points:
- Someone pointed out that my GPU is overclocked and may be unstable as a result. But it turns out that I am running it in Silent mode, which appears to be an *under*clock.

- I said earlier that the "glitches" I experience happened in different places, but for a while one particular frame consistently glitched. After my last few attemps to fix it, the "glitch" did move away to another frame of the same video. Again, since these glitches move around in this way and do not appear in an external player (VLC) I don't think it's the source footage at fault.

- you mentioned that you don't trust ADATA, and from your description I can understand why (cache-less SSDs are bullsh*t), but I benchmarked the drive using CrystalDiskMark and it almost matched the Samsung drive in terms of speed. It also has good reviews online.

- For some reason, I can't find a download link for the AMD Ryzen Chipset drivers anymore, and MSI Dragon Centre can't find an available update either.

There are two more things that I want to try for now, and I'll post again with updates:
- When I get the time tonight, I'll run a handbrake render and transcode my footage into H264 as you suggested in a later comment. I may actually try HEVC/H265 as well to be thorough.

- I'm running the latest stable MSI Motherboard BIOS, but for some reason the "next" update has been marked as Beta for a while, for far longer than other motherboards have done so for the same AMD AGESA update. I don't want to risk installing a beta, but on this latest stable release my motherboard has had issues taking a little too long to POST. With that information in mind, I'm considering rolling back to the *previous* stable BIOS version.

Report · Jan 10, 2021

Oh yeah, one more thing: I'm not sure preview renders are to blame. You know how there's that bar on the top of the timeline that shows different colours for the render status? One of the clips that consistently glitches is marked yellow, which I gather is "should be fine with GPU acceleration turned on".

In another project file where the same clip and same effects are used, but with the Mercury Playback Engine set to Software Only, I have rendered that segment and it appears with the color green. However, the glitch still occurs here now and then. Having said that, this project file was still using the SATA/HDD drive for previews at the time.

Report · Jan 08, 2021

EBalma; Have you tried to convert your videos to H264 using media encoder (or handbrake) before importing them and see what happens? If you provide a dropbox to download a sample of your footage, I would be prepared to check if I see the same artificating you do on my system for you if that would be helpfull.

Report · Jan 10, 2021

Here's a OneDrive link to one of the source videos. Note that this was filmed in slow motion and needs to be sped up 4x to match realtime.

https://jupitermediavic-my.sharepoint.com/:v:/g/personal/ethan_jupitermediavic_onmicrosoft_com/EZO5a...

Report · Jan 10, 2021

Okay, I downloaded you file and found somethign very interesting.....

The file is perfect by the way, not a single frame is damaged.

Premier and media player will play it perfect at the native frame rate, also plays fine at 200%, 300% and 400% when using frame sampling (The default). I had to do no rendering, despite the timeline being red and in same cases yellow is played fine;

If I changed the blend mode to Optical Flow; it starts to look like the sample you provided. I will attempt to attach the screen shot. Once I changed it to Optical flow; the playback issues started to show up. I could change it to frame blend or frame sample, and the issues were still present. If I scrubbed the timeline the issue would appear on different parts of the video, not always the same

I decided to render preview the timeline, and then when scrubbing all those artifcats were no longer present. It didnt matter how hard I tried, scrubbing didnt reveal the artificats pictures below.

I will also say, that its 100% repeatable, I can very seldom scub without issue. Playback was always fine for me after I rendered the preview files without fail.

This is the timeline after I enabled optical flow, and started to scub it agressive. The quicker the movement of the playhead, the easier it was to get this result.

I then decided to use Media encoder to drag the file you provided into it, and used the YouTube Present and converted it to a MP4 container. The file performs flawless on all scubbing and I could not duplicate the issue at all that I captured above. The MP4 container takes a marginal split second that you can notice to render the frame the frame you stop at when scrubbing. But in 100% of the testing, there was never any artificating.

I am can say that 100% of every single frame of video you provided is fine. There is somethign wrogn with the encoding or decoding of the .MOV container you were using. I lean towards the decoder in premier for the timeline itself, as media encoder had no issue using the NVENC encoder to convert it to a MP4 file, and it scubbs and plays back perfect at 100%, 200%, 300% and 400% with agressive time line scrubbing.

Does this help you?

Report · Jan 10, 2021

Holy crap that's amazing!!!

So what happens now? It sounds like the solution for now is to transcode my videos to another container format, film all future footage in a different format and hope Adobe come up with a fix eventually?

Report · Jan 10, 2021

gotta say, I downloaded the clip and had no issues with it with software rendering on an ancient 2012 macbookpro. I use avchd material all the time on my windows machine at my studio. I'll take a look at the file when I get in to the office. I suspect that there's something wonky on your system. bwdik

Report · Jan 10, 2021

mgrenadier I am interested to see what you find. To me this looks like a subtle differnce in how the .mov container is handled. Your findings would be of significant interest to me on this matter. If I had to bet, I think its Adobe rewrite of timeline HW acceleration at the root. For me the issue only presented when scrubbing very quick. It feels like the routine to read the frames on the timeline is designed for performance, and will not read back far enough to rebuilt the frame the head rests on when you stop. In theory if you look that frame structure of his source, we may find that when he recorded in slow motion [(it looks like 25FPS footage to me) as he indicated that you need to apply a 400% speed up to get it to play real time], that the frame structure may not have full frames close enough to each other to rebuild the entire frame that premier is expecting.

My gut says that is an edge case because it was recorded as a slow motion clip and the container may not have been build to the exact standards adobe is looking for and thus they dont search frames far enough back from the playhead when drawing the requested frame to get a full proper frame. I suspect this is the case as a frame by frame inspection shows they are all intact, further, the slow motion likly is not putting enough full frames into the stream as it might be taking a encoding shortcut in order to maintain the recorded frame rate. My suspecion is that on its own, the source footage would be fine as we see with media player and VLC, but adobe frame look back for a redraw is just not far enough back (every frame they look back will slow down performance of that 'snappy' time line we expect. If its not adobe code, then its the nvidia SDK they use for the nvenc encoder itself. Overall, a minor issue that is not likly to be commonly found by users, and thus has been undetected in testing.

But all that said, I am very interested to learn what you discover, as it sounds like your have used AVCHD way more than me. Pleae keep in mind that your Mac would not be using the nvenc/nvidia software for timeline redrawing (like the OP and my system does) and is likly to have a different frame look back and thus no redraw issues. I suspect the foundatinal software code to be different between the PC and MAC versions for this sub-routine. I noted that you said your 'ancient' mac had no issues. My system didnt have any issues with this footage either for resources as it didnt even use 2% of the video card, and didnt break 3% of the CPU when playing it. The file is actualy not hard to redraw frames, and that 2012 macs performance doesnt suprise me for this footage.

Report · Jan 10, 2021

a lot of what your discussing is going right over my head. I'm an editor who has a basic grasp of the technology (well maybe a little beyond basic) but nowhere near your depth of knowledge. And I've spent the last 30 years in apple land (and before that in msdos, pre windows) and have been transitioning to windows over the last 9 months. but I prefer to work with an all iframe format rather than an mpeg format for many reasons and when I have the time, I'll transcode to prores rather than work in avchd. but I'll see if I experience any issues on my windows machine in the studio either tomorrow or Tuesday.

Report · Jan 10, 2021

mgrenadier; I can tell you know your stuff, anyone that prefers all iframe format knows more than enough to know its ideal. It will use more space (not a big deal these days).

As a foundation statement for others reading this, when your using all Iframe it has all the info it needs to display the full video frame (It is a the full and complete picture nothing missing) contained within that one frame. The format the OP is using requires that the decoder reads all the frames from the prev iframe up to the frame it needs to displayed (its like puzzel peices the software needs to arrange so they all fit together and the more distance between iframes the harder the computer works to arrange more of those peices).

My thinking for the OP is that a reencode would be enough for them to work on thier project and avoid the redraw issues. If they are comforable, they could encode in any new format, like prores and it will also solve the issues. I was trying to avoid complications in explaining the different codecs one could use. For this footage, it seems like any format will allow them to work around the issue.

With that all said, for a really solid editing experaince that is snappy, and often avoid many issues in these high compression formats, ProRes seems to be ideal, very happy it was added to Premier for Windows.

Also, Welcome to the World of Windows! I came off a Mac about 4 years ago, but when they made that new version of Final Cut X (glorified imovie), I had to leave, I hated that version, windows was very atractive back then for the performance you could get.

Report · Jan 10, 2021

You're absolutely right, I would definitely be working with ProRes or even GoPro Cineform, unfortunately I have heaps of footage and neither the space to keep all-iframe versions nor the budget to buy a properly big SSD storage.

I saw what you said about needing more hardware resources to decode HEVC compared to H264, I'll keep that in mind and try again with H264 if it doesn't work out.

Report · Jan 10, 2021

Ebalma if your short space, go ahead and use HVEC/H265. The hardware resources on your system are not going to hurt much (especialy if its 1080p). What you will notice is that hitting pause, or moving the playhead to a new location will take a little extra before it done drawing the video frame. But if your short space and comfortable with HVEC, then its okay to use. Everythign is a trade off, if you know what you get in return for what you trade, then by all means proceed.

I am really impaintent, so that 1/2 second delay when I scrub the timeline really bothers me... I work with drone footage which is really hard on the system (and often in h264/265), so I use proxies for everything I can. Its a big help as the timeline is VERY snappy.

I look forward to your confirmation this work around also worked for you.

There is nothign wrong with working around the constraints one has, make the best from what you have.

Report · Jan 10, 2021

Ebalma, I dont know what 'best' for you, you will have to try something that works for you. I posted another response with my thoughts as to why this "might" be happening, so I will not rewrite it here (I'm sure if you have an interest, you will read through it).

I think the logical step for you is to update the firmware of the device you used to record this and check it change log to see if anything is noted about .mov files enhancements. I would say, that typicaly, PC users will use the .mp4 container when editing on a PC. So if using .mp4 as the recording container for your camera's works, I would stick to that format if it is possible, and doesnt cause you any workflow issues.

h265 is harder to work with than h264 formats, takes considerable more resources to decode than a h264 stream, but your machine should have no issues to handle it (scubbing performance might me a little slow but tolerable). I would also suggest that you look into a proxy workflow; there is some good youtube videos out there for this... but ONLY look at the recent ones, in the last 6 months maybe (proxy workslow has been recently revised and is way easier than the old way). This will give you very snappy timeline performance and in general a smooth editing experinece.

I wonder if footage created by that camera that has not been recorded in the slow motion format exhibits the same symptoms? If you have standard footage from it, I would be open to check that.

In the mean time, I would test a conversation to avoid this .mov container. Prores is an ideal format to use, but I will venture a guess and say that encoding it to h264 @ 100mps (or what ever your camera gears original but rate was) is going to be fine. The goal would be to rewrap the file so it gets the video structure it needs for premier to not have issues. We can call this a work around... I think your issue is a edge case, and its not likly to be seen by many.

But do try the firmware update for that camera that created that. All of this to tell you, I dont think there is anythign wrong with your PC or premier install. Once you recode those files to MP4, and if you find no issues, you will know one way or the other. It might be worth putting in a bug report for Adobe with that video file as a sample, as I do think that your source file triggers the issue, but I dont know if its the cause or just exposes a bug within premier.

Id like to hear back from you after you try the re encoding. If you have a project built aroudn this files, I thiink you can even swap the media into your original footage so you dont have to apply all your edits to it. I have not done this myself, but I think I saw somewhere there was a media swap procedure if you need it.

Report · Jan 10, 2021

I would convert to an all iframe format like prores422hq rather than another mpeg format...