UNI Universal Natural Intelligence

Wiki · The Colony & the Method

Broadcast re-architecture — composition outside OBS (workflow-verified plan)

The Colony & the Method · docs/BROADCAST_REARCHITECTURE.md @ 44baf03d5041 (gen2-runtime) — opens the published snapshot ac338733bbba

How to read this page

Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.

Eighty-four pages about the colony. Each agent is an Elixir process holding a generative model and doing inference, attached to a body that logs into a Minecraft world as an ordinary player. Around that sit the broadcast suite that films them and the runbooks that keep the whole thing running. There are typed specifications for each organ of the model, plus the world and genome specs. There are also the adversarial review personas used to attack a proposed change before it ships.

It is for the reader curious how a running system is put together and how it is held to account. The accountability half is the more distinctive. There is a lab protocol governing evidence and attribution, and a claim fence that restricts the vocabulary a claim is allowed to use. There is a public gate log. And there is a standing invitation to reproduce any verdict from the commit and the seed named in its receipt.

Start with the public read, then the lab protocol, then the falsification invitation. If you want the mathematics rather than the operations, go straight to the typed organ specs.

What it is not: a description of a mind, and not all one kind of document. A large part of this corpus is design and planning — specs marked as proposed rather than applied, organs designed but not built, plans that were later superseded — and each page states which it is. A specification is not a running system, and these pages are careful about the difference; the reader should be too. Eight documents were withheld from publication because they describe private infrastructure.

Your browser cannot switch reading levels, so the document itself is shown.

Precise — the source document

This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.

Problem: OBS's dual-GPU CEF can't composite multiple web feeds (renders black/crashes). Fix (operator's insight, validated): composite ALL feeds + frame in ONE real-GPU Chrome page; feed that single composite to a dumb encoder. Scene control lives in HTML/JS, not OBS.

Validated on the box: the composite page renders in one real Chrome; the :8080 UNI.OS appliance glass (black in OBS CEF) renders fully. Router CSP already patched (router.ex → content-security-policy: base-uri 'self', no frame-ancestors) so the HUD :4000/stream frames.

Recommendation — PHASED HYBRID

  • Phase 1 (now, <2-min cutover, stream never stops): OBS = dumb encoder doing ONE WGC Window Capture (method:2 — not gdigrab, which returns blank for GPU-composited Chrome) of the single /broadcast Chrome window. Keep the existing rtmp_custom YouTube output + x264 + the looping Soundtrack source. Single-source swap on the live scene → instant rollback.
  • Phase 2 (after 24–48h burn-in, portable to the appliance): drop OBS — headless Chrome (--headless=new) + CDP Page.startScreencast → one ffmpeg (h264_nvenc, T1000 NVENC present) that loops album_full.m4a and pushes RTMP. Window-less, occlusion-proof, ports to headless Linux.
  • The /broadcast page is identical across both phases — build it first.

The composite page (/broadcast, 1920×1080, served same-origin from Phoenix :4000)

  • #wa left 44,206 896×504: prismarine cam :3020 (hero) — iframe 1920×1080 scale(0.46667).
  • #wb right 980,206 896×504: UNI.OS appliance :8080 — same scale.
  • #wc full-stage 0,0 1920×1080: HUD :4000/stream (transparent, pointer-events:none) over all.
  • Top layer: title / LIVE pulse / feed tabs / lower-third / brand, inlined from broadcast_frame.html.
  • <title>UNI.OS Broadcast</title> (matches obs_capture.cjs WINDOW string). Scene cuts = in-page JS.

Build plan

  1. Write ui/priv/static/broadcast.html (the spec) — same-origin so the HUD LiveView socket carries its session, and so Phase-2 headless loads it over http (not file://). Add a /broadcast route or Plug.Static entry (priv/static isn't auto-served unless whitelisted).
  2. Smoke-test in REAL Chrome FIRST — the go/no-go gate for the cam. Launch: chrome --user-data-dir=...\chrome-broadcast --app=http://127.0.0.1:4000/broadcast.html --window-size=1920,1080 --force-device-scale-factor=1 --autoplay-policy=no-user-gesture-required --ignore-certificate-errors --allow-running-insecure-content --disable-features=CalculateNativeWinOcclusion --enable-gpu-rasterization --ignore-gpu-blocklist. Verify the prismarine cam PAINTS (if black here it's black headless too).
  3. Pin Chrome to the T1000 (Windows Settings → Display → Graphics → chrome.exe → High performance); confirm chrome://gpu = hardware-accelerated. (Dual-GPU SwiftShader fallback is the cam's #1 risk.)
  4. Add audio to the live scene BEFORE cutover: obs-websocket CreateSceneItem "Soundtrack" → "Migration Pro" and the new "Broadcast" scene (it's currently only on Colony Live / Mind Cockpit).
  5. Phase-1 cutover: viewer/obs_capture.cjs (WGC capture of the window, stretched 1920×1080, set current). No StopStream, same RTMP session. Fallback: pin Chrome+OBS to the same GPU; ddagrab last.
  6. Burn-in 24–48h with the old CEF sources hidden (instant rollback); then RemoveInput them. 7–10. Phase 2: broadcaster.cjs (puppeteer-core headless + CDP screencast) → ffmpeg -c:v h264_nvenc -rc cbr -b:v 5M -g 60 -no-scenecut 1 ... -c:a aac -ar 48000 (album is 48kHz!) → rtmp://a.rtmp.youtube.com/live2/<KEY from env>; dry-run to a file + ffprobe (≈2s keyframes) before cutover; supervise with NSSM/while-loop + nightly restart for the Chrome renderer leak.

Gotchas the adversarial pass caught (real, on this box)

  • gdigrab is dead for GPU Chrome (blank GDI DC). WGC (Phase 1) / CDP (Phase 2) read the GPU swapchain.
  • :8080 is http→https 301 with a self-signed cert → needs --ignore-certificate-errors --allow-running-insecure-content (or reverse-proxy through Phoenix).
  • Soundtrack missing on the live scene — a naive swap drops music; add it first.
  • -ar 48000 (album is AAC 48kHz); -stream_loop -1 on AAC clicks every loop → pre-transcode to WAV.
  • ffmpeg 8.0: use -f mjpeg -framerate 30 -i pipe:0, not image2pipe; add ffmpeg.stdin.on('error').

sha256 4ff031f238a05e21 — of the original file, so what was ingested stays checkable.

Plain — written for this website, not the source document

Written for this website — not the document. This is a plain-language retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. (or choose Precise in the reading-level control above)

This is a plan, not a finished build. It describes a change to how a live video picture is put together, and it is written as a recommendation with two phases.

The problem is simple. The broadcasting software cannot draw several web pages at once on this particular machine; it renders black or falls over. The proposed fix is to move the whole job somewhere else. Build the entire picture, including the frame around it, inside one ordinary browser page. Then hand that single finished picture to the encoder as if it were any other window. Scene changes then happen inside the page rather than in the broadcast software.

The first phase keeps the existing encoder and simply points it at that one window, so the stream never stops and a rollback is one step. The second phase, after a burn-in period, drops the broadcast software entirely in favour of a headless browser feeding a command-line encoder.

The page ends with a list of specific traps found by testing on the actual machine.

Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 4ff031f238a05e21

Clear — written for this website, not the source document

Written for this website — not the document. This is a clearer retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. (or choose Precise in the reading-level control above)

This document is a phased plan for rebuilding how a live picture is composed, written after testing the idea on the actual machine. It states the problem, the fix, what was checked, a recommendation in two phases, a build order, and a list of traps.

The problem: on a computer with two graphics chips, the broadcast software cannot composite several web feeds at once. It renders black or crashes. The fix, credited to the operator, is to stop asking it to. Instead, compose every feed and the surrounding frame in a single browser page running on the real graphics chip, and give the broadcast software one job it can do: capture that one window and encode it. Scene control moves into the page itself.

A short section records what was checked on the box rather than assumed. The composite page renders in a real browser, and a panel that came out black inside the broadcast software renders fully. A security header on the serving side was already adjusted so that another surface can be embedded in a frame.

The recommendation is a hybrid. The first phase changes almost nothing: the broadcast software becomes a dumb encoder capturing one window using a specific capture method, because the older method returns a blank picture for a browser drawn on the graphics chip. The existing output, encoder and looping soundtrack stay. Because it is a single-source swap on the live scene, rollback is instant and the stream never stops. The second phase, after a burn-in period, removes the broadcast software altogether: a headless browser streams frames over a debugging channel into a command-line encoder that also loops the audio and pushes the stream out. That version has no window to occlude and carries over to a headless machine. The page notes that the composite page itself is identical in both phases, so it is built first.

A layout section then describes the composite page precisely. A hero camera on the left, an appliance view on the right, and a transparent overlay across the whole stage that ignores the mouse. On top, a layer carrying the title, a live indicator, feed tabs and branding. The window title is chosen to match what the capture script looks for.

The build order is numbered, and step two is called the go or no-go point: launch the page in a real browser and check that the camera actually paints, since a black picture there will be black later too. Other steps cover pinning the browser to the faster graphics chip, adding audio to the live scene before the switch so a naive swap does not drop the music, the cutover itself, the burn-in, and the second-phase work.

The final section lists traps an adversarial pass caught on this machine. A capture method is dead for browsers drawn on the graphics chip, and a redirect and a self-signed certificate need specific flags. Audio is missing on the live scene. An audio sample rate and a looping click call for pre-conversion, and a command-line option changed in a newer encoder version.

Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 4ff031f238a05e21