If you start FFmpeg in an ordinary SSH terminal, closing that connection can end the terminal-bound job. Run FFmpeg inside a named tmux session on the remote host, detach from the session before closing SSH, and reattach later to inspect it.
This separates the stream process from your local terminal; it does not keep a host alive, restart an exited process, or guarantee recovery when YouTube or the network disconnects. Those are different failure cases and need separate checks.
Why an SSH disconnect can end a terminal-bound job
An SSH window is a connection to a shell on another machine. When you run FFmpeg directly in that shell, its input, output and lifetime can be tied to the terminal session. If the connection closes unexpectedly, the shell may terminate the process or leave you unable to manage it. The exact outcome can depend on the shell and how the command was started, so do not treat an ordinary SSH window as a reliable background job manager.
A terminal multiplexer such as tmux gives you a terminal on the remote host that is not the same thing as your local SSH window. You connect to that terminal, run FFmpeg there, then detach. The remote session remains available after you disconnect, and you can reconnect to it later. The tmux project’s getting-started guide describes this use: keeping remote programs protected from connection drops.
The distinction is practical. If your laptop sleeps or your broadband drops, tmux can preserve the remote terminal session and its still-running process. If the remote machine powers off, FFmpeg crashes, or YouTube stops accepting the feed, tmux cannot fix those events. It is a way to keep a job independent of the SSH client, not a guarantee that the job will continue under every condition.
Before you begin, confirm that FFmpeg and tmux are installed on the remote host, that you can SSH into the account that will run the stream, and that the YouTube Live event is ready. If this is a VPS-based broadcast, the choice of host and its limits are a separate decision; see the practical comparison of a VPS and a cloud PC for a YouTube stream in India.
Start or attach to a named tmux session
A named session is easier to find than a default session with a number. Connect to the remote machine with SSH, then run:
tmux new-session -A -s youtube-live
The -s option names the session youtube-live. The -A option tells tmux to attach to that session if it already exists, or create it if it does not. This makes the command useful both for the first start and for a later return. If you prefer to create the session explicitly, tmux new-session -s youtube-live creates it; if the name already exists, use the attach command described below instead.
Once the command succeeds, your terminal is displaying a shell inside tmux. You are still on the remote host, but the terminal you are using is now managed by tmux. Commands typed at this point run in that session. Check that the host is the expected one and that the account has access to the video file, configuration and network resources FFmpeg needs.
You can list sessions with tmux ls if you are unsure whether a session exists. If the command says there is no server or no sessions, that may simply mean you have not created one yet. If a named session is already attached elsewhere, tmux can still let you manage it, but avoid opening multiple shells and launching duplicate FFmpeg jobs by habit. One session should have one intended broadcast process unless you have a deliberate reason to run more.
Keep the session name simple and consistent. youtube-live is only an example; choose a name that identifies the channel or job without putting credentials in it. A session name is not secret storage, and it is not a substitute for checking which host you connected to.
Launch FFmpeg inside the session
Run the FFmpeg command from the shell inside tmux, not in a separate ordinary SSH window. The command needs a valid input, the appropriate codecs and output settings, and the current YouTube ingest destination and stream key. FFmpeg’s RTMP protocol documentation shows a real-time file-streaming example using -re and an FLV output, but its example server address is illustrative, not a usable YouTube destination.
A deliberately incomplete outline might look like this:
ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f flv 'INGEST_URL/STREAM_KEY'
Treat this as a shape, not a ready-to-run command. Replace the input and output with the values and settings for your stream; check the FFmpeg build, codecs, resolution, frame rate and audio mapping. If you use a file intended to repeat, build the loop behaviour into the input or command deliberately and test it. Do not assume that tmux makes an invalid command valid or that a file will repeat just because the terminal remains open.
YouTube’s encoder workflow requires a server URL and stream key. Retrieve the current values from the channel’s Live Control Room and use YouTube’s official encoder setup instructions rather than copying an old endpoint from notes or a tutorial. YouTube recommends RTMPS for Live ingestion; its stream settings guidance explains the protocol and lists platform recommendations for video settings.
A stream key is a credential. Avoid exposing it in a screenshot, a shared terminal recording, a public log, or a command-history file that other users can read. Quoting a URL may help the shell interpret special characters correctly, but it does not conceal the URL from every process or every person with access to the host. Use an account and permissions appropriate to your environment, and rotate the key if you expose it.
After launching, watch FFmpeg’s output. Confirm that it opens the input, begins encoding and reports output progress rather than immediately returning to the shell with an error. Also check the Live Control Room’s preview and status. The right signal is not just that FFmpeg printed a startup line; it is that YouTube is receiving the intended feed and the picture and sound are correct. For a recorded programme, review the bitrate settings for a pre-recorded YouTube Live stream against your resolution, frame rate and codec rather than choosing a number without context.
Detach before closing SSH
When FFmpeg is running and you have checked its output, detach from tmux rather than closing the terminal window as your first action. With tmux’s default key sequence, press Ctrl+b, release both keys, then press d. The terminal should report that you have detached, and your shell prompt will return outside the tmux session. The FFmpeg process remains in the remote tmux session if it is still running.
You can now close the SSH connection. Detaching is different from typing exit at the shell where FFmpeg is running, sending an interrupt, or closing an interactive shell that owns the job. Do not press Ctrl+c unless you intend to stop FFmpeg. Do not kill the tmux session as a way to close your laptop terminal: that removes the session that is holding the job.
A useful first test is to detach, disconnect, and reconnect after a short interval while you can still monitor the YouTube event. Verify the stream from the platform side or another device as well as from FFmpeg’s output after reattachment. This tests your actual host, account and command rather than relying on a memory of what should happen. For an always-on devotional, music or study channel, it is better to do this test before relying on the setup overnight.
If your key sequence is not recognised, check whether your tmux configuration changes the prefix, or use tmux’s command prompt to detach. The default is the sequence above, but user configuration can change it. Do not assume a frozen-looking SSH window means you detached successfully; confirm that the client has returned to its outer shell or that the SSH connection has closed while the session remains listed on the host.
Reconnect and reattach to inspect the process
To return, SSH to the same remote host and account, then run:
tmux attach-session -t youtube-live
This attaches your terminal to the named session. You should see the shell and FFmpeg output in the state they were left. If FFmpeg is still running, its output continues to update. If the process exited, the shell may be sitting at a prompt, or its last output may show an error. The session being present does not prove the encoder is healthy; inspect the process output and check YouTube’s Live Control Room.
If tmux reports that it cannot find the session, first run tmux ls and confirm you are on the same host and using the same account that created it. Sessions belong to the remote machine and account context, not to the local laptop. A reboot, a different host name, a different user, or an ended tmux server can explain why the name is missing. Do not immediately launch a second FFmpeg command without checking whether another stream process is already sending to the event.
If you reattach and see an error or a shell prompt, record the useful diagnostic output before starting again. Check whether the input file is accessible, whether storage is full, whether FFmpeg returned an error, and whether the YouTube event is still configured as expected. Restarting without finding the cause can create a repeated failure or a second process competing for the same stream key.
For a stream that runs from a playlist or repeated files, tmux only preserves the command you actually started. It does not schedule a new item, repair an out-of-sync audio track, or decide what to play next. If the main concern is how a sequence of recorded material should run without a camera, the guide to streaming recorded church services on YouTube covers that content workflow separately.
Terminal persistence is not network recovery
A detached tmux session helps when the SSH connection goes away but the remote process and its path to YouTube remain healthy. A separate problem occurs when FFmpeg is alive but its output connection to YouTube fails. tmux does not reconnect an RTMP or RTMPS output on its own. Likewise, a stream can be receiving data at the host while YouTube reports a problem with the event, key or ingest connection.
FFmpeg documents a FIFO muxer pattern for attempting recovery through a temporary network outage. Its all-options documentation describes options including -f fifo, -fifo_format flv, -attempt_recovery 1 and -recovery_wait_time 1. Its example aims to keep processing at real-time rate and retry recovery; it is not a promise that every FFmpeg build, network interruption or YouTube-side failure will recover cleanly.
The pattern must be adapted to your actual input, codec, mapping and destination. Do not copy an example RTMP host from a manual and treat it as YouTube’s endpoint. Test on the same host and with the same kind of source and destination you plan to use, then observe whether the broadcast resumes in YouTube’s control room after a controlled interruption. Recovery logic can also have trade-offs: buffering or dropping packets affects what viewers receive, and a recovered connection does not necessarily mean the stream has no discontinuity.
YouTube recommends RTMPS, so use the current protocol and URL supplied for your broadcast where available. If the stream repeatedly goes offline, troubleshoot the actual link, host network and ingest status rather than adding tmux commands. Readers whose failures happen on a home connection may find the Airtel broadband troubleshooting guide useful for separating local connectivity symptoms from a process-lifetime issue.
Plan for host restarts and FFmpeg exits
A tmux session lives on the remote host. If that host reboots, shuts down, loses power or becomes unavailable, the session and the FFmpeg process do not survive merely because they were detached. The same is true if FFmpeg exits because of an invalid input, a codec error, a full disk, a signal or a resource problem. Once the process has stopped, tmux can show you the closed shell or its output, but it does not automatically relaunch the encoder.
If you need recovery after a process exit or boot, evaluate a process supervisor or service manager separately. Compare its restart behaviour, boot startup, log access, and how it handles environment variables and credentials. Those mechanisms require careful configuration and testing; they are not part of the tmux workflow, and you should consult the official documentation for the tool and operating system you choose. Keep the stream key protected when deciding how a command is launched or logged.
Make the failure visible. Check YouTube’s Live Control Room during initial tests, decide how you will notice a stream has stopped, and document the exact host, account, session name and command location for whoever may need to investigate. For ongoing channels, keep a short runbook with steps to check the host, reattach to tmux, inspect FFmpeg output, and verify the platform feed. A runbook will not prevent failure, but it reduces guesswork when the person who started the stream is unavailable.
YouTube’s current guidance says streams under 12 hours are automatically archived, and its Live eligibility information lists limits of 10 active streams per channel and 3 active streams per stream key. Check the current YouTube Help guidance before planning a longer-running or concurrent broadcast, since platform rules can change. These limits and archive behaviour are YouTube platform details, not properties of tmux or FFmpeg.
For a simpler operating arrangement, StreamNeo removes the need to keep a remote FFmpeg session under your care: you upload the video once, supply the YouTube stream key, and the broadcast runs with your own computer switched off, with monitoring and automatic restart if the broadcast drops. It is YouTube-only, so it will not suit a workflow that needs a different destination or hands-on control of a custom FFmpeg command.
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
Will FFmpeg keep running if I close my laptop?
It can, if FFmpeg is running inside a tmux session on a separate remote host and you detach before ending SSH. Closing the laptop only removes your local connection; it does not protect the remote host from failure or keep a stopped process running.
Does tmux reconnect FFmpeg to YouTube after an outage?
No. tmux preserves the terminal session, not the connection to YouTube. FFmpeg has a documented FIFO recovery pattern for some temporary network outages, but adapt and test it for your actual stream and do not treat it as guaranteed recovery.
What if the tmux session is missing when I reconnect?
Check that you connected to the same host and account, then use tmux ls to see whether the session still exists. If the host rebooted or the session ended, tmux cannot restore the old process; inspect the host and FFmpeg logs before starting a replacement.
Can tmux restart FFmpeg after a reboot or crash?
No. tmux does not supervise FFmpeg or start it at boot. If you require those behaviours, assess a suitable supervisor or service manager and test its restart, logging and credential handling separately.