Proxy workflow - interpret footage

[Samuel Neff]

Please make the "interpret footage" feature pass down from hi-res native footage to attached proxies. For example, if native camera footage is interpreted from 60fps down to 23.976fps, then the 60fps Premiere-generated proxies should be interpreted that way as well.

[Tom1587]

@justin VanAlstyne I'm not sure to understand: "interpret footage" is the only way I see to modify the framerate of a clip without creating or calculating new frames - it's perfectly clean (to go from a 25ps footage to a 24fps one, for instance). Slowing down with speed/duration will create those inter-frames, whatever the chosen way.

[Jean-Philippe Gagnon]

It's been 4 years now?

[Alberto Bedin]

We need this bug to be fixed.

Workarounds add very annoying extra steps and they do not always work (sometimes we want to change framerate only on few clips, not all, during editing time)

[jmvdigital]

Alberto, you can change framerate/speed of individual clips on the timeline using the "Speed/Duration" option. I also keep this little list handy, which gives me the speed percents to input when I want to convert a clip to play on a 23.976 fps timeline…

Convert —> 24fps

30 FPS: 80%
48 FPS: 50%
60 FPS: 40%
96 FPS: 25%
100 FPS: 24%
120 FPS: 20%
15 0FPS: 16%
180 FPS: 13%
240 FPS: 10%

[Tom1587]

@justin Beware, "speed/duration" is really not the same thing. This process will create inter-images, by interpolation or interpretation of the footage, and give a dirtier result than the original video.

We all use interpretation footage here specifically to avoid that (for instance to edit together 24 fps and 25 fps clips on the same timeline, as it's usual with archives, while keeping the video quality clean and not creating any inter-frame).

[Andy Adkins]

@TB54 it seems like speed/duration using frame sampling actually does give you the same final results as interpreting to a different framerate although I do remember when it wasn't this way. I was curious and just tested it out. I duplicated a 60fps clip, interpreted one to 24 then dropped it in a 24 timeline. With the second I dropped it in the same timeline as 60 and slowed down to 40%. Going through frame by frame they look identical. So it does appear to be sampling the "correct" underlying frames, which was not always the case.

This is good, however, it isn't really addressing the problem at hand and there are other workflow considerations at play here.

[jmvdigital]

@Andy Adkins and @TB54… as long as your math is exact, it should divide those frames up evenly. For my specific camera and workflow, I can shoot in 59.94 fps and use speed/duration to drop it to 40% and plop it on a 23.976 fps timeline. 59.94 goes into 23.976 exactly 2.5x. But if say your original clip was actually 60.0 fps going onto a 23.976 fps timeline, then the math gets trickier and you might have some frame changes. BUT, the same thing would happen with "interpret footage". You can't cleanly interpret 60.00 into 23.976 without dropped frames.

[James Taggart]

Would be great to know when this will be fixed.. I have 1000's of proxies with the incorrect frame rate. I suspect the speed effect work around will cause conform issues when we go for final post.

[BroughtWhat]

It now seems the workaround has been disabled? I cannot right-click > Interpret Footage in AME anymore.

Hopefully this means there has been a fix? Does anyone have info on how to interpret proxy footage to match interpreted primary footage?

[James Taggart]

Still there for me, AME 15.4.5

[master_Daisy15B9]

Here too, the option to interprete footage has gone with the recent update to AME 22.4. It's still available when manually dragging footage into AME. However, that's a workaround for the workaround. So please fix this once and for all, Adobe.
Is it really so hard to make AME use the same setting for footage interpretation as premiere (automatically) when handing the footage over? Years have passed…

[braydon]

It's 2022 and I still can't work with off-speed proxies.

This is a critical issue. Fix it already!!!

[David Schlaepfer]

I see this is in progress! It's about time. Thank you for prioritizing this critical issue.

[Rustic Media]

This is unacceptable, a major known oversite and critical to make the Proxy workflow remotely usable with Offspeed footage.

Relying on Speed/Duration can make roundtrips with Resolve a nightmare 😉

[stevem14987728]

Thanks for looking at this one! I don't believe it's the right fix. For most people proxies are made as part of the ingest settings. In other words they are made before the footage is interpreted.

The ideal fix is that when footage is interpreted, the proxy that already exists of the footage gets interpreted too.

Many thanks

[Alberto Bedin]

Hello Fergus, thanks for the update. This is not the fix that is needed at all. Everyone creates proxies while importing footage. THEN we interpret footage only on clips those we need.

Proxies should be created using the same fps of the original footage AND they simply need to change footage according to the "interpret footage" setting.

[Alex Elkins]

4 and a half years waiting for this very obvious fix to one of the most used features, and the fix Adobe proposes is one that won’t work properly from the start. Brilliant. That’s what we pay our money for.

Frame count of proxies simply needs to match that of the original clip and then play back at whatever is set in the project. It’s extremely simple.

Crucially this also applies to clips that have been manually duplicated in the project - we need to be able to set different frame rates even if they’re sharing the same proxy.

[Ryan Fritzsche]

I agree completely with these other posts. This proposed fix sounds like it will create more headaches. Proxies should be a clone of whatever the original source is. Premiere should apply interpret footage settings to the proxy as they’re being applied to the original source.

[Tom1587]

I add my protest to the other ones: this is not at all the solution has been asked by 200+ people here since 2018. Proxies should just behave like the real files, whatever you apply to them. I would prefer Adobe to take more time to work on the real solution (which is still for me the major problem on Premiere Pro right now) rather than this fake fix which will delay the real fix needed for who know how many more years...

[Jan Bambach]

I have to agree with the previous post that the proposed fix sadly does not seem suitable. It would be nice to change the behaviour of Premiere/Media Encoder to the expected one.

[FinalAdobePro]

This proposed fix is good in as much as it makes the current method of working around the problem a bit easier to do, but it's more like automating the workaround than fixing the issue. What needs to happen is for proxy footage to behave just like regular imported footage whereby you import a clip and make decisions about it while editing, those decisions might include interpreting the playback speed to a particular framerate, they also might include changing that playback speed again, to a different playback speed, (maybe you chose the wrong one by mistake).

Ideally using proxies should be a mostly invisible process after the import stage of a project. You shouldn't really need to think about them, and the only consideration needed for using them once made is whether to turn them on or off. If the fix for this bug was directed towards this end, then interpreting clips with proxies should ultimately be no different to interpreting clips without proxies, there should be one proxy made at native frame rate of the source clip and interpretation should happen to it just as it does a normal clip and can be changed on the fly without the need to re-encode. It's evidently possible as any clip imported in to Premiere can be treated as such and interpreting clips doesn't intrinsically change any of it's constituent frames so I don't understand why there's an issue with marrying two versions of the same clip with the same native frame rate the way a proxy file is tied to it's original clip. Whatever the timecode address of a given frame in a clip, the frame number is unique and unchanging so it shouldn't present a problem when toggling proxies on or off, and again, it's evidently not a problem of Premiere itself somehow working differently to that under the hood because again it works with imported clips when sending them out to grade via XML.

Anyway though, up until now, given the existence of the bug, I have worked around it by importing clips with click and drag, highlighting those that need to be interpreted and adding those to the proxy queue first so I can cancel the process in AME and then interpret the clips in the queue correctly before restarting the queue so the proposed fix would be a slight upgrade by cutting 1 or 2 steps but still entrenches what seems like an unnecessary issue to begin with and all it's associated problems. Wasted opportunity.

[Lukas_Be]

It’s great that Adobe attempts to fix this issue but like the others have said it should create the proxies at native frame rate and interpret them as set in the project

[Samuel Neff]

Amazing. I'm the original person who posted this "idea" for Premiere Pro over 4 YEARS ago. Realistically, this should have taken 3 months for Adobe to see and fix this in a bug fix update. In fact, this was ignored for so long that I stopped my Adobe subscription and moved to greener pastures. Now Adobe is finally addressing it by...putting duct tape over it, and leaving the original headache entirely in place. All the other comments in the last day are hitting the nail on the head. This is not a solution. "whatever frame rate entered in Interpret Footage will be used by Media Encoder to create proxies" is NOT a solution. Any video editor can (and has) explained this below. Adobe needs to do better, and I'm not waiting around to see if they do. Bye.

[JesseSchluntz]

After many years of using a proxy workflow, I'm happy to report that this issue is no longer a problem for me because of my new system. I'm able to cut 6 angle, 4K multicams (gopros, sony a7s iii, and sony FX 9) with almost zero lag. No proxies used at all.

This was unthinkable before. I upgraded to the new Mac Studio, but after a lot of research, DID NOT opt for the top tier processor because the performance difference was so small for the money.

Just wanted to share my setup. See attached images. This new system is worth every penny.

[Ryan Fritzsche]

Samuel Neff: Tough but fair. You're exactly right.

Fergus, do you guys understand the problem we're having? There's no issue with creating proxies that needs to be fixed. Proxy creation is solid. The issue is that Premiere can't seem to treat the proxies the same as it treats the original media.