unusually blocky / noisy, low quality renders with V15

Mindmatter wrote on 8/3/2018, 12:10 PM

Hi all,

i'm running into some trouble here...I'm working on a kids' project with lots of stop motion and compositing, and for a reason I don't understand, the renders are really bad. I did a very similar project last year on V13 and all was really clean and without issues. I tried GPU on and off, Sony and Magix AVC 16mb/s, 8 and 32 bit. Please have a look at the artifacts in the sky here, and the general amount of noise, this one is a Magix AVC 32 bit render at average 16mb/s:

The other thing is that when I render 8 bit, the compositing goes completely haywire and elements are all over the place, flickering, disappearing etc..like so:( this version is still pretty harmless )

I'm quite clueless here, it's the first time I feel the rendered files are so bad I can't deliver them.16mb/s should be a large enough bitrate to avoid such artifacts. I'm a bit worried to be honest, as I cannot seem to find the reason as to why things look so crappy. I might try and copy the project to v13, but seriously, I shouldn't have to do that.

Any help is greatly appreciated!

Comments

Kinvermark wrote on 8/3/2018, 1:36 PM

As a quick fix to get you working, you could try rendering out to a lossless intermediate and then encode in Handbrake (it's really good at lower bitrates.)

I would use Magic YUV as the intermediate, but XAVC-intra should work too.

Deva-Bida wrote on 8/3/2018, 9:16 PM

Nice concept, BTW.

Mindmatter wrote on 8/4/2018, 2:01 AM

thanks for your help Kinermark, and thanks Deva-Bida.

I did a couple of hours of troubleshooting and could eliminate at least some of the issues.

* some of the clips weren't quantized to frames, which Vegas really doesn't forgive when it comes to compositing. The scene in the room is now less chaotic, but still messes up when rendered in 8 bit ( which I usually don't btw, but just makes me wonder why )

* the source footage is 8 bit 4.2.0 Sony XAVC-S from my A7S , which I usually rerender to XAVC-I in Calalyst Browse prior to editing to make it easier on the timeline . But I had also prerendered some of the stop motion sequences to MXF, but had chosen a 4.2.2 profile by mistake, and It seems that rerendereing those 422 prerenders in an 8 bit 4.2.0 context really created some ugly artifacts, as when I rendered directly from the photo sequences, mixed with some generated media like the sky and the gradients, it turns ot clean.

The one thing I noticed several times with Veas ( even posted some examples here in the past) is that fades from white to black generated media or vice versa can be really ugly , stuttering and banding, even in 32 bit. It really leaves me clueless each time I see that, considering it's such a simple action, and Vegas' qualities.

BTW Kinvermark, do you consider 16mb/s a low bitrate? I usually dliver 16 when I know it's going to websites, YT etc, and it usually looks good. Would you deliver at higher bitrates?

Thanks!

Kinvermark wrote on 8/4/2018, 9:37 AM

BTW Kinvermark, do you consider 16mb/s a low bitrate? I usually dliver 16 when I know it's going to websites, YT etc, and it usually looks good. Would you deliver at higher bitrates?

Not particularly. Let's call it "medium." I have found that Handbrake does seem to produce less artifacts than other h264 encoders, but that it is more noticeable the lower you go. Maybe something to try when you have some spare time.

Seems like you have a complex workflow with transcodes that can introduce artifacts. Can you simplify? The best quality will always be source to final render without detours. Catalyst browse installed an OpenCL emulation driver on my computer (gives a message during install) that totally messed up my GPU - so I cannot recommend that software.

My experience has been that 32 bit mode is MORE likely to introduce strange errors. The fades are, of course, presented in 8 bit web quality (not so good), and I have not seen any improvement with 32 bit either.

Mindmatter wrote on 8/4/2018, 11:48 AM

Indeed, for some reason, Vegas' fades can be sou ugly that I avoid them alltogether. I wonder if other NLEs have the same problem with a simple fade?? Same with credit rolls that stutter like it's windows 95. I just don't get it that a compositing NLE that can do the things Vegas does cannot handle a simple fade.

I'll give the whole thing a go with the original XAVCS files and see what that does to the renders. I did. a 1:1 comparison and as far as the image quality goes, I couldn't detect any difference between the original XAVCs and the XAVCI renders from Catalyst. As you mentioned, I'll stick to the unrendered stop motion sequences also. I also have a feeling that generally, on my Windows 10 partition, things with Vegas are less problematic. I'll work the project on Win10 next week and see what happens, and keep posting what I see.

fifonik wrote on 8/4/2018, 7:11 PM

I'd say 16 mbps is a bit too low for MagixAVC encoder in general for encoding 1080-50p. My tests using MSU Quality Measurement Tool shows a lot of blocking artifacts even on higher bitrates for the encoder (SonyAVC produces less blocking artifacts but more blurry). Sure it depend on scenes and for your cartoonish scenes might be OK.

I agree with Kinvermark that intermediate encodings should be avoided at all cost.

Mindmatter wrote on 8/5/2018, 2:43 AM

Thaks for that link and your extensive work on this fifonik. I haven't gone through your download files yet, but I will. The whole thing does leave me worried though. What is the solution then? Why is there no cleaner codec for us to render to? Do other NLEs have the same problem?

I mostly don't wok in this kind of material and style, and have met blocking arifacts before, on more real life footage like interviews in picture areas that didn't make any sense, like a small green surface behind the talking head that suddenly showed a large amout of banding and blocking.

I always record everything on my Atomon Shogun Flame simultanously to the cam as a backup in DNxHD220. I wonder if using that as source material might help. I'll give that a try.

So what are you using after all your conlusions?

fifonik wrote on 8/5/2018, 7:25 AM

> What is the solution then?

I'm using x264 through frameserver.

> Do other NLEs have the same problem?

I do not know. Video editing is my hobby. It's a bit expensive to have more than one 'pro' solution. I've chosen Vegas long time ago and still like its UI. So was using Mainconcept AVC encoder until it got broken in VP12 (it was better in VP11, not as good as x264 though) and then switched to x264 (encoding workflow is more complicated with x264). Reported the issue to Sony. Then to Magix. Rest is up to them.

> I always record everything on my Atomon Shogun Flame simultanously to the cam as a backup in DNxHD220. I wonder if using that as source material might help

I do not think so. For me it looks like the encoder issue.

Anyway, I have never seen such blocking issues with Sony AVC. Unfortunately, it is more blurry and maximum bitrate is not enough for my taste.

OldSmoke wrote on 8/5/2018, 8:57 AM

If you have a good internet connection you can upload XAVC-S files.

Kinvermark wrote on 8/5/2018, 1:25 PM

I did a very similar project last year on V13 and all was really clean and without issues

@Mindmatter

Can you not just use the same workflow in Vegas 15 as you did successfully in Vegas 13?

Mindmatter wrote on 8/6/2018, 3:23 AM

Kinvermark, the last project I was referring to actually had DNxHD files only and was less long, it also had a couple less complex compositing instances and no luma keying. There's a scene here with 39 composited tracks with kids and their paper double :

Butalso on the last project, there were, although different, issues with compositing messes related to GPU on while rendering., but not the blocky quality issues.

So far, I changed all the clips back to the orighinal XAVC-S files, deleted all the intermediates, and I've managed to get my first clean render with this one, but not without complications:

3 render crashes with GPU on, twice at 85%, one at 97%. Reason unknown, I insisted having GPU on as without it, the renders take 2,5 hours.Gave up on it in the end, and with GPU off the renders didn't crash.

32bit did cure the compositing scene ( with GPU off and quantized to frames ) but introduced other problems ( as you mentioned above ):

Suddenly, some masks became visible by seeming not to be 100% transparent anymore. The cure was some FX order voodoo. As some scenes required specific FX and tweaking to clean up the luminosity key, I had to use a chain of color curves --> Colorfast2--> luma key-->color fixer pro after the key to bring back some brightness and saturation I had to reduce to clean the lumy key. Now, puttting pan/crop at the very end of that chain cured some issues, but not always...I had to try out different order combinations each time until the scenes were finally clean. It seemed totally arbitrary. At other times, text on a white square png onto a white generated media suddenly showed a weird fringed white border in 32 bit. The weird solution...changing the png to a different track. Go figure. The FX pancrop order also strongly affects the quality of the luma key. Pancrop at the end strangeley results ain a cleaner key. then again, the render shows things I cannot see on the timeline:

1=timeline snapshot, 2= render snapshot. see the mask around the 2nd kid's head and the line of the large mask above, only visible in the render. That's why i don't even know how to fix this one except try and render a few seconds...

Having said that, putting colorfast 2 after pancrop usually messes up the scene as it affects the whole image instead of just the cropped section. Putting it BEFORE pancrop is the solution ( thanks again Marco for the tip).

Last but not least, unfortunately i had used NB titler pro in the project, and og course it showed an " enter text" disappearing title in the successful render, but that's another story.