AMD has similar limitations. Why is a great question for them.

The real question in my mind is why Intel added 4:2:2 hardware decoding at a time when all currently made camera sensors only capture 4:2:0. Those cameras that write 4:2:2 formats to media fill in the missing pixels with interpolated data that can just as well be computed in post before edit or by the display monitor after edit. My 4k cameras (Canon xf605 and Z-Cam E2) can do either format. So can the Z-Cam Zraw format converter. And objective quality analysis shows no advantage to inflating the media before edit.

Fwiw, I still use a 13-year old Canon xf305 which sports a 3-CCD sensor array that writes honest-to-goodness 4:2:2. But strictly HD. The real deal is glorious enough to stand up next to 4k clips in multicam projects if you don't look too closely.

Why does NVIDIA support

10-bit 4:4:4

12-bit 4:2:0

12-bit 4:4:4

but not 10-bit 4:2:2? Are those more common capture formats?

It's more that Intel is just decoding every potential HEVC variant rather than guessing which formats will become popular and it's winning at that. (I bought an Intel CPU for this reason).

I don't think the 4:4:4 decoding support is for cameras... they probably have screen capture for gamers in mind. The newer gpus from Amd and Nvidia can put up 12-bit video if the monitor is capable. Also hdmi recorders can upscale across the cable for their displays. But it seems to me that capturing that is more appropriate for gaming/generated media than camera footage unless cameras advance. Maybe they're anticipating a lithography breakthrough for camera sensors that can shrink a 4:4:4 pixel matrix without requiring medium-format or larger lenses for coverage.

4:4:4 refers to YUV compression, camera sensors capture RGB, which is then converted to YUV during the encoding process. The typical camera sensor has 2x the green pixels than it does red or blue (1 red, 1 blue, 2 green) per 4 sub-pixel block (bayer pattern). If you wanted to have equal pixels of all colors, you'd probably want to use more sensors (like the old 3CCD cameras) and color filters rather than smaller pixels, which affects the focal range and how much light each pixel can capture per exposure.

@Kloverton I tried your clip and it's 4:2:2 hevc. Only Intel uhd750 or later igpus or Arcs can decode that in hardware. Doing a test render in Vegas took almost an hour on my 11900k system with the Vegas decoder set to the Amd 6900xt gpu (and legacy hevc unchecked). This setup fails over to the cpu for decoding that format. However, transcoding your clip to 4:2:0 hevc with ffmpeg knocked the test render down to around 7-1/2 minutes with Amd actually decoding. Your system, which has no igpu but has more cores, would probably be better suited for video formats like hevc 4:2:0. Or ProRes which benefits more from cpu and disk resources than gpus.

I used all the builds and on a latest right now, 411. I do PC building as a second job, and i tried those 8K files on 13900ks ... Same thing

My 11900k with decoding set to it's uhd750 chomped through your 4:2:2 clip in about 8-1/2 minutes. If you got poorer performance with a 13900ks, something's wrong. You might want to check that your Intel graphics drivers are current and that Vegas is set to use the uhd770 igpu for decoding.

AFAIK, 13900ks has no iGPU.

AMD has similar limitations. Why is a great question for them.

The real question in my mind is why Intel added 4:2:2 hardware decoding at a time when all currently made camera sensors only capture 4:2:0. Those cameras that write 4:2:2 formats to media fill in the missing pixels with interpolated data that can just as well be computed in post before edit or by the display monitor after edit.

@Howard-Vigorita I know you actually believe this because you keep saying it, but I don't understand how you're arriving at that conclusion. You're somehow equating bayer filters on single CMOS cameras and de-mosaicing 50% green 25% red 25% blue with an effective 420 color from the sensor, Keep in mind many cameras super sample with various resolutions and shutter speeds which can result in not 422 color but real 444 color ans sharper images.

Forgetting about super sampling, what do you think those image processing engines are doing that Nikon and Canon won't shutup about on their high end cameras? They're not padding out 420 images to appear 422 via simple interpolation. We've all seen how many modern cameras handle bright red lights at concerts etc, so not a perfected technology.

@Former user I keep saying it because it's a fact. All currently made video camera sensors are 4:2:0 meaning they have 1-red, 1-blue, and 2-green sensor elements for each pixel. But they are arranged with adjacent greens next to one another making the green stripes fatter. So they need to be re-arranged before storage and that process was originally called de-mosaicing. The debayering invention added fabrication of missing elements in-camera to obtain a more equal number of elements before saving to recording media and has become conflated with de-mosaicing. Personally, I think that was the worst idea ever invented. My Z-Cam E2 can capture raw directly off its Sony Exmor sensor which is now called partial debayering... which is simply the original de-mosiacing without the faked elements.

Btw, the whole idea of capturing fewer than all the color elements was originated in color tv broadcast to reduce signal content at the transmitter so power and coverage could be increased. It's based on the distribution of color sensitive cone sensor elements in the eyes of all earthlings... there are more green cones because life here evolved on a green planet and the human target audience can discern more shades of green than red or blue. I think when hd sensors were first being upscaled, one maker tried upscaling it's rgb sensor but quickly dropped it when it became obvious that more pixels yielded more noticeable quality than fewer pixels to make room for more red and blues. There are some rgb sensors used for instrumentation and IR but I haven't seen any in a conventional video camera. With shrinking lithography, they could probably now make an 8k sensor with a 4:2:2-sized rgb array... if 16k sensors don't catch on.

I see that there is a artical out on Vegas 21 and Z Depth

VEGAS Pro 21
Introduction to the new features
VEGAS Z-Depth OFX plug-in and compositor

Is Version 21 out???

@Former user I keep saying it because it's a fact. All currently made video camera sensors are 4:2:0 meaning they have 1-red, 1-blue, and 2-green sensor elements for each pixel.

@Howard-Vigorita But that's an analogue process, chroma subsampling is digital

We know the huge expensive TV studio cameras used for green screen work output in 444 12bit, and you wouldn't say that's fake 444, but look at this, It's a single CMOS prosumer camera with 25% red, 25% blue, 50% green elements, which you're calling 4:2:0, but look at the superior results for 444, you think that's not real 444?

If 4:2:0 were a limitation of the sensor layout, rather than encoding for video, wouldn't it also show up in raw still images? I'm not seeing any such flaws in the RGB data that is debayered in post. I don't see why with sufficient processing power a camera couldn't do a similar conversion itself at greater precision than 4:2:0.

The sensor geometry is what it is. If all the elements are not there, the missing data has to be interpolated from the nearby elements to get more. Which is what debayering does inside the camera. Monitors can also do that internally.

If you want to measure the error propagation, start with a raw capture that matches the 4:2:0 sensor geometry and also make a 4:2:2 version in post. When I did that, I found little to no deviations with simple transcodes. But the more I edited the 2 clips in tandem, the greater the deviation measurements got.

My experience shooting and editing 4:2:2 HD from a 3-CCD camera for a decade is that none of this applies because that camera actually captures and records nothing but real data. Canon actually downscales it from full rgb to accommodate the transfer-speed limits of its CF media. It was just a chore to edit until cpus got faster.

We know the huge expensive TV studio cameras used for green screen work output in 444 12bit, and you wouldn't say that's fake 444, but look at this, It's a single CMOS prosumer camera with 25% red, 25% blue, 50% green elements, which you're calling 4:2:0, but look at the superior results for 444, you think that's not real 444?

@Former user I can tell you that I've shot Z-Raw which is partially debayered 4:2:0 matching sensor geometry and used it's converter to complete debayering into DNxHD YUV 422 & 444 as well as straight YUV 422 & 444. Renders were no greater quality than conversion to hevc 420 or 422. Didn't add anything except clip size. My cameras don't do 12-bit, but I'm pretty sure that bloating the clips further with a 10-bit to 12-bit upscale would just be more of the same.

I think all the Z-Raw Converter options are only there to satisfy delivery and work flow requirements.