To send one FFmpeg programme to YouTube’s primary and backup ingest addresses, use the tee muxer with two destinations and explicitly map the audio and video streams. Fetch both URLs for the actual stream from YouTube; for RTMPS, use its separate RTMPS addresses rather than changing the scheme on an RTMP URL.
This sends two copies towards YouTube at the same time. It does not, by itself, guarantee that viewers will switch seamlessly between them if one feed fails. Treat it as redundant ingest to test, not a promise of viewer-side failover.
What primary and backup ingest addresses do
YouTube provides a primary ingestion address and a backup ingestion address for a live stream. They are destinations for encoder output. The YouTube LiveStreams API describes the corresponding fields as ingestionAddress and backupIngestionAddress; the stream resource also includes a streamName, which is the key-like part used to identify the stream. For RTMPS there are separate rtmpsIngestionAddress and rtmpsBackupIngestionAddress fields. See the LiveStreams resource documentation rather than copying an address from an old tutorial.
A conventional encoder may offer separate boxes for the server URL and stream key. With FFmpeg, you will normally assemble the full destination in the form expected by the protocol and your encoder invocation. YouTube documents that the URL and stream name can be entered separately or combined as STREAM_URL/STREAM_NAME. Use the values shown for the event you are configuring, and follow the format in the current YouTube interface or API response.
The backup address is intended to accept the same content concurrently with the primary. That makes it possible to send two outputs, but it does not establish what YouTube will present to viewers after a fault, how quickly any transition would occur, or whether a particular event is configured to use the backup as you expect. Those are separate operational questions.
If you are only trying to recover a broadcast after a single output drops, a second destination may not solve the underlying problem. First identify whether the failure is in the source, encoder, network, ingest path or event configuration. A stable source that still buffers at the viewer end calls for a different investigation; the checklist in how to prevent a YouTube radio stream from buffering when the source is stable helps separate those symptoms.
Choose the matching RTMP or RTMPS URLs
RTMP and RTMPS are not interchangeable labels for the same URL. YouTube exposes distinct address fields for each protocol. Select the pair that corresponds to the protocol you intend to use, and retain the URL path and stream name arrangement supplied for that stream. Do not take an rtmp address and turn it into rtmps by editing only the first few characters.
YouTube describes RTMPS as RTMP carried through an SSL/TLS connection and recommends RTMPS for ordinary user content. Its RTMPS ingestion guide specifies a valid RTMPS endpoint and path, port 443, and the server hostname in the TLS SNI handshake. This is relevant when diagnosing TLS negotiation failures: a connection to the right IP address is not necessarily enough if the hostname expected by the TLS handshake is lost or mismatched.
| Choice | Address to obtain | Practical detail |
|---|---|---|
| RTMP | YouTube’s primary and backup RTMP ingestion fields | Use an RTMP-compatible FLV output and the full stream destination in the required format. |
| RTMPS | YouTube’s primary and backup RTMPS ingestion fields | Preserve the supplied hostname and path; the TLS connection uses port 443 and SNI. |
A firewall or restricted network may treat the two protocols differently. Confirm outbound access for the protocol you selected instead of assuming that a port open for one is open for the other. If RTMPS fails before media reaches YouTube, inspect the FFmpeg error for TLS or connection details and check network policy, hostname handling and the exact copied URL. Do not remove TLS checks as a shortcut.
Prepare the stream key and output URLs
Create or open the event in YouTube Live Control Room and retrieve the primary address, backup address and stream key for that event. The API fields are useful terminology, but the key point is operational: do not paste a generic endpoint found in a forum post when YouTube has supplied values for the stream you are about to run. The stream key is a credential, not a public identifier. YouTube’s live streaming settings guidance treats stream keys as password-like; keep them out of published scripts, screenshots and support logs.
For a shell command, prepare two complete destination strings before writing the tee expression. In the schematic example below, PRIMARY_URL and BACKUP_URL stand for the actual full values, including the stream name in the position required by YouTube. They are placeholders, not literal destinations. Avoid leaving angle-bracket placeholders in a command you run: shell characters can be interpreted rather than treated as text.
If the stream key contains characters with special meaning to a shell or URL parser, quoting the whole tee argument helps protect the shell-level separators, but it does not magically encode every character for FFmpeg. Check how the installed FFmpeg version parses the URL, and use the format YouTube provides. A dry run that merely parses the command is not proof that both remote addresses accept media.
Keep a private working copy of the command and redact the stream name before sharing diagnostics. If you need a more deliberate credential-handling workflow, see how to protect YouTube stream keys on a cloud server. The same care applies when testing from a personal workstation: shell history, copied terminal output and screenshots can disclose a key even when the live player itself is private.
Map audio and video explicitly
The tee muxer duplicates an already selected and encoded output to several destinations. It does not choose the audio and video streams for you. When using tee, FFmpeg cannot infer which streams to include because the muxer is not a single output format. Use -map options to select the intended video and audio streams from the input.
For a file with one video stream and one audio stream, the schematic mappings -map 0:v -map 0:a select all video and audio streams from input zero. If the file has multiple tracks, that may include more than you intend. For a particular first video and first audio stream, a more constrained selection such as -map 0:v:0 -map 0:a:0 expresses that choice. Check the file before streaming and select the language, commentary, or music track deliberately.
If the source has no audio, do not assume that mapping 0:a will succeed. Either omit audio mapping and configure the outputs accordingly, or add an intentional audio source. Likewise, if the input is a playlist or a live capture source, confirm which input index and streams FFmpeg reports. Explicit mapping makes the command predictable; it cannot repair a source that lacks the track you expect.
Codec choice and rate settings depend on the material, resolution and available uplink. YouTube’s encoder guidance lists H.264 video and AAC or MP3 audio among supported choices, recommends constant bitrate and a two-second keyframe interval, and says the interval should not exceed four seconds. Use those as platform guidance, not as a universal bitrate prescription. For a music station, set rate and resolution to suit the actual feed and connection; the bitrate guide for a 24/7 Indian music stream can help frame that separate decision.
Build the FFmpeg tee outputs
A basic command pattern for a file input is below. This is an adaptable example, not a command tested against your live event. Replace the placeholders with your input path and YouTube’s full primary and backup destinations, and confirm that your FFmpeg build has the selected encoders and muxer.
ffmpeg -re -i INPUT \\
-map 0:v -map 0:a \\
-c:v libx264 -c:a aac \\
-f tee \\
'[f=flv]PRIMARY_URL|[f=flv]BACKUP_URL'
The -re option reads a file at its native rate, which is generally useful when using a file as a live programme source. It is not a substitute for a source designed to loop or continue indefinitely. The codec options encode one video and one audio output before tee distributes it. The [f=flv] part tells tee to use the FLV muxer for each RTMP-family destination. FFmpeg’s formats documentation explains tee output syntax and per-output options.
The | between the bracketed outputs is tee’s destination separator. Quoting the complete tee string prevents a typical shell from treating that character as a pipeline operator. Other shells and URL characters can introduce their own quoting concerns. Test the exact command syntax with your installed FFmpeg version and avoid pasting a real stream key into a public issue or article.
FFmpeg’s tee onfail option defaults to abort: if a slave output fails, the tee output can fail rather than continuing with the other destination. You can choose onfail=ignore for a destination whose failure should not stop the other output, for example:
'[f=flv:onfail=ignore]PRIMARY_URL|[f=flv:onfail=ignore]BACKUP_URL'
That choice has a trade-off. Ignoring a failed output can let the surviving destination continue, but it can also leave you running with only one feed and no obvious indication unless you monitor logs and status. Keeping the default makes an output failure more visible to the process, but may stop both destinations. Decide which behaviour suits your operator response, and make sure someone or something is watching for errors.
The FFmpeg tee muxer also supports FIFO processing for output isolation and recovery behaviour. FIFO can be useful where destinations differ in latency or reliability, but adds configuration and is not a substitute for a tested event plan. Neither FIFO nor onfail=ignore promises that YouTube will switch viewers to the backup address. Start with the simplest configuration that meets your need, then add recovery behaviour only after you understand its failure modes.
Check TLS, hostname and port for RTMPS
For RTMPS, first confirm that both copied destinations are the RTMPS-specific primary and backup values. Then check that the network permits outbound traffic to port 443 and that FFmpeg can establish TLS to the hostname in the URL. The hostname matters because TLS SNI identifies the intended server during the handshake. An IP-only substitution, an altered host, or a malformed path can prevent the connection even if the address appears reachable.
Do not “fix” an RTMPS failure by changing the URL to RTMP unless you have deliberately chosen RTMP and obtained the matching addresses. That changes the transport rather than resolving the original TLS issue. Check the FFmpeg build, the installed TLS support, local proxy or firewall rules, and the complete URL as copied. Be mindful not to expose the stream name while sharing an error transcript.
RTMP may be easier to support in a constrained encoder environment, while RTMPS adds an encrypted transport that YouTube recommends for ordinary user content. Your decision should account for the exact endpoint information YouTube supplies and the network where FFmpeg runs. In India, this could mean checking a small business office connection or a home broadband router before scheduling an overnight test; the relevant result is whether the chosen protocol stays connected under your real conditions, not whether a short local command starts successfully.
Verify both feeds in YouTube Live Control Room
Before depending on the command for a long programme, test it with a short, controlled event or a planned test window. Start FFmpeg, inspect its output for successful connections to both destinations, and then check the Live Control Room preview and stream health. A process that remains running is not proof that both outputs are arriving. Verify the two ingest paths as far as YouTube’s interface exposes them, and confirm that the event is behaving as intended.
Check video and audio, not just a green connection indicator. Listen for the intended track, look for a stable preview, and compare the stream’s selected resolution and frame behaviour with your source. YouTube’s encoder settings guidance and streaming tips recommend testing, previewing in Live Control Room and testing failover by stopping the primary encoder. Apply equivalent end-to-end testing to your particular dual-output arrangement rather than assuming that a successful launch validates the backup path.
Test failure behaviour with a deliberate plan. For example, conduct the test before a public devotional programme, tell anyone monitoring the channel what you will stop and when, then observe what the event and preview do. Do not treat the act of terminating one FFmpeg destination as evidence of seamless viewer transition. Record what actually happened, including whether the other feed remained connected and whether the public event continued as expected.
For a long-running channel, also check the file and process lifecycle. A short file can end cleanly while the command itself was correct, and a playlist can fail when it reaches an unavailable item. A 24/7 programme needs a source and restart plan beyond dual ingest. If your pain is leaving a home computer on simply to repeat a study playlist, the practical trade-offs in keeping a YouTube study music stream live without a home computer are relevant; the operational model is separate from FFmpeg’s two-output syntax.
Understand the limits of redundant delivery
Two ingest connections can help when one destination path has a problem, but sending two copies does not make every part of the broadcast redundant. Both outputs may share the same input file, encoder process, power supply and internet connection. A source failure or a local network outage can affect both at once. Redundancy at the ingest destination is only one layer in a larger continuity plan.
There is also a distinction between encoder-side behaviour and viewer-side behaviour. FFmpeg can attempt to send the same encoded programme to both addresses. The tee onfail setting governs what the FFmpeg process does when an output fails. YouTube’s support for a backup ingestion address establishes that it can receive the same content, but the documentation does not promise that this exact tee arrangement causes a seamless viewer switch. A viewer may see interruption, buffering or a different event result. Test the actual configuration and avoid advertising a failover guarantee to your audience.
Operationally, choose the failure policy you can observe and respond to. With the default abort, a slave failure may stop the tee output and make the problem conspicuous, at the cost of losing the surviving output too. With onfail=ignore, FFmpeg may keep sending to the other destination, at the cost of needing better monitoring to detect a degraded state. FIFO can isolate output processing but requires its own validation. None of these choices replaces a human escalation plan for a channel that must run overnight.
If a live channel has a single recurring operational burden—such as leaving a computer on for an uploaded programme—an alternative workflow may remove that particular burden without changing the need to verify the YouTube event. StreamNeo can remove the task of keeping your own computer running for an uploaded video loop, while this FFmpeg pattern remains useful when you specifically need to control encoder output to two YouTube ingest destinations.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does FFmpeg tee automatically map the audio and video?
No. Tee does not infer stream selection, so specify the intended tracks with -map before encoding. Check the input’s stream list and avoid broad mappings if it contains several language or commentary tracks.
Can I use the same URL for RTMP and RTMPS?
No. Obtain the protocol-specific address pair from YouTube for the stream. RTMPS uses TLS, port 443 and hostname/SNI requirements, so editing the scheme on an RTMP URL is not a reliable conversion.
Does sending to both addresses guarantee seamless failover for viewers?
No. It sends concurrent copies towards primary and backup ingest, but that alone does not guarantee what viewers see if a feed fails. Test the event in Live Control Room and treat the observed behaviour as specific to your configuration.
Should I set onfail=ignore?
Only if you want FFmpeg to continue when one tee destination fails and have a way to notice that one feed has dropped. The default is abort, which makes failure more visible but can stop the overall tee output; neither setting creates viewer-side failover.