[kimsun721]

Viewer SDK for browsers

Why

The viewer protocol was spoken only inside watch.html, and nothing in a browser spoke the relay side, so browser viewers never relayed.

Changes

• sdk/: @kimsun721/stream-viewer. Joins a room, plays it, follows simulcast layers, sends perf reports, reconnects with backoff, and has a debug log.
• A player on top of the core, styled through CSS custom properties.
• P2P relay, both sides. A relay forwards what it receives over a second peer link and reports relay_outgoing. A leaf answers the relay's offer and falls back to the server's stream on a lost link or demote.
• The relay re-encodes, so it holds its encoder near the bitrate it receives: a ceiling, plus a start and a floor in the leaf's answer. Chrome otherwise starts low and the server demotes the pair within seconds.
• A switch between the server's stream and a relay's keeps the old picture until the new source decodes a frame. A leaf whose relay goes silent for a second falls back without waiting for the connection state.
• The upload probe is left unanswered until the server measures upload itself, so the server does not promote a browser yet.
• /stream-viewer.js serves the SDK as one file, and /watch runs on it.
• CI builds and tests the SDK and fails when the served bundle drifts from the sources.
• sdk/e2e/: end to end scenarios that start a server and drive headless Chrome. sdk is left out of the docker build context.

Tested

• cd sdk && npm run check: 21 unit tests.
• cargo test.
• cd sdk && npm run e2e: headless Chrome against a release build, with a Chrome publisher sending three layers. Three runs.
  • watch: playback, layer picks, auto, idle and back, a room that is not live. 13/13.
  • relay, the probe answered by the test: pairing, no stall when the relay takes over, the pair holding 10 s, the relay leaving. 12/12. The leaf noticed in 1.2 to 1.3 s and its picture stood still 1.25 to 1.42 s, the rest being the server's keyframe from a publisher that answers requests at once.

Part of #87