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.

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

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.

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

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.

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

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.

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! :)

@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?

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.

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

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?

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.

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

@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.

@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.

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. 😷

@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.

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

@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.

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

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.