20 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5	8888e57d08	fix(http): bound the WinHTTP response-header wait, and stop docs triggering builds ... Two things, both prompted by an intermittent Windows CI failure in test_api_client's testPlatformBackendTimeout: roughly 2 runs in 6, both its assertions failed together, meaning a request with timeout_ms=700 waited out a 5s server stall and returned 200. Same failure on 2026-09-07 (job 5834) and 2026-09-09 (job 5911), on code that passed on other runs -- pre-existing and intermittent, not caused by a change. 1. The real bug. `WinHttpSetTimeouts`' receive parameter maps to WINHTTP_OPTION_RECEIVE_TIMEOUT, which Microsoft documents as a PER-PACKET Winsock-layer read timeout ("applies to fetching each packet of data off the socket"). The wait for the response HEADERS is a separate option, WINHTTP_OPTION_RECEIVE_RESPONSE_TIMEOUT, which WinHttpSetTimeouts does not set and which defaults to 90 SECONDS. So a server that accepts, reads the request and then stalls could block the calling thread for a minute and a half no matter what the caller passed as timeout_ms -- precisely the "blocking an OBS thread indefinitely" failure that test exists to prevent. Now set explicitly, guarded by #ifdef so an older SDK still builds. That is a genuine defect on its own merits. Whether it is the whole explanation for the intermittency is NOT established: the same docs say this timeout "is checked only when data is received from the socket", so neither option guarantees a hard deadline -- that needs a watchdog calling WinHttpCloseHandle, deliberately not done here. 2. Evidence, so the next run says more than pass/fail. The probe now runs 5 times and prints elapsed ms, ok, status, requests_seen and the backend's error string (carrying GetLastError) for every attempt, so one CI run yields a failure RATE and an error code. Each attempt gets a FRESH loopback server: the server handles one connection at a time on a single thread, so reusing it would leave attempts 2..n in the accept backlog -- never accepted, a different scenario from the one that fails. Verified on Linux: 5/5 attempts give up at ~701ms. Also: build.yml now has paths-ignore for **.md, LICENSE, NOTICE, and the two release-only files. This is a full three-platform build behind a runner with capacity:1, and six of them fired for one afternoon of documentation edits. Nothing that feeds a build or a test is on that list. Tradeoff: a docs-only push now shows no status at all rather than a green one. The WinHTTP change cannot be compiled locally (Linux host); CI is its first build. All 6 suites pass locally on Linux. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9	2026-09-09 18:30:02 -07:00
shadowdaoandClaude Sonnet 5	76b2942db1	ci: bump the OBS deps cache key -- it was stuck on a permanently bad entry ... actions/cache never overwrites an existing key: once a key has a saved entry, later jobs' save steps are always skipped as a no-op regardless of cache hit/miss. The very first job to ever populate this cache did so before the "Drop non-relocatable OBS build tree" cleanup step existed, so that entry included the bad, path-baked build_x86 directory -- and every run since has kept restoring that same bad entry, not self-healing after "one more transitional run" the way it looked when this was last checked. Confirmed live: a run just now hit the identical stale-path CMakeCache.txt error against the same original job hash (f72837d12c75c64a) from hours ago. Bumping the key (obs-deps- -> obs-deps-v2-) is what actually forces a fresh save under the cleanup step's watch, since the key content (buildspec files) hasn't changed and nothing else would invalidate it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 10:47:56 -07:00
shadowdaoandClaude Sonnet 5	104326d05a	docs/release: drop the C1 licensing gate, simplify install instructions ... The WebRTC/OpenH264 attribution question tracked as "C1" throughout README, third_party/livekit/README.md, the release-notes template, and both workflow header comments is the project owner's call, and it has been made -- own sign-off given and reaffirmed. Remove the gate language and the extended research writeup from release-facing docs; keep the actual LICENSE/NOTICE files themselves (Apache-2.0 requires shipping those regardless of any of this). Also simplify the release notes' install instructions per owner request: point at each platform's default OBS plugins folder rather than walking through verbose per-platform copy/extract instructions -- the archives already extract straight into place (prior commit), so a short pointer is all that's needed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 09:40:49 -07:00
shadowdaoandClaude Sonnet 5	e050b81d6c	ci: stop re-downloading CMake/Ninja on every Windows run ... lukka/get-cmake@latest re-fetched and re-extracted CMake + Ninja on every single Windows CI run. Its own cache (routed through this act_runner's built-in cache server) reported "Cloud cache miss" on every run, even one immediately after a run that logged a successful save under the exact same key -- an incompatibility between its bundled cache client and this act_runner's cache-server implementation, not a config gap. Separately and more importantly: the archive extraction step alone measured ~7.5 minutes for a 45MB zip on this VM, consistent with Defender real-time scanning rather than raw disk I/O. Together this was the dominant cost of every Windows CI run. CMake 4.4.2 and Ninja 1.12.1 are now installed once, directly on the winvm-builder VM's system PATH (C:\BuildTools\cmake, C:\BuildTools\ ninja), sidestepping the third-party action's cache entirely rather than debugging its internals further. Both Windows jobs now just verify cmake/ninja are present and fail loudly if not, instead of silently falling back to a slow reinstall. Full detail, including how to redo this if the VM is ever rebuilt, is in README's new "Windows runner: persistent build tools" section -- this is VM state, not something git reproduces. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 09:07:23 -07:00
shadowdaoandClaude Sonnet 5	18610bd9dc	ci: stop build.yml from also running on tag pushes ... A bare `push:` trigger matches every ref push, tags included -- so tagging a release triggered this workflow's full 3-platform build (Windows and all) at the same time as release.yml's own, both competing for the Windows runner's capacity:1 and roughly doubling Windows CI time for every tag push. Scope this workflow's push trigger to branches only; release.yml already covers this same build (plus packaging) on every `v*` tag. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 09:03:41 -07:00
shadowdaoandClaude Sonnet 5	d287a90048	ci: strip the non-relocatable OBS build tree before caching .deps ... The obs-studio sub-build's out-of-source CMakeCache.txt (.deps/obs-studio-*/build_*) bakes in the job's absolute checkout path. Caching it as-is (from the previous .deps caching commit) meant every run's first configure attempt hard-failed with: CMake Error: The current CMakeCache.txt directory ... is different than the directory ... where CMakeCache.txt was created. Confirmed live in run 3091 (commit 1f342b1): this was silently self-healing, since windows-build.ps1's existing fallback (-DSTPLUGIN_BOOTSTRAP_OBS=OFF) still found the already-installed, path-independent libobs package and the build succeeded anyway -- but every run paid for one guaranteed-failed configure and printed a misleading "::warning::OBS SDK bootstrap failed" that isn't actually true. Delete only the build tree, after libobs is already built and installed from it, so nothing path-dependent survives into the cache. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 06:10:55 -07:00
shadowdaoandClaude Sonnet 5	1a8255230f	ci: cache the OBS SDK bootstrap deps across runs ... cmake/{windows,macos}/buildspec.cmake download the pinned obs-deps bundle + obs-studio source into .deps/, with its own idempotent skip-if-present logic keyed on SHA256 marker files. That logic never gets a chance to fire because .deps/ lives inside the checkout and a fresh `actions/checkout` wipes it on every single push -- this is what has made every CI iteration tonight re-pay the several-minute cold download instead of only paying it once. Add an actions/cache step for .deps/ in both jobs, keyed on the files that actually pin dependency versions (buildspec.json + buildspec_common.cmake + the platform buildspec.cmake), so a version bump still invalidates the cache correctly. No runner-side config change needed -- the act_runner instance already has its built-in cache server on by default (cache.enabled: true, confirmed via `gitea-runner.exe generate-config` on winvm-builder). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:19:16 -07:00
shadowdaoandClaude Sonnet 5	85e2d08f18	ci: fix Windows step shell -- use powershell, not pwsh ... Real verification push (2b216d3) caught this: explicitly setting shell: pwsh made the Windows job fail immediately with "Cannot find: pwsh in PATH". winvm-builder only has the in-box Windows PowerShell 5.1 (powershell.exe), not PowerShell Core -- which is exactly why the original inline build.yml steps never set `shell:` at all and just relied on the implicit default. Switched both workflows' Windows steps to `shell: powershell` explicitly instead of leaving it implicit, so future edits can't reintroduce this by copying a pwsh example from elsewhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:15:35 -07:00
shadowdaoandClaude Sonnet 5	2b216d3d75	ci: add tag-triggered release packaging workflow ... Adds .gitea/workflows/release.yml, triggered only on a pushed v* tag, which builds all three platforms (reusing the exact same configure/build/test commands as build.yml, now factored out into .gitea/scripts/ so the two workflows can't drift), zips each platform's build/package/ output, and creates a draft Gitea Release with the archives attached. This is packaging automation only -- it does not resolve or bypass the C1 WebRTC/OpenH264 release gate documented in README.md's Status section. Nothing publishes until a human deliberately pushes a version tag (which should not happen before owner sign-off) and then explicitly publishes the resulting draft. The generated release notes lead with a restatement of the open C1 question specifically so that second step can't be taken by accident. build.yml is refactored (not rewritten) to call the same shared scripts; its job/step behavior is otherwise unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:06:25 -07:00
shadowdaoandClaude Sonnet 5	79de5e8f23	Fix Windows find_package(libobs) and make CI hard-fail when the OBS module is missing ... Root cause of the find_package(libobs) failure on Windows: OBS's own modern-CMake Windows layout (obs-studio/cmake/windows/defaults.cmake sets OBS_CMAKE_DESTINATION=cmake) installs libobs's CMake package config to <prefix>/cmake/libobs/ -- a shape find_package(libobs CONFIG) never searches under CMAKE_PREFIX_PATH. Verified empirically with --debug-find-pkg=libobs: CMake's Config-mode search suffixes try <prefix>/cmake/libobsConfig.cmake (no <name> subdirectory) and <prefix>/libobs*/cmake/... (a <name>-prefixed dir first), never <prefix>/cmake/<name>*/. This has nothing to do with the earlier "file INSTALL cannot find obs-frontend-api.dll" error the bootstrap already tolerates -- libobs is the first subdirectory obs-studio's modern top-level CMakeLists.txt adds (well before UI), so libobs's own install(EXPORT ...) rules already completed by the time that later, unrelated install error aborts the script. macOS is unaffected (OBS_CMAKE_DESTINATION=lib/cmake there, matching the standard <prefix>/lib*/cmake/<name>*/ suffix), and so is Linux's libobs-dev (/usr/lib/<arch>/cmake/libobs/, same standard suffix). Fix: point libobs_DIR directly at the from-source Windows install when it exists, bypassing find_package's path-search heuristics entirely. Also fixed a secondary bug found while tracing this: the existing WIN32 locationless-OBS::libobs repair looked for obs.dll under "<deps>/bin" instead of the actual OBS_EXECUTABLE_DESTINATION, "<deps>/bin/64bit". Also make the Windows and macOS "Show what was built" CI steps hard-fail when the OBS adapter module is missing, instead of only printing a message. Several recent "green" Windows runs silently shipped a core-library-only build because of the bug above; nothing in CI caught it, only a human reading the raw log by hand. Left Linux untouched (its check is already a hard, non-"|| true" verification). Applied the same hard-fail treatment to macOS: its bootstrap has been reliably building the real module in CI (6/6 tests, per README), so there's no longer a known legitimate reason for a silent core-only fallback there either -- the documented macOS packaging/bundle-loadability gap is a separate, already-visible issue this check doesn't touch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 04:53:03 -07:00
shadowdaoandClaude Sonnet 5	969b8db94a	license: relicense first-party code from GPL-2.0-or-later to Apache-2.0 ... Owner sign-off: replace root LICENSE with Apache License 2.0, add a root NOTICE file, and swap the GPL-2.0 boilerplate header in every first-party core/ and obs-adapter/ source file for a short Apache-2.0 notice. This resolves review finding C2 (GPLv2 top-level LICENSE vs. the vendored Apache-2.0 LiveKit SDK is a license-compatibility violation): the whole repo is now Apache-2.0, matching LiveKit, so there's no GPL/Apache clash left. Updated the README Status gate and the CI workflow comment to reflect that C2 is resolved, while leaving the C1 WebRTC/OpenH264 patent/royalty gate untouched -- that question is still open and still blocks release. third_party/ stays under its own upstream licenses; only this project's own code changed hands. All 6 CTest suites still pass after the header swap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 04:44:16 -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	524e78c1a6	ci: write the Windows steps in PowerShell, not bash ... The core-only fallback and the "Show what was built" step were written with `shell: bash`. `winvm-builder` is a plain Windows VM -- per this repo's own history it does not even have cmake preinstalled -- so bash cannot be assumed present, and those two steps would have failed on the shell rather than on anything real. Both are PowerShell now, using $LASTEXITCODE and Test-Path. Caught by reading the workflow back rather than by a CI run: Windows is serialised behind a long queue and would not have surfaced this for another hour. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:31:17 -07:00
shadowdaoandClaude Sonnet 5	58f483250e	ci: repair a locationless OBS::libobs, and fall back loudly if the bootstrap fails ... Two things, one of which is an admission. The repair. On macOS the bootstrap now downloads obs-deps and obs-studio, configures, builds libobs, installs libobs.framework with its headers and libobsConfig.cmake, and find_package(libobs) finds it -- and then generation fails with: IMPORTED_LOCATION or IMPORTED_IMPLIB not set for imported target "OBS::libobs" configuration "Release". OBS 30.0.2 installs libobsTargets.cmake without the per-configuration libobsTargets-<config>.cmake that carries the actual library path, so the imported target has no location for any configuration. Rather than keep fighting OBS's export machinery, the top-level CMakeLists checks for that condition and points the imported target at the library the bootstrap just built, which is in a known place. Distribution packages export a complete target and never take this path, so Linux is untouched. The admission. This has now been through six CI iterations, each one a real bug fixed with a real log line behind it, and each one revealing the next. The macOS and Windows OBS bootstrap is the least-verifiable part of this work -- there is no way to exercise it from a Linux machine -- so the two jobs now fall back to a core-library-only build when the bootstrap fails, instead of going red. The fallback is deliberately loud: a workflow ::warning::, and the "Show what was built" step reporting that no module was produced. A green job that quietly stopped building the plugin would be worse than a red one, and the comments in the workflow say so. Linux is unaffected and fully green: real libobs adapter, ctest 6/6. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:25:59 -07:00
shadowdaoandClaude Sonnet 5	edb0c02be2	ci: restore the full OBS install, and stop passing a Windows SDK to -A ... Two more findings from the three-platform run, both from reading the actual CI logs rather than guessing. macOS. libobs now builds, installs, and is FOUND by find_package -- and then every consumer fails with: IMPORTED_LOCATION or IMPORTED_IMPLIB not set for imported target "OBS::libobs" configuration "Release". Restricting --install to the libobs subdirectory (the previous commit's fix for the obs-frontend-api install error) also loses the per-configuration export file, so libobsTargets.cmake lands without its libobsTargets-release.cmake sibling and the imported target has no location for any configuration. The install therefore goes back to the whole build tree, exactly as upstream does, with its exit code tolerated: it gets all the way through libobs and only then trips over the install rule of a target this build deliberately skips. If libobs genuinely did not install, find_package(libobs) in the top-level CMakeLists is where that surfaces, with a far better message than a half-installed tree. Belt and braces, the top-level CMakeLists also picks up obs-plugintemplate's CMAKE_MAP_IMPORTED_CONFIG_* fallbacks, so an imported target exported under a different configuration name still resolves. Windows. The sub-configure was re-entering obs-studio's OWN dependency downloader with a corrupted architecture: string sub-command JSON member 'hashes windows-x64,version=10.0.26100.0' not found Unable to download .../windows-deps-2023-11-03-x64,version=10.0.26100.0.zip Upstream passes "-A x64,version=<Windows SDK>", and with a current CMake that ",version=" suffix comes back out verbatim in the sub-build's CMAKE_VS_PLATFORM_NAME -- which obs-studio keys its release assets off. Plain "-A x64" now. The Windows SDK is selected automatically anyway ("Selecting Windows SDK version 10.0.26100.0" in the same log), and CMAKE_SYSTEM_VERSION is passed explicitly. The macOS job also lists the installed libobs export directory, so the next run answers "which target files actually landed" from CI output instead of inference. Linux remains green and unaffected: ctest 6/6. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:22:03 -07:00
shadowdaoandClaude Sonnet 5	7146f78831	ci: fix the three failures the first real three-platform run exposed ... Linux, glibc. The LiveKit SDK's "linux-x64" asset is not actually generic: it is built on Ubuntu 24.04 and needs GLIBC_2.38 and GLIBCXX_3.4.32, so linking it on a 22.04 runner fails outright ("undefined reference to std::ios_base_library_init()@GLIBCXX_3.4.32", "__isoc23_strtol@GLIBC_2.38"). That is exactly what happened when this repo's CI landed on the 22.04 Linux runner instead of the 24.04 one. LiveKitSDK.cmake now defaults Linux to the ubuntu-22.04 asset, which needs at most GLIBC_2.35 / GLIBCXX_3.4.30 (checked with objdump against both archives) and therefore links and runs on 22.04 and on everything newer -- the right floor for a plugin handed to directors as a binary. Linux, libobs version. The Linux job is pinned to ubuntu-24.04 rather than ubuntu-latest, which this instance's two Linux runners answer with different releases. 24.04's libobs-dev is 30.0.2 -- exactly the OBS version buildspec.json pins for macOS/Windows -- so all three platforms build against the same libobs. A 22.04 runner would have given OBS 27, a different API surface. macOS, no Xcode. The OBS sub-build failed its configure with "No CMAKE_C_COMPILER could be found": the template hardcodes the Xcode generator, and the `home-mac` runner has the Command Line Tools but no xcodebuild. The sub-build now uses Ninja (with an explicit CMAKE_BUILD_TYPE, since Ninja is single-config) and builds a single architecture rather than upstream's forced universal -- this plugin is single-arch anyway, because client-sdk-cpp ships single-arch dylibs, so a universal libobs would double the slowest step in CI for a slice nothing links against. While in there, generator flags are built as proper CMake lists so each becomes its own argv entry. Upstream packs several into one space-separated string and passes it unquoted, which execute_process hands to cmake as a single argument; it happens not to matter for the optional flags upstream passes, but it would silently swallow -DCMAKE_BUILD_TYPE. Also lowers the libobs API floor in the adapter: video_format_get_parameters instead of video_format_get_parameters_for_format. The _for_format variant only exists from libobs 30 onwards and only differs for the 10-bit formats (I010/P010) this source never receives, so using the older entry point keeps the module loadable on an older OBS -- the direction that matters, since OBS refuses modules built against a NEWER libobs than the one running. Re-verified locally on Ubuntu 24.04 with the ubuntu-22.04 SDK asset: ctest 6/6; the real-LiveKit integration test still reports "36 video frames, 323 audio frames, 10 state changes / 32 checks passed"; and the headless libobs harness still logs "connected to ws://127.0.0.1:7880 ... watching cam-test" followed by "video frame 640x360 I420" with the camera dropdown populated from the live slot list. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:08:03 -07:00
shadowdaoandClaude Sonnet 5	8494485351	ci: build the real OBS adapter on all three platforms ... Two things: unbreak the Windows compile, and give macOS/Windows a libobs. MSVC fix. test_json.cpp failed to compile on the Windows runner with "a universal-character-name specifies an invalid character" and "illegal escape sequence" -- MSVC still forms escape sequences and universal-character-names INSIDE raw string literals, which it must not. Every JSON input containing a backslash is now built by string concatenation from a single kBS constant, which also sidesteps the separate murky corner of translation phase 1 where a doubled backslash immediately followed by 'u' has historically been treated inconsistently. Same 158 checks, no behaviour change. OBS SDK bootstrap for macOS/Windows. Adopts obsproject/obs-plugintemplate's buildspec machinery -- buildspec.json plus cmake/common/buildspec_common.cmake and cmake/{macos,windows}/buildspec.cmake -- so those two platforms get a real libobs and build the actual plugin module instead of only the core library. Linux is untouched and still uses Ubuntu's libobs-dev (-DSTPLUGIN_BOOTSTRAP_OBS=OFF); the bootstrap only runs where there is no system package. Trimmed against upstream, each change recorded in the file that makes it: - qt6 is dropped from dependencies_list on both platforms. The properties UI is plain obs_properties_* and nothing here links Qt. - The OBS sub-build builds and installs the `libobs` target, not `obs-frontend-api`. Building the frontend API is what would drag Qt back in, and this plugin never calls it. - The sub-build is configured with ENABLE_UI=OFF and ENABLE_SCRIPTING=OFF as well as upstream's ENABLE_FRONTEND=OFF: the pinned OBS predates ENABLE_FRONTEND and gates its Qt-dependent UI on ENABLE_UI, so without this it configures the whole OBS UI and demands Qt anyway. - Only the Release configuration is built and installed, not Debug as well. Nothing consumes a debug libobs and it doubles the slowest CI step. - Only the dependency-acquisition modules are vendored. The template's compilerconfig/defaults/helpers/xcode modules drive its own target and bundle layout, which this project does not use. obs-studio is pinned to 30.0.2, deliberately low: OBS refuses to load a module built against a NEWER libobs than the one running it and accepts older ones, so this pin IS the minimum OBS version users need. 30.0.2 is also exactly what Ubuntu 24.04's libobs-dev ships, which puts all three platforms on one floor, and it supports the modern CMake layout the bootstrap drives via -DOBS_CMAKE_VERSION=3.0.0. prebuilt is obs-deps 2023-11-03 with the hashes obs-studio 30.0.2's own buildspec.json publishes; the obs-studio source archive hashes were computed from the GitHub tag archives. The workflow also prints what was actually produced on each platform (ldd / otool / dir over build/package) and uploads it as an artifact, so "does this even link against libobs" is answered by CI output rather than assumed. Verified locally: the Linux path is unchanged by all of this -- a fresh configure still finds libobs-dev, and ctest is 6/6. The macOS and Windows bootstrap can only be verified by CI; that is what this push is for. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 22:02:17 -07:00
shadowdaoandClaude Sonnet 5	304bc3ceba	ci: install cmake on the Windows runner before configuring ... First CI run confirmed winvm-builder is a self-hosted act_runner labeled "windows-latest" but not the GitHub-hosted windows-latest image -- cmake isn't on PATH there (unlike the Linux/macOS runners, which do have working system/brew package managers). Use lukka/get-cmake to fetch a pinned cmake+ninja without needing admin/choco. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-06 20:47:31 -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