Wow guys!! I'm like a kid with a new toy after you guys recommend Voukoder!!
Works great and the files are so much smaller!! I probably should stop playing with the many settings now...there are so many settings/options :)

Here's a couple of examples of the same piece that has the issue with the NVIDIA Encoder.

Voukoder x265 HEVC

Voukoder NVIDA HEVC

Voukoder H.264.mp4

Was just looking through the forum re frame rates and saw this post similar to mine from VP15 in 2020.

https://www.vegascreativesoftware.info/us/forum/4k-nvidia-encoder-large-png-artifacts-and-or-locked-renders--124365/

@clarkerza This problem comes up weekly with still images causing problems, also seems common for computer game captures, The user doesn't present the evidence of the problem as well as you have and the default response is to challenge/blame the user which isn't that unreasonable because the truth is so ridiculous, It's a Vegas bug that affects hardware encoding that has been present since 2017

Other problems that still exist since 2017/2018, Decoder runaway causing lagging of timeline, GPU decoding not working for certain formats that work fine on other NLE's, decoder that is powered by a single CPU core (no multithreading) for certain formats, slower Nvenc encoding due to a pause every 60frames
I tested AVC and HEVC hardware encoding using the default Vegas render template for the resolution and frame rate, result is different to your custom bitrates but still a failure. The cat should appear for 5 seconds.

I also tested a common forum reply to this problem, and that is to alter the maximum bitrate, so instead of using the render template of 24mbit average 48mbit Max, use a lower Max such as 34, this also resulted in corruption.

@clarkerza This problem comes up weekly with still images causing problems, also seems common for computer game captures, The user doesn't present the evidence of the problem as well as you have and the default response is to challenge/blame the user which isn't that unreasonable because the truth is so ridiculous, It's a Vegas bug that affects hardware encoding that has been present since 2017

Other problems that still exist since 2017/2018, Decoder runaway causing lagging of timeline, GPU decoding not working for certain formats that work fine on other NLE's, decoder that is powered by a single CPU core (no multithreading) for certain formats, slower Nvenc encoding due to a pause every 60frames
I tested AVC and HEVC hardware encoding using the default Vegas render template for the resolution and frame rate, result is different to your custom bitrates but still a failure. The cat should appear for 5 seconds.

I also tested a common forum reply to this problem, and that is to alter the maximum bitrate, so instead of using the render template of 24mbit average 48mbit Max, use a lower Max such as 34, this also resulted in corruption.

 

 

Thanks todd-b, I found it happened to me when the average bit rate goes above 20MB/s when using both AVC and HEVC NVIDIA. The NVIDIA rendering works fine with Voukoder as @Musicvid also confirms.
Using the software rendering is OK but does take 3 to 4 times as long for me which is OK, but hopefully MAGIX will fix this at some point if it's impacting so many of their customers.

The NVIDIA rendering works fine with Voukoder as @Musicvid also confirms.

This needs to be fixed, and I know your thread will be read by developers and hopefully addressed in a release coming soon.

Using the software rendering is OK but does take 3 to 4 times as long for me which is OK, but hopefully MAGIX will fix this at some point if it's impacting so many of their customers.

Unfortunately, this is not going to happen in the foreseeable future. It is in the laws of physical math, not something that can be programmed away. (Note: x264 and x265 software encoders in Voukoder are a little faster than Mainconcept bc they can use CRF encoding, instead of ABR.)

• Long-GOP Interframe software (CPU) compression takes much longer, and produces much better quality at similar file sizes. Fast is only good when making crêpes or playing video games. Translation: It's better.
• Hardware (iGPU) encoding is much faster, and currently requires much larger file sizes (bitrate) for "barely" comparable quality. Translation: It's faster.
• The future of iGPU hardware encoding does leave room for several advances, yet my crystal ball tells me we will probably not get to Quality / Size Parity with software GPU encoding during our lifetimes; the state of the art simply does not support it. Yet it will always be faster.

I have alluded to these relationships several times during the course of this thread; here is a 20 year old meme that is equally true today; smart video hobbyists will refer to it often:

"SIZE, QUALITY, SPEED. PICK TWO."

Internet soothsayers, pundits, and alchemists will always tell you differently, and support their confabulations with fake and flawed evidence. Only your own informed testing, reasoning and math skills will lead you to the answers that work best for you. Mathematical quality benchmarks for video include MSE / RMSR, PSNR, SSIM (best overall), and VMAF.

Keep in mind that your visual impressions are not a stable reference, but a moving target that is easily fooled by the environment (the observer effect), biochemistry, and personal expectations (the pygmalion effect). Here's an example of perceptual drift that always gives an untrue impression;

https://www.vegascreativesoftware.info/us/forum/color-fatigue-demo--118176/

Welcome to the learning curve. I've contributed all I can to this discussion -- get out there and make some really good mistakes -- my Winter Holidays began a few hours ago!

@clarkerza

Sorry when I said:
Using the software rendering is OK but does take 3 to 4 times as long for me which is OK, but hopefully MAGIX will fix this at some point if it's impacting so many of their customers.
I meant fix the other issue not the longer rending time.

Totally agree with what you said though ""SIZE, QUALITY, SPEED. PICK TWO.""
It's similar to the project life cycle triangle (Time, Cost, Quality) - you change one - you impact the other two.
With the main job working in the mobile industry, I am fine with SIP mobile codecs (g711, g722, AMR-NB, AMR-WB etc) but these video codecs are are a dark art to me. I definitely need to better understand them.

Thanks all.

Now I understand your comment, which was actually two. Still, the truth about fast-'n-dirty hardware compressors needs to be repeated from time to time. Hardware fanatics and gamers are being fed a can of beans by chip manufacturers, and they (consumers) don't have the critical thinking skills to see through the hype.

Video codecs in general have a troubled and chaotic past, and are constantly being reimagined for best fit with new delivery standards, which themselves are usually incompatible with older models and are heavily monetized and politicized. Production conflicts are the norm, not the exception.

I only have the evolution of these beasts stuck in my head because I lived it -- from when we had only two uncompressed formats and were first beginning to explore interframe compression (MPEG-1).

Thank you for an intelligent, patient discussion and welcome to the forums. People whose minds who are not disfigured by Google and social media are a rarity around here, especially this time of year!

@clarkerza said "I am fine with SIP mobile codecs (g711..."

Wikipedia said, "G.711 passes audio signals in the range of 300–3400 Hz and samples them at the rate of 8,000 samples per second"

The ancient technical critic said: "Do you have to bang the microphone on the table to loosen the carbon so the other party can hear you?"