One connection in, every city out.

A channel is the thing that has an address; a broadcast is one session on it. Create it once and use it as often as you like — the watch address does not change between broadcasts.

curl -X POST https://dash.yunzheng.space/api/v1/stream/streams \
  -H "Authorization: Bearer $ORBIT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Sunday service"}'

The reply carries the stream key. It is shown once and cannot be read back — not by the API, not in the console, not by us. If it is lost, issue a new one.

Two fields in any broadcasting software that speaks RTMP: the server and the key. The connection is RTMPS — there is no plaintext port, because the key travels inside the publish command and a plaintext port would put it on the wire every time the software reconnects.

Server:  rtmps://ingest-<city>.edge.yunzheng.space:1936/live
Key:     osk_…

Both are in the console and in the reply that created the channel. From the command line the same thing looks like this:

ffmpeg -re -i input.mp4 \
  -c:v libx264 -preset veryfast -g 60 -c:a aac -ar 48000 \
  -f flv rtmps://ingest-<city>.edge.yunzheng.space:1936/live/$STREAM_KEY

Two forms, both from the playback identifier, which is a different string from the stream key. The key never appears in anything a browser requests.

https://live-<city>.edge.yunzheng.space/p/<playback id>            a page that plays it
https://live-<city>.edge.yunzheng.space/s/<playback id>/index.m3u8  HLS, for your own player

The city in the address is the one the broadcast is published to, not the one a viewer is in — a viewer is always answered by the city nearest them. Both addresses come back with the channel, so nothing has to be assembled by hand.

Playback is served from the same edge as every other hostname on the network, so a viewer is answered by the city nearest them and the broadcast is pulled across once per city rather than once per viewer.

Issue a new key at any time. By default the broadcast that is on air keeps running on the old key until it ends, and the new key is the one that works for the next one — so a key can be rotated in the middle of an event without taking it off the air.

curl -X POST https://dash.yunzheng.space/api/v1/stream/streams/<id>/key \
  -H "Authorization: Bearer $ORBIT_TOKEN"

Send {"revoke_now": true} to end the broadcast on air at the same time. That is the one to use if a key has leaked.

A channel says whether it is on air, since when, and in which city. Past broadcasts are kept as a record of when each one ran, how long, how much was published and how much was served, and how it ended.

curl https://dash.yunzheng.space/api/v1/stream/streams/<id>/sessions \
  -H "Authorization: Bearer $ORBIT_TOKEN"

A channel that cannot go on air says so on itself, in a sentence: a pack limit reached, or a key that has been revoked. The broadcasting software will only report that it could not connect, so the reason lives here.