Proxies not working properly with CUDA

[Vissa]

Hello everyone!

Been having this problem for a while, and because of that I can't update to the newest version of Premiere since they disabled choosing to work with "Mercury Playback Engine Software Only"

My workflow have been creating proxies and storing them in a external sd (Samsung T7 Shield - 2TB), while I keep my footage in an internal fast SSD. My footage is in 4k, my cliente records in OBS and then send it to me.

If I use "Mercury Playback Engine Software Only", the playback is smooth, no problem at all, both in my proxies and in my timeline. But if I change to GPU Acceleration the playback becomes horrible. Anyone know why that might be happening?

Usually I have to edit the project using "Mercury Playback Engine Software Only" and then when its time to render I change to CUDA because it's faster

Every new Premiere update I try updating to see if something fixed, but so far nothing. I have been using version 25.1

Any help would be appreciated

Some info about the file I recieve accourding to MediaInfo:
General Format: MPEG-4
VIdeo Format: HEVC
Frame rate mode: Variable
Color Space: YUV
Color Range: Limited

I know variable frame rate is not ideal, but any reason for that to not work with CUDA and then disabling CUDA seems fine?

How I create my proxies:
Using the preset "ProRes QuickTime Proxy" and setting to a Quarter frame size

My PC:

Intel(R) Core(TM) i9-14900K (3.20 GHz)
128 GB RAM
NVIDIA GeForce RTX 5070

[R Neil Haugen]

I'm wondering if the VFR part is the trouble?

Premiere doesn't actually convert VFR to CFR when you make proxies. Have you tried simply batch converting the media in HandBrake or ShutterEncoder to CFR, then import to Premiere and make proxies?

It's a pretty fast operation in either, really.

The other thing is there is absolutely no reason for them to be using VFR in OBS ... there are tons of OBS users like me who do not use VFR, but export from OBS in CFR.

So you might want to suggest offering help and advice to the client.

[Vissa]

I'm wondering the same. I need to check his setting on OBS, because is definitely not on purpose that he is recording in VFR. I saw people commenting that can happen if OBS remux. MediaInfo can also give a false positive about VFR, but I'm not sure about that, that's what I learned today.

Our media is pretty large, a lot of 4 hour files, so trying to convert in ShutterEncoder and HandBrake gave me as estimate of a lot of hours per file. Not sure if I'm doing anything wrong there, but that's what I got.

What's weird is that the footage works well if I'm not using CUDA.

[R Neil Haugen]

The 'not using Cuda' thing sounds like your computer has a pretty spiffy iGPU unit ... and/or processing for the media.

Yea, check on their OBS settings ... I simply use the mp4 even though it says "if the app shuts  down while recording you can't use the audio" ...as that has never happened in over 5 years of pretty heavy usage. 

[IanB_360]

Hi @Vissa 
Could you share the project file and any media you have with us? We would like to take a look at this and see if it is in fact the footage. I will message you and you can feel free to file share anything you have with us.
Here to help.

Ian

[Vissa]

Hello Ian! 

The footage is pretty big, but I can upload that to a drive to send it to you. I just started a new project so I guess is a good time to check that.

The playback is faster without CUDA, with our without proxies. And with CUDA the playback get's worse using proxies.

[Vissa]

Hello again Ian, I have the files uploaded to a drive, I'm waiting now for you message so I can send it to you 

[FlyingFourFun]

@R Neil Haugen @IanB_360 Maybe its time that Adobe deals with VFR...  at the VERY least, when you create a proxy, maybe the proxy can be CFR.....  frankly, it seems like a pretty minor thing to fix if a free bit of software can do it... adobe should address this once and for all.

[R Neil Haugen]

When you are coding effects at the level that Premiere does, you can't compare to the prosumer stuff. Even though a couple of them now have a few pretty spiffy/splashy things they do, everything that Premiere does would have to be set for the odd processing involved in VFR.

And VFR is a capture thing ... it cuts down on the frames needed to be encoded to the file, just like the long-GOP process cuts down on the pixel data being encoded to file. And in both cases, the playback device then does a ton more work to make it not obvious.

So ... can it be done? I would expect it could. But the next question ... given everything else that people want Premiere to start doing, and the constant upgrading to work with newer hardware, dump code for older not-used hardware, all that constant never ending process ... priorities are needed.

And would handling VFR better take precedence over 55 or 60 other things? For some users, yes, of course. For the majority of the user base ... maybe not so much. 

It's rather like a lot of the upper-end colorist stuff I would like to get in Premiere. Yes, the devs know that for a few of their users like me, it would be an awesome addition. But the vast majority of their users, they'd never use it ... so ... I've been told it wouldn't be wise to hold my breath even for something really awesome for some higher-end workflows.

As a long-time self-employed business person, I had to make a lot of decisions I did not like making at all. But the data were clear, and I needed to make changes at times dropping a photo style I loved doing. For instance. But things change all the time.

So ... maybe at some point, VFR would be a natural fit and welcomed by enough users to be worth the major effort it would take to fully support it 'natively'. 

[FlyingFourFun]

@R Neil Haugen

I don’t disagree (read that as mostly agree also).  I'm not suggesting anything fancy for VFR support - but rather something as simple as a way to detect VFR and alert the user to go and deal with it.... and a little better, right click, and render replace without VFR.  I don’t think I would want VFR support to be built in past the 'render and replace' (on import) approach.

The costs of developing it are likely lower than the costs of addressing the problems with support - or the 'negative' aspects that people walk away with without even knowing what the core issue is with VFR.  

With that said, there are so many people using it for game recording, and OBS etc - this is a new workflow that is big enough that I think adobe needs to address with at least an alert in import - and better yet a way to convert to VFR on import.

Feels like we are at the point where we can’t hide from VFR issues as there seems to be so many valid ways to create it.  Now, I don’t use, and have never used VFR or OBS, and maybe there are ways to turn it off in OBS and force CFR - but again, if at the very least on import an alert that VFR was detected - would cause people to think about how they record next time.

Also feels like the fact that VFR has the potential to cause all sorts of other issues - Adobe would save on support costs, users would likely have less surprises too....

Feels like we are at the point we cant hide from VFR issues as there seems to be so many valid ways to create it.  Now, I dont use, and have never used VFR or OBS, and maybe there are ways to turn it off in OBS and force CFR - but again, if at the very least on import an alert that VFR was detected - would cause people to think abotu how they record next time.

Also feels like the fact that VFR has the potential to cause all sorts of other issues - Adobe would save on support costs, users would likly have less surpirses too....

[R Neil Haugen]

Great idea, that of detect and offer render/replace within Premiere or maybe MediaEncoder!

That should get posted over to the Ideas section of this forum ... @Ann Bens could you move this post as an Idea?