4 Commits

Include renames

Author	SHA1	Message	Date
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