Greater GPU use means more hanging

michael-harrison wrote on 5/31/2020, 6:57 PM

At least on my lowly Lenovo with a GTX 1050 chip.

The problem has gotten worse going to build 452.

I've found that I can consistently hang VP by playing my current project and when I hit the section that has two PIP tracks with Layer Dimensionality going, GPU use hits 50% or so and most of the time VP will start dropping frames (with the frame counter showing ... over and over) and eventually hang.

If I reduce the preview resolution from Preview-Full to Preview-Half, VP never drops frames and VP doesn't hang. So, at least I have a workaround for now. [added later... never mind that workaround doesn't hold up either]

Any thoughts from the Magix crew @VEGASDerek ?

I'm using the latest studio driver.

Comments

RogerS wrote on 5/31/2020, 9:58 PM

The only thing that helped me with my Geforce 1050 is changing dynamic ram preview to 0. Otherwise I need to switch File I/O decoding to the Intel processor, not NVIDIA, or I have lots of crashes.

michael-harrison wrote on 5/31/2020, 10:02 PM

@RogerS I asked in another thread but didn't get an answer... How can we tell what, if anything, happens when we change the preview ram to *anything* I've never seen *any* difference no matter what value I use.

And yeah, I found that I can't use the nvidia decoder either.

RogerS wrote on 5/31/2020, 10:24 PM

How can I tell? Vegas no longer hangs... it's pretty clear to me.

I had a test project with two video tracks. One had a bezier mask applied to the video that revealed a picture below. I created a range selection and just put Vegas on replay. Within a few minutes it was showing graphical glitches and then crashed. I could also trigger this by playing and then clicking around the bezier mask section. Same glitches, GPU use would climb and then it crashed.

So I recommend the same- create a test project (or use a problem section of a current project), restart the system, open Vegas and loop it for a while. If it's stable, try clicking around and playing it from different parts. Change dynamic ram to zero and repeat. Restore dynamic ram to 200 and change decoder to Intel, reset and repeat.

To give credit, this is where I got the idea from:
When I watched this I had already done the NVIDIA vs Intel tests and found the Intel decoder to be stable, so I was planning to do a test to debunk this method. Instead, I ended up validating it, and a week later I haven't had a crash.

NickHope wrote on 6/1/2020, 2:50 AM

Any thoughts from the Magix crew @NickHope ?

In case you didn't know, I don't work for Magix. I'm a volunteer moderator. And I don't have an NVIDIA GPU. The only suggestions I can think of would be disabling GPU acceleration, which obviously isn't a satisfactory solution, or disabling so4compoundplug.dll, if the footage is AVC.

michael-harrison wrote on 6/1/2020, 3:03 AM

@NickHope Sorry to bother. I'd have sworn I'd seen a post from you talking about a fix you put in too late to make this last update. I can't explain why I had it in my head that I could ignore the so4 hack but I'll give it a try. Probably 90% of my videos are AVC.

@RogerS the lack of any change in behavior when I change the ram usage has been a constant for me since VP 15. Fortunately for me, when I first enabled the nvidia decoder I very quickly ran into problems and switched to Intel. Have you twiddled any of the nvidia control panel settings or are you using the driver defaults?

RogerS wrote on 6/1/2020, 3:11 AM

Did you do discrete tests only changing a single variable at a time?

I find dynamic ram to be more an on or off issue- either zero or some other value (though I haven't done much testing of amounts greater than 200.)

VP has changed a lot since VP 15 and GPU acceleration. I made no changes to the NVIDIA control panel besides assigning the NVIDIA processor to Vegas. I mainly edit 4K Sony X-AVC S files these days.

NickHope wrote on 6/1/2020, 3:18 AM

@michael-harrison You're thinking of VEGASderek. Mods have an "M" avatar. The VEGAS team and MAGIX employees have 3 green slanted lines.

vkmast wrote on 6/1/2020, 3:24 AM

@michael-harrison re the hexagons. Click an avatar to see the profile.

michael-harrison wrote on 6/1/2020, 3:31 AM

@RogerS re. testing: yep. Long time developer who also learned long ago not to change more than one variable at a time. :-) News below.

@NickHope yah, corrected in the OP.

And it turns out that the root of the problem with my current project is indeed the so4 dll.

But...

I don't have to disable the dll for AVC to work around the hangs. I can get near-equivalent results by disabling "Enable Hardware decoding for So4 Compound Reader" I say "near-equivalent" because by disabling HW support I still see some dropped frames but have been unable to get my project to hang no matter how I jump around. With the dll disabled I get no hangs and no dropped frames.

Operating on the theory (until a dev tells me otherwise) that there are other benefits to using the so4 dll over the non-so4, I'll give that change a shot for a while.

Note that if I enable the dll or hw accel, my project hangs nearly instantly if I jump around while playing.

I'm very resistant to marking this as a "solution" because it's nothing of the kind.

The forum needs a "Tag as workaround" button

RogerS wrote on 6/1/2020, 3:46 AM

You should report your findings to the developers so hopefully these issues can be fixed. Way too many workarounds in Vegas.

michael-harrison wrote on 6/1/2020, 3:59 AM

@RogerS well, it turns out just disabling hw support isn't a workaround for long. It just let's me get comfortable long enough to bite me. Naturally it hung after I'd made a bunch of changes to my project and hadn't saved yet. I may have to turn on the automatic save after every change.

I disabled the dll and was able to work for about 20 minutes before it hung, so that definitely changes the problem but also isn't a good workaround.

Yah, I'll ball up the project and write up a support request.

KenB wrote on 6/1/2020, 10:21 AM

Interesting, @RogerS. I loaded a short, 10 second 4K AVC clip and set it to loop play. With "GPU acceleration of video processing" set to my NVIDIA GTX 1660 (Studio driver 442.92) there is a memory leak. This is just playing, not rendering. After every loop the memory usage bumps up. After several loops Vegas Pro 17.0 build 452 runs out of memory. The same happens in Vegas Movie Studio Platinum 17.0 (build 143). But if I turn the GPU acceleration off, or use Intel graphics, there is no memory leak.

Here is the short clip:

http://caydays.net/wp-content/uploads/2017/03/hawaii_blue_water_4K.mp4

Here is a screen capture showing the memory leak, with the preview window finally turning red (I sped up most of it so you don't fall asleep):

Ken.

michael-harrison wrote on 6/1/2020, 10:22 AM

@RogerS @NickHope @VEGASDerek

In case you're interested, the workaround that's holding the longest for me is to turn off Layer Dimensionality. Looks like combining that with PIP is a recipe for hanging with 452. I was using it just fine in 421.

lenard-p wrote on 6/1/2020, 1:01 PM

Interesting, @RogerS. I loaded a short, 10 second 4K AVC clip and set it to loop play. With "GPU acceleration of video processing" set to my NVIDIA GTX 1660 (Studio driver 442.92) there is a memory leak.

Ken.

 

Yes I get the same memory leak. I can close the project, but vegas does not let go of memory. I close vegas, and vegas does not let go of memory. It's just sitting there hogging the memory while it's not running. I"M using Nvidia card also

frmax wrote on 6/1/2020, 1:12 PM

@KenB:

I tried to reproduce your problem, downloaded your mp4 file and made the same settings as you. Loop-play in the preview monitor did not show any "red screen" for more than 30 minutes, the load in the task manager was constant in low level.

My Specs are I9900K, 32GB RAM and GTX 2080 with 8GB, so maybe not only "sex sells" but hardware sells...Of course that´s not solving your problem, but anyway it can be sign of more aggressive consumption of hardware ressources by build 452 then before

,

lenard-p wrote on 6/1/2020, 3:45 PM

@KenB:

I tried to reproduce your problem, downloaded your mp4 file and made the same settings as you. Loop-play in the preview monitor did not show any "red screen" for more than 30 minutes, the load in the task manager was constant in low level.

Look at vegas exe, see if it's memory percentage keeps going up with every loop.

In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in such a way that memory which is no longer needed is not released. A memory leak may also happen when an object is stored in memory but cannot be accessed by the running code.

Reyfox wrote on 6/2/2020, 5:37 AM

Interesting, @RogerS. I loaded a short, 10 second 4K AVC clip and set it to loop play. With "GPU acceleration of video processing" set to my NVIDIA GTX 1660 (Studio driver 442.92) there is a memory leak. This is just playing, not rendering. After every loop the memory usage bumps up. After several loops Vegas Pro 17.0 build 452 runs out of memory. The same happens in Vegas Movie Studio Platinum 17.0 (build 143). But if I turn the GPU acceleration off, or use Intel graphics, there is no memory leak.

I am seeing the same thing with an AMD RX480 8GB graphics card. With each play of the clips I work on, RAM usage slightly increases and is never released back.

I haven't turned off graphics use yet to see if memory stays the same.

lenard-p wrote on 6/2/2020, 6:02 AM

The other thing I noticed about this test is that vegas does not release memory when closing project (can be seen at end of my video) and when closing vegas there can be 2 situations , Vegas remains a process and does not release it's memory, or it slowly does reduce it's ram causing my compute to almost crash. it freezes , audio playing makes a digital type noise. and have a frozen screen for maybe 20 seconds, internet is lost, no response to keyboard or mouse. Then system comes back, and vegas exe is gone and memory is dumped.

It sounds like I have an unstable windows, but vegas is the only thing that can almost crash my computer like that. I do get a few seconds of lagginess when closing Chrome with 40tabs open, and chrome releases the masses of ram it uses but not the borderline system crash that vegas does

RogerS wrote on 6/2/2020, 7:10 AM

I did a similar X-AVC S 4K test with just looping timeline playback. Memory ratcheted up slightly between passes- about 200MB in 5 min. When I stopped play it gave back 100MB or so. At this rate it would take a very long time to run out of ram. A more memory intensive project might show this issue sooner.

I closed Vegas and it removed itself from memory as expected.

VEGASHeman wrote on 6/2/2020, 8:28 AM

I am one of the VEGAS engineers, and am following this issue. My first concern is to track down any regressions or issues introduced with the latest update (b452), and then tackle the more persistent issues, but to also triage this so that multiple issues do not get rolled into one, if they are in fact unique.

For now, my question is for @KenB: we are able to reproduce the leak you mentioned with the Blue Hawaii clip, but not just in the latest update, but also the prior one (b421) - in fact, we can reproduce it going back all the way to VP 15. As you described, it goes away when GPU acceleration for video processing is turned off; the choice of actual decoder does not matter (or for that matter, whether so4compoundplug is used or not, as that is just the decoding part). But we do not see this problem with other 4K AVC clips we tried with (or for that matter, 4K HEVC). We noticed that this was a AVC High, Level 5.2 clip, and tried others of the same type, without any luck. So we are still trying to figure out what is unique about this clip - can you provide us some more information about how you obtained it (camera, third-party software encoders etc). Please note that this test was doing with only the clip added to the timeline, and set to loop play - no other effects were added.

I will try to come back to the other issues you folks mentioned, about VEGAS being more unstable with this update - but my impression is that occurs with use of NVDEC and effects - which has been a source of concern in the past too. Please correct me if I am wrong.

lenard-p wrote on 6/2/2020, 8:32 AM

I did a similar X-AVC S 4K test with just looping timeline playback. Memory ratcheted up slightly between passes- about 200MB in 5 min.

@RogerS are you able to do exactly what @KenB did with same settings and same file and see if you can replicate the problem. And if everyone can, it's simple and quick enough to try. And list your GPU and whether you were effected. It's a pretty interesting

 

edit: I did not notice @VEGASHeman had replied. It's a known fault so no need

RogerS wrote on 6/2/2020, 8:37 AM

Lenard, I did not replicate Ken's test as other users (and now Magix staff) verified it. I wanted to see if it was a more generic issue so tested it with a Sony a6600 file.

KenB wrote on 6/2/2020, 8:44 AM

@VEGASHeman I was looking for a short 4K clip that was reasonably calm (not much movement) to do some testing of 4K editing and effects and just happened to find that clip with an internet search. It's not mine, unfortunately! But when I was doing some editing with it I started noticing some issues with memory usage. It was the second post by RogerS that gave me the idea of playing it in a loop. I'm glad you have been able to reproduce the problem. And I confirm that I was playing it with no effects added. It is interesting that frmax could not reproduce it.

Ken.

VEGASHeman wrote on 6/2/2020, 8:50 AM

@Ken-Embry, @lenard-p, @RogerS: Thanks. Even if this is a known issue, we would like to collect more information. So if folks can try loop play of other 4K AVC clips they have, and see the leak in a loop playback setup, please let us know. A copy of such clip would also be very helpful.