- Posts: 1
- Joined: Thu Jul 27, 2023 6:58 pm
- Real Name: John Passaniti
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?
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?