295fdfb322
Wires the controller to the connection. Reports arrive on the bidi stream the client already holds, one a second; the worst of them across attached clients drives the decision, because one encoder serves them all and the client that cannot decode is the one that matters -- averaging its trouble away leaves it never recovering while the numbers look fine. Reports are *taken* rather than read, so a client that stops reporting stops looking healthy. A report describes the second that just passed, and acting on it again the next second is acting on evidence that has expired. The fallback path view comes from the selected path rather than the connection as a whole: a connection typically holds one route through a relay and one direct, and only the selected one says anything about where the media is going. A client setting the bitrate by hand stands the controller down, and setting a mode brings it back. Overriding a person's setting a second later would remove the only tool that finds this class of bug -- it is how the original report was shown to be wrong about the bitrate having been lowered. The controller's own commands carry no codec and no bit depth, which matters more than it reads: the far end rebuilds its video session for anything that might be either, and a rebuild costs a keyframe. Saying nothing it does not mean is what keeps a per-second adjustment free. And the counter is split. One video byte count could not distinguish an encoder ignoring its target from a stream that is mostly keyframes, and those have opposite fixes -- a session overshooting tenfold looked identical either way, which is why the cause stayed ambiguous for weeks. Keyframe bits, delta bits and keyframes per second now travel separately, alongside what the controller is asking for, the ceiling it is working within, and why. Appended to the stats packet, so an older reader keeps working on the part it understands. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
neshub
One connection out of the box.
Everything inside the guest that produces or consumes a stream talks to neshub over a Unix socket. neshub muxes it all into a single iroh QUIC endpoint and fans client input back the other way. A client dials that endpoint with a ticket and gets video, audio, cursor and stats on it.
The sockets
| socket | default | direction | carries |
|---|---|---|---|
--video-ipc |
/tmp/nestri-video.sock |
nescapture → neshub | encoded video frames |
--audio-ipc |
/tmp/nestri-audio.sock |
neswire → neshub | Opus packets |
--input-ipc |
/tmp/nestri-input.sock |
neshub ↔ nescope | input out, cursor and stats back |
--stats-ipc |
/tmp/nestri-stats.sock |
nescapture → neshub | encoder stats |
--screenshot-ipc |
/tmp/nestri-screenshot.sock |
neshub → nescope | a picture of the screen, on request |
--ticket-ipc |
/tmp/nestri-ticket.sock |
neshub → nesinit | the ticket, once |
| — | /tmp/nescapture-cmd.sock |
neshub → nescapture | IDR requests, encode settings |
neshub is the listener on every one of them and the other side dials in. That is deliberate: it removes the startup ordering problem entirely, since a producer that is not running yet simply has not connected yet.
The ticket
nestri:<base64 of {endpoint_addr, stream_name}>
Generated once per boot, when the endpoint binds. It is served on a socket
rather than printed because stdout here is a log file inside a virtual machine
and the person who needs it is outside one — nesinit reads it and carries it
to the host.
What it does not do
neshub does not start the payload, know its name, or decide when the box is
finished — nesinit owns all three, and shuts the VM down around this process.
The same neshub binary serves a game, a desktop, or anything else that draws to
nescope, because it never learns which one it is looking at.
Running it
cargo run --bin neshub # every socket at its default
cargo run --bin neshub -- --relay none # direct connections only
RUST_LOG=neshub=debug cargo run --bin neshub