BUG: Use Previews....Doesn't Use Previews.

Report · Mar 16, 2023

This workflow has been broken for a long time and I would really love to fix this one. I know this used to be on uservoice but I can't find the old bug.

Steps:

1. Set sequence preview file to "Apple ProRes 422HQ" or whatever your favorite is.

2. Render Sequence to full green.

3. Go to Export, Select an H.264 preset, check "use previews"

4. Watch as PrPro doesn't acess a single preview on disk and instead renders the whole timeline from scratch.

From my current example I have a .png sequence from blender than I've rendered to green in the timeline.

Export->H.264, use previews checked...

Look at windows resource monitor, why is premiere chewing up PNGs when it should just be referencing the preview files I JUST RENDERED.

.aecache files being acessed for no reason.

.png sequence being read. WHY.

Report · Dec 20, 2023

From latest beta...

No use previews when using match source h.264...

Comes back when you use the match seqeunce setting...

Report · Dec 20, 2023

I don't think they use previews with long-GOP media. As your cuts aren't limited to iframes, anything has to be encoded "fresh". Premiere has no muxing capabilities.

So that may explain the difference. Match source specifically matches to H.264. Match sequence doesn't, as H.264 isn't part of the sequence metadata. It's just a clip type used on the sequence. Which likely will have different codecs.

Edit:

An easy way to check, is have a sequence with mostly say ProRes or DNX on it, all intraframe. Try the match source option, and see if it shows "use previews" as an option.

Report · Dec 20, 2023

Hi Neil,

As I've explained before in this thread there is no technical reason why Premiere Pro can't use the preview files that are ProResLT or 422HQ files on disk and pass those into the H.264 encoder, bypassing the source media. We aren't dealing with the days where the default seqeunce preview was a low quality Mpeg file.

My workflow is typically very AE heavy and I use dynamic links to build transitions, lower thirds, graphics, and any other manner of basic VFX (screen replacements etc) that I then assmble in Premiere. I know "render and replace" exists, and use it begrudginly from time to time, but often times these things need to remain as live dynamic links, and its very convienient to be able to bash CTRL+E to jump in and tweak a screen graphic or other effect.

I use the previews to get smooth playback and "render as I go," which is a pretty typical way to work. Of coruse I can then output that to a ProRes422 file; smart rendering still works, but I don't want to send a 100GB ProRes422hq file to client. I don't have a need for that until final delivery typically. So its an uncecessary extra step to generate a ProRes quicktime and then drop that into media encoder. Rendering straight to h.264 can take forever on certain jobs since it doesn't bother to use the preview files on disk which are of high quality.

Look I'm a workflow nerd at heart, and I hate anything that is throwing a wrench in the pipeline, espscially when it worked in a superior way in previous iterations (don't get me started on the neuvo export window in general) Media Encoder sometimes follows the old behavior of using the preview files on disk but does this inconsistently at best, which is par for the course with AME.

If they could give us this, along with having preview files go mysteriously red when you close the forground AE process I would sing the praises of the Pr dev team, but it looks like they are moving away from what could be a huge timesaver which makes me unhappy.

Report · Dec 20, 2023

All very understandable. But you and I aren't the ones building this ... and there is such a thing as engineering "outlook". Which can vary notably among engineers, of course.

And from the many discussions I've had with the devs at NAB and elsewhere, I'm very familiar with the difference between user logic chains and "obvious" associations, and the engineering view of the same things.

I think all of us "here" have engineering decisions and choices we disagree with. I *certainly* do!

And as someone who uses and discusses Resolve nearly as much, there's the same difference "over there". Just typically on different issues.

Would certainly be nice to be able to get more buy-in of "our" viewpoints on many things. No question.

But I do pass on what I've gleaned from discussions with devs. Whether or not I agree with them is immaterial really. But maybe of use for understanding why X is ... X.

That's all.

Report · Dec 20, 2023

Premiere is becoming a nightmare with exports, it's still not using Previews and it keep pausing then continuing then pause again. It never paused before when no effects were on the timeline.

Report · Dec 20, 2023

Just ... ouch! Not happening here, and no clue why you're getting that. There's some truly odd behaviors that users here and there are getting, and I can't see the why behind them. Often equipment and processes are different from others getting the specific crud, but sometimes, they're the same.

Report · Dec 21, 2023

This is a bug. it used to work. It was broken somewhere around version 2019 or 2020. Adobe needs to fix it. I do not understand why it would not be possible. I've never once used a long-GOP codec for previews, and even if I did... if Premiere can play it back in real-time, then it should be able to use it to use it to export. 90% of my exports are at low-res and quality doesn't matter, so I don't care that re-rendering everything from scratch is "better" (which is debateable, depending on preview settings, obviously but still irrelevant). But it taking 20 minutes to export something that I've already spent 20 mins rendering and which should take 2 minutes to encode from ProRes to H.264 is a huge problem.

Report · Dec 21, 2023

Looks like this topic still lives. I also had given up after my assumption that it always worked but at some point it didn't anymore? 2019 or something....

I don't understand why there would be arguments against it or why it has been removed. A professional video editing software should have the means to use chache/render prior to export and from there to any format regardless of what the chosen cache format is. I'm not saying copy BMD Resolve exactly, but one would expect at least some kind of comparable robust, and usable mechanic. The current way really serves no purpose in a world with multiple deliverable formats with heavy source timelines.

Report · Dec 21, 2023

I think what we're seeing in the current beta is the process of being able to use Previews being fixed. Of course, this is just a guess.

As best as I can tell, Use Previews is working again as expected when the Previews are ProRes and the export is ProRes. Prior to this beta, if the ProRes Preview frame size was lower than the Sequence Frame size for faster rendering of previews in a rough cut, exporting no longer scaled the previews correctly (the preview frame size would be positioned at the upper left with green filling the export frame size),

Hopefully this means that we'll see this extended to exporting to other formats. For example, while we can export ProRes to a watch folder for transcode to H264, it would be better to be able to export to H264 directly - especially when queuing multiple Media Files for export in Export Mode.

For what it's worth, all NLEs require frame independent formats (ProRes, DNx, All I-frame MPEG) for previews (Premiere Pro, Final Cut Pro, Resolve). Long-GOP formats can be source footage, but not previews footage.

Report · Dec 21, 2023

Yeah I may have spoken too soon on the beta build I don't use it every day but I was testing it out for a small project this week and the "use preview" checkbox re-appeared today...

Report · Dec 21, 2023

Also just doing a test render here of a green timleine of AE comps and its still re-rendering from the aecache instead of just reading the .PRV folder...so not fixed...yet...

Report · Dec 23, 2023

Well, I must admit I have only scan read most of the posts under this topoic but can agree that 'Use Previews' in Premiere now seems to have been nuked completely as it loses the pre-rendered Pro Res 422 Render files

See my post here

https://community.adobe.com/t5/premiere-pro-bugs/some-prores-422-video-preview-files-lost-on-closing...

Other users reporting this now.

The feature seems to have been 'nuked' totally - and I am not convinced if you have the previews it actually is using them.

I rendered a clip using Neat Video denoise plug-in this afternoon.

On the timeline the it looked good when complete, but took ages to render initially as this rendered a preview to Pro Res 422 format as it should. I could see that lareg file in my Video Previews Folder.

But come export time the export got stuck in the same place!. It was trying to re-render the clip all over again on export when I had ticked 'Use Previews on Export'. It should have used the clips in my Video Previews Folder

The export matched my sequence settings exactly as the Pro Res 422 Previews.

What is Premiere doing?

I think this whole area of functionality needs 'the road digging up' and Engineering need to sort it out.

Finally - I agree with the earlier discussion that in principle, it should not really matter what format you export to using Premiere.

If you have Pro Res 422 Pre-Rendered timeline clips then there is no reason why it can't export them as H264 or H265. All it will be doing is using the embedded Media Encoder to translate those clips.

Just hope 2024 sees some improvement in this area for Premiere Pro as it is causing me a lot of hassle and wasted time.

This is basic stuff.

Report · Dec 23, 2023

It's frustrating as it used to work perfectly, and it was a massive bonus to be able to do that. I used to like watching my edit rended and knowing that it will look exactly like that in the exported file.

So please Adobe, it's not something new we are asking for, it's an option we are paying for every year since many years and it should work 100% on a paid software.

Report · Jan 05, 2024

My Work Around! Been doing it for a while.

Make sure entire sequence is rendered. Then go to File/Project settings/General and change renderer to software only. And then it will export using previews that is if yout previews are rendered to the same codec you're exporting to. When finished switch it back to Mercury Playback Engine.

Also, the make sure entire sequence is rendered before switching to software only is important, B/C if a portion of a clip is rendered and you finsih rendering it in software only there will be a color shift Mid Clip.

Hope this helps. It's a pain in the ass but it works

Report · Jan 05, 2024

I opened a case with Adobe for this; waiting to hear back after explaining the issue to someone who called me back. They acknowledged that if engineering wants to fix this, it won't be until the next major release at the end of 2024.

Report · Jan 05, 2024

Well it's nice to hear an actual update. Thx for sharing. It's a pity it's not on any big fix lists already; it's been a problem for a few years now. But here's to hoping for v2025 to fix it.

Report · Jan 06, 2024

"They acknowledged that if engineering wants to fix this, it won't be until the next major release at the end of 2024."

I find this highly concerning. Especially the "if engineering wants to fix this" part.

Report · Jan 06, 2024

I find that statement 'if engineering wants to fix this' worrying

Before I retired I ran an R&D team in the Voice & Data Comms world. Engineering didn't get to choose what they fixed - it was the customers shouting from the rooftops and not paying their bills. Our Product Management/Commercial team would prioritise what got fixed. It was certainly not up to Engineering.

They had to put their heads on the line and commit to realistic Fixing timescales. If it was reproduceable bugs - they would be first on the list to be fixed. Reproducing a bug is 80+ percent there to fix it.

What sort of company is Adobe running ?.

Report · Jan 06, 2024

Comment from R Neil Haugen

"All very understandable. But you and I aren't the ones building this ... and there is such a thing as engineering "outlook". Which can vary notably among engineers, of course".

Come on now Neil - as an R&D manager - if I had said that in my day I would have been out the door in no time.

Customers come first - not Engineering's view on life

Adobe should not be running a holiday camp ?

Report · Jan 06, 2024

"Companies" are just groups of humans. Every human is by nature, different than any other. And all groups also are different from any other group. There will be similarities in some things, but many things will be carried out differently. So ... that's the underlying humanity of the thing.

I've dealt with I don't know how many companies over the last 40+ years of pro imaging. From those making hardware ... such as large photoprocessors, to integrated hardware/software machines, to software only.

And in every case, every case, there was always an Engineering viewpoint to deal with. While it varied in how much one needed to explain a difference in outlook, it wasn't that big a variance. Well, and most companies had someone who ran ... interference, or perhaps, translation, betwen clients and vendors. Facilitating real-time interchanges of perceptible data points.

I've met a number of the devs for Premiere, AfterEffects, and Audtion at events. They all are heavy duty editors in their own time, passionately so, and they do feel quite comfortable in discussing the app in general use. And naturally, that they do feel they are also Users.

They are delightful people, in all. Fascinating to get to meet and talk with, always.

Yet, there is that "engineering" nature to their approach. They are very aware of, and partial to, having "clean" code. Unclean code is baaaaad, Leads to unexpected things, which always leads to unhappy clients.

Very, very baaad.

So when it's a case of a suggestion from users, that to them, seems like the most 'natural' way to implement would be to bugger the code a bit, well ... that's not going to go very far.

Because they then feel they are protecting the users. Worried about potential user troubles due to X change.

Well ... sometimes, "we" aren't as interested in being protected as being ... perhaps, enabled, shall we say?

Like the limitations in Lumetri's 'reach' for changes. Which are there by intent, to keep users from screwing up their pixels. However, many of us wish we could tell "Lumetri" to let us bugger those pixels up, if we choose to do so.

For an entirely different company, take BlackMagic. As someone who's been around colorists heavily ... works for/with/teaches them ... for years now ... there's a TON of things many top pro colorists have wanted changed in behaviors in Resolve for version after version.

And ... are still on their pleading's list of things they ask for, every version ...

Report · Jan 06, 2024

I totally respect what you have said here.

We also made clear our views into setting priority of develeopment as an engineering team - but commercial impact and customer satisfaction ruled.

The desire for 'Clean code' approach rings many bells...... 🙂

I think in summary we are in agreement - however - the problem we are focuing on in this thread is so well defined and reproduceable that it totally baffles me and many others why this has been ignored for so long.

Smart rendering was promoted by Kevin Monahan a while back and we all got on board with this as it was a great workflow. Now its broken.

Anyway, all we can do is hope this issue of losing rendered ProRes files gets addressed.

( I did see a post by MyerPJ where using ProResLT worked - yet to try it !)

New year, new hope !!

Report · Jan 06, 2024

Yea, what seems to be perhaps several general issues with smart rendering are defintely needing attention. Some formats/codecs don't respond as it seems they should.

I know of one SoCal editor who does apparently much network stuff, who says they typically do render & replace of their 'main' sequences set to run overnight, to the one format/codec they have normally working. Which is the same as their expected export deliverable. I'm assuming probably a ProRes.

It just keeps their workflow ... flowing. Playback is better, exports quicker, life moves on.

I know they said after they export from Pr, they routinely use some other specialized app to make the two or three required deliverables, which are probably some form of H.264.

A bit more complex than what I work with. And I'm sure they wish they didn't need to always do an R&R ... but ... this gets it out the door on time. All the time.

Report · Jan 08, 2024

(I'm the same account as "mobygamer", this is my regular account for the forums) I just got a call from Adobe support that they brought it up to engineering, they were able to reproduce it, and are definitely targeting to fix it in the new version to be released at Adobe MAX in roughly September or October. I relayed the information that some of us have seen success if the Renderer is set to Software Only in the project settings.

While I'm not happy I have to wait for exports again for roughly the rest of the year, I am encouraged by the fact that they contacted me back, acknowledged the problem, and gave a tentative date for a fix.

Report · Jan 09, 2024

Thanks for that Moby.

As promising as that may sound, personally I still think aiming to fix a bug in a major next release sounds to me like they aren't even considering it as a bug when arguably you can. Or simply a broken feature. Now they seem to make us think it's going to be a "new feature" which we should be happy about that takes time to develop and release. The only way you can make me happy is a hotfix releasing tomorrow which should've been fixed years ago.

Report · Jan 09, 2024

@MobyTrix this is great to hear. If the engineers are finally engaged and working on it, then that's great news. I'm still a little peeved it's taken so long to get anyone to pay attention to it and that it's going to take another 10 months to get addressed, but still happy it's finally happening.