Oh, I have to use RAM previews for sure. It's the only way to see what anything actually looks like. And Preview/Auto quality most other times.

While previewing is definitely multi-threaded, and it does offload some work to the GPU, I get the sneaking suspicion that whatever causing the chugging is very single-threaded.

One thing I've noticed is that if I'm working with a HUGE image, like 10,000x10,000 pixels and using media zoom/pan (to maintain source resolution), playback preview comes to a literal stop for SECONDS whenever it needs to be zoomed/resized overall. But, if I pan across the image at an unchanging zoom level, it's suddenly smooth.

I was just trying to figure out what actually would help this be better, besides getting Magix to recode the software. :-)

You already have top-notch hardware so assuming it's working properly (not throttling, having adequate power, performing to spec) I don't think there is a way to buy better performance in Vegas.

I think you're right about some bottleneck- could be with legacy code handling stills, text, or pan/crop? I've found those to be oddly sluggish despite at least in theory their simplicity.

Feel free to make a sample project with what you are doing if you want others here to test it on different hardware [though you kind of already did that with your AMD to Intel switch]

While previewing is definitely multi-threaded, and it does offload some work to the GPU, I get the sneaking suspicion that whatever causing the chugging is very single-threaded.

I think you are correct. Vegas has always had trouble loading available cores. When you check everything and the only part of the system 100% at capacity is one core then that's your bottleneck.

@daniel-t If you can upload a zip with your project and the pngs to a cloud drive, I'd be happy to try and see if I can figure out if any Vegas settings help. My laptop is like a lower powered version of your system.

So, in writing this up... I'm maybe answering myself, but I think the most important to preview speed might be single-threaded performance (only one thread shows higher usage when everything chugs) combined with GPU performance... combined with Vegas not being well optimized.

Anyone have any thoughts?

Like you I was a Vegas user from Vegas 4.0 all the way up to Vegas 20 which is the last version I've purchased, I've used it for almost two decades. Long story short Vegas just doesn't make good use of hardware. I've since switched 100% over to Davinci Resolve because of this very reason as Resolve makes excellent use of hardware. For example my Dell XPS 15 laptop with an i7-11800H cpu and little NVidia 3050ti gpu is able to breeze through the timeline with 200mbps HEVC 4:2:2 video footage, no problems at all whereas Vegas totally chokes on it. Likewise Resolve will max out the gpu at 100% during renders, it just makes excellent use of available resources unlike Vegas which just can't seem to.

I just didn't see this situation ever changing so I've moved on as I don't think throwing more hardware at the problem will ever fix Vegas's performance issues. Perhaps not the answer you wanted to hear but it's the conclusion I came to as a long time Vegas user. Likewise this will likely be my last post here. Best of luck!

 

While previewing is definitely multi-threaded, and it does offload some work to the GPU, I get the sneaking suspicion that whatever causing the chugging is very single-threaded.

@daniel-t Much of the time Gpu decode of HEVC video is single core. There's combinations of:

• single core GPU decode playback, and single core decode when encoding (everything is slow)
• single core GPU decode playback, but multicore GPU decode when encoding to file
• Multi core GPU decode playback, Multi core GPU decode when rendering to file

The last combination is obviously how it's supposed to work with an NLE, but it's very rare on Vegas

I understand what RealityStudio is saying and hold out hope it will improve. That said if you need a program to do something today that it simply can't do, I don't begrudge anyone for switching.

In hindsight, if we would had this optimization component search been asked several years (or a decade) ago... I'd had to relinquish hopes for significant improvement at video operations like rendering, previewing, complex FX chains, 4k or higher resolutions.
Instead at 2022, the phrase "throwing more hardware at the problem" means quite not the same than in previous years.

For one, INTEL and AMD are on a real increasing competition course, this past month both achieving higher single/threaded performance (Intel has now made notable progress in improving their v/f curve, which allows them to squeeze out more raw frequency) in turbo core frequency of up to 5.8 GHz on Core i9-13900K, where only a few years ago their top freq number was closer to 3 GHz.

Then the biggest chain bottleneck, the slowest component being storage access has steadily been improving speeds from below 300 Mbps to the NvMe newest controllers and 3D memory being released to cope the highest allowance of its available PCIe specification max, in a bi or tri-yearly cycle. Now at 7.450/6.900 Mbps read/write
Following with the faster RAM already at DDR5 and 64GB capacities in laptops.

It is not just throwing MORE hardware but radically better one to the matter. Which means the actual performance constraints are now switching into connectors, protocols and the related software involved.
For instance, Microsoft finally announced only a couple of weeks ago the coming of DirectX XII Ultimate.
"enables (or rather, will enable) GPU asset decompression, allowing for modern compressed assets to bypass the CPU and be decompressed on the GPU instead."
https://www.anandtech.com/show/17613/microsoft-directstorage-11-with-gpu-decompression-finally-on-its-way

Some of these interdependent base capacities are being radically improved. Not only coming with future gear, but also relatively recent hardware might also show practical, effective improvements by way of GPU driver or own Microsoft upgrades. Both taking advantage of yet unrealized but installed hardware capacities.
Therefore this thread's question becomes a quite relevant one, to be reformulated each time there is an upgrade, be it a bettered component or related software becoming available.

That said, I am happy VEGAS development team has been carefully watching and advancing the tool as a whole complex system. Both improving necessitated (even advanced) features with related performance, while maintaining the great workflow already in place. They have proven that are capable of upgrading all involved aspects, besides increasing responsiveness with our every time more vocal and sophisticated community. Which has been a very difficult balancing act.

Nowadays VEGAS is a relevant NLE being considered in AMD's own debugging and published release logs, plus being part of benchmarks and reviews. With mature V19 and taking of V20, 2022 seems a very good time to be onboard imho.


 

In trying to replicate my issue in a simple project (which is actually pretty easy to do), I’ve noticed that there is some kind of caching going on where if the project and motion is small enough (like a couple seconds max), it eventually gets cached and can play back smoother or, at one point, pretty smoothly. But in a larger project this cache isn’t big enough and keeps getting wiped by other elements, so the issue is very blatant.

A couple things I’ve noticed…

* Scaling large images is the biggest issue to performance, particularly if using a motion zoom. Do multiple of these simultaneously and a project can crawl to its knees.

* Preview resolution and quality has far less effect on motion zooming performance than one might expect. It seems to impact composition and panning of already scaled images, but even at the lowest preview quality setting, any media-based zooms on large images are useless.

And by “large images” I’m talking 3840x2160 minimum, going up to 5000x5000, 7860x4320, even 15000x10000 which is a nightmare (but necessary due to a zoom).

* Creating a RAM preview seems to replicate exactly what happens during playback, but at least the system keeps working until the frame is done, so it’s easier to see what’s happening. And while building this preview, ONE core hits a maximum 48% utilization, and the GPU 68%. But not at the same time - it would appear that all image rescaling is done via a single CPU thread, while panning across that image and composition is GPU assisted.

* Once a media motion event has been scaled, so long as the dimensions do not change, that existing scaled image seems to be used for pans even across portions of the image that were off-frame. Which kind of implies to me that the width/height keyframe values are essentially inverse: if you take a 5000x5000 image and keep it at 5000x5000, it actually creates a project resolution image of 1920x1920 showing the whole width of the image. But if you zoom in to a keyframe value of say 1920x1080, or 1:1, it’s actually now working with a 5000x5000 image you can pan across, which is a lot more intensive.

All valid observations, and they have historical merit. Here is a FAQ that was posted a long time ago that mentions some of these.

https://www.vegascreativesoftware.info/us/forum/faq-how-can-i-make-my-video-preview-play-smoothly-in-vegas-pro--104624/

* Scaling large images is the biggest issue to performance

Yes. I know you use high resolution images as your source. Pre-scaling them to their maximum zoomed project resolution before importing will help. Example: if your product is 1920x1080, and your maximum zoom factor is 2x, your prescaled image is most efficient at a size of 3840x2160.

• It is important to be aware that Track Motion works at project resolution; it is really not the best place to zoom. On the other hand, Event Pan/Crop works at media source resolution.
• Play with different image formats as well; I prefer PSD, but you may also have good luck with transparent PNG. TIF used to be unusable because it used the Quicktime 32 bit decoder, I haven't retested since that changed.
• In addition to base preview resolution, play with these options to arrive at the best optimization for your workflow.
• 

From your other posts, and by your own admission you are doing things with Vegas that are uncharted territory, I'll be interested to share any ideas you have for improving preview performance, which has always been a subject of discussion here.

@daniel-t

Yes, I’ve battled with track motion resolution limits in prior posts - it’s one reason I settled at a 4K render resolution, as zoomed softness was too obvious at 1080p. I have since started pre-cropping my character source files (which are native 5000x5000) to ensure that, for every scene, I’m maintaining as much source resolution as possible.

Otherwise, I already try to maintain 1:1 with projection resolution as much as possible. For example my latest video has a 19,900x2160 image file for a very large/wide horizontal pan, which does indeed perform very poorly, but at least there’s no scaling.

Currently I’m using transparent PNG. I could experiment with TIFF or PSD just to see if it makes any difference.

Personally, I think there needs to be far more multi-threaded activity going on. Clearly all image resizing is single-threaded, but I’m pretty sure folks like Adobe have figured out multi-threaded ways to handle that. And perhaps the way in which it handles large images needs to be reconsidered, so it’s not always working needlessly with all data.

Typically I work at Preview/Auto for normal editing, Best/Full when I need accurate alignment, and use RAM preview for any awkward areas.

I’m a bit jealous that V20 now has preview zoom. I typically turn off scaling when I need to see 1:1, but I can’t pan the window and can only see center.

Very good observations, Daniel. Nothing like some hands-on investigation to separate the real issues from the speculation.

For example my latest video has a 19,900x2160 image file for a very large/wide horizontal pan, which does indeed perform very poorly, but at least there’s no scaling.

Wow! Could you possibly try it in sections like 3980x2160 and still get a seamless pan? My thought is it could take some load off the event buffers, or at least distribute it more equitably.

Personally, I think there needs to be far more multi-threaded activity going on. Clearly all image resizing is single-threaded, 

I'm going to run that thought past some better minds than mine. On its face, it seems to have merit.

I’m a bit jealous that V20 now has preview zoom.

It has great promise, but it can still use some refinement. The one thing it allows me to do is zoom to the pixel level to take precise white / neutral / black point samples, the way I've done in Photoshop for twenty-five years.

 I typically turn off scaling when I need to see 1:1, but I can’t pan the window and can only see center.

Yes, that's always been a point of contention with me, and I go back twenty years with Vegas, to 2001.

It's so rare to come across a newer user with such clarity and focus; at seventy-three and a survivor of the film industry, I welcome the connection.

Hailing from the real Southpark, I've got some edgy ideas for Timmy. Sometime, after the right amount of Balvenie, I may share them with you. Have a great ride!

Another thought for you: Vegas has good multilayer PSD support. Being able to turn layers on and off in a single image has got to be easier on buffers than separate images, sound right?

That huge image is a linear pan, so I could break it up, but that particular example wasn't too critical as it's only in one small section.

I was looking at PSD support, and seems it breaks the layers up into separate streams, accessed similarly to takes? Main issue is there doesn't seem to be any way to name the streams? Naming layers prior to saving the PSD doesn't seem to be reflected inside Vegas. This could still likely work for multiplane backgrounds, if there's any performance benefit, but the confusion factor might be an issue. I'll probably give it a try the next time I need a large image pan.

I'm a bit surprised there isn't a good, efficient, fast-reading open-source multilayer image file format (at least one that's common). Like an extension to PNG.

I've actually been using Vegas for a very long time! First project was in 2003, and I was using it for HDV video at the beginning of 2005 (bought a Sony HDR-FX1). Granted I only did a couple projects a year.