Skip to main content

​
Simulcast a webinar with RTMP egress

Your webinar already runs on Orbit; RTMP egress is how the same broadcast also goes out on the platforms where your audience actually is. An RTMP egress takes the scheduled room’s composite video and pushes it, live, to an RTMP ingest that you own the credentials for: YouTube Live, LinkedIn Live, a corporate Vimeo account, or any self-hosted RTMP server. This guide walks the full lifecycle: provision the room, start one egress with several simultaneous destinations, stop it, and recover when a destination drops mid-show.

​
What RTMP egress is

An egress is one outbound live push attached to one scheduled video room. Orbit renders the room composite once (the same layout a recording would use) and streams it as a single adaptive-bitrate RTMP push to every destination you list on that egress. Each egress has its own id, so you can run several egresses on one room and stop any one of them without touching the others or the room itself. Two related surfaces are easy to confuse with it:
  • Recording writes the composite to a file in your storage bucket. It can run next to an RTMP egress on the same room; stopping one never stops the other. See Bring your own storage for recordings.
  • HLS/DASH playback is pull-based adaptive streaming for viewers Orbit serves. RTMP egress is the opposite direction: a push out to a third-party ingest you authenticate against, for audiences on platforms you do not operate.
An egress only pushes while the room is live, and nothing about it places a call or message; it is pure video out.

​
Prerequisites

Before the first request below, you need:
  1. A scheduled video room. The egress endpoints take the scheduled room id in the path. If you do not have one yet, follow Registration-gated video webinars up to the point where the room exists, then come back here.
  2. A broadcast destination for each platform. On each platform’s live encoder setup page, copy the ingest URL and the stream key. YouTube gives you rtmps://a.rtmp.youtube.com/live2 plus a key; LinkedIn and Vimeo hand you the equivalent pair. The URL must start with rtmp:// or rtmps:// and must include the ingest’s app path (the /live2 part), not just the host.
  3. An API key with the video:write scope, held by a user with the owner or admin role. Starting a public stream is deliberately restricted to the host tier; other roles receive a 403.
  4. A recording consent receipt, if your organization requires one. An RTMP egress leaves a persistent recording on the destination platform, so tenants in two-party-consent jurisdictions must pass recording_consent_receipt_id on the start call, exactly as the in-app recording paths do.
Keep stream keys secret. Orbit stores and echoes only the ingest URL, never the key, and the same discipline applies on your side: keys belong in your secrets store, not in client-side code or shared documents. Rotate them on the platform if one leaks; a revoked key is the most common reason a push fails.

​
Provision the scheduled room

RTMP egress never creates a room; it attaches to one. Create and schedule the room as usual (see Registration-gated video webinars) and note its id, for example room_9f2c below. The room does not need to be live when you start the egress; the push begins carrying content as soon as the room session is producing video.

​
Start an egress

POST /api/v1/video/rooms-scheduled/{id}/egress/rtmp starts one egress. The body splits each destination into rtmp_url and stream_key so the key is a clearly labelled secret field:
layout picks the composite layout the destinations receive: grid, speaker, single-speaker, picture-in-picture, sidebar, highlight, or gallery. It defaults to speaker, which is usually right for a webinar because it foregrounds the presenter. The response returns the egress id plus every destination URL without its key, so you can display them safely:
Store the egress_id; it is the handle for the matching stop call later.

​
Simulcast to several platforms in one egress

A simulcast does not need one egress per platform. Pass the first destination as rtmp_url / stream_key and the rest in additional_destinations; the composite is rendered once and fanned out to all of them inside the same egress, so three platforms cost one render, not three. You may add up to four additional destinations, five simultaneous destinations per egress in total, and one egress may not list the same URL-plus-key destination twice. The worked example below takes one scheduled webinar to YouTube Live, LinkedIn Live, and a corporate Vimeo account at the same time:
Each destination shows a moment of encoder latency before the platform marks the stream live; that is normal ingest behaviour, not a fault in the push. If you need more than five destinations, start a second egress on the same room; egresses are independent and each stops by its own id. You can also give an egress a backup destination (backup_rtmp_url + backup_stream_key, supplied together): if the primary ingest refuses the push at launch, the egress starts against the backup instead of failing.

​
Lifecycle: stop one egress

DELETE /api/v1/video/rooms-scheduled/{id}/egress/rtmp/{egressId} stops exactly that egress, including its whole fan-out when it simulcasts. The call is idempotent, and it leaves every other egress, the room, and any recording running untouched:
The platform side settles within seconds; YouTube and LinkedIn mark the broadcast ended and archive what they received up to that point. Across the room’s own lifecycle, egress follows the session: it pushes while the room session runs, and when the session ends Orbit stops any egress still running on it. The egress id from a finished session is not reusable; to simulcast the next session of the same scheduled room, start a fresh egress with the same call.

​
When an egress stops unintentionally

Three failures cover most incidents, and each has the same recovery: start a new egress with corrected destinations.
  1. The destination refuses the push at launch. Usually a mistyped or revoked stream key, or an ingest that was never armed on the platform side. The start call fails rather than leaving a half-live stream; if you supplied backup_rtmp_url / backup_stream_key, the egress transparently starts against the backup and your broadcast survives.
  2. The destination ends the stream mid-show. The platform rotated the key, an admin on the platform stopped the live event, or the account hit a platform-side limit. The egress reports the failed destination and stops pushing to it; verify the key on the platform, then POST a new egress to re-attach. Minutes you missed are not backfilled; live means live.
  3. The request was rejected before launch. A 422 at start is almost always one of these: the URL does not begin with rtmp:// or rtmps://; the URL is a bare host with no ingest app path (rtmps://a.rtmp.youtube.com/live2 is valid, rtmps://youtube.com is not); a backup URL was given without its key or vice versa; or two listed destinations are the same URL and key. A 403 means the caller lacks the owner/admin role or the video:write scope; a 503 means Orbit Media is not configured for the tenant, which your administrator enables.
In all three cases the room itself is unaffected: attendees in the room keep their session, and a recording keeps recording.

​
Monitoring and history

Three surfaces tell you what your egresses are doing:
  • The start response gives you the egress_id and the destination URLs (keys stripped), which is enough to drive a “live on” banner.
  • The room’s settings carry the active egress list: for each running egress, its id, ingest URL, start time, and who started it. Keys never appear there.
  • The session history records the outcome after the room ends. Each finished session’s record includes its media metrics and egress status, so “did the LinkedIn leg actually run” is answerable after the fact; see Video room history for reading that trajectory.
For viewer-side truth (concurrent viewers, watch time, chat), read the platform’s own dashboard; Orbit reports the health of the push, the platform reports the audience. Video engagement analytics covers the in-room side of the same event.