obs-websocket: Encode 10-bit sources to sRGB in screenshots

[rdoupe]

Fixes #1141

Merge after #1145 (the Session Duration submodule bump) (same obs-websocket master, ws#15 comes before ws#16 there), so the submodule only moves forward.

What and why

obs-websocket's GetSourceScreenshot and SaveSourceScreenshot of a 10- or 12-bit source now show the colours the program shows, instead of a much darker picture.

• TakeSourceScreenshot() (plugins/obs-websocket/src/requesthandler/RequestHandler_Sources.cpp) rendered the source on its own into an 8-bit GS_RGBA texrender with linear sRGB off. libobs keeps I010/P010/I210/I412 frames (HEVC Main10, VP9 profile 2, ProRes, 10-bit capture cards) as a linear float texture (need_linear_output(), GS_CS_SRGB_16F). It only turns on the framebuffer's sRGB encode while linear sRGB is on, so the linear values went into the image unencoded: orange (255, 96, 0) became (255, 30, 0), mid grey 128 became 55. Scenes (render_item() in libobs/obs-scene.c) and the Properties/Filters/Interaction previews draw with gs_set_linear_srgb(true), so the program, the preview, scene screenshots and recordings were right.
• The fork fix, utils: Encode high-bit-depth sources to sRGB in screenshots obs-websocket#16, moves the function unchanged into src/utils/SourceScreenshot.cpp (Utils::TakeSourceScreenshot()). It then draws the source with linear sRGB on when its colour space (obs_source_get_color_space() with SRGB, SRGB_16F and 709_EXTENDED preferred, the list transitions use) is not 8-bit sRGB. This PR moves the submodule to it.
• 8-bit sources keep the direct path, so their screenshots don't change (byte-identical in the product check below). Turning linear sRGB on for them too would make libobs premultiply semi-transparent 8-bit async sources (DrawNonlinearAlpha), and the PNG would get darker edges. HDR (PQ/HLG) async sources were already tone mapped with linear sRGB forced on by libobs, so nothing changes for them.
• Found by our release check (FFmpeg 8.1.3 and libvpx 1.17.0 validation, checks 61 and 90: ProRes, HEVC Main10 and VP9 profile 2 files looked wrong in the source screenshot only). No upstream report. The screenshot issues upstream are other bugs: Bug: "Save/GetSourceScreenshot" (Doesn't Match OBS Behaviour) obsproject/obs-websocket#1213 is about cropping, Bug: GetSourceScreenshot returns image of preview and not program when both are the same scene but preview has changes obsproject/obs-websocket#1257 preview vs program, Bug: GetSourceScreenshot not giving correct MIME type for imageFormat: jpg obsproject/obs-websocket#1298 the MIME type.

Reproduced in release v0.1.0-beta.20261014 (AppImage, headless: private Xvfb, private HOME, dbus-run-session, --multi, loopback-only network namespace). A Media Source is the only item of the program scene, playing ordinary files made by ffmpeg from one pattern (below the top strip: left half (255, 96, 0), right half (0, 96, 255)). Left patch of GetSourceScreenshot of the source / of the scene / a recording frame:

File	v0.1.0-beta.20261014	This branch, C libobs lane	This branch, Rust libobs lane
ProRes 422 HQ 10-bit	(255, 30, 0) / (255, 96, 0) / (255, 95, 0)	(255, 96, 0) / (255, 96, 0) / (255, 95, 0)	(255, 96, 0) / (255, 96, 0) / (255, 95, 0)
HEVC Main10 4:2:0	(254, 30, 0) / (255, 96, 0) / (255, 95, 0)	(255, 96, 0) / (255, 96, 0) / (255, 95, 0)	(255, 96, 0) / (255, 96, 0) / (255, 95, 0)
ProRes 4444 10-bit, alpha	(255, 30, 0) / (255, 96, 0) / (255, 95, 0), alpha 254/0	(255, 96, 0) / (255, 96, 0) / (255, 95, 0), alpha 254/0	(255, 96, 0) / (255, 96, 0) / (255, 95, 0), alpha 254/0
H.264 8-bit (control)	(255, 96, 1) / (255, 96, 1) / (255, 95, 0)	the same	the same
VP9 alpha 8-bit (control)	(255, 106, 0) / (255, 106, 0) / (255, 105, 0), alpha 255/0	the same	the same

The two 8-bit source screenshots are byte-identical to the release's in both lanes (all 48000 pixels below the pattern's changing strip).

RED → GREEN

• RED commit: 0e0dbda test/cmocka: Add failing test for websocket screenshots of 10-bit sources. It moves the submodule from master's pin f06b040 to e87c6e1, the fork PR's first commit, which moves TakeSourceScreenshot() into Utils::TakeSourceScreenshot() unchanged. test_ws_screenshot_srgb builds that file against libobs and the built OpenGL module (GRAPHICS_MODULE_PATH), with Qt Gui for QImage. It shows a flat full-range BT.709 colour from a test async source as the only item of the program scene (BGRA output), and checks the screenshot's centre pixel against the expected sRGB colour and the program output. It fails 4 of 6 cases in both lanes: p010_grey_is_srgb (55 instead of 128), p010_orange_is_srgb, i010_orange_is_srgb and i210_orange_is_srgb ((255, 30, 0) instead of (255, 96, 0), the program (255, 96, 0)). The controls nv12_orange_is_unchanged and bgra_with_alpha_keeps_straight_colour (200, 100, 50 at alpha 128 stays as sent) pass. Linux only, like the other tests that load the OpenGL module; the cases skip without a display (checked with DISPLAY unset).
• GREEN: 1ce9f47 moves plugins/obs-websocket from e87c6e1 to d79d2c2, the fix (d79d2c2 once utils: Encode high-bit-depth sources to sRGB in screenshots obs-websocket#16 merges; forward only). 6 of 6 pass with ENABLE_RUST_LIBOBS OFF and ON. Full OBS build (frontend + obs-websocket) in both lanes. Full ctest -j8 (private Xvfb, dbus-run-session, system libobs-opengl masked, TMPDIR unset): 275/275 in both lanes, and test_ws_screenshot_srgb ran all 6 cases there. Every PipeWire/PulseAudio test ran. Skipped only open_crashes_without_obs_core (both lanes) and, in the Rust lane, test_startup_alloc_stable: its one case skips when one of its 100 obs_startup() calls fails under load, and it passed on a rerun alone. clang-format 22.1.3, gersemi and ci/test_registration.py clean.

Checklist

• Base is master
• I claimed the issue, or no one else has an open PR for it
• Characterization test (if the unit had none), then RED, then GREEN commits
• (Optional) Local gate passed and the pushed head is stamped; otherwise PR CI runs the full suite
• Warning or flag changes (-W..., ratchets): none
• Intentional differences from C listed in the parity test header and rust/README.md (ports): not a port

AI note: Claude Code (Claude Opus 5.5) wrote the code, the test, the commit messages and this text under the submitter's direction, and ran the tests above on the submitter's machines.

🤖 Generated with Claude Code

[zackees]

Maintainer push: rebased onto master after #1145 merged. GitHub's own rebase reported a conflict; a local rebase was clean. The two commits are unchanged, now d84fd8267 and 5ac5bcb4a. #1145 merged in its earlier form, so master's plugins/obs-websocket is 8bca4ac. This PR moves it forward to d79d2c2 (adds obs-websocket#16), so the pointer only moves forward. I'll queue it once CI is green.