If FFmpeg is running in the foreground of an SSH terminal, closing that connection can stop the process. The practical fix is to start FFmpeg inside a named tmux session on the remote server, then detach from the session instead of ending the process.
This keeps the shell and FFmpeg process on the server while your local SSH window disappears. It does not restart FFmpeg after a crash, repair a failed network connection, or prove that YouTube is still receiving a healthy broadcast.
Why an SSH disconnect can stop FFmpeg
When you connect to a remote Linux machine over SSH, you normally receive a shell whose input and output are connected to your SSH session. If you launch FFmpeg there, it is a foreground child of that shell. Your local terminal may only show the command, but the command is still tied to the remote session that created it.
A clean logout, a broken Wi-Fi connection, a laptop going to sleep, or an SSH timeout can therefore change what happens to the process. Depending on the shell, SSH configuration, and how the process handles its terminal, FFmpeg may receive a hangup signal, lose its input or output, or simply be terminated when the session disappears. This is why a stream can stop when nothing about the media file has changed.
A terminal multiplexer changes that relationship. tmux runs a server-side session that can have one or more clients attached to it. Your SSH window becomes a client of tmux rather than the only place where the shell exists. Detaching removes your view of the session, while the session and its programs remain on the remote machine.
That distinction matters. You are solving process lifetime after an SSH disconnect, not creating a complete broadcast-reliability system. The remote host still needs to stay powered and reachable, FFmpeg still needs to remain running, and YouTube still needs to accept the outgoing feed.
Before leaving a channel unattended, use a broader 24/7 stream pre-flight checklist to test the file, audio, account settings, and recovery procedure rather than checking only whether the command starts.
Create a named tmux session
First connect to the remote server with SSH and check that tmux is available:
tmux -V
If the command is not found, install tmux using the package instructions for the operating system and distribution running on that server. Package names and installation commands vary, so do not copy a command meant for a different system without checking its documentation.
Create a session with a name that describes its purpose:
tmux new -s youtube-live
You should now see a new shell inside tmux. The name is useful when you have more than one channel, test job, or maintenance session. A name such as youtube-live is clearer than relying on a number or an automatically generated label.
You can list tmux sessions from a normal shell with:
tmux ls
If youtube-live already exists, do not create another session by guesswork. Check whether FFmpeg is already running inside it:
tmux attach -t youtube-live
Starting a second encoder with the same stream key can create confusion about which process is sending the feed. Treat the named session as the place where this channel is operated, and keep notes if you run several channels on the same host.
The session exists on the remote server, not on your laptop. Closing your local terminal does not remove it, provided the remote machine and tmux process remain available. If the server reboots, however, the session normally disappears unless you have separately designed and tested a boot-time service arrangement.
Launch FFmpeg inside the session
Run the FFmpeg command only after you are inside youtube-live. The basic shape is:
ffmpeg -nostdin [input and output options]
Replace the bracketed part with the actual media input and YouTube output settings for your stream. The example deliberately does not include a real stream URL or key. Never paste a live stream key into an article, public script, screenshot, issue tracker, or shell command that other people can access.
Place -nostdin among FFmpeg's global options, before the relevant input and output arguments. FFmpeg normally checks console input. In a background or detached workflow, that check is unnecessary and can cause undesirable terminal behaviour. The FFmpeg FAQ documents -nostdin for suppressing those console checks and describes redirecting standard input from /dev/null as an alternative on Linux and macOS.
A command will usually contain three kinds of information:
| Part | Purpose | What to check |
|---|---|---|
| Input | Reads your video, audio, or playlist source | Confirm the remote path exists and the account can read it |
| Encoding and timing | Produces the video and audio feed | Match the settings to the source and the stream you intend to run |
| Output | Sends the feed to YouTube | Use the current server URL and the correct stream key |
The exact command depends on your file, codecs, desired output, and existing setup. The safest approach is to use a command you have already tested in the same environment, then add -nostdin if it is not already present. Do not treat tmux as a replacement for validating the FFmpeg command itself.
YouTube provides the live server URL and stream key through Live Control Room. Its encoder guidance explains where those values come from and how the encoder sends content to the channel. Labels and controls can change, so check the current YouTube interface before starting a new broadcast.
Watch the first output carefully. You want to see FFmpeg open the input, process frames, and maintain an output connection without immediate errors. A command that returns to the shell has exited, even if the tmux session itself remains open. tmux keeps the terminal session alive; it does not keep a finished command running.
Detach without stopping the stream
Once FFmpeg is running, leave it in place by detaching from tmux rather than closing the terminal or pressing keys intended to stop FFmpeg.
Use the tmux prefix followed by the detach command:
Ctrl-b, then d
Press and hold Ctrl, press b, release both, then press d. You should return to your ordinary SSH shell and see a message indicating that the session was detached. At that point, you can close SSH.
Detaching is not the same as stopping the stream. The FFmpeg process remains inside the remote tmux session, and its output continues to be written to the tmux window. You are no longer watching that output, but absence of a terminal view does not by itself end the process.
Do not use Ctrl-c if your intention is only to leave the stream running. Ctrl-c is commonly interpreted by FFmpeg as an interrupt and can stop the encoder. Likewise, logging out from inside the tmux shell is not the normal way to leave a running job. Use the tmux detach sequence first, then exit SSH from the outer shell if you want to close the connection.
A useful operating habit is to write down the session name, the remote host, the input path, and the time the command was started. If another person later needs to inspect the channel, they can identify the correct session instead of starting a second process or terminating the wrong one.
For a devotional, study, or ambience channel, also distinguish the encoder from the content workflow. A persistent tmux session can keep one FFmpeg command alive, but it does not decide whether a playlist should loop, whether a video repeats, or whether the audio remains present. Those are separate parts of the stream design, as explained in the guide to running a playlist continuously on YouTube.
Reconnect and reattach to inspect it
When you want to inspect FFmpeg again, connect to the same remote server with SSH and list the sessions:
tmux ls
Then reattach to the named session:
tmux attach -t youtube-live
You should see the shell window where FFmpeg is running. Its recent output may show frame processing, timestamps, bitrate information, warnings, or an error. Reattaching does not restart the command. It only gives you another view of the existing session.
If there is no session with that name, check the exact name and whether the remote host has rebooted. You can also inspect the process list, but do not assume that a process with an FFmpeg name is sending the expected YouTube feed. A process may be stalled, writing to a local file, connected to a different output, or using a different input.
When you have finished inspecting the output, detach again with:
Ctrl-b, then d
You can repeat this cycle whenever needed. Attach to observe or operate the process, detach to leave it on the server. If you need to stop FFmpeg deliberately, reattach first and use the appropriate interrupt or stop procedure, then confirm the process has exited.
Stopping the local encoder feed is separate from managing the YouTube broadcast state. YouTube's stream settings guidance explains the relevant Live Control Room controls and credentials. Check the current state in YouTube rather than assuming that detaching tmux ends the live event.
Keep the stream key out of the workflow's public parts
A YouTube stream key is a credential for sending a feed to the channel. Treat it like a password even when the FFmpeg command is stored on a private server. Shell history, process listings, terminal recordings, screenshots, backups, and shared notes can all expose command-line values.
Use the key only where it is needed, restrict access to the server and files that contain it, and avoid posting full command lines when asking for help. If you believe the key has been exposed, use YouTube's current Live Control Room controls to reset it, then update the encoder with the replacement. The YouTube encoder help page describes the relationship between the key, the server URL, and the encoder.
A key change also means that a previously working FFmpeg command may stop connecting until it is updated. That is an authentication change, not a tmux failure. Keep the two diagnoses separate: first check whether FFmpeg is still running, then check whether its output can authenticate and reach YouTube.
What tmux does not recover from
tmux protects the session from the loss of its attached terminal. It does not supervise FFmpeg's health. If FFmpeg exits because the input file ends, a filter fails, an output error is treated as fatal, or the process is interrupted, tmux leaves you with a session containing a stopped shell or a command prompt.
It also does not restart the process after a remote server reboot. A power failure, host maintenance, operating-system crash, storage problem, or an account-level termination can remove both the tmux session and FFmpeg. A persistent session is only persistent while the machine and its supporting services remain available.
Network failures are another boundary. The connection from the server to YouTube may fail while the SSH connection remains available, or SSH may fail while FFmpeg continues trying to send. Local connectivity, the remote host's route, DNS, firewall rules, YouTube ingest, and stream credentials are distinct failure points. Reattaching to tmux can show you FFmpeg's message, but it cannot repair each one.
Nor does a live-looking process prove that viewers are receiving a healthy broadcast. FFmpeg might be blocked, repeatedly reporting output errors, producing no useful frames, or sending content that YouTube does not accept as expected. Check the YouTube Live Control Room and the public viewing experience as well as the terminal output.
This is the same reason a slow internet connection needs a separate assessment. Keeping the command alive and having enough stable upload capacity are different tasks.
When to add a separate restart and monitoring plan
Use tmux when a person starts the encoder and occasionally reconnects to inspect it. It is a straightforward interactive tool for protecting a running FFmpeg command from an SSH disconnect. It is not an unattended restart policy.
If the channel must recover after an FFmpeg exit or host reboot, you need a separately designed process-supervision and monitoring plan. The exact configuration depends on the operating system, the account that should run FFmpeg, the input and output paths, the desired restart conditions, logging, secrets, and the risk of a restart loop. Do not copy a service unit from a different Linux distribution and assume it has been tested for your stream.
Before choosing that route, write down the failures you actually need to handle:
- SSH disconnect while the server is healthy.
- FFmpeg exits because of an input or output error.
- The source file ends or becomes unreadable.
- The server loses network access.
- The remote host reboots.
- YouTube rejects the key or stops accepting the ingest connection.
- The process appears alive but the broadcast is not healthy.
Then decide which of those conditions should trigger an alert, a manual investigation, or an automatic restart. A restart can be useful for a transient process failure, but it cannot make an unavailable network or invalid stream key work. Repeatedly restarting a bad command can also hide the original error and make diagnosis harder.
Keep logs somewhere you can inspect after a failure, and test the recovery path while you are present. A plan that has never been deliberately interrupted is only an assumption. For channels with several outputs, a method for keeping multiple 24/7 channels organised can prevent you from confusing one server process, stream key, or Live Control Room event with another.
If you do not want to maintain a remote FFmpeg process, a hosted workflow can remove the need to keep your own SSH session and machine available. StreamNeo is designed for the narrower case where you upload the video once, provide the YouTube stream key, and let the broadcast run without your computer remaining switched on. It still does not remove the need to check the source, YouTube settings, and channel status.
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 tmux keep FFmpeg running after I close my SSH window?
It is designed to leave programs running when you detach its client, so FFmpeg can continue after the SSH window closes. Start FFmpeg inside the named tmux session and use Ctrl-b, then d, rather than stopping the process. This assumes the remote host and FFmpeg remain healthy.
Does -nostdin keep FFmpeg alive by itself?
No. -nostdin prevents FFmpeg from checking console input, which is useful when the command runs without an interactive terminal. It does not create a persistent session, restart a crashed process, or fix a lost connection to YouTube.
How do I view the FFmpeg output again?
Reconnect to the same server, list the sessions with tmux ls, and run tmux attach -t youtube-live. To leave it running, detach with Ctrl-b, then d. If the session is missing, investigate whether the command exited or the server restarted.
What should I use if the channel must restart after a reboot?
Use a separately researched process-supervision and monitoring plan for the operating system and failure modes involved. tmux handles an SSH terminal disconnect, but it does not provide boot recovery or automatic restart after FFmpeg fails. Test any restart policy with the actual input, credentials, logging, and YouTube workflow before relying on it.