Resolve external preview chroma sampling, no 4:2:2 output?

I expected the external preview on a Decklink (Decklink 4K Pro in my case) to be 4:2:2 by default in Resolve, but that doesn’t seem to be the case. So what is the default output? The manual doesn’t say.

I haven’t been able to locate a reliable test image for 4:2:0 but I suspect that’s what it is. But if that’s the case, why is there no option for a 4:2:2 output when there’s one for 4:4:4?

I can force 4:2:2 (verified with test image) by setting DaVinci Resolve to 4:4:4 and then disable 4:4:4 in the Desktop Video Setup instead (tested on Windows). But it would be nice to be able to control that directly within Resolve.

Why do you think default is not 422?
Default should be 422 and then you can enable 444 (when supported). SDI is not going to be 420 for sure.

I used a test image. The last one looks strange doesn't it?

DaVinci Resolve 444 enabled.jpg (31.53 KiB) Viewed 8526 times

DaVinci Resolve 444 enabled - Decklink 444 disabled.jpg (49.62 KiB) Viewed 8526 times

DaVinci Resolve 444 disabled.jpg (31.08 KiB) Viewed 8526 times

Here's the actual test image i used.

Hi,

And changing the attributes of the clip "Data levels": auto vs Video vs full? (Not tested). From what I understood Davinci Resolve override all the BM desktop settings except the SDI (video tab).

1st image is good, 2nd also but bit confusing.
If you untick 444 in Resolve but then open BM card settings and turn it on this may 'confuse' chain and you get 3rd image. What if you then close BM settings and tick 444 and back untick it (without touching BM settings anymore)? I think Resolve should overwrite BM settings, so you should not need to look at BM settings at all. I may be wrong

Jean, there's no significant change to the chroma subsampling if I change from video to data levels.

Andrew, it certainly is confusing... As far as Resolve is concerned the third image is the default. That is how it looks on a completely new install of Windows/Resolve/Desktop Video. The only way to get a proper looking 4:2:2 image is by fooling the signal chain and enabling 4:4:4 in Resolve and immediately disabling it in Desktop Video Setup. After I have 4:2:2 working trough Desktop Video Setup, toggling 4:4:4 off/on/off in Resolve doesn't bring back 4:2:2.

In summary, Resolve only toggles between the weird chroma subsampling mode that I can't identify and 4:4:4. Desktop Video Setup toggles between 4:2:2 and 4:4:4. This is on a 4:4:4 capable DeckLink.

On an UltraStudio Mini Monitor (max 4:2:2 capable) the Resolve 4:4:4 toggle toggles between the weird mode and 4:2:2.

Report it to BM using support ticket.
3rd image is not what you should get on SDI signal.
I used the same test image and it was either 1st or 2nd (test outside Resolve and BM hardware)

It is indeed Resolve that is doing something unexpected. I converted the test PNG to DPX and opened it in Media Express. Output on the DeckLink from Media Express was perfect 4:2:2 or 4:4:4 depending on settings in Desktop Video Setup.

Hmm... I wonder if Resolve is shifting the image one pixel up or down.

Finally figured it out, to a degree at least. Resolve's 4:2:2 output is fine when all the clips on the timeline are 4:2:2. If you have a 4:4:4 clip on the timeline and monitor at 4:2:2 that clip will look much worse than normal 4:2:2. Renders are fine though.

Edit: Renders to DNxHR 4:2:2 are fine, but the super fast Grass Valley codec (4:2:2) exhibits the same behaviour as the monitoring output when it's fed a 4:4:4 image.

[Peter Chamberlain]

Finally figured it out, to a degree at least. Resolve's 4:2:2 output is fine when all the clips on the timeline are 4:2:2. If you have a 4:4:4 clip on the timeline and monitor at 4:2:2 that clip will look much worse than normal 4:2:2. Renders are fine though.

This doesn't make sense. All source clips are transformed to RGB 32 bit float for image processing. The SDI out will be as per the project settings and the source format has no relevance. Leave the desktop video app off and just control in Resolve.

There is some issue here as per 3rd image from few posts above. This test pattern is properly design and works well. I used it many times.
Looks like Resolve doesn't properly reset preview to 422 once 444 being activated.

All source clips are transformed to RGB 32 bit float for image processing....the source format has no relevance.

Somehow I feel like that is the confirmation I have been waiting to hear from BMD ever since I first launched DR. Thank you!

So Peter, please can you answer the question: If I import YUV 422 footage, how does DR upres the chroma channels to 444 for the RGB transform? And similarly, if I export a graded scene to YUV 422, how does DR subsample the chroma channels? Spline? Bicubic? Lanczos? Some documentation of this behavior would be very much appreciated.

I can only assume that unless you import/export RGB sequences, then 422 footage will be subjected to some sort of scaling algo. Thank you.

I believe I've been very thorough in investigating this but there might be something I've missed. Here's another rundown.

Summary: 4:4:4/RGB clips look very pixelated/aliased on a DeckLink or UltraStudio Mini Monitor when Resolve Project Settings > Master Project Settings > Video Monitoring > Use 4:4:4 SDI is disabled. I expect 4:2:2 output but it looks much worse than normal 4:2:2. The issue only affects 4:4:4/RGB clips, not 4:2:2 clips.

Here are some lossless blown up crops (PNG, 300%, nearest neighbor) of a chroma subsampling test. Click to view unscaled. Image number 3 shows the issue I'm trying to avoid.

1. Original 1080p RGB file - Perfect



2. Rendered as uncompressed 4:2:2 in Resolve - Good, this is expected and also what I expect the 4:2:2 monitor output on the DeckLink to look like



3. Monitored image 1 in Resolve on a DeckLink - Extreme aliasing. Only Resolve project settings are used (Desktop Video Setup isn't even started). This image is captured from the SDI output and accurately shows what I'm seeing on the monitor. Interestingly, rendering to the Grass Valley codec shows the same issue.



4. Monitored with workaround - Very good, the desired result! The "workaround" being enabling 4:4:4 in Resolve and then starting Desktop Video Setup and disabling 4:4:4 there. This has the side effect of slowing down Resolve just as much as when actually using 4:4:4, no use even trying to have the internal scopes on (curiously, the slowdown disappears if you set Data Levels to Full instead of Video).


All tests performed in Windows 10 Pro, DaVinci Resolve Studio 12.5.4.019 and BM Desktop Video 10.8.4 on an HP Z840 with Dual Xeon 6-core@2.4GHz, 48GB RAM, Dual 12GB GeForce GTX Titan X (Maxwell), DeckLink 4K Pro.

Also tried on a MacBook Pro Retina mid 2014 using an UltraStudio Mini Monitor, it outputs the same pixelated/aliased image when "Use 4:4:4 SDI" is disabled.

Uncompressed 1080p DPX files of the four images above (uncropped) are attached.

Yep, clearly there are bugs in Resolve.

Roger,

Thank you for the detailed comparison. I downloaded your DPX files and tried them out on my system which is an Intensity Pro 4K. The original RGB image monitored via 422 and HDMI looks very similar to your #3 example with extreme aliasing.

Of course, since the IP4K has no 4:4:4 SDI output, I have no ability to implement the workaround that you describe to get the desired result—unless someone can describe what it is I am not getting?

Sounds like huge bug in Resolve, not restricted to 1 card.

Unfortunately, the bug with downsampling 4:4:4/RGB to 4:2:2 in Video Monitoring and Grass Valley output persists in Resolve 12.5.5.

So it seems I got a warning for mentioning this issue in another thread, sorry about that, just trying to help.

This issue is easily verifiable and it persists in v14.

For the Grass Valley codec, this issue is finally fixed in Resolve v14.0.0.078.

The same issue with downsampling 4:4:4 footage to 4:2:2 still remains with external preview though.

Unfortunately now Grass Valley doesn't preserve super-whites when rendering even though it worked in v12.5.4-v12.5.6. Actually, several codecs that previously preserved super-whites no longer do so in v14.

In which codecs you don't see superwhites any more?
I can still see them in those Sony cameras that always used to generate superwhites.

I still get super-whites with the original acquisition files from the camera (C300). That works fine in Resolve v12 and v14. But files rendered by Resolve v14.0.0 are clipped and do not preserve the super-whites.

For example in v12.5.4 for Mac they added this ability to the ProRes codec:

Added support for preserving super-white and sub-black data in ProRes 4444 codecs

I have tested it and renders to ProRes 4444 and Grass Valley preserves super-whites in v12.5.6 but not in v14.0.0.

Did you switch to full swing on output? Otherwise you'll have to pull down those superwhites.

Or do you see the problem when importing? You may need to switch from "Auto" to "Full" in the clip attributes.

That's actually my point, before v14 you could export with data level set to "Video" and the sub-black and super-white would still be intact for the mentioned codecs. Odd that they would promote this as an added feature and then remove it. That's why I feel it's a bug.

A compelling reason for this to work is if you're using Resolve as an editor only, and someone else grades your rendered files.

Woohoo! Downsampling RGB/4:4:4 media to 4:2:2 on external preview is fixed in Resolve 15!

So all this time people were looking at quite corrupted output (most likely not having clue about it)