docs: the macOS bundle was fine all along, and record the GUI verification #6

2026-09-10T12:31:26Z

jknapp commented

2026-09-10 12:31:26 +00:00

1. The macOS "packaging gap" was wrong

The README claimed the macOS artifact is "a bare streamer-tools-camera.so" with a relative libobs install name that "will not load in OBS.app as it stands" — and contradicted the release notes for the same build. Downloading and inspecting the shipped streamer-tools-camera-v0.1.0-macos.zip settles it the other way:

Proper bundle: streamer-tools-camera.plugin/Contents/MacOS/streamer-tools-camera 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 specific doubt in the old text. 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 its own LC_RPATH @loader_path. Nothing points into a build tree.
All three binaries are code-signed (LC_CODE_SIGNATURE, superblob 0xfade0cc0) — not optional, since 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+. Intel Macs can't load it regardless. And 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 in the GUI — including a live show

Video and audio both arrive and hold up across a session: Linux verified by the project owner, Windows by two directors independently, and the plugin carried a live broadcast on 2026-09-07.

Because listing cameras requires an API call, that also retires "the WinHTTP backend has never run against a real streamer-tools server, only the loopback test server".

Deliberately not inflated — still on the unverified list:

Measured A/V sync and end-to-end latency against the existing egress path. No reported drift is not a measurement, and the os_gettime_ns() timestamp caveat is exactly why numbers are wanted.
Whether a publisher restarting mid-show recovers cleanly on screen.
macOS in the GUI.

The "Not verified anywhere" list is also deduplicated — my earlier edit left two overlapping macOS bullets and two A/V sync bullets.

3. Stale CI row

The table still said Windows was "Failing, fix pushed and awaiting a completed run". It's green, after the WinHTTP deadline fix (PR #5).

Release notes

Template updated to match, and v0.1.0's published notes regenerated through it so the public download page stops repeating the bare-.so claim. Rendered locally before publishing; bash -n clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9

## 1. The macOS "packaging gap" was wrong The README claimed the macOS artifact is *"a bare `streamer-tools-camera.so`"* with a relative libobs install name that *"will not load in OBS.app as it stands"* — and contradicted the release notes for the same build. Downloading and inspecting the shipped `streamer-tools-camera-v0.1.0-macos.zip` settles it the other way: - **Proper bundle:** `streamer-tools-camera.plugin/Contents/MacOS/streamer-tools-camera` 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 specific doubt in the old text. 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 its own `LC_RPATH @loader_path`. Nothing points into a build tree. - **All three binaries are code-signed** (`LC_CODE_SIGNATURE`, superblob `0xfade0cc0`) — not optional, since 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+. Intel Macs can't load it regardless. And 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 in the GUI — including a live show Video and audio both arrive and hold up across a session: **Linux** verified by the project owner, **Windows** by two directors independently, and the plugin **carried a live broadcast on 2026-09-07**. Because listing cameras requires an API call, that also retires *"the WinHTTP backend has never run against a real streamer-tools server, only the loopback test server"*. Deliberately **not** inflated — still on the unverified list: - **Measured** A/V sync and end-to-end latency against the existing egress path. No reported drift is not a measurement, and the `os_gettime_ns()` timestamp caveat is exactly why numbers are wanted. - Whether a publisher restarting mid-show recovers cleanly on screen. - macOS in the GUI. The "Not verified anywhere" list is also deduplicated — my earlier edit left two overlapping macOS bullets and two A/V sync bullets. ## 3. Stale CI row The table still said Windows was *"Failing, fix pushed and awaiting a completed run"*. It's green, after the WinHTTP deadline fix (PR #5). ## Release notes Template updated to match, and **v0.1.0's published notes regenerated through it** so the public download page stops repeating the bare-`.so` claim. Rendered locally before publishing; `bash -n` clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9

jknapp added 1 commit 2026-09-10 12:31:27 +00:00

docs: the macOS bundle was fine all along, and record the GUI verification ab455a9cfe

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

jknapp merged commit 48a74e8c67 into main

2026-09-10 12:31:33 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: CyberCoveLLC/obs-streamer-tools-plugin#6