HDMI Colorspaces

I suspect my question will be a bit unusual from the kind asked by most Blackmagic users. But ultimately, it's about HDMI colorspaces.

We have an embedded system that generates an HDMI video stream. When connected to a video monitor, the video looks fine on the screen. But when we try to record video (using an ATOMOS Ninja), it refuses. It doesn't like something about the HDMI output.

To address this, someone suggested we use a Blackmagic converter (the "Mini Converter UpDownCross HD") between the embedded system and the video recorder. And yep, that worked. My guess is that whatever was wrong with the HDMI signaling was cleaned up by the converter box. So instead of fixing the problem, we just used the converter box to fix the problem. We decided to figure out the actual problem later.

Time passes and we get access to a HDMI analyzer. With it, we think we understand what the problem was (VSYNC Delay was off by one), but I noticed something else. The HDMI video direct out of the embedded system showed up as being in the RGB colorspace. But when we add the Blackmagic converter box, our analyzer says it's now in the YCbCr color space.

My understanding is that YCbCr is just the digital form of the YUV colorspace. And I know that 8-bit YUV limits luma to 16 to 235 and chroma to 16 to 240. So I'm concerned that the Blackmagic converter box, although it "fixed" the original problem we had, is introducing a subtle new problem-- that the video coming out has somewhat less dynamic range.

My questions:

1. Is my concern valid? Is the YCbCr output dynamic range limited compared to RGB?

2. Is an off-by-one VSYNC Delay something that could make the ATOMOS Ninja refuse to record?

3. Is the Blackmagic converter box likely "cleaning up" this incorrect VSYNC Delay?

4. Why is the Blackmagic converter box changing the colorspace?

1-Not really, the UDX shouldn’t be mapping 10 bit to 8 so likely the source is 8 bit.

2-No

3-No

4-The Ninja doesn’t record RGB, the sink in the Ninja is telling the UDX YCrCb so that’s the output the UDX is sending.

Good Luck

it would be nice if "the embedded system" that is used, isn't a secret, i thought the end procces was always in the "limited" range, only when recording in log(s) the range would be "full" ?

Y/Cb-Cr is typically recorded as limited, but that has nothing to do with dynamic range encoded. It's just how the range is encoded to file. Which seems weird at first.

RGB media does not necessarily have a wider dynamic range. It all depends on the camera and settings used.

Sent from my SM-S908U using Tapatalk

Prores is 10 bit which supports 0-1019, whether or not the Ninja truncates that to a legal 64-960 I can't say right now, not bored enough to check. Either way the HDMI RGB output should be set to limited (if possible) to avoid levels issues and the associated clipping. For the record 10 bit YCrCB has more dynamic range than RGB because it supports super whites and sub blacks whereas rgb is always 0-100% in limited or full.

Good Luck

I'm having the same issue with a Decklink 8K Pro [edit: problem also occurs with Mini Monitor 4K] and a Dell AW3423DWF. The Decklink is outputting RGB over SDI, but when the signal is converted to HDMI in the bi-directional converter, it is also converted to YCbCr and then the full range signal is clipped to video levels at the display. This doesn't happen with my LG 32EP950 display, nor does it happen when I output HDMI directly from my Decklink mini monitor 4K to the Dell. I'm wondering whether it's an EDID problem between the Bi-directional converter and the AW3423DWF.

Does the Bi-Directional converter support RGB over SDI? Can the RGB SDI output be verified anywhere else? It's my understanding that a 4:4:4 configuration requires a dual SDI setup.

Good Luck