Short answer: Enhanced RTMP extends the RTMP/FLV message format so a compatible sender and receiver can signal newer codecs such as HEVC or AV1. The sender and receiver still need matching codec support. RTMPS is the TLS-protected transport variant. Confirm the current YouTube ingest specification before creating the event.
Start with the YouTube output contract
| Layer | Question to answer | Do not infer |
|---|---|---|
| Enhanced RTMP | Does the sender and YouTube ingest path support the required enhanced codec signalling? | That all RTMP receivers accept HEVC or AV1 |
| Video codec | Which codec, profile, resolution, frame rate and rate-control values does the destination currently accept? | That a codec choice is encryption |
| RTMPS | What secure ingest URL does YouTube provide for this stream? | That an unrelated RTMP Server accepts rtmps:// |
| Audience playback | What processing and rendition status does YouTube report after ingest? | That the contribution codec is the viewer's final rendition |
Before you create the output
Create or schedule the YouTube live stream, then copy its current server URL and stream key only into the destination configuration. Choose a source profile the destination documents. YouTube's encoder settings page is the authority for current codec, resolution, bitrate and protocol guidance; do not reuse a profile solely because it worked for a previous event.
Create the YouTube output
Create a Restream with the selected source binding and the YouTube destination URL/key. This is an output workflow: YouTube's destination settings govern that handoff. For the underlying control surface, see Restreaming and live video transcoding.
Choose a profile from the production
Work backward from YouTube's currently published ingest settings. Confirm whether the source already has the required codec or whether an output needs a supported transcode profile. Also check audio codec, keyframe cadence and rate control against the destination guidance. Enhanced RTMP carries codec-capability information; use the rehearsal to assess the actual output.
One concrete output choice
For an event that accepts it, 1080p30 H.264/AAC is a practical compatibility-first choice. Use HEVC with Enhanced RTMP when the current YouTube endpoint and the actual source/output support that route. In either case, check video profile, GOP/keyframe cadence, audio and the assigned endpoint before rehearsal.
Rehearse the audience path
- Start a private test with the exact source format.
- Confirm that Callaba sees the input and that the configured output connects.
- Check YouTube Live Control Room for the received stream state and warnings.
- Open the preview/audience path and check programme audio and video.
- Stop and restart the source once, then document the observed recovery procedure.
Diagnose by boundary
If the source is healthy but YouTube shows no ingest, recheck the copied server URL/key and output protocol. If YouTube receives a stream but rejects video, compare codec/profile and other encoder settings to its current specification. If ingest is healthy but the audience view is delayed or unavailable, inspect the YouTube event state and playback path rather than changing the RTMP source blindly.
References and next step
Use YouTube's live encoder settings and the Veovera Enhanced RTMP v2 specification as the configuration references. For a source that first publishes into Callaba, use RTMP Server, then configure the separate YouTube output.
