obs-studio
obs-studio copied to clipboard
obsproject
Video Capture Source incorrectly defaults to 601 YUV matrix, does not read metadata
Platform
Operating system and version: Windows 10 2004 19041 OBS Studio version: 26.0 RC1
Expected Behavior
Loopback video of OBS virtual cam in OBS should be mostly stable apart from the known issue of subsampled chroma siting which is deemed unimportant currently.
Current Behavior
Loopback video quickly degrades within seconds with severe darkening of the video. Reported at https://discord.com/channels/348973006581923840/748615007238881411/749967931672231967
Steps to Reproduce
- Enable virtual camera output
- Add virtual camera output as an input source to OBS
Additional information
The recent switch to sRGB tagging (with 709 YUV conversion) as default for the OBS main output combined with the addition of virtual camera output has revealed an incorrect default in the Video Capture Source. Rec601 is a legacy colour format, reserved for old analogue video sources. Modern video is almost exclusively Rec709, and that is also the new default for OBS' own output. The incorrect default of 601 causes extreme video degradation when adding OBS' own virtual camera output as a Video Capture Source in OBS itself, because of the mismatched matrices.
Changing the default to 709 should fix the most egregious symptoms, but ideally the virtual camera output should tag the used colour space properly in its VIDEOINFOHEADER2 structure, and the Video Capture Source should read colour space metadata from that same structure to automatically select the correct YUV conversion matrix.
What member of VIDEOINFOHEADER2 specifies color space? I'm not seeing any.
From MSDN:
Color-space information is given in the VIDEOINFOHEADER2 structure. The information is stored in the upper 24 bits of the dwControlFlags field. If color-space information is present, set the AMCONTROL_COLORINFO_PRESENT flag in dwControlFlags. When this flag is set, the dwControlFlags field should be interpreted as a DXVA_ExtendedFormat structure, except that the lower 8 bits of the structure are reserved for AMCONTROL_xxx flags.
https://docs.microsoft.com/en-us/windows/win32/medfound/extended-color-information https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/dxva/ns-dxva-_dxva_extendedformat
Moving this to the 26.1 milestone to allow for further discussion, and since this is not a critical issue that needs to be immediately addressed.
Moving this to the 26.1 milestone to allow for further discussion, and since this is not a critical issue that needs to be immediately addressed.
Just for the record, I consider #3415 to fix the immediate issue of mismatched matrices, the metadata stuff is more of a "we should ideally do this" for 26.1. If @jpark37 makes a draft PR for that, this issue can be closed and the implementation discussion continued there.
In the absence of color metedata, it's probably a good idea to default to BT.601 for vertical resolutions <= 576 and BT.709 for >576 vertical lines on incoming video captures?
And while this is a broader thing in the BT.601 space, there's SMPTE-C vs EBU primaries and D65 vs D93 white point to deal with as well (NTSC-J being EBU + D93 on a 525-line system vs North American SMPTE-C + D65 on 525-line or Brazil on EBU PAL, but 525 line, for instance).
NTSC-J being EBU + D93 on a 525-line system
Ah, yes, Japanese D93. Well, you see, it is not really the whitepoint, it is just a reference illuminant. So color managment should make it look under D65 dim room (SDR spec) the same as it would under D93. Netflix converts it automatically and H.274 (not H.273, mind you) clarifies how metadata for viewing environment should look like. Anyway, it is kinda nuts.
Using OBS 30.0.0-rc2 and an ATEM Extreme SDI and an UltraStudio HD to loop my output into my input I produced these images.
I absolutely favor using Rec 709 as the default. If possible, also default Blackmagic UVC devices to Full range, rather than Legal.
