6 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5	d9f73926e4	feat(release): publish releases directly, and fix the install path in the notes ... Releases were created as drafts for one stated reason: nobody had run the plugin in the OBS GUI on any platform, so a human had to look before anything became visible. The first confirmed GUI load (Windows, OBS 32.2.2 on Windows 11, 2026-09-09) retired that gate, so `publish-release.sh` now posts `"draft": False` and the workflow no longer needs a human click. The caveats did not go away, they moved: the generated release notes now lead with what is actually confirmed (module loads and registers its source type, Windows only) and what is not (video rendering, A/V sync, latency, mid-show publisher restart, Linux and macOS in the GUI at all), and the per-platform table carries the rest. Also fixes the third and last copy of the wrong Windows install path. The release notes template told every downloader to extract into `%APPDATA%\obs-studio\plugins\`, which on Windows is OBS's config directory and is never scanned for plugins -- that is what stopped a director's correctly-shaped install from loading. The notes now carry a per-platform table (`C:\ProgramData\obs-studio\plugins\` on Windows), the exact finished path, a warning about Explorer's "Extract All..." wrapper folder, and how to confirm the load in the OBS log. Both failure modes are silent, which is precisely why they belong in the notes. Note the tradeoff now that nothing is held back: assets upload after the release row is created, so a release is briefly visible with no files attached. Called out in the script header. Verified by rendering the heredoc with a stub tag: backslash escaping survives into correct markdown, and the YAML parses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9	2026-09-09 16:50:44 -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	43a501c06c	release: package archives as direct drop-ins to OBS plugin dirs ... Previously each release zip mirrored build/package/ verbatim (bin/ + data/ at the archive root), which needed a manual mkdir + cp -r into the right OBS plugin subdirectory per the install instructions. Wrap Linux and Windows archives in a top-level streamer-tools-camera/ directory instead -- matching AddExtraModulePaths()'s expected <config>/obs-studio/plugins/<name>/bin/64bit + data layout -- so `unzip -d ~/.config/obs-studio/plugins/` (or Expand-Archive to %APPDATA%\obs-studio\plugins\ on Windows) is the entire install step. macOS already produced the right shape (the .plugin bundle itself at the archive's top level, since OBS wants the whole bundle directly under plugins/, not nested under a named subdirectory) -- no packaging change needed there, just an install-instructions rewrite plus making that text properly conditional on MACOS_BUNDLE_FOUND like MACOS_NOTE already was, since the old hard-coded "not yet that bundle shape" text was stale once the macOS bundle packaging fix landed. Verified locally: staged a fake build/package/ tree, ran the new packaging logic, and confirmed extracting the resulting zip into a plugins directory produces <name>/bin/64bit/... and <name>/data/... directly. Also dry-ran publish-release.sh's notes generation for both MACOS_BUNDLE_FOUND values to confirm the conditional install text renders correctly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 08:41:44 -07:00
shadowdaoandClaude Sonnet 5	14fa00af3f	docs: OpenH264/MPEG-LA royalty finding sharpens C1 -- not resolved ... Cisco's own OpenH264 FAQ (openh264.org/faq.html) is explicit: they cover MPEG-LA/AVC patent-pool royalties only for their own prebuilt binary, downloaded at install time. Anyone who compiles OpenH264 from source and redistributes it inside their own binary takes on "all applicable license fees" themselves -- Cisco "will not be liable for any licensing fees incurred by other parties" in that case. LiveKit's client-sdk-cpp links Google libwebrtc via the webrtc-sdk org's fork, whose documented build args (rtc_use_h264=true, ffmpeg_branding="Chrome") are the standard Chromium/WebRTC recipe -- which links a from-source, statically-compiled copy of OpenH264 (from Google's mirror, not Cisco's runtime binary) into libwebrtc. That is exactly the shape of case Cisco's FAQ says voids their coverage. Not independently confirmed against LiveKit's actual pinned v1.10.1 build (their release archives ship only compiled output, no build manifest) -- this is webrtc-sdk/libwebrtc's documented default, not a verified fact about this specific artifact. This sharpens C1 into a concrete mechanism instead of a general open question. It does not resolve C1 -- if anything it strengthens the case for treating it as unresolved -- and none of this is a substitute for an actual legal opinion. Recorded in third_party/livekit/README.md (the full writeup), README.md's Status section, and the release-notes template in publish-release.sh so it reaches whoever opens a draft release next, not just this one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 07:45:36 -07:00
shadowdaoandClaude Sonnet 5	b5c91c72e5	macOS: real .plugin bundle packaging, libobs @rpath fixup, hard-fail CI check ... Closes the "macOS packaging gap" documented in README.md: CI built a real adapter module on macOS but staged it as a bare streamer-tools-camera.so, which OBS.app cannot load (it needs a <name>.plugin bundle), and otool -L showed the libobs dependency as the relative path libobs/libobs.framework/Versions/A/libobs instead of an @rpath reference. cmake/macos/helpers.cmake adapts (not vendors as-is) obs-plugintemplate's cmake/macos/helpers.cmake: upstream builds the bundle almost entirely through XCODE_ATTRIBUTE_* properties and its own CI drives that with `xcodebuild -project <name>.xcodeproj`, but this project's home-mac runner has only the Command Line Tools, not Xcode.app (already established by buildspec_common.cmake's CI-iteration-1 comment), and the whole project builds with Ninja end to end. So this reimplements the same outcome -- Contents/MacOS, Contents/Resources, a real Info.plist -- with CMake's own generator-agnostic BUNDLE/BUNDLE_EXTENSION/MACOSX_BUNDLE_INFO_PLIST/ MACOSX_PACKAGE_LOCATION target properties (verified working under Ninja via a dry-run configure with APPLE spoofed), and does by hand what upstream gets from Xcode's embed/codesign build phases: - copies obs-adapter/data/** into Contents/Resources/**, since OBS's AddExtraModulePaths() (UI/window-basic-main.cpp) passes Contents/Resources as a macOS module's *data path* -- not a sibling data/ the way Linux/Windows work -- so the locale ini has to land at Contents/Resources/locale/en-US.ini for OBS_MODULE_USE_DEFAULT_LOCALE to find it - copies the LiveKit runtime dylibs into Contents/Frameworks - fixes up the libobs dependency: cmake/macos/fixup-libobs-rpath.sh rewrites the relative install name the from-source libobs build records to @rpath/libobs.framework/Versions/A/libobs (LiveKit's own dylibs already record @rpath references, confirmed in prior CI otool -L output, so only libobs needs the rewrite) - gives the plugin binary two LC_RPATH entries via INSTALL_RPATH: @loader_path/../Frameworks (this bundle's own Frameworks, for LiveKit) and @executable_path/../Frameworks (OBS.app/Contents/Frameworks, for libobs.framework -- @executable_path is always relative to the host process's main executable, not this dlopen'd bundle) obs-adapter/CMakeLists.txt: calls stplugin_macos_finalize_bundle() before staging, and corrects the staged layout for macOS -- OBS's module search wants the whole <name>.plugin dropped directly into .../obs-studio/plugins/, not nested under a bin/ subdirectory the way Linux/Windows are, so build/package/ now holds the bundle at its own top level on macOS instead of build/package/bin/<name>.plugin. .gitea/scripts/macos-build.sh (this project's macOS steps were factored out of build.yml into this shared script, used by both build.yml and release.yml, in a concurrent commit -- rebased onto that): the "Show what was built" section now hard-fails unless a real .plugin bundle (with Info.plist, bundled LiveKit dylibs, and locale data) was produced, the libobs dependency resolves via @rpath rather than the old relative path, and both LC_RPATH entries are present -- closing the same false-positive-green gap this project's Windows find_package(libobs) incident just exposed, which this check previously did not cover (it only checked for a bare .so). release.yml's macOS packaging step already globs for any `*.plugin` under build/ (added in the concurrent commit, anticipating this fix), so it picks up the new layout with no change needed. Verified: Linux configure/build/ctest (STPLUGIN_BOOTSTRAP_OBS=OFF) still passes 6/6, unaffected -- the new macOS CMake logic is fully guarded by if(APPLE). The bundle/Info.plist/Resources-mapping logic itself was dry-run verified by configuring a throwaway CMake project with APPLE spoofed to TRUE, confirming buildspec.json values substitute correctly into Info.plist and obs-adapter/data/locale/en-US.ini maps to Resources/locale/en-US.ini. Not verified: an actual macOS build/link/otool pass, or loading the result in real OBS.app -- this is a Linux sandbox with no way to do either: this commit is going to the home-mac CI runner to get that verification next. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:16:57 -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