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

Back to post

Comments

AVsupport wrote on 2/11/2019, 6:26 PM

@Kinvermark , what's your workflow for the initial render to intermediate, is there a bulk conversion you do for all clips first, a script or 3rd party software?

Kinvermark wrote on 2/11/2019, 6:44 PM

@AVsupport

The workflow I mentioned earlier in this post is simply for render. So, original camera clips would be used on the timeline (i.e. not transcoded.) The finished project timeline would be rendered to MagicYUV (lossless), then that file taken into Handbrake for a high quality h264 encode. In my experience this avoids certain "glitches" like compositing errors that can occur during h264 renders straight out of Vegas.

I do also work with proxies or intermediates of source clips depending on the project, and these are produced either in Davinci Resolve (if I am doing a lot of colour work on the project) or by Vegas using Vegasaur's batch transcode facilities. Cineform "filmscan 2" from Resolve; Magic YUV lossless from Vegas-vegasaur batch.

AVsupport wrote on 2/12/2019, 12:19 AM

Understood! Thanks for the insight @Kinvermark ; I think i was hoping for a secret ‘intermediate as proxie’ replace method that would alleviate timeline playback issues. Its such a shame VP still can’t do bulk transcode from inside VP

klt wrote on 2/12/2019, 12:49 AM

@OldSmoke I tried to render a "problem" project set it to 32bit. It was glitchy. Then also tried the same, but now to MagicYUV, as @Kinvermark suggested. This is how it went (fast forward in the middle to make it shorter):

Around 85% the glithes can be seen during render time. The rendered avi contains additional glitches that were not visible during render time (as when rendering, Vegas displays only every 5th rendered frame or so).

However, If I set rendering thread number to 1, the render is perfect, whatever template I choose.

Kinvermark wrote on 2/12/2019, 9:24 AM

Sorry to see my "trick" didn't help. Same problems if you render at only 8 bit? Your theory that multi-threading falls apart at higher levels of complexity seems valid. There have certainly been reports of compositing errors in the past.

Maybe one of the moderators can help get your project into the hands of the developers.

klt wrote on 2/12/2019, 10:04 AM

Sorry to see my "trick" didn't help.

No problem. 😉

Same problems if you render at only 8 bit?

Yes, in fact I never use 32bit. I did this time only because @OldSmoke suggested to try it.

I would love to give that to developers to debug. Once I uploaded a whole project to Magix which had the same problem. (Actually uploaded to my own storage and waited until Kimberly downloads)

But I'm ready to participate in any form if that can make Vegas better. Just like you, I want a perfect Vegas! 😉

fr0sty wrote on 2/13/2019, 12:15 PM

kinvermark, why don't you frame serve to handbrake? Or maybe using Happy Otter's Render+ will speed up your workflow, eliminating the need for that intermediate.

Kinvermark wrote on 2/13/2019, 12:48 PM

No particular reason. :)

I do try to keep things as simple as possible, so reducing the number of pieces of software I need to install and keep updated, etc. Don't always have a choice of course.

I have not yet had the time to investigate Waag's HOS, but it is on my radar to do so when time allows.

I don't see a quality loss using the extra step, and render time is not a big deal for me, as I think it represents a tiny amount of "machine" time compared to the vast & costly amount of "human" editing time.