Thank you !

The source is 10bit 4:2:2 so I suppose it's because of the Magix AVC MP4 render which is locked at 8bit.

Is there another option to render and maintain the 10bit while being compatible for all TVs ? (I'm a wedding videographer and don't want my customers to return unplayable formats).

Magix AVC MP4 is always compatible and very good quality but does not support 10bit :(

I think there is some confusion here. You don't need the final output file to be in greater than 8 bit depth precision to benefit from doing internal calculations in 32-bits. For example if your source file is 10-bit log, you do significant corrections to gamma and color in Vegas you would want those corrections to be done at 32-bit precision to avoid banding. You can then output a normal 8-bit 4:2:0 AVC file using MagixAVC.

@Marco.  ... Keeping in mind that I don't use 32 bit float, I recall on the forum lots of years ago that using 32 bit as the project setting could cause problems with some transitions. At the time, I trialed 32 bit on VP's timeline and indeed some transitions, even native Vegas Pro transitions, introduced weird color artifacts that didn't occur in 8 bit. At the time, the recommendation was not to use 32 bit in Vegas Pro unless the original media was 32 bit. With transitions, is that still the case or have all Vegas Pro transitions been tuned over the years to now work well with 32 bit media regardless of the original media's bit rate? Sorry if this is a dumb question - I'm just curious.

The question isn't dumb at all but I can't answer it because meanwhile I rarely use float point projects (and same is for transitions).

There has been some controversy here on the board regarding whether or not using 32 bit mode with 8 bit source video yields any visible benefit. What seems uncontroversial is that 32 bit renders take a lot longer, and trying to edit in 32 bit mode puts a lot more strain on the system. I find that "pushing" hard on 8-bit files, with combinations of curves, saturation increases, and color correction does produce visible artifacts like banding which appear smoother when rendered out in 32 bit mode. Experiment for yourself to see what works for your workflow, and beware the dogma! :)

being compatible for all TVs ? 

You will edit and render at the DELIVERY bit depth and format, not the source.

In this case, the LCF for delivery is 8 bit 4:2:0. End of .speculation.

With transitions, is that still the case or have all Vegas Pro transitions been tuned over the years to now work well with 32 bit media regardless of the original media's bit rate? Sorry if this is a dumb question - I'm just curious.

Ooh, sounds like there's a test hiding in there.

Biggest thing for transitions is, and always has been maintaining adequate bitrate. With the old Mainconcept encoders, we had some leverage over this. That's why I generally use x264 /x265 and set vbv-bufsize and vbv-maxrate to effect a sustainable minimum bitrate. With other delivery encoders, it is difficult to do so

There has been some controversy here on the board regarding whether or not using 32 bit mode with 8 bit source video yields any visible benefit. What seems uncontroversial is that 32 bit renders take a lot longer, and trying to edit in 32 bit mode puts a lot more strain on the system. I find that "pushing" hard on 8-bit files, with combinations of curves, saturation increases, and color correction does produce visible artifacts like banding which appear smoother when rendered out in 32 bit mode. Experiment for yourself to see what works for your workflow, and beware the dogma! :)

The source video includes 10bit 4:2:2 HVEC mp4 here.

FWIW, I just did a few tests of S-log2 and S-log 3 on an 8-bit only camera with LUTs and other corrections and did find more banding in a sky in 8-bit mode than 32-bit video. (renders were with x264 via Voukoder). S-log 2 was just about acceptable and S-log 3 not at all. I hope the day comes when all calculations are done at high internal bit depth in Vegas Pro.

IDK, man, shooting log in 8bit doesn't make any sense to me.

IDK, man, shooting log in 8bit doesn't make any sense to me.

I generally agree, though Slog2 and XAVCS came out better than expected (usable). I was running technical tests and plan to continue using Cine 2 for actual projects.

There just isn't much noticeable difference between doing 8-bit integer math and 32-bit floating point. In audio, the difference doesn't become clearly perceptible until internal storage and calculations are done 64-bit with double precision math. It's most noticeable with multitrack audio because the more tracks there are, the more truncation error propagates into audible content which muddies everything up. Not sure that would necessarily apply to video which doesn't mux together camera tracks quite as much as audio blends sound tracks. Perhaps applies to Vegas which pipelines all of its fx in series. Parallel FX might be a less computationally intensive way to deal with that, however.

I generally agree, though Slog2 and XAVCS came out better than expected (usable). I was running technical tests and plan to continue using Cine 2 for actual projects.

Been playing with HLG and Z-Cam's implementation of WDR with combines it's zlog2 limited range capture with wider dynamic range. Problem with HLG is that Vegas goes into 32-bit floating point full mode with ACEes as soon as it's enabled which slows everything down. Makes working in the Color Grading panel a bear. Shut off ACEes and Vegas drops out of HLG. The WDR footage however allows 8-bit limited legacy editing with a zlog2 lut which is quite brisk. The shadow detail I'm getting exceeds that of both regular zlog2 and rec709 linear with minimal increase in shadow noise. And I can throw the project into 32-bit limited mode without color shifts right before rendering. Gotta play with it some more in low light where I've always gotten better results with linear.

IDK, man, shooting log in 8bit doesn't make any sense to me.

I generally agree, though Slog2 and XAVCS came out better than expected (usable). I was running technical tests and plan to continue using Cine 2 for actual projects.

Hm...how do they take heavy color grading? I'm skeptical.

There just isn't much noticeable difference between doing 8-bit integer math and 32-bit floating point. In audio, the difference doesn't become clearly perceptible until internal storage and calculations are done 64-bit with double precision math. It's most noticeable with multitrack audio because the more tracks there are, the more truncation error propagates into audible content which muddies everything up. Not sure that would necessarily apply to video which doesn't mux together camera tracks quite as much as audio blends sound tracks. Perhaps applies to Vegas which pipelines all of its fx in series. Parallel FX might be a less computationally intensive way to deal with that, however.

Dithering kills truncation errors, that's what dithering is for.

Dithering kills truncation errors, that's what dithering is for.

That's a related but different issue designed to cover-up and soften the noise shaping of the quietest passages in a final 16-bit mix. Quantization error also creeps into content and increases with every added track. Even if recorded 24-bit. And there's no way to cover that up with pleasant dithering noise without making things worse.

Dithering kills truncation errors, that's what dithering is for.

That's a related but different issue designed to cover-up and soften the noise shaping of the quietest passages in a final 16-bit mix. Quantization error also creeps into content and increases with every added track. Even if recorded 24-bit. And there's no way to cover that up with pleasant dithering noise without making things worse.

Excuse me, what? Adding more track (summing) only makes you go above zero - clipping. So you turn your mix down by the amount being clipped (if you don't like the sound of clipped audio). Quantization errors at 24 bit happen 144 dB below zero, so what quantization errors are you talking about exactly? Inaudible ones?

IDK, man, shooting log in 8bit doesn't make any sense to me.

I'd like to understand this. I shoot video on a Google Pixel 5 running Filmic Pro with vlog2, and when I import it into VEGAS Pro, I render intermediate files of the regions I want to use... those intermediates are in MagicYUV CODEC with a LUT applied that translates from vlog2 to Rec.709.
I am under the impression that this gives the captured video a bit more room to avoid underexposure and overexposure, within the limits of the little sensor in the Pixel 5. Am I mislead about any benefit to using such an option?

IDK, man, shooting log in 8bit doesn't make any sense to me.

I generally agree, though Slog2 and XAVCS came out better than expected (usable). I was running technical tests and plan to continue using Cine 2 for actual projects.

Hm...how do they take heavy color grading? I'm skeptical.

As far as I'm concerned, all grading of log files is heavy grading- the transformation of gamma and color is significant enough to expose weakness in 8-bit codecs. However, if the scene doesn't have much in the way of continuous tones (detailed subject and even motion) its limitations may not be visible to most users.

Some (like Johnny Behiri and Alister Chapman) found Sony 8-bit X-AVC S and S-log 2 to be usable. Personally I'd prefer tonal precision to extended dynamic range, and choose a different profile for my work.

Feel free to run your own tests as I did so as not to rely upon the opinions and value judgments of others.

IDK, man, shooting log in 8bit doesn't make any sense to me.

I'd like to understand this. I shoot video on a Google Pixel 5 running Filmic Pro with vlog2, and when I import it into VEGAS Pro, I render intermediate files of the regions I want to use... those intermediates are in MagicYUV CODEC with a LUT applied that translates from vlog2 to Rec.709.
I am under the impression that this gives the captured video a bit more room to avoid underexposure and overexposure, within the limits of the little sensor in the Pixel 5. Am I mislead about any benefit to using such an option?

Well, shooting log brings you more captured stops, yes, but at the expense of loosing contrast - gamma is all wrong. And not only gamma. Wrong for sRGB or 709 monitor you're using to view the footage, that is (and if you're fine with flat looking, washed out, image more power to you!). So you have to correct for it using transforms or LUTs, then you'll have to grade it, move the colors back and forth, and by doing so, and having shot using only 8 bit, you inevitably are going to induce banding which wouldn't have happened had you shot to 10 bit or more. Or shot "regular", "normal", "standard" etc. to 8 bit.

Simply put, in my opinion, 8 bit lacks precision (code values, there's only 256 of them) needed for post work when shooting log.

IDK, man, shooting log in 8bit doesn't make any sense to me.

I generally agree, though Slog2 and XAVCS came out better than expected (usable). I was running technical tests and plan to continue using Cine 2 for actual projects.

Hm...how do they take heavy color grading? I'm skeptical.

As far as I'm concerned, all grading of log files is heavy grading- the transformation of gamma and color is significant enough to expose weakness in 8-bit codecs. However, if the scene doesn't have much in the way of continuous tones (detailed subject and even motion) its limitations may not be visible to most users.

Some (like Johnny Behiri and Alister Chapman) found Sony 8-bit X-AVC S and S-log 2 to be usable. Personally I'd prefer tonal precision to extended dynamic range, and choose a different profile for my work.

Feel free to run your own tests as I did so as not to rely upon the opinions and value judgments of others.

Thank you, RogerS! :)

It's a tradeoff, everything is a tradeoff. If you are a Sony shooter, unless you have an a7SIII, 10-bit is not an option. If you're shooting S-log 2 side by side with older cameras perhaps the benefit of consistency outweights the risk of banding, or the dynamic range increase improves the scene more than artifacts in sky detract from it.

Here's a simple edit of S-log 2 shot on a 1" sensor camera (RX 100IV).

I'm not sure how well it will show up here, but a sky example in S-log 2 (some banding/posterization in the clouds)

Somewhat ameliorated in 32-bit mode:

In a few seconds-long clip nobody is going to notice artifacts like this. There are award-winning documentaries (Vivian Maier; Gasland) with heavy DSLR artifacts like aliasing from line skipping, but it didn't keep them from international recognition, so it's worth keeping technical shortcomings in perspective.

Contrast that with S-log 3 (shown in 8-bit mode for emphasis) from my a6600 where there is a dancing line of posterized noise in the sky with cyan and purple mixed in with the blue after just applying a correction LUT and light s-curve. That's just not going to look great on a big screen and may be noticeable to an ordinary viewer as it looks unnatural.

Thank you for that analysis and information, @adis-a3097
I am an engineer by background, so I understand trade-offs. I will try some tests with the same scene using the various color curves available in FilmicPro. (Native, Natural, Dynamic, Flat, Log). The "Flat" option also has a LUT for translating to Rec.709, so I assume it will have the same potential for banding that you mentioned I should look for with Log.
Getting colors "right" or pleasing to my eyes has been one of the most challenging aspects of the short projects I have made (in part because they're 48 Hour Film Projects, and I don't have time to tweak things repeatedly). I've learned alot about how motion looks better and worse with certain settings, and how to accommodate the limitations of the equipment and framerate, but I'm still struggling with color. One of my short movies I made Black-and-White, and when people asked about that "artistic choice," I confessed, it wasn't artistic; I simply couldn't get the colors suitable-to-present, so I desaturated to B&W.

I'd run some tests and see if there is visible banding or other artifacts, such as on skin or sky gradients. If you're not sure what you are seeing feel free to upload a clip post LUT. The Iphone has some 10-bit options, not sure about the 5.

. Quantization error also creeps into content and increases with every added track.

Excuse me, what?

Yes, that's exactly right. The only audio work-arounds are increasing digital word size or summing in the analog domain. But summing in the analog domain isn't an option for video. I'm just not sure there is an actual issue in video if data sizes are sufficient large already. Being that the digital solution works by pushing the creeping error components further away from content. If present data element sizes in video already do that, then it''s a solution in search of a problem. It needs to be demonstrated to be a problem in video as has been done in audio. The acid test being trying a larger data-element size and seeing an improvement.