Origin CPU
Current · % of one core
The listening room / Deja Vu
Turn it up.
Deja Vu Ambient Sunrise Mix. Original 4K. Sound on. Your browser can help the next person hear it.
The same broadcast, through your native media servers. Measure the origin and the player separately.
Local media comparison
Licensed full broadcastReady to measure
Same source. Your machine.
Choose a server and run the comparison.
—Checking the room…
The complete 4K mix. Press play, put your headphones on, and watch the stream move.
Choose your run
Select a locally installed server to see its version.
Same source and offset for every run. Switching servers starts a fresh measurement. The origin and the publisher have separate CPU and memory readings.
Playing shares video segments with other viewers. Pause to leave the audience and stop sharing. The ticker stays live while you browse.
The first listener starts the room. New arrivals join at its live position. After the last listener leaves, it closes following a short grace period. The 1080p excerpt has its own room.
This is happening in your browser
Watch the stream move.
Measured hereListener reportGlow follows the music
Moving dots carry video. Larger dots carry more.
Ready to play. The origin gets you started.
- From media host
- 0 B
- Verified from viewers
- 0 B
- Media sent by you
- 0 B
- Listeners here
- — 0 connected to you
Totals for this playback. Peer downloads count only complete, verified video segments.
Connection details Rates and reported paths
What joining means
RelaySwarm uses public Nostr relays to find viewers, then WebRTC to exchange verified media. Connected peers can see one another's network addresses. Sharing uses up to 4 MiB/s of upload, 1 GiB per playback session and a 64 MiB media cache. The room shares temporary listener handles and media-transfer readings so you can see its activity. Dashed links are listener reports. Pause or close the page to stop sharing. Your player keeps the origin available whenever peers can't help.
The origin and publisher have separate process readings. Compare the same source, profile, transport and source window.
Look closer at playback Frames, buffer and timing
Measured during this run
The cost. The picture.
Dashes mean no observation is available. No live process readings are taken on the public site.
Origin memory
Current process RSS
Decoded frame rate
Browser video dimensions
Click → first frame
Includes local server startup
Browser playback
- Playback engine
- —
- Peer engine
- —
- Video time
- —
- Shared clock offset
- —
- Playable buffer
- —
- Stalls after first frame
- —
- Time stalled
- —
- Media response bytes
- —
- Media resource requests
- —
- Observed player / HTTP errors
- —
Origin HTTP
- Response body bytes
- —
- Requests / completed / active
- —
- Origin request hops / redirects
- —
- Request errors
- —
- Current response rate
- —
- First byte · p50 / p95 / p99
- —
- Response · p50 / p95 / p99
- —
- Origin uptime
- —
| Process | Current CPU · one core | CPU seconds | Current RSS | Peak sampled RSS |
|---|---|---|---|---|
| Origin / media server | — | — | — | — |
| Publisher / FFmpeg | — | — | — | — |
| SRT sender | — | — | — | — |
| Viewer packet relay | — | — | — | — |
Recorded local comparisons Versions, source and measurements
Keep a fair comparison
Completed runs, side by side.
| Server / version | Ingest | Viewer relay | Window | Mean sampled origin CPU | Peak sampled RSS | First frame | Mean decoded FPS | Stalls |
|---|---|---|---|---|---|---|---|---|
| Complete a local run, or open a published receipt, to put real measurements here. | ||||||||
Rows cover completed source windows at offset 0. Browser playback can lag behind ingest; downloads retain the actual video time and decoded frames. Compare the same source, profile and window on the same host. Stopping early leaves the table untouched; no winner is inferred from a single run.
An audience that can give something back
Your audience can carry the stream.
Every viewer normally asks the server for another piece of video. RelaySwarm lets a browser supply a piece it already has to another listener. The counters above show whether that is happening in this session.
- The origin starts it.Your encoder publishes to Sapflow. Sapflow packages the media as HLS for your player. This public mix is a recording served as HLS from the media host.SRT / RTMP → HLS
- The audience can help.Viewers find each other through Nostr relays and exchange video directly with WebRTC. Every received segment is checked before it reaches the player.RelaySwarm / verified bytes
- The music keeps going.No useful peer, or a missed deadline? The player returns to the origin. Your application can add Spry TURN for networks that need a relay.Origin fallback / optional TURN
Build with it
Your stream.
Your stack.
Keep the encoder and player you already know. Put a small Rust origin behind them, add peer delivery where it helps, and run the pieces on infrastructure you control.
Sapflow
RUST / ORIGIN + MEDIA LIBRARIESFrom your encoder to the browser. Receive SRT or RTMP, package Low-Latency HLS and keep an MP4 recording. Run the native server or embed the media core.
RelaySwarm
WEBRTC / EXPERIMENTAL BROWSER LIBRARYPut viewers in the delivery path. Exchange verified HLS segments over direct browser connections, with a bounded peer attempt before normal HTTP fallback.
Spry TURN
NATIVE RUST / UDP + TCP + TLSConnect peers across awkward networks. Run a small standalone TURN server or embed the Rust library. Shared-secret credentials and bounded resources are built in.
MIT-licensed projects with their own dependency notices. The public listening room uses direct peer connections with origin fallback. The local comparison can exercise Spry and coturn with the same media.
Measured on Apple M4 Max
Give the server
some room.
We run the same workloads against the alternatives and publish the conditions. Bring your stream and measure the trade-offs on your own machine.
Read the benchmark reportless origin CPU
Sapflow's optional HTTP loop against MediaMTX 1.21.2 at 750 simulated viewers.
less process memory
26.4 MiB peak RSS against 276.7 MiB in the same Sapflow viewer trials.
more UDP packets per second
Spry 0.2.1 against coturn 4.18.0. TLS delivered 27–35% more packets per second.
Native ARM64 M4 Max measurements, 23 October 2026. Sapflow's figures use a dated development snapshot with its optional 16-worker HTTP loop. Spry's figures cover six loopback workloads per transport. These are separate tests; the report includes source versions, configuration, platform differences and every result.
Try it with your stream
Make it part
of what you build.
Start with Sapflow, add RelaySwarm to your HLS player, or compare the native servers with a recording you already have.