Hi there. This has been a problem for me for quite some time, but I historically haven't used ProRes much. But I've recently moved to a very ProRes-heavy workflow and this is becoming a huge problem....
Whenever I'm playing back ProRes-encoded files in Premiere Pro (422HQ 4K30 and 4K60), it plays for a couple seconds and then the audio drops out for a while, maybe comes back after some stuttering. Sometimes the audio just drops out and video playback keeps going like normal. But it happens with just about EVERY ProRes file.
I thought I was being bottlenecked by my gigabit network (editing from a NAS mainly) but just noticed today this is happening from local hard drive footage, too! It also works with or without CUDA engine on.
I use a secondary SSD for cache/scratch disks. I reset scratch to "next to project media" and tried cleaning the cache and moving it to a folder on my C: NVMe boot SSD (there is not "reset to default" for cache, sadly) - but that hasn't helped.
Performance is the same whether playback quality is set to 100% or 1/4, 1/8, etc.
Windows 10 Home x64
Latest (available via CC client) Premiere Pro CC x64
Intel Core i7-6900K
32GB DDR4 RAM
GTX 1080 8GB
ASUS X-99 A II motherboard
Any ideas how I can fix this? This is a huge burden to my daily workflow. 😕
One thing I would recommend is dedicated drives for System, Projects, Cache, Media and Exports. This helps eliminate any bottlenecks.
Adding to that, you'll need a very large, very fast Media drive for 4K ProRes. Unless your last name is Gates, that's probably best achieved with an HDD RAID.
Until you have that up and running, try the Proxy workflow. Stick to the included Cineform Presets.
I would have assumed I was being bottlenecked by my network raid either by the raid itself or the gigabit speeds - but the same issue is happening even reading footage from a PCIe NVMe SSD with ~2gbps read speeds while the footage is 700-800mbps. I feel like that shouldn't be the bottleneck here. 😕
Is the footage the only thing on that drive? Are the Cache files on a separate drive? System on yet still another drive?
Yes, I have that in my OP. System drive just runs Premiere & OS, etc. Project files/footage are on a totally separate drive (usually a high-speed NAS, but also local HDDs/SSDs in my testing and troubleshooting). Scratch disk and Cache goes to a dedicated SSD purely for that purpose.
Additional tests I've done:
Muting the video track while cutting allows audio to keep playing. Clearly the video feed is the main thing system is choking on. But obvious problems running that.
Splitting the audio/video on timeline and "Render and Replace"ing the audio to a .WAV seems to allow it to play back fine. But this is far too many steps to do on a mass workflow level, and unlinking clips causes plenty of other problems while cutting and is not worth it compared to just muting the video track.
Muting/solo-ing any specific audio tracks makes no difference.
Audio devices are all synced at the correct sample rate and displayed appropriately in Premiere's settings.
I do NOT have this issue with similar data rate files!! The exact same footage transcoded to GoPro Cineform or DNxHR do NOT choke like this!!! Only ProRes.
So currently for this big main project I am rendering proxies because I need to edit this now, and I can also set my primary recorder to record to DNxHR instead of ProRes - but that does not fix the terabytes of ProRes footage I'm current running with, and the proxy workflow isn't really convenient as-is to work with on my day-to-day projects; only bigger ones. This is a workaround, not a solution.
Just thought I'd add that this also happens with Red footage not just ProRes. In my limited test, it happened on a very fast fibre channel RAID and a simple G-RAID dual over thunderbolt so I think it might be processor limited. Footage is about 220 MB/s. Can generally only play about 5 seconds before the audio goes out - I actually wish we had an option to prioritize smooth audio over smooth video. IOW, skip as many frames as needed to keep audio playback from dropping out.
I'd assume my problem was just with the huge data rates if it wasn't for the fact that DNxHR seems to not have much of a problem.
Do Sequence Settings match Audio Sample Settings precisely? If not, change the Sequence Settings to match. If they must remain mismatched, try rendering audio.
If at all possible, try and move the acquisition of this footage to Cineform or DNxHR. That's an all around smoother workflow for PC, IMO.
I have this issue as well working with ProRes on a PC. When you say "Do Sequence Settings match Audio Sample Settings precisely" what exactly do you mean? For example, the audio for my footage is 48000 Hz 24-Bit, my sequence settings are the same. Is this what you mean?
I am pretty frustrated. I just recently moved from mac to PC simply so I could run PP smoothly. I got the latest generation Intel i7 8700k with an Nvidia 1070 8GB GPU and 32 GB of RAM. There is no reason I should have any issues. The whole concept around PP is that you don't need to transcode your footage. I have been trying to make PP the main NLE for a small production company for a year now and it had given us nothing but issues. It is the most buggy piece of software I have ever used. It is great in so many ways, but in terms of performance and consistent usability, it really sucks. I think it's approaching time to go back the AVID.
Hey there, wondering if you found a fix.
Also having the issue with playback stopping after a few seconds occasionally, making you think there was a cut or mismatch in playback regions. I also am seeing that until one of the two tracks are muted, I get no sound from either during playback.
Same thing. But I was working perfectly with Pro Res for about a year with the same computer.
It just start happening.
Same probleme here, on a PC Windows 10 with good specs (Core i9-9880 - NVIDIA GeForce RTX 2070 - 32GB RAM) and the last version of PP updated only with Apple Pro Res files.
The only solution I found to work correctly for now without converting all the files was to hide the video track concerned.