Ongoing Dynamic RAM Preview issue

Deuce wrote on 2/7/2019, 1:22 PM

I've mentioned this here last year but will try again. When rendering using the default 200MB setting for Dynamic RAM Preview my rendered video is full of glitches. When I set Dynamic RAM to 0MB my video comes out perfect. However, the renders are 35% FASTER when Dynamic RAM is at 200MB! This is a big difference especially when you're in a crunch. Time is money and a 35% decrease in render time is a big deal.

I was hoping when I got my new computer that this stupid issue would magically go away but it's still there and it's extremely frustrating.

Magix, why has this STILL not been fixed????

 

Win10, 32GB RAM, 6GB GTX

Comments

klt wrote on 2/7/2019, 2:03 PM

Similar to these glitches?

https://www.vegascreativesoftware.info/us/forum/v16-permanent-problem-with-dynamic-ram-in-rendering--113885/#ca705891

To my experience if you get this kind of glitches, people tend to blame your hardware / drivers combo. I showed that this phenomenon appears when your project reaches certain complexity, and it is NOT the hardware or settings. For example, having 2 parent tracks and both have 2-3 child tracks, each having its own track motion, plus parentmotion...

This problem seems to me a flaw deep in Vegas, and I could bet it's related to some buffer handling threadsafe, which is not... You can lower DRP value, if anything above zero, your render will be fast - at least this is my experience. But before playing with DRP, for adding some data to my investigation, could you please try, if you limit max number of rendering threads to 1? Don't change anything else! Just limit the rendering threads to 1.

Do the glitches go away? If you set up render threads to 2 do the glitches come back again?

Thanks in advance.

j-v wrote on 2/7/2019, 2:30 PM

What has rendering to do with Dynamic RAM Preview?

When I set it to 0 or 200 or 2000 it makes no difference, only when using it in a project for previewing something in preview with that funtion selected in the menu Tools.
But I never use that function because I know the program and believe when my settings are right that it comes good and I never was misleaded by that belief.
Only at new options or possibilities I use it (most) once.

klt wrote on 2/7/2019, 2:45 PM

When I set it to 0 or 200 or 2000 it makes no difference,

You mean no difference in rendered video, or no difference in render time?

I can confirm that set Dynamic RAM preview to 0 increases render time. Sometimes set it to 0 can help avoid glitches, sometimes not.

And in this thread:

https://www.vegascreativesoftware.info/us/forum/how-extend-multiple-clips-on-sony-vegas--114695/?page=2

your render is glitchy too.

https://s3.eu-central-1.amazonaws.com/live.vegas.info/340/5C2/50668BF4F56C448D8E56FAA2BBFAE584.mp4

 

Last changed by klt on 2/7/2019, 2:54 PM, changed a total of 1 times.

Camera: JVC GY-HM600

Desktop: AMD Ryzen 5 1600, 16GB RAM (dual channel 2400 MHz) - Videocard: Radeon R9 380 2GB

Laptop: i5 5200u, 8GB RAM (1600MHz single channel) Videocard: integrated HD5500

j-v wrote on 2/7/2019, 3:37 PM

When I set it to 0 or 200 or 2000 it makes no difference,

You mean no difference in rendered video, or no difference in render time?

I can confirm that set Dynamic RAM preview to 0 increases render time. Sometimes set it to 0 can help avoid glitches, sometimes not.

And in this thread:

https://www.vegascreativesoftware.info/us/forum/how-extend-multiple-clips-on-sony-vegas--114695/?page=2

your render is glitchy too.

https://s3.eu-central-1.amazonaws.com/live.vegas.info/340/5C2/50668BF4F56C448D8E56FAA2BBFAE584.mp4

My question was what those settings have to do with rendering.
With me the only increases for the rendertimes is the use of a certain codec and its specification.
The Dyn Ram Prev options are only for using a small piece to preview in full, not for the export render. There it has no function at all.
The settings for DRP can only have influence on the start of the program or loading of sourcefiles while those are also using your RAM.

j-v wrote on 2/7/2019, 3:39 PM

My video's you show here are only results to show the faulty work around from the OP in that Post.

Eagle Six wrote on 2/7/2019, 3:44 PM

Not really wanting to get in between you guys @j-v & @klt, just wanted to comment that I have read in the past several users who had render issues, and setting the Ram Preview to 'zero' and it solved their issue. Not me, and I cannot vouch for them, but that is what they reported.

I haven't, as yet, found any difference in render quality or speed when adjusting the DRP setting, but I also haven't perform an exhausting study that would prove in every imaginable project that it didn't make a difference.

Last changed by Eagle Six on 2/7/2019, 3:45 PM, changed a total of 1 times.

System Specs......
Corsair Obsidian Series 450D ATX Mid Tower
Asus X99-A II LGA 2011-v3, Intel X99 SATA 6 Gb/s USB 3.1/3.0 ATX Intel Motherboard
Intel Core i7-6800K 15M Broadwell-E, 6 core 3.4 GHz LGA 2011-v3 (overclocked 20%)
64GB Corsair Vengeance LPX DDR4 3200
Corsair Hydro Series H110i GTX 280mm Extreme Performance Liquid CPU Cooler
MSI Radeon R9 390 DirectX 12 8GB Video Card
Corsair RMx Series RM750X 740W 80 Plus Gold power pack
Samsung 970 EVO NVMe M.2 boot drive
Corsair Neutron XT 2.5 480GB SATA III SSD - video work drive
Western Digitial 1TB 7200 RPM SATA - video work drive
Western Digital Black 6TB 7200 RPM SATA 6Bb/s 128MB Cache 3.5 data drive

Bluray Disc burner drive
2x 1080p monitors
Microsoft Window 10 Pro
DaVinci Resolve 15.2.3
SVP13, MVP15, MVP16, MVMS15

j-v wrote on 2/7/2019, 5:15 PM

Sorry, but probably I'm not allowed the answer you because my answer was deleted by someone.

Deuce wrote on 2/7/2019, 9:15 PM

My question was what those settings have to do with rendering.
With me the only increases for the rendertimes is the use of a certain codec and its specification.
The Dyn Ram Prev options are only for using a small piece to preview in full, not for the export render. There it has no function at all.
The settings for DRP can only have influence on the start of the program or loading of sourcefiles while those are also using your RAM.

DRP makes a big difference in my render times. Set to 200MB it renders 35% faster then when it's set to 0MB. I'm not sure why it affects render times but it definitely does for me.

Deuce wrote on 2/7/2019, 9:22 PM

This problem seems to me a flaw deep in Vegas, and I could bet it's related to some buffer handling threadsafe, which is not... You can lower DRP value, if anything above zero, your render will be fast - at least this is my experience. But before playing with DRP, for adding some data to my investigation, could you please try, if you limit max number of rendering threads to 1? Don't change anything else! Just limit the rendering threads to 1.

Do the glitches go away? If you set up render threads to 2 do the glitches come back again?

Thanks in advance.

 

I did a couple of tests.

1. DRP set to 1MB instead of 0MB - renders faster but still get glitches

2. DRP 200MB and render threads set to 1 - render is glitch free and faster than 0MB and 32 threads

So now I'm even more confused! :)

 

klt wrote on 2/8/2019, 12:56 AM

@j-v Peace 😀

If we read about what Dynamic RAM preview (I just abbreviate it as DRP) is supposed to do it has nothing to do with pure render out. Theoretically there's no difference between theory and practice, but in practice.... 😀

Personally I never use DRP, instead I do selective prerender when I need. So I could disable it too. However, if I disable DRP via set it to 0, render time is hugely affected. That's a fact.

What if if we render a project that has a constant white background, and the rendered video has randomly missing on some of the frames the background, or frames flashing in randomly which should not be there? Simpler said the rendered video has random flashing stuff which is not edited in the project? That render is buggy, isn't it?

And that's the result of a bug in Vegas.

It is common that more experienced long time users of Vegas blame the HW and/or drivers of users experiencing such a problem, and advice to update/downgrade graphics drivers, etc.

I mentioned your glitchy render, but my intention was not to insult you. I wanted to point out that the bug is present on your system too. At the moment you will need to create a more complex project, you will be hit too.

And all this below are my guesses.

@Deuce

If we disable DRP, it probably means a different execution path in the render engine. I guess this makes the difference in render time.

If we enable multiple rendering threads, then obviously more threads will work.

Putting more load to rendering threads one thread sometimes thrashes buffers the other thread is working on. And/or this thread just grabs contents of a buffer the other thread was working on, supposed to be ready, but the other thread still did not finish, still working on that buffer...

So basically I mean, that using more rendering threads the threads interfere with each other in some way. This thing just cannot happen, if there's only 1 thread working.

This is my theory, I may be completely wrong 😉.

The experience however tells me that I may be right on this. If only one example is shown, where the rendering threads number is only 1 and still there are glitches like this, that would a solid proof of my theory being wrong.

And again: it seems to be necessary to have a complex project to trigger this bug.

To mee it seems having 2 parent tracks both having 3 children, and each having some track motions, including parent motions, seems to be eligible to trigger the bug.

@Deuce how many parent and children tracks are in your failing project?

j-v wrote on 2/8/2019, 3:18 AM

At the moment you will need to create a more complex project, you will be hit too.

I think I never will be hit because I also made very complex projects.
But I never will use so much unneeded tracks where it is possible you loose your controle.
Vegas has a long history of the use of "inbedded vegs" and I 'm going to use that function if I get a lack of controlling it all.
That function had it bad moments with the introduction of the first release of the first total made version under Magix management, but since the last V16 releases it works for me without a hitch, also with very complex inbedded vegs (sometimes more than 10) in my final project that will be rendered for export without any lag or glitches in the rendered result for mostly FHD 50p AVC or HEVC files, but sometimes also the same framerate in 2,7 or 4K.

matthias-krutz wrote on 2/8/2019, 3:27 AM

I think that it is important that the problem is addressed again. For me it occurs in VP14-16. I do not have an earlier version of Vegas. However, with MovieStudio12 Platinum, the problem does not occur on the same hardware. That's why I can rule out a hardware error. In the meantime, I also switched from Windows 7 to 10. The problem has remained. The glitches in the preview are sporadic and not necessarily seen during rendering.
I have uploaded an example with which everyone can test themselves. Since it is not observed in simple projects, I have chosen a stereoscopic 3d project. The MPO files are from the Fuji Finepix real 3d w3. MPOs are JPG files containing 2 streams.

https://1drv.ms/u/s!AqT8_NAXc5TbgXzNYAhOjcOkyMrz

VP14-dynamic RAM.mp4

VP15-dynamic RAM.mp4

 

klt wrote on 2/8/2019, 4:01 AM

I think I never will be hit because I also made very complex projects.

Yes, sure.

And then don't even talk about a bug that hits others, because Vegas is perfect for you in all of your projects. And who needs a feature Vegas should be capable of* (namely using unlimited number of tracks including parent - children tracks), that poor man is just crazy, and wants to use the unneeded tracks.

*Those glitchy project render just fine CPU only, without GPU. At least 25 times slower, but they render...

I don't think I'd loose control on "unneeded" 14 tracks.

(Sidenote: someone can control even up to 35 tracks https://www.vegascreativesoftware.info/us/forum/post-your-vegas-creations--109464/?page=6#ca709386

And if those are just tracks topping each-other, I still would call it a simple project. )

Nesting projects is just something different than having multiple tracks. And that puts up another question:

Do you just nest the .veg into the container and render it, or do you do some compositing as well?

Say, you have a 4 tracks veg "A". Then nest this into project "B" as a track2. Set track2 as child of track1, and use track1 as mask, and have track1 compositing mode "multiply mask" and add a gradient in track1. And then maybe nest another .veg on track3 as a bakcdrop... Do you do such things, or just nest one project on one track and render?

 

Marco. wrote on 2/8/2019, 4:31 AM

I can't repro these kind of glitches shown in the demo videos. Most of the time I have set my DRP value to 4096 - 8192. Also that flicker demo project works without glitches here (also no crash when setting the stereoscopic mode to red/cyan). Tested with VP15 and VP16.

klt wrote on 2/8/2019, 4:48 AM

@Marco. @OldSmoke reproed my glitches. We had a private discussion about that.

Last changed by klt on 2/8/2019, 4:48 AM, changed a total of 1 times.

Camera: JVC GY-HM600

Desktop: AMD Ryzen 5 1600, 16GB RAM (dual channel 2400 MHz) - Videocard: Radeon R9 380 2GB

Laptop: i5 5200u, 8GB RAM (1600MHz single channel) Videocard: integrated HD5500

matthias-krutz wrote on 2/8/2019, 5:01 AM

@Marco.That is interesting. Now the question arises, what makes the difference.
Maybe, the problem only occur with AMD GPUs. I use the Radeon R9 380 here.@Marco.

Marco. wrote on 2/8/2019, 5:03 AM

@klt
No doubt there is an issue as Matthias' demo video clearly shows. But I never noticed it on my own (having almost never set DRP to 0). Curious what might trigger the issue.

@matthias-krutz
My current grafic device is Intel HD graphics 520.

j-v wrote on 2/8/2019, 5:16 AM

And then don't even talk about a bug that hits others, because Vegas is perfect for you in all of your projects.

@klt
Because you use your own interpretation of what I'm saying, but that's up to you.
Therefore it stop now here arguing with you because it means no help to users that have really problems and asked for help.
I'm not here to learn what I have to do, because I think I'm old and wise enough with a long time experience with Vegas software and was almost 10 years moderating our Dutch Vegas forum from which I was co-founder. 😷

 

Last changed by j-v on 2/8/2019, 5:18 AM, changed a total of 2 times.

met vriendelijke groet
Jan

Camera : Pan X900,GoProHero5
Desktop :AsRock Z270 Pro4, W10 , i7 7700K 4.2Ghz,16 DDR4 GB RAM, Gef. GTX 1050 Ti.
Laptop  :Asus ROG GL753VD, W10 home, version1803 build 17134.407, CPU i7 7700HQ, 16 GB RAM, GeF. GTX 1050 (2 GB) + Int. HD Graphics 630(2GB)
Both Nvidia GPU's has driver version 418.81
TV      :LG 4K 55EG960V

Dutch video tutorials for beginners

OldSmoke wrote on 2/8/2019, 5:38 AM

@Marco. @OldSmoke reproed my glitches. We had a private discussion about that.

Yes, I confirmed the issue on my system. And as @klt mentioned it goes away with changing the render threads to 1, switching off GPU or set DPR to 0. It may however be entirely related to AMD GPUs.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15.

System Spec.:
Motherboard: Intel DX79SR
Ram: G.Skill 8x4GB DDR3 2133 (running at 1600 and lower latency)
CPU: 3930K @ 4.3GHz (custom water cooling system)
GPU: 1x ASUS Fury-X
Hard drives: 4x 2GB WD Red in RAID 5 (with Hot Spare), 2x Crucial 256GB SSD in RAID 0 (mulitcam project drive), 1x Samsung 850 Pro 256GB SSD (System), 1x Crucial 64GB SSD (temp files and swap file), 1x 3.5" Hotswap Bay, 1x LG BluRay Burner
PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM, 1x Sony HDTV 32" preview monitor

klt wrote on 2/8/2019, 5:55 AM

Sadly it's It's not exclusively AMD related.

These were rendered on my laptop with i5 5200u and Intel HD5500:

(DRP=0, GPU=ON)

First glitch at 0:27

(DRP=200 GPU=ON)

First glitch at 0:08

 

OldSmoke wrote on 2/8/2019, 6:01 AM

@klt I did not expect that. Can you also try and render it with setting the project to 32bit video levels only and 32bit full? I know that 32bit full will change the colors and levels and take very long but it’s just for testing to narrow it down.

Last changed by OldSmoke on 2/8/2019, 6:03 AM, changed a total of 1 times.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15.

System Spec.:
Motherboard: Intel DX79SR
Ram: G.Skill 8x4GB DDR3 2133 (running at 1600 and lower latency)
CPU: 3930K @ 4.3GHz (custom water cooling system)
GPU: 1x ASUS Fury-X
Hard drives: 4x 2GB WD Red in RAID 5 (with Hot Spare), 2x Crucial 256GB SSD in RAID 0 (mulitcam project drive), 1x Samsung 850 Pro 256GB SSD (System), 1x Crucial 64GB SSD (temp files and swap file), 1x 3.5" Hotswap Bay, 1x LG BluRay Burner
PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM, 1x Sony HDTV 32" preview monitor

AVsupport wrote on 2/8/2019, 6:42 AM

@klt if you were to disable you iGPU in Bios would these problems go away?

my current Win10/64 system (latest drivers, water cooled) :

Intel Coffee Lake i5 Hexacore (unlocked, but not overclocked) 4.0 GHz on Z370 chipset board,

16GB (2x8GB Corsair Dual Channel DDR4-2133) XMP-3000 RAM,

Intel 600series 512GB M.2 SSD system drive running Win10/64 home automatic driver updates,

4TB 7200RPM NAS HGST data drive,

Intel HD630 iGPU - currently disabled in Bios,

nVidia GTX1060 6GB, always on latest drivers

main screen 4K/50p 1ms scaled @175%, second screen 1920x1080/50p 1ms.

AVsupport wrote on 2/8/2019, 6:55 AM

I'd say DRP can definitely screw with your timeline playback performance, as outlined here https://www.vegascreativesoftware.info/us/forum/vp16-high-dpi-scaling-issues--112578/?page=2

I have suspected wrong internal buffer handling and read-ahead for quite some time.

my current Win10/64 system (latest drivers, water cooled) :

Intel Coffee Lake i5 Hexacore (unlocked, but not overclocked) 4.0 GHz on Z370 chipset board,

16GB (2x8GB Corsair Dual Channel DDR4-2133) XMP-3000 RAM,

Intel 600series 512GB M.2 SSD system drive running Win10/64 home automatic driver updates,

4TB 7200RPM NAS HGST data drive,

Intel HD630 iGPU - currently disabled in Bios,

nVidia GTX1060 6GB, always on latest drivers

main screen 4K/50p 1ms scaled @175%, second screen 1920x1080/50p 1ms.

Kinvermark wrote on 2/8/2019, 9:13 AM

These issues are ephemeral and difficult to pin down, but there have been so many reports over the years that it seems very likely to be a persistent bug.

To avoid these kinds of problems I always first render to an intermediate (usually lossless MagicYUV) and then encode h264/265 in Handbrake. IMHO this gives the best quality final result and the time penalty is not as bad as you think, because the MagicYUV render is much much faster than a h264/265 render out of Vegas (except NVENC/VCE). For me the reliability and quality are worth it.