To keep an FFmpeg process running after you close SSH, start it inside a tmux session on the remote host that is running FFmpeg, then detach from tmux before ending the SSH connection. Later, reconnect to the same host as the same user and attach to that named session to inspect the process.
This protects the process from losing its terminal when SSH disconnects; it does not protect it from a host shutdown, network failure or FFmpeg crash. The steps below show how to set up the session, use YouTube’s current stream details and check what happened when you return.
Why an SSH disconnect stops some streams
When you run a command directly in an SSH terminal, that terminal is part of the command’s working environment. If the connection closes unexpectedly, the shell or its child process may receive a hangup signal and stop. The exact behaviour depends on how the process was started and the host’s configuration, so a command that appears to survive one disconnection is not a dependable plan for an overnight stream.
Tmux adds a persistent terminal session on the remote machine. Your SSH connection is a client attached to that session. Detaching closes the client’s view but leaves the session and its foreground program running. The tmux project’s getting-started guide describes this detach-and-reattach model.
The location matters. If you open tmux on your laptop and SSH from there to another machine, FFmpeg is still running on the other machine, outside the laptop’s tmux session. SSH into the destination first, then start tmux there. You can confirm the destination with hostname and the account with whoami before beginning.
Tmux is not a supervisor or a promise that a 24/7 stream will stay live. It does not restart FFmpeg after an error, restore a process after a reboot, or repair a broken route to YouTube. Think of it as protection against losing the interactive terminal, and plan separately for failures beyond that.
Check tmux on the remote host
After connecting to the Linux host that will run FFmpeg, check whether tmux is available:
tmux -V
If the shell reports that the command is not found, install tmux using the package manager for that host’s operating system, or ask the system administrator if you do not have permission to install software. Package names and installation commands vary by distribution; use its current documentation rather than copying a command meant for a different system.
Also check that FFmpeg is installed and that the build supports the input and output formats you need:
ffmpeg -version
These checks establish only that the programs are present. They do not confirm that your file can be decoded, that the host has sufficient capacity, or that YouTube accepts the output. For those questions, test the actual file and streaming command before relying on the setup. Our guide to checking CPU and RAM needs for FFmpeg explains why the workload matters more than simply having the command installed.
A remote host must remain powered on and have a usable network connection for the stream to continue. If you do not already have a machine suited to that role, a remote Linux host is one possible way to run the process; it is not a requirement of tmux itself. The cloud video playout overview covers a different operating approach for readers who would rather not manage a command-line host.
Create a named tmux session
Start a session with a name that tells you what it is for:
tmux new -s youtube-live
Your terminal will now show a shell inside the new tmux session. The name is useful when you have more than one session or when you return after several hours and need to identify the right one. You can choose another clear name, but use it consistently in the commands that follow.
If you may already have created the session, inspect the existing sessions before starting another one:
tmux ls
Starting a second session and running the same broadcast command there could create two FFmpeg processes trying to use the same stream key. Instead, attach to the existing session or use tmux’s create-or-attach option:
tmux new-session -A -s youtube-live
The tmux manual documents session creation and attachment options in its tmux(1) reference. The important habit is to check before launching: a session that already exists may be the one you meant to inspect, not a reason to start another stream.
Prepare the FFmpeg command and YouTube details
Get the stream URL and stream key from YouTube Live Control Room. YouTube’s guide to creating a live stream with an encoder explains where to retrieve them. Treat the key as a credential: do not put the real value in a public script, screenshot, shared terminal log or article example. Use a placeholder when drafting commands, then enter the actual value privately on the host.
YouTube recommends RTMPS, the encrypted form of RTMP, when your encoder supports it. Check YouTube’s current RTMPS instructions for the applicable URL and troubleshooting guidance. A wrong endpoint, key or unsupported protocol can prevent a connection even when tmux is working correctly.
FFmpeg’s protocol documentation shows the general pattern for sending a file in real time to an RTMP destination:
ffmpeg -re -i myfile -f flv rtmp://example.invalid/live/<STREAM_KEY>
This is a shape for the command, not a complete recipe for every source. Replace the example input and destination with your own file and current YouTube details. Choose codecs, bitrate, frame size and audio settings for the source and YouTube’s current encoder guidance; do not assume that the placeholder endpoint will work. For current recommendations, consult YouTube’s encoder settings, bitrates and resolutions page.
For a file input, -re asks FFmpeg to read at approximately the input’s native rate rather than sending the file as quickly as possible. A single finite file will still reach its end and stop. Tmux will keep a running process attached to its session, but it will not make a video repeat. If you need a loop or playlist, configure that behaviour in FFmpeg deliberately and test it before leaving the host unattended. The FFmpeg guide for a Telugu story channel is a relevant example of planning the FFmpeg side for a continuous channel.
Launch FFmpeg inside the session
With the named session open, run your tested FFmpeg command at its shell prompt. Keep it in the foreground in that tmux pane. You should see FFmpeg’s output there, including progress and any connection or encoding errors. If you send it to the background and close the shell, you add another layer of process handling that is not needed for this workflow.
Before you detach, verify that FFmpeg has started and is making progress. Then check YouTube Live Control Room to confirm that the stream is arriving and review its health indicators. YouTube recommends testing before going live, using representative movement and audio, and monitoring stream health. A successful command launch is not proof that viewers are receiving the intended picture and sound.
For a devotional channel, for instance, test an actual section of the bhajan file rather than a silent or static placeholder. Listen for audio continuity, watch for an unexpected end of file and check that the Live Control Room recognises the incoming stream. If your stream is a playlist, verify transitions and filenames as well; a playlist can fail for reasons unrelated to SSH or tmux. The troubleshooting notes on VLC playlists with Hindi filenames may help if that is your playback method.
Do not paste the real stream key into a command history that other users can read. Shell history behaviour varies, and access controls differ between hosts. If your key has been exposed, use YouTube’s controls to replace or reset it and update the command you use. Avoid posting terminal output publicly without reviewing it for credentials.
Detach before closing SSH
When FFmpeg is running in the tmux pane, detach with the default key sequence: press Ctrl-b, release both keys, then press d. Do not press the keys simultaneously. You should return to the shell that launched tmux, while the named session and the FFmpeg process inside it continue running.
Detaching is different from typing exit in the pane. exit closes the shell running inside the session; if FFmpeg has stopped or has returned to the shell, that may end the session as well. Likewise, do not kill the session if your intention is to leave its process running. The tmux guide documents the default detach binding and what it means to leave a session running without an attached client.
Once detached, you can close the SSH connection normally. You can also check that the session still exists before disconnecting:
tmux ls
A listed session is useful evidence that the tmux session remains present, but it does not confirm that FFmpeg is healthy or that YouTube is receiving the stream. For that, reconnect and inspect the process output and the Live Control Room. This distinction prevents a common false reassurance: a session can survive while the process inside it has already exited with an error.
Reconnect and inspect the stream
Later, SSH back to the same host and account that created the session. If the name is unclear, check hostname and whoami again, then list sessions:
tmux ls
Attach to the named session with either command:
tmux attach-session -t youtube-live
or:
tmux attach -t youtube-live
You will return to the pane where FFmpeg was running. Read its recent output and check whether it is still advancing. If you need to leave again, detach with Ctrl-b, then d; do not type exit merely to close the view. When you have intentionally finished the stream, stop FFmpeg using the appropriate method for the command you ran, and close the session only after you no longer need it.
If tmux says the session does not exist, first verify that you reached the same remote host and logged in as the same user. Tmux sessions are associated with a user and its tmux server; a different account or host will not normally show the session you expect. It may also have been exited or killed. Check the host and account before creating another session, particularly if a stream may already be active.
If you can attach but FFmpeg has exited, inspect the last visible error. A missing input file, a full filesystem, an invalid output URL, a rejected key or a lost network path can all stop FFmpeg independently of tmux. Correct the underlying problem, then start a new FFmpeg process deliberately and confirm the incoming stream in Live Control Room rather than assuming the old session recovered.
Know what tmux does not recover
The boundaries are worth making explicit before you rely on a remote stream overnight. Tmux keeps a terminal session separate from the SSH client; it is not responsible for restarting the program or recovering a machine. If the host reboots, the tmux session and its process are gone. If FFmpeg exits, tmux may remain open showing the shell and the error, but the broadcast has stopped.
A network interruption between the host and YouTube can also break the output, even while FFmpeg remains visible in the pane. FFmpeg has its own options for handling some temporary output failures, including a FIFO muxer pattern documented in the FFmpeg documentation; that is a separate streaming behaviour, not something tmux supplies. Any retry strategy should be tested with your encoder build and stream configuration.
If you need automatic restart after a process failure or launch at boot, consider a suitable service manager or another deliberate recovery mechanism. That changes the job from keeping an interactive terminal available to managing a program’s lifecycle, so it needs its own configuration and logs. Tmux is the simpler fit when your main need is to start a command, disconnect SSH and later return to see the same terminal.
| Need | tmux session | Separate service manager |
|---|---|---|
| Detach from SSH and return to the same terminal | Designed for this workflow | Usually not the main purpose |
| Restart FFmpeg after it exits | Not by itself | Can be configured, depending on the manager and service definition |
| Start the stream after a host reboot | Not by itself | Can be configured, with suitable boot and service settings |
| Inspect interactive FFmpeg output | Attach to the session | Usually inspect logs or service status |
These approaches solve different problems and can be combined, but do not assume either is configured merely because FFmpeg started once. For an interactive one-off test or a carefully watched stream, tmux is straightforward. For a channel where recovery after a crash or reboot matters, plan and test a proper restart path as a separate piece of work.
Before relying on a stream after closing SSH, test the full sequence during a period when you can monitor it: connect, start FFmpeg, detach, reconnect, inspect and verify the picture and sound in YouTube. Keep the URL and key private, and write down the host, account, session name and exact command with the secret omitted. This makes it easier to distinguish a session problem from a source, encoder or connection problem when you return.
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 tmux keep FFmpeg running after I close SSH?
It keeps the tmux session and a running process inside it independent of the SSH client when you detach properly. Start tmux on the remote host running FFmpeg, not on your local computer, and detach before closing SSH. It does not protect the stream from failures beyond the terminal connection.
What should I do if I cannot find the session after reconnecting?
Confirm that you connected to the same host and logged in as the same user, then run tmux ls. The session may have ended or been killed; if it is missing, do not launch a duplicate stream until you have checked YouTube Live Control Room and established what is currently broadcasting.
Will tmux restart FFmpeg after a crash or host reboot?
No. Tmux does not restart a failed process or restore a session after the host reboots. Use a separately configured recovery method if those behaviours matter, and test it rather than treating detachment as a restart policy.
How do I leave the stream running but close the terminal?
While FFmpeg is running in the tmux pane, press Ctrl-b, release, then press d. This detaches from the session; typing exit or killing the session is not the same action. You can close SSH after detaching and later attach with tmux attach -t youtube-live.