So you RENDER and hope to see the effect when it isn't a preview render effect? This means it won't render into your previews as it still processes the underlying frame as long as it is turned on... ...It's not a cop out. It's the result of some extended testing. I turned off the warp, rendered to green, close and open, everything is fine, still green in most cases, occasionally yellow and "conforming" message but I attributed that to audio of other than pcm formatting.
In order to BURN IN your warp, you have to EXPORT the sequence out. That is the only way.
Cop out... ...lol. That slang usually means that somebody doesn't want to spend time on what their "copping" out of. I spent some time on it, tested it, found more caveats, and even describe a workflow to work around it.
Can I be honest with you? I've never found much to be gained from working only one shot and then rendering previews. I nest everything, cut in the effects, and export the shot through AME wherever possible, then move on to the next area. When it's done, it gets imported to my project, I drag it to a video layer above my effects section and have a full format view. I get to keep working, and my system can render several sections while I keep going. With some audio effects, I like rendering a preview, as it's faster and efficient. Also, I've never gotten a warp to work well for longer than 5s of footage. You're better off with Twixtor which burns in each algorithm it uses in a set order rather than using a primary algorithm to determine the order (like the warp stabilizer does). If you use compressed input to begin with, this problem is compounded. When exporting, it needs to decompress, then read then adjust then recompress. I work with nesting, but when I nest, I replace with HQ before the export and output a compressed visual. It's still fast for use, but I rip out an HQ as well, for use later. Once I've finished cutting, I only use HQ footage, then I render out. It may take a pile of space, but the render time is about 1\10th to 1\30th of the compressed to compressed time. Hey if it was same in to same out, without color correction or warp, it would be the blink of an eye, as only a few frames would change; but I apply at least a few changes to every frame, especially in color treating.
And FINALLY:
It doesn't LOSE render files. It's simply doesn't create a readable render (It's flagged). It's not meant as a burn in preview, it's meant to be the last entry due to the resources it has to use. When you render it out, it looks fine. Close and reopen, and the Warp is now overlayed onto a set of frames that are rendered but not readable, so it reverts to using footage. Turn it off. If nothing changes (the red is still there),leave it off, save, close, and reopen. You should see green or yellow. Green is a rendered preview, yellow is footage only. Trying to leave the warp on when rendering doesn't work. It REQUIRES full footage information, not previews, and its a BETA effect that tags any renders unreadable. Whining that it shouldn't require original footage or the initial testing that defines it's function doesn't change the way the algorithm functions. The algorithm was built that way. Deal with it or don't use it. Beta is beta. Why is it still in beta? Take a wild guess. Inconsistent output could be the reason. Maybe they're still working on the algorithm. Either way, it's still BETA. It might not function perfectly.
However, there are ways of working around it...
After effects can be used as an intermediary. When doing so, that engine will handle preview rendering, which allows for PRECOMP renders, meaning it will render out a compressed or lesser quality version if you set that, or a full quality effect in the AE engine, and you won't need to rely on premiere for this effect. It will function with whatever footage you give it, including an entire sequence from premiere, and link a single file to active memory rather than a multi-stream set like premiere does. The effect in the premiere engine is in BETA, but in AE it's actually functioning more fully. It's almost like exporting it, but it allows you to make changes to the original sequence without rendering in premiere, it will work only on the memory of the AE engine to pass your video back (warning; if you don't pre-render again to afix the changes it may slow the video coming back). You'll still have to render your warp again, but it will be done behind your premiere work, so you can keep working on other sections. It's much more efficient in workflow, but I wouldn't pass too many sequences at once, it will slow your roll with each set you pass. Exporting via queuing in AME is still the most efficient way to work this, as you can queue up a long list of exports, but limit how many are actually rendering at any time, and you can add a proxy and HQ render so you can prep for output. As an alt, you can pass the export from AME to AE, loop it back to your premiere, and then adjust whatever you want in the original footage, using the export function to get a preview, and the COMP from AE to place an AEengine version of the video back into your sequencing. The AE engine will read the current file data for passing to premiere just make sure you export to the same file name. I use the frame numbers and then place over the top, which gives me yellow, but I know it's "Footage Effects" so it plays back beautifully. I've also applied only the warp in AE, and effects in premiere, then rendered. This works effectively. AE handles the warp in its engine (which is active through premiere every time I open the project with a comp in it), and any other effects I apply work as if applied to full footage.
Why#2:
AE and PPRO have different rendering engines and architectures. While similar, they aren't perfectly alike. However they have frameserver functions built in that allow their media cache data to feed into each other. Their plugins can function within each other because of this. Video can be passed between their render engines.
PPro frames to AE render, or AE frames to PPro render. They feed each others' playback as if from footage. That means they can each take advantage of plugins and tools from the other simply by reading an XML file, linking the data, and passing it through the engine of the other.
I would love for this to be a burn in effect, but it's an overpowered algorithm--overcomplicated at best, logically bandjaxed at worst--and you didn't pay extra for it. It came as a BETA and is still in BETA as far as premiere goes. That means it's only for TESTING in premiere. If you want an effect that's burn in, try re:vision or redgiant. Their algorithms occur in stages that are set and burn in, so turning sections on or off is easy, and each section uses the original frame data, without any adjustments from other sections. They've been around longer, and they are fully functional in all adobe apps. I highly recomend you look into them if you absolutlely need this effect for professional (as in PAID) work. Otherwise, work around the problem, and submit an email to support (which will probably point you back here). Of course, you could use AE as I suggested above... Which is what the full algorithm was originally built for (obvious from functionality as it worked in AE first and premiere is still showing issues mainly with respect to rendering which points to some issues with the plug in the render engine).
167
Replies
AdChoices
