Why can't warp stabilizer and speed be used on the same clip?

[Jeena22389650a1ho]

Is there any particular reason that Adobe has chosen not to implement this functionality in Premiere? It just seems odd to me that you can actually do it, but you have to use the nested sequence trick in order to achieve it. And it works flawlessly, so clearly the Premiere already has the capacity to do this. But now I have all of these nested sequences complicating my workflow, and I just don't understand the rationale behind this. For clarity, the workaround I am referencing is that if you nest a clip thats on the timeline, you can go into that nested sequence, apply warp stabilizer to the clip, and then go back to the sequence where that nested sequence lives, and apply your speed adjustments to that. And it just works! I would be interested to hear an employees feedback on why I have to go about things in this manner, rather than Premiere just allowing me to apple both effects to a single clip at the same time. Thanks.

[R Neil Haugen]

You are using two of the most complicated computing effects possible at the same time on the same clip.

And ... you do understand that a sequence only exists as metadata, right? A text file, that is used to populate the timeline panel. So how things are written into that file makes a huge difference in how they are computed. "Nesting" simply sets a very specific order and separation of processing steps. Which is why it's so useful for several 'heavy' effects used together.

Warp is easily the biggest resource hog in the whole app, even worse than say Neat video noise removal.

I do recommend to anyone, no matter your hardware ... when you get a Warp set to your liking, do a full render and replace of the clip on the sequence to a solid DI format, like ProRes422 or better.

Then you have a solid, stable clip that has no processing overhead to it. And you can apply color, time changes, whatever to your heart's content, and it will simply playback and export vastly quicker and easier.

It's simply a practical thing. I'm all about the practical. What works, works. Get on with things.

I work for/with/teach pro colorists, btw, who do things like automatically transcode all H.264/5 media on receipt from a client, as they don't want to mess with that crud on their 'heavy iron' systems that make most of us editors look like we're on cheapo stuff.

We're talking core counts above 16, and RAM around 256GB, humongous GPUs, and large high-speed commercial RAID units via 10Gbe links for fast playback. Working multiple 8k Red or Arri files without issue.

And editors with 32GB of RAM on a six core machine will complain about needing to nest, t-code, or proxy. Go figure.

[Kevin-Monahan]

Hi @Jeena22389650a1ho,

Thanks for the feature request. Would you like me to move your post to the Ideas forum? As Neil said, nesting is required to reconfigure the render order of that specific combination of effects. You have to do the same thing in other NLE applications that I've used over the years, I'm afraid. 

This article by Neat Video might explain the render order pipeline better if you'd like more info. Anything like this is possible in software, but I'm not sure about the demand to pull off such a thing as "background render pipeline reordering." I would hope that they eventually do make it easier to add logical effects combinations in any order and at any time. That said, it's nice to have the ability to change the order of the render order pipeline for a wider variety of effects possibilities.

I hope the info helps.

Thanks,
Kevin

[Jeena22389650a1ho]

That's okay, Kevin, but thank you for the offer. I now see that my question belied some ignorance as to mechanics of the render pipeline, so i'd feel kind of goofy putting forth that feature request all things considered.

Neil, as I become more seasoned and fluent in Premiere, and therefore confident that I won't flipflop on my choices so often (such as making various changes that have sometimes required me to re-analyze a warp (thus requiring a new render and replace), I will certainly consider implementing that render and replace workflow that you recommend. If that will make a marked improvement in Premiere's performance than I'm all for it.

And Kevin, thank you for sharing that article about the render pipeline with me! That was an interesting read. Totally foreign concept for me, but I'm here for it.

Thank you all once again for your expertise and willingness to answer so many begginer questions. You frequest posters are all truly invaluable to people like me who show up here. I cannot thank each of you enough for patiently answering so many of my questions. It's exciting to be developing some core competency in Premiere knowing that there is a forum frequented by some clearly exceptionally experienced and helpful people such as yourselves. Cheers.

[R Neil Haugen]

No worries! We have ALL "been there", you know?

And will all be there again, as there are so many different parts to this app and editing in general, so we are all always learning something.