. Anyone who has worked with Vegas Pro 13 and before will know exactly what I mean, when I say that MP4/AVC rendering quality is unacceptable.

I don't know "exactly" what you mean.   Perhaps you could point us to your previous discussions of this? 

Anyway, AFAIK the mp4 rendering engine choices are the same - mainconcept or sonyavc.  (Unless you use framserve to handbrake... which looks like you prefer to avoid.)

I think while I'm no pro, I never had in VPro 12 and/or 13 unacceptable rendering of MP4 AVC.
BTW. Which of the 2 codecs gave you this onacceptable result or maybe both?
For VPro 14 you can see it yourself using the trial for 30 days.

The problem exists with both the Sony or the Mainconcept codec, and affects 13 and earlier. Sony is a bit better, but still yields soft video with incorrect gamma. There are many posts online about this, and this is why there are solutions to send out the render to handbrake. Try rendering a short video to AVI uncompressed, and then convert it to MP4 in Handbrake. If you don't see the difference, I suppose it is not an issue for you.

That said, the suggestion to just download and try the 14 trial version probably makes the most sense, and I will do it.

Thanks

. Anyone who has worked with Vegas Pro 13 and before will know exactly what I mean, when I say that MP4/AVC rendering quality is unacceptable.

 

I don't know "exactly" what you mean.   Perhaps you could point us to your previous discussions of this? 

Anyway, AFAIK the mp4 rendering engine choices are the same - mainconcept or sonyavc.  (Unless you use framserve to handbrake... which looks like you prefer to avoid.)

 

 

Frameserving to Handbrake would be unnecessary if this issue was solved. This is precisely why people do this.

I am interested in this topic; and also have no wish to frameserve to handbrake.    Sure would be easier to discuss if you could post a link to one of the earlier "online posts" you are referring to.  I tried a couple searches, but didn't find them.

The problem exists with both the Sony or the Mainconcept codec, and affects 13 and earlier. Sony is a bit better, but still yields soft video with incorrect gamma. There are many posts online about this...

I've never heard of incorrect gamma from either the Sony or MainConcept AVC encoders. You have any links about that?

This post should help you get the most out of these encoders, or external encoders: https://www.vegascreativesoftware.info/us/forum/faq-how-can-i-improve-the-quality-of-my-avc-h-264-renders--104642/

Most players will expand levels, which can look like gamma issues. This is an editors error in not having the levels correct passing through the workflow, and not the software.

As far as the softness goes, are you sure you have your profiles set right for your needs? Are you do a 1:1 project to render format? Any scaling will alter the look a little. Best Full rendering uses the best scaler, while Handbrake uses an even better one/more modern.

Most players will expand levels, which can look like gamma issues. This is an editors error in not having the levels correct passing through the workflow, and not the software.

Ah, that's probably what JoeAustin meant. Well, if your camera shoots whites above 235 and/or blacks below 16, Vegas won't automatically correct that for you. Personally I'm glad it doesn't, but certainly Vegas could do more to stop us messing up, such as offering different preview levels options, and an option to automatically adjust levels, or simply some warning prompts/instructions.

Most players will expand levels, which can look like gamma issues. This is an editors error in not having the levels correct passing through the workflow, and not the software.

Ah, that's probably what JoeAustin meant. Well, if your camera shoots whites above 235 and/or blacks below 16, Vegas won't automatically correct that for you. Personally I'm glad it doesn't, but certainly Vegas could do more to stop us messing up, such as offering different preview levels options, and an option to automatically adjust levels, or simply some warning prompts/instructions.

Nope. Not the case. I am very familiar with broadcast safe colors. As a matter of fact, there is no better way to illustrate the gamma issue than with a SMPTE test pattern. Best viewed on a calibrated monitor. You should know to interpret the PLUGE ideally, but the difference is pretty obvious. The following three files are a still image, a rendered MP4 using the Sony AVC coded from Vegas, and finally a H.264 render from Davinci Resolve.

https://app.box.com/s/texjz324yka3svedfgaqu9r4iq04r9ki

Well, if you had provided some details we wouldn't have to guess   😀

AFAIK, Davinci Resolve's mp4 encoder is also mainconcept, and there is plenty of complaining over on the BMD forum about it.  Here's a link to one thread "RE:poor encoding quality in DaVinci":

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=56789&start=50&sid=66553003b2a05e162a33155367fc89a7#p326367

You have made some pretty strong claims, but not backed them up with fact, or enough detail to be verified.  Until you do, I don't think your claim should be taken seriously.

Well, if you had provided some details we wouldn't have to guess   😀

AFAIK, Davinci Resolve's mp4 encoder is also mainconcept, and there is plenty of complaining over on the BMD forum about it.  Here's a link to one thread "RE:poor encoding quality in DaVinci":

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=56789&start=50&sid=66553003b2a05e162a33155367fc89a7#p326367

You have made some pretty strong claims, but not backed them up with fact, or enough detail to be verified.  Until you do, I don't think your claim should be taken seriously.

 

 

 

Ummm.... I think you missed the previous post with examples. As to what issues Resolve also suffer, it does render gamma correctly.

No, I saw your examples.  But providing "test results" without ANY explanation of your methodology is not useful - nobody can replicate your results, nobody can analyse your methodology, and nobody can offer a solution.  Is that what you want?  No solution.

Sir, one must manually set levels in Vegas to conform the color space. It is not automatic, Vegas does not scan your source, does not read VUI flags, does not engage in guesswork, and does not correct rgb stills, such as your smpte bars to REC 601/709.

It's always been this way, and it's a design choice, not a bug.

In this case one would apply a Studio RGB filter on the output to render mp4 from your still. If you would like this done for you, it should come in the form of a feature request to Magix.

Nope. Not the case. I am very familiar with broadcast safe colors. As a matter of fact, there is no better way to illustrate the gamma issue than with a SMPTE test pattern. Best viewed on a calibrated monitor. You should know to interpret the PLUGE ideally, but the difference is pretty obvious. The following three files are a still image, a rendered MP4 using the Sony AVC coded from Vegas, and finally a H.264 render from Davinci Resolve.

In the Vegas preview window on my system the luminance and gamma of the Sony AVC render match the still image, while the Resolve render decodes to a narrower luminance range but with the same gamma (give or take the small discrepancies that are to be expected after rendering). As to which is correct, that depends on the luminance characteristics of the source footage and what you want to do with the rendered file. If your source footage is nominally RGB 0 to 255 then it looks like Resolve is saving you the trouble of "squashing" the luminance range for web/TV distribution. I have no idea how "intelligent" Resolve is with levels but if it always does that by default, and your camera shoots 16-235, then you'll end up with insufficient contrast in most playback scenarios unless you adjust it before rendering.

By gamma, I effectively mean linearity. To see a demonstration of gamma adjustment in Vegas, put a 16-235 color gradient on the timeline, add a Color Corrector FX to it, and watch the video scopes while adjusting the Gamma slider.

I couldn't resist.

Thanks John. That's the same behaviour that I see.

That's two in a row.

Three, at least. :D

Facts just get in the way of perceptions. Shame on you guys.

Thanks for doing that John.   

So it looks like when comparing various renders to the original test pattern jpeg, you only see a difference on the smpte pattern (pluge) showing the Davinci Resolve render - all the others (including mainconcept)  are unchanged (correct).   There does appear to be some minor difference on the vectorscope on all except the uncompressed.  Why would that be?

Resolve has default settings, but not automatic. If you look at your preferences when setting up a project and when rendering, you will see settings for color space.

There does appear to be some minor difference on the vectorscope on all except the uncompressed.  Why would that be?

We call that "lossy compression."

The smaller dots that move the most on the vectorscope are the transitions (borders) between the colour blocks. Those aren't clean transitions in the original test pattern JPEG, and the lossy compression changes them significantly.