6 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Opus 5	ab455a9cfe	docs: the macOS bundle was fine all along, and record the GUI verification ... Two corrections and one promotion, all from evidence rather than inference. 1. The "macOS packaging gap (known, unfixed)" section was WRONG, and it contradicted the release notes for the same build. It claimed the artifact is "a bare streamer-tools-camera.so" with a relative libobs install name that "will not load in OBS.app as it stands". Downloading and inspecting the shipped streamer-tools-camera-v0.1.0-macos.zip shows otherwise: - a proper streamer-tools-camera.plugin bundle -- Contents/MacOS/<name> is Mach-O MH_BUNDLE (what OBS loads), with Info.plist (BNDL, correct CFBundleExecutable), Contents/Resources/locale/en-US.ini, and both LiveKit dylibs in Contents/Frameworks/ - install names are right: the module loads @rpath/libobs.framework/Versions/A/libobs and carries LC_RPATH @executable_path/../Frameworks, which inside OBS.app resolves to OBS.app/Contents/Frameworks; @rpath/liblivekit.dylib resolves through LC_RPATH @loader_path/../Frameworks to the bundle's own copy, and liblivekit.dylib finds liblivekit_ffi.dylib through LC_RPATH @loader_path. Nothing points into a build tree. - all three binaries carry LC_CODE_SIGNATURE, which is not optional: arm64 macOS refuses to load unsigned code. The real macOS limitation is different and now stated: the bundle is arm64-only (no x86_64 slice), macOS 13+. Nobody has still ever opened it in OBS.app -- well formed and signed is a prior, not a load. 2. Linux and Windows are confirmed working in the OBS GUI: video and audio both arrive and hold up across a session, Linux by the project owner and Windows by two directors independently, and the plugin carried a live show on 2026-09-07. Since listing cameras requires an API call, that also retires "the WinHTTP backend has never run against a real streamer-tools server". Scoped, not inflated: MEASURED A/V sync and latency against the egress path are still unverified (no drift reported is not a measurement), as is mid-show publisher restart. The "Not verified anywhere" list is now deduplicated and says exactly that. 3. The CI table's Windows row still said "Failing, fix pushed and awaiting a completed run". It is green, after the WinHTTP deadline fix. Release notes template updated to match, and v0.1.0's published notes have been regenerated through it so the public page stops repeating the bare-.so claim. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9	2026-09-10 05:31:09 -07:00
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	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