57abdb9663
Three additions, all of them plumbing for a bitrate that something actually decides. `BootDescriptor` gains `VideoLimits`. It rides the boot document rather than a kernel command line because `nesinit` handles `Boot` by mounting and *then* bringing the stack up, so the value is in hand before `neshub` is spawned -- no parsing, no window where the service is running without its configuration. It is on the descriptor rather than a launch because its consumer is a service that comes up with the box; geometry went the other way for the same reason, its consumer being started per launch. `bitrate_kbps` is an `Option` and the distinction is load-bearing. "Nobody said" is not zero and is not unlimited, and a reader that conflates the first with the last reproduces the bug exactly: every session offered 10 Mbps because no number had ever been chosen and the encoder's own default stood in for one. `neshub` now says which it got, and falls back to something modest rather than to whatever it finds. Note what `deny_unknown_fields` means here, since it is deliberate: a host that sends `video` to a guest too old to know the field is refused rather than quietly served. That is the right direction to fail -- the alternative is a box that boots, streams, and ignores its ceiling -- and it means the guest image is rebuilt before a host starts sending one. `MSG_RECEIVER_REPORT` carries what a second looked like from the far end: goodput actually released to the decoder, frames released, incomplete and never-arrived, and the receiver's own RTT. The hub cannot work any of this out for itself. Its own view was measured saying the path was healthy while almost nothing was arriving, and one reason is structural -- `send_datagram` evicts the oldest queued datagrams and returns `Ok`, so the send side has no backpressure signal at all. `MSG_CONTROL_MODE` says who is choosing the bitrate. Manual exists because it is how this class of bug gets found: the original report said the bitrate had already been lowered, and the only way anyone established otherwise was by setting one by hand and watching the picture come back. Both decoders refuse what they cannot read rather than guessing. `loss()` returns `None` for a second that accounted for no frames at all, because a second with nothing sent and a second with nothing arriving are indistinguishable from there, and answering either 0% or 100% would tell a controller something nobody knows. 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