How to Set Up SRT Ingest for YouTube | Callaba

Before opening Callaba

• Use a YouTube channel that is eligible to live stream and an account permitted to manage its Live Control Room.
• Decide whether the first rehearsal will be private or unlisted. Do not make the first transport test the public event.
• Prepare a representative source with real motion and audio. A static slate can hide bitrate, keyframe, and sync problems.
• Keep the YouTube stream key, passphrase, and Stream ID out of screenshots, tickets, shared documents, browser recordings, and page source.
• Make sure the Callaba host can reach the destination and that any UDP port required by the incoming SRT leg is allowed by the cloud security group and host firewall.

Google's public Live Streaming API protocol comparison currently documents RTMP, RTMPS, HLS, and DASH for third-party ingestion; it does not list a generally available SRT endpoint. That makes the protocol selector in the actual channel—not an old screenshot—the deciding evidence. When SRT is unavailable, a common alternative is SRT from the field into Callaba, followed by a supported YouTube output from Callaba.

The fastest deployment path is the Callaba cloud launch guide. Teams operating their own infrastructure can use the self-hosted Linux installation guide. The media workflow is the same after the dashboard is available.

Part 1: create the YouTube SRT destination

Part 2: prove the contribution input in Callaba

Separating contribution from delivery makes troubleshooting much faster. The source sends to Callaba first; Callaba then sends a new output to YouTube. A source that already arrives through RTMP, SRT, a restream, or another supported Callaba module can be selected directly in the next part. When the source is SRT, create a named listener so its connection and media state remain visible to the operator.

1. Open SRT Servers and create a server with a name tied to the production, not a generic name such as “test.”
2. Choose the connection role that matches the sender. A common contribution layout is Callaba as Listener and the encoder as Caller.
3. Assign the approved publisher port and configure identity or access restrictions required by the production.
4. Save and start the server. Copy the publisher address into the encoder without publishing receiver details to the source operator.
5. Start the source and verify that the expected session connects. Confirm moving video, intended audio, sustained bitrate, and transport statistics rather than accepting “connected” as proof.

The SRT Server user guide covers the dashboard workflow. The Callaba SRT Server page explains monitoring, access control, failover, recording, and routing options around that ingest.

Part 3: create the separate YouTube output

1. Open Restreaming in Callaba and select Add New.
2. Name the restream after the destination and event, then select the input you proved in the previous step.
3. Choose the destination option for an SRT output URL.
4. Paste the complete URL supplied by YouTube. Recheck characters around the passphrase and Stream ID if the value crossed a chat application or formatted document.
5. Save and start the restream. Keep the input running while you wait for a preview in YouTube Live Control Room.

Do not add an arbitrary latency value simply because SRT accepts a latency parameter. Sender and receiver behavior, round-trip conditions, packet-loss profile, and the destination's accepted contract all matter. Begin with the exact endpoint YouTube supplied, test it, and change transport parameters only when both ends support the change and the production has a reason to make it.

For field-by-field dashboard guidance, continue with Restreaming in the Callaba user guide. Once the manual route is accepted, the Restream API create method can reproduce the reviewed configuration.

Run an acceptance test before the public event

YouTube recommends testing with audio and motion similar to the real stream and monitoring stream health during the event. Test long enough to include the failure modes that matter: an encoder restart, a brief network interruption, a Callaba output restart, and a check from the viewer side. Record which action restores each leg. “It reconnected once” is not an operating procedure.

Troubleshoot from the first missing signal

No session appears in Callaba

Inspect the encoder's SRT role, destination address, UDP port, firewall path, Stream ID, and passphrase. The YouTube configuration is downstream and cannot repair this leg.

Callaba receives the source, but YouTube shows no preview

Confirm the restream uses the intended input, is running, and contains the current SRT URL for the correct stream key. Recopy the URL if any secret was rotated.

YouTube reports incompatible media

Follow the current encoder guidance linked from Live Control Room. Check codec, resolution, frame rate, keyframe behavior, audio codec, and sample rate at the output that reaches YouTube.

The preview exists but is unstable

Correlate Callaba input statistics, output state, source encoder load, and YouTube's timestamped health messages. A clean contribution input and an unstable destination point to a different branch than packet loss arriving from the venue.

Use current YouTube guidance as the destination authority

YouTube changes Live Control Room and destination requirements independently of Callaba. Verify the production against YouTube's encoder workflow, current encoder settings and bitrate guidance, and the health messages shown for the live stream. This page intentionally avoids promising that SRT is enabled for every channel.