CyberCoveLLC/obs-streamer-tools-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

LiveKit integration: real camera feed pipeline #1

Merged
jknapp merged 17 commits from feat/livekit-integration into main 2026-09-07 06:06:50 +00:00
Conversation 0 Commits 17 Files Changed 43
+66 -18
2 changed files with 66 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 551f782d8a - Show all commits
.gitea/workflows/build.yml
+9
View File
@@ -9,6 +9,15 @@ name: Build
# bootstrap (buildspec.json + cmake/common/buildspec_common.cmake), which
# downloads the pinned obs-deps bundle and obs-studio source and builds just
# `libobs`. That step is the slow one: several minutes on a cold runner.
#
# RELEASE GATE: this workflow only builds, tests, and uploads CI-internal
# workflow artifacts (actions/upload-artifact, below) -- it does not create a
# Gitea Release, push a tag-triggered publish, or otherwise distribute
# binaries publicly, and it must not start doing so without explicit owner
# sign-off on the WebRTC/OpenH264 attribution and GPLv2/Apache-2.0
# license-compatibility questions tracked in third_party/livekit/README.md
# and the README's top-level Status section. If a real release/publish step
# is ever added here, it must carry that same gate.
on:
push:
README.md
+52 -13
View File
@@ -8,6 +8,20 @@ Media-Source path for directors. Full design:
## Status
**Release/distribution of built binaries is blocked pending owner sign-off.**
This plugin statically/dynamically pulls in Google WebRTC and OpenH264 code
through the LiveKit SDK, and this repository's own top-level `LICENSE` is
GPLv2 while the vendored LiveKit binaries are Apache-2.0 — both a real patent/
royalty question (OpenH264/WebRTC) and a real license-compatibility question
(GPLv2 vs. Apache-2.0-linked code) that only the project owner can decide.
Nothing in this repo should be built into a package and handed out, posted,
or attached to a public release until that sign-off happens. See
`third_party/livekit/README.md` for the specifics of what is and is not
currently known/shipped on the licensing side. (CI in `.gitea/workflows/build.yml`
currently only builds, tests, and uploads CI-internal build artifacts — it
does not create a Gitea Release or otherwise publish anything publicly; if
that ever changes, the new step must carry this same gate.)
The plugin is **functionally complete on Linux and verified end to end there**
(module loads into real libobs, connects to a real LiveKit server through the
real streamer-tools API shape, and pushes decoded frames into
@@ -15,7 +29,13 @@ real streamer-tools API shape, and pushes decoded frames into
It has **not been run in the OBS GUI on any platform.** macOS builds the real
module in CI but its artifact is not yet loadable (see the macOS packaging gap
under CI). Windows has not yet completed a build with the current fixes.
under CI). Windows CI has **failed on every completed run so far** (7
consecutive failures on this branch as of this writing); a run against the
commit with the `-A x64` argument fix is in progress but not yet complete,
and the commit with the PowerShell rewrite of the Windows steps is still
queued behind it. Neither fix has a completed, passing run yet. See "Where
the Windows bootstrap got to" under CI below for the exact record, and check
current CI status rather than trusting this paragraph's age.
See "What is verified, and how" below for exactly what has and has not been
checked, and "Testing this by hand" for what a human still needs to do.
@@ -173,7 +193,7 @@ livekit-server 1.13.6 in dev mode):
|---|---|
| The pinned LiveKit SDK links and is callable | `test_livekit_smoke`: `initialize()`/`shutdown()` round-trip, header version asserted equal to the CMake pin |
| The JSON reader handles real and hostile input | `test_json`, 158 checks, including truncated bodies, HTML error pages, binary garbage, lone surrogates, and a depth-limit case |
| The API client parses the real response shapes and every error branch | `test_api_client`, 121 checks, against a fake HTTP client **and** a real loopback HTTP server driving the actual platform backend |
| The API client parses the real response shapes and every error branch | `test_api_client`, 127 checks, against a fake HTTP client **and** a real loopback HTTP server driving the actual platform backend |
| A dead/stalled/garbage server cannot hang or crash the plugin | loopback cases: truncated JSON, connection closed with no reply, non-HTTP bytes, dead port, stalled server cut off by the client timeout |
| Session state transitions, track selection, frame geometry | `test_session`, 81 checks, plus real `connect()` failures against the real SDK |
| **Media actually flows** | `test_integration_livekit` against a real LiveKit server: 36 video frames + 323 audio frames, correct I420 geometry and plane pointers, publisher unpublish → `hasVideo()` false with **no further frames from the dead publisher**, republish → video resumes |
@@ -208,7 +228,7 @@ runners available to this repo under the `CyberCoveLLC` org.
|---|---|---|---|
| `linux` | `ubuntu-24.04` | `localhost.localdomain` | **Green.** Builds the real adapter against Ubuntu's libobs-dev 30.0.2, runs all six test suites, uploads `build/package` as an artifact |
| `macos` | `macos-latest` | `home-mac` (Global) | **Green.** Builds libobs 30.0.2 from source, then the real adapter; 6/6 tests; artifact uploaded. But see the macOS packaging gap below |
| `windows` | `windows-latest` | `winvm-builder` (org-scoped) | **Unconfirmed** — see below |
| `windows` | `windows-latest` | `winvm-builder` (org-scoped) | **Failing** — 7/7 completed runs on this branch have failed; see below |
The Linux job is pinned to `ubuntu-24.04` rather than `ubuntu-latest`: this
instance's two Linux runners answer `ubuntu-latest` with different releases,
@@ -282,11 +302,25 @@ attempted here rather than guessed at.
Windows is by far the slowest job — the `lukka/get-cmake` step alone takes
7-15 minutes on `winvm-builder`, and the runner serialises jobs, so a burst of
pushes leaves a queue that takes an hour to drain. One confirmed bug of its
own was found and fixed: upstream passes `-A x64,version=<Windows SDK>` to the
OBS sub-configure, and with a current CMake that `,version=` suffix reappears
verbatim in the sub-build's `CMAKE_VS_PLATFORM_NAME` — which obs-studio's own
dependency downloader uses as the architecture, sending it after
pushes leaves a queue that takes an hour to drain.
**The honest record: every completed Windows CI run on this branch has
failed. 7 consecutive failures**, at the 7 branch commits (in order) that had
a completed Windows run as of this writing -- all of them at commits before
the `-A x64` fix below was applied. As of this writing, a Windows run against
the commit with that fix is in progress but has not yet completed, and the
commit with the PowerShell rewrite is still queued behind it (the runner's
serial queue means fixed commits can sit behind older, unfixed ones for a
while). Do not read either fix below as "confirmed" until a Windows run
actually goes green on a commit that includes it; check current CI status
rather than trusting this paragraph's age.
Two bugs of its own were found and (believed, not yet proven) fixed:
1. Upstream passes `-A x64,version=<Windows SDK>` to the OBS sub-configure,
and with a current CMake that `,version=` suffix reappears verbatim in the
sub-build's `CMAKE_VS_PLATFORM_NAME` — which obs-studio's own dependency
downloader uses as the architecture, sending it after
`windows-deps-2023-11-03-x64,version=10.0.26100.0.zip`:
```
@@ -294,8 +328,13 @@ string sub-command JSON member 'hashes windows-x64,version=10.0.26100.0' not fou
Unable to download .../windows-deps-2023-11-03-x64,version=10.0.26100.0.zip
```
Plain `-A x64` now. **No Windows run has yet completed with that fix in
place**, so Windows should be treated as unverified beyond "the core library
and the WinHTTP backend compile and their tests pass", which earlier runs did
show. Expect further iterations there of the same kind the macOS bootstrap
needed.
Plain `-A x64` now.
2. The Windows CI steps were originally written in bash (via
`shell: bash`), which is a poor fit for a `windows-latest` runner's
default toolchain expectations; they were rewritten in PowerShell.
Until a Windows run completes green with both fixes in place, Windows should
be treated as unverified beyond "the core library and the WinHTTP backend
compile and their tests pass", which earlier (failing-job) runs did show
before failing later in the job. Expect further iterations there of the same
kind the macOS bootstrap needed.