6 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Sonnet 5	c5fedd176f	docs: the -A x64 fix is confirmed; Windows now blocked on OBS's own CMake ... Updates the Windows record written in 551f782, which was accurate when written but has since been overtaken: the run it described as "in progress" (edb0c02, the first commit carrying the -A x64 fix) has now completed. The informative part is that the fix worked and Windows failed further along. obs-deps and Qt6 downloaded, CEF was skipped, the OBS sub-configure ran for 53s and correctly reported "Plugin Support" and "User Interface" disabled -- then failed at generate time: CMake Error at libobs/cmake/os-windows.cmake:46 (target_link_libraries): Target "libobs" links to: OBS::w32-pthreads but the target was not found. Traced at the 30.0.2 tag, and it does not appear to be anything this repo is doing wrong: - libobs/cmake/os-windows.cmake links OBS::w32-pthreads; - that target exists only in deps/w32-pthreads/CMakeLists.txt, reached only via deps/CMakeLists.txt; - deps/ is added only by the LEGACY branch of the top-level CMakeLists. The modern branch that -DOBS_CMAKE_VERSION=3.0.0 selects adds libobs, libobs-d3d11, libobs-winrt, libobs-opengl, plugins, test/test-input and UI -- never deps; - libobs/CMakeLists.txt adds only deps/libcaption and deps/uthash; - plugins/CMakeLists.txt returns immediately under ENABLE_PLUGINS=OFF, and does not add deps/ even when enabled. macOS is unaffected because its libobs does not link w32-pthreads, and at 30.0.2 the modern path was the default only on macOS -- consistent with the Windows side of it being under-exercised upstream. Deliberately NOT "fixed" here by bumping the pin: 30.0.2, 30.1.2, 30.2.3, 31.0.3 and 31.1.1 all still link OBS::w32-pthreads and none of them add deps/w32-pthreads from libobs/CMakeLists.txt, so a bump is not obviously the answer and needs checking rather than assuming. Three options are written up with the evidence behind each, so whoever picks this up starts from a diagnosis instead of from the error message. Everything else 551f782 said stands, including its caution not to treat either fix as confirmed without a green run -- the PowerShell rewrite is still queued and still unproven, and is marked as such. The CI table row and the top-level Status paragraph are updated to match; the licensing/release gate is untouched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 23:08:39 -07:00
shadowdaoandClaude Sonnet 5	551f782d8a	docs: correct Windows CI record, add release-gating note (C1/C2, I6) ... - I6: README claimed Windows CI status as "Unconfirmed". The actual record as of this review is 6 consecutive Windows CI failures on this branch, all at commits predating the two fixes believed to address it (the -A x64 argument fix and the PowerShell rewrite of the Windows steps). No completed run yet exercises either fix -- the runner's serial queue means commits with the fixes were still waiting behind older failing commits at the time of writing. Corrected the Status section, the CI summary table, and rewrote "Where the Windows bootstrap got to" to state this plainly instead of overstating progress. - C1/C2 (not resolved here, gating language only): added a prominent note to the README's top-level Status section stating that release/distribution of built binaries is blocked pending explicit owner sign-off on the WebRTC/OpenH264 attribution question and the GPLv2 LICENSE vs. Apache-2.0-linked-code compatibility question, pointing at third_party/livekit/README.md where the details already live. Checked .gitea/workflows/build.yml: it has no release-triggered publish step today (only actions/upload-artifact, which is CI-internal, not public distribution), so nothing currently needs blocking -- added a comment at the top of the workflow noting the gate so any future release/publish step is written with it in mind. Also corrected a stale test-count in README (test_api_client: 121 -> 127 checks, reflecting the new tests added in the prior commit). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 23:00:48 -07:00
shadowdaoandClaude Sonnet 5	6829dd545a	Stage the plugin into the directory layout OBS actually searches ... The staged package put the module in build/package/bin. OBS does not look there. From AddExtraModulePaths() in obs-studio's UI/window-basic-main.cpp, the per-user plugin layout on Linux and Windows is: <config>/obs-studio/plugins/<name>/bin/64bit/<name>.{so,dll} <config>/obs-studio/plugins/<name>/data/ so build/package/ now uses bin/64bit and is a straight drop-in. Re-verified in the headless libobs harness from the new path: the module loads, both sources connect, frames arrive, the camera switch round-trips, and `ldd` on the staged copy resolves liblivekit and liblivekit_ffi from bin/64bit via $ORIGIN. macOS deliberately keeps the flat bin/ -- there OBS looks for a <name>.plugin/Contents/MacOS bundle, which this build does not produce. That gap is documented in README.md rather than papered over with a directory name that would only look right. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:36:01 -07:00
shadowdaoandClaude Sonnet 5	9a1a1474a9	docs: record what CI actually proved, and the macOS packaging gap it does not ... The macOS bootstrap now works end to end: obs-deps and obs-studio download, libobs 30.0.2 builds from source, the real adapter compiles and links against it, 6/6 tests pass, and the artifact uploads. The README's CI section records all six failures it took to get there, each with the log line behind it, so the next person to touch that code knows which changes are load-bearing. It also records the gap CI cannot see. **The macOS artifact will not load in OBS.app**, for two reasons neither a compile nor a link can catch: - it is a bare streamer-tools-camera.so, and OBS on macOS loads plugins as <name>.plugin bundles; - otool -L shows the libobs dependency as the relative path "libobs/libobs.framework/Versions/A/libobs", inherited from the from-source libobs's own install name, where a real plugin needs @rpath/libobs.framework/Versions/A/libobs plus an LC_RPATH into OBS.app/Contents/Frameworks. Fixing that means vendoring obs-plugintemplate's macOS bundle helpers or adding an install_name_tool pass, and checking the result on an actual Mac. Deliberately not attempted here rather than guessed at. Windows is recorded as unverified. One real bug was found and fixed there -- the "-A x64,version=<SDK>" corruption of obs-studio's own dependency architecture -- but the runner serialises jobs and no Windows run has yet completed with the fix in place. Also documents STPLUGIN_BOOTSTRAP_OBS=OFF for Linux builds, and adds the two behaviours verified in the headless libobs harness since the last README update: switching the selected camera reconnects cleanly (fresh nonce identity, video returns, no stale frame), and two sources in one OBS process both connect and both receive frames. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:28:52 -07:00
shadowdaoandClaude Sonnet 5	a484abec61	Make the OBS adapter real: properties UI, connect, and frame output ... The stub source becomes an actual streamer-tools camera. On create it reads server URL / room slug / read key / camera identity from obs_data_t, mints a subscribe-only token through ApiClient, connects LiveKitSession, and pushes decoded frames into obs_source_output_video / obs_source_output_audio. The source is now OBS_SOURCE_ASYNC_VIDEO | OBS_SOURCE_AUDIO | OBS_SOURCE_DO_NOT_DUPLICATE with an OBS_ICON_TYPE_CAMERA icon. The file is C++ rather than C now: the core library's API is C++ and the C ABI shim existed only to avoid that. obs-module.h already declares the module entry points extern "C", so nothing is lost. Properties UI: server URL, room slug, a masked read-key field (it is a credential and is masked everywhere else in streamer-tools), a camera dropdown, a "Refresh camera list" button, and a status line. - The dropdown is built from a cache the worker keeps warm on every connect, so opening properties never blocks on the network. The button is the explicit way to force a round trip, with a shortened 5s timeout -- for which ApiClient's two calls gained a timeout_ms parameter. - The currently-selected identity is always in the list, labelled "(not in this room)" if absent, so OBS cannot silently clear a working setting just because the room happens to be dark. - The status line is the OBS_TEXT_INFO property's description (which is what OBS actually renders) and switches to the warning info type on a real error. Threading: OBS's UI and graphics threads are never blocked on the network. Each source owns a worker thread that mints, connects, and reconnects with exponential backoff (1s -> 30s), waking early on any settings change via a generation counter. Frames are pushed from LiveKitSession's reader threads directly; obs_source_output_video/_audio are thread-safe. Two details that matter operationally: - A null frame is pushed whenever the session leaves Connected, so a camera that stopped publishing clears instead of leaving its last frame on screen. Leaving stale media up is precisely the failure this plugin exists to avoid. - The SDK's own logging is routed into OBS's log file via livekit::setLogCallback, instead of stderr where a director would never see it. The adapter also logs the first frame and every later geometry change, so a log answers "did video ever arrive, and at what size". Packaging: the build now stages a runnable layout into build/package/ -- the module (RPATH $ORIGIN / @loader_path, so it resolves the LiveKit libraries from beside itself rather than from the build tree), liblivekit + liblivekit_ffi, the locale data, and the licence files. third_party/livekit/ carries client-sdk-cpp's Apache-2.0 LICENSE and NOTICE from the pinned tag. Its README records a correction to the design doc: the "bundled LICENSE.md with ~28 third-party licence blocks" the doc expects DOES NOT EXIST at v1.10.1 -- not in any of the five release archives (which contain only include/, lib/, bin/ and build-info.json) and not in the repo at that tag, which has only LICENSE and NOTICE. The aggregated third-party notice covering the WebRTC/OpenH264 code inside liblivekit_ffi.so has not been located, and that is flagged as an open licensing question rather than papered over. Verified on Ubuntu 24.04 against real libobs 30.0.2, a real livekit-server 1.13.6, and a stand-in API serving plugin.routes.ts's exact shapes, using a headless libobs harness (obs_startup + obs_reset_audio + obs_reset_video + obs_open_module + obs_source_create): registered=1 output_flags=0x87 [streamer-tools-camera] connected to ws://127.0.0.1:7880 as obs:main-room:qY85r9D0PaPt, watching cam-test [streamer-tools-camera] video frame 640x360 I420 camera dropdown has 3 items: [0] (no camera selected) = [1] Test Camera = cam-test [2] Dark Camera (offline) = other-cam status: connected (info_type=0) and with a deliberately wrong read key: status: unknown room slug, or the read key is wrong or has been rotated (info_type=1) with retry-and-backoff and no crash. ctest: 6/6 passed. Still unverified, and the README says so plainly: the OBS GUI on any platform, macOS/Windows beyond compiling, A/V sync, and end-to-end latency. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 21:54:11 -07:00
shadowdaoandClaude Sonnet 5	105f1041ab	Scaffold core/OBS-adapter split, prove CMake toolchain, add 3-platform CI ... First pass on the streamer-tools OBS camera plugin: a minimal but real CMake project matching the design doc's core-library/OBS-adapter split (docs/superpowers/specs/2026-09-06-obs-camera-plugin-design.md in the streamer-tools repo). No LiveKit FFI integration yet -- this proves the toolchain works. - core/: dependency-free C++17 library (no OBS dependency), unit tested via CTest with no external test framework. - obs-adapter/: adapted from obsproject/obs-plugintemplate (commit 3e7d7ac, 2025-12-09). Registers a real, stubbed OBS source type; builds as a genuine dynamically-linked OBS module against Ubuntu's system libobs-dev (confirmed via ldd/nm, not a fake stand-in). - Simpler hand-written top-level CMakeLists.txt in place of the template's full buildspec-driven bootstrap (which downloads full OBS source + prebuilt deps) -- find_package(libobs) alone is enough on Linux; falls back to core-library-only when libobs isn't found (expected on macOS/Windows CI for now). - .gitea/workflows/build.yml: 3-platform matrix (ubuntu-latest, macos-latest, windows-latest) matching the runners confirmed available to this repo under the CyberCoveLLC org. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 20:46:08 -07:00