Installing FFmpeg on Debian is a short APT task: refresh package metadata, install the package, and check that ffmpeg and ffprobe run. That confirms the local tools are present; it does not confirm that your input, chosen encoder, upload connection, stream key, or YouTube broadcast will work.
For an always-on channel, treat installation and broadcast setup as separate jobs. First verify what Debian installed, then match the output to YouTube's current ingestion guidance, and finally run the process under supervision with logs and a recovery test.
Refresh Debian's package metadata
APT uses repository metadata to determine which package versions and dependencies are available from the repositories configured on your Debian system. Refresh that metadata before installation:
sudo apt update
This command updates the local package index. It does not upgrade every installed package, install FFmpeg, or test your internet connection's ability to sustain a live upload. Read any errors it prints. If a repository cannot be reached, has an invalid signature, or is misconfigured, resolve that before interpreting later package results.
Use the Debian repositories already configured for the machine unless you have a specific, verified reason to do otherwise. Package versions vary by Debian release and repository state. Debian's package pages are useful for identifying what a release lists, but do not copy a version number from an article or another machine and assume it applies to yours. The Debian FFmpeg wiki installation guidance gives the repository-based route; the Debian package listing provides release-specific package details.
If the machine is remote, connect using a session that can tolerate interruption and keep a separate route back in if practical. Updating package metadata is usually routine, but the streaming workflow should not depend on an SSH terminal remaining open. Later sections cover how to detach the broadcast from an interactive session.
Install FFmpeg with APT
Install the package with:
sudo apt install ffmpeg
Review APT's proposed changes before confirming. On Debian, the package is the normal starting point for the command-line tools used in this guide. The package listing describes ffmpeg, ffprobe, ffplay, and qt-faststart; which items you use depends on the job. For a file-based stream, ffprobe is particularly useful for inspecting the media before starting a long run.
If APT says the package cannot be located, first check whether apt update completed successfully and whether the system's configured repositories match the installed Debian release. Avoid adding an unfamiliar repository or compiling from source as a first reaction. Those routes introduce maintenance and compatibility choices that may not be needed to install the packaged tools.
An APT install is only an installation result. It says nothing about whether the file you plan to loop is readable, whether the build provides the encoder you intend to use, or whether YouTube will accept the resulting stream. Keep those checks separate rather than treating a successful package command as a completed broadcast setup.
Verify the installed tools and build
Ask each program to report its version and build information:
ffmpeg -version
ffprobe -version
Both commands should print information and return you to the shell. This is a basic local check that the programs can start; it is not a test of a particular file or YouTube connection. The version and configuration output also help when comparing behaviour across machines or asking for support.
Package versions differ between releases and can change as Debian publishes updates. For example, Debian package listings observed on 3 October 2026 showed different FFmpeg versions for trixie and bookworm. Those are dated repository observations, not a promise about the version on your machine. Check your installed output and the package listing for your own release rather than pinning a guide to an old number.
If you need a particular encoder, inspect the build before writing a long-running command:
ffmpeg -encoders
Search the output for the encoder you plan to use, then test a short encode with representative media. The list tells you what that build advertises; it does not establish that a hardware path is enabled, that the machine can encode at the chosen rate, or that the stream will be accepted. Debian's build may differ by release, architecture, and available configuration. Do not add repositories or compile a replacement simply because a command copied from another system names an encoder you do not have. First decide whether software encoding or a different supported output is appropriate.
The FFmpeg manpage on Debian describes command-line options, but options and available encoders should be checked against the version actually installed. Keep the output from these checks with your setup notes so that a future package change is easier to diagnose.
Check the input and encoding requirements
Before configuring YouTube, inspect the file or live source that FFmpeg will read. For a file, use ffprobe to see the container, video and audio streams, dimensions, frame rate, duration, and other relevant properties:
ffprobe -hide_banner /path/to/channel-video.mp4
Replace the example path with your actual file. Confirm that the service account which will run FFmpeg can read it. A file that plays in your desktop account may not be accessible to a system service running under a different account. Also check available disk space if you are generating logs or changing the media, and confirm that the intended source remains available after a reboot.
Decide whether you need to encode or can pass through existing compatible streams. Encoding allows you to choose output properties but consumes CPU or supported accelerator capacity. Copying an already encoded stream uses less processing, but only works when its codec and properties fit the intended output and YouTube ingest requirements. A file that has H.264 video is not automatically ready for every resolution, frame rate, audio format, or stream workflow. For a useful comparison of source formats and output choices, see video formats for 24/7 YouTube Live streaming.
If you encode, test the exact codec and settings on the target Debian machine for longer than a brief launch check. Watch CPU use, temperatures if relevant, and whether audio remains in sync. A stream can begin successfully and still fail later under sustained load. The machine's ability to keep up is an operational question, not something apt install measures.
For a file that should repeat, plan the loop behaviour deliberately. Test that the chosen input options produce the intended transition from the end back to the beginning, including continuous audio. Do not assume a command that loops a still image or a playlist behaves the same way with every media input. Keep the initial test short and inspect it in YouTube before relying on it overnight.
Choose YouTube ingestion settings
Use YouTube's current live encoder settings as the reference for protocol, codec, bitrate, keyframes, frame rate, and colour settings. The guidance recommends RTMPS, constant bitrate (CBR), and a keyframe interval of two seconds, not exceeding four seconds. It lists H.264, H.265/HEVC, and AV1 video options for RTMP/RTMPS, with AAC or MP3 audio. Match your FFmpeg build and actual YouTube Live workflow rather than assuming every codec is available or appropriate on every Debian machine.
Select resolution, frame rate, codec, and bitrate together. The following published figures are YouTube's H.264 recommendations, not a measured promise of the quality or stability you will get. YouTube publishes different recommended figures for other codecs, so do not transfer this table to AV1 or H.265 without checking its current settings page.
| H.264 output mode | YouTube-published minimum | YouTube-published recommended bitrate |
|---|---|---|
| 720p at 30 fps | 3 Mbps | 8 Mbps |
| 1080p at 30 fps | 5 Mbps | 14 Mbps |
| 1080p at 60 fps | 6 Mbps | 17 Mbps |
| 4K at 30 fps | 11 Mbps | 42 Mbps |
The network must sustain the selected bitrate with headroom for normal variation and other traffic. A speed test at one moment does not prove that an upload link can maintain the stream all day. If the household or shop connection is shared, account for other devices, and test at the time and location where the channel will run. If the connection cannot reliably support a mode, choose a lower resolution or frame rate and test that configuration rather than repeatedly increasing bitrate.
For ordinary SDR, YouTube's guidance calls for Rec. 709 colour and 8-bit depth; HDR has separate requirements. Set these deliberately when relevant to the source, and avoid labelling SDR material as HDR simply to select a different output. RTMPS is the direct fit for a continuous low-latency contribution where the workflow supports it. YouTube notes that HLS has higher latency than RTMP because it sends segments, so choose HLS only when that workflow and its delay suit your channel.
Set up the stream in YouTube Live Control Room and obtain the current server URL and stream key for the chosen broadcast. Do not paste a key into a public script, repository, screenshot, or support post. Anyone who obtains it may be able to send to the channel. Keep it in a restricted configuration file or an appropriate secret mechanism, and rotate it if you expose it. YouTube's Live streaming help is the place to check current account and event requirements; confirm those directly because they can change.
Build a supervised streaming process
A command entered into an interactive shell is tied to that session and the host. Closing the terminal, losing the connection, or rebooting the computer can end the process. For a 24/7 channel, use a service manager such as systemd to launch FFmpeg at startup, restart it after an unexpected exit, and send logs somewhere you can inspect. This is process supervision, not a guarantee of uninterrupted streaming.
Build and test the FFmpeg command by hand first. Keep the input path, loop behaviour, video and audio choices, bitrate, keyframe interval, output protocol, and destination explicit. Avoid copying a command from a different source type: a file loop, a capture device, and a playlist have different input requirements. Put secrets outside a broadly readable script and restrict permissions on files that contain the stream key. Also avoid placing the key in shared shell history or pasting it into a public issue.
Once a command works in a short foreground test, place it under a systemd service configured for the account that can read the input and its configuration. Give the service an appropriate restart policy, and configure it to start after the host has network availability. Make logs accessible to the person who will respond to a failure. The exact unit depends on your paths, account, credentials, and command, so do not install a generic unit unchanged. A misconfigured service can fail before FFmpeg starts, run with different permissions from your test, or repeatedly restart without fixing the underlying fault.
Test the service lifecycle rather than only the FFmpeg command. Confirm it starts on demand, produces expected logs, stops cleanly, and starts again after a controlled restart. If a machine reboots, check that the service is enabled and that the source file and secret configuration are available at startup. Keep a record of the working command and settings without recording the key itself.
A restart policy addresses a process that exits; it cannot make a missing file appear, repair an invalid key, provide upload capacity, or solve a YouTube-side ingest issue. Where the pain is keeping a broadcast running without leaving a particular computer switched on, StreamNeo removes that specific machine dependency by letting you upload the video and run the YouTube broadcast with your computer off. It does not change the need to prepare suitable media, protect channel access, or check YouTube's stream health.
Test the complete path and separate failures
Run a private or unlisted test through the complete path before relying on it for a public overnight channel. Use the real input, audio, video motion, output settings, and connection that the always-on stream will use. YouTube recommends testing with movement and sound similar to the real stream, then watching stream health and status messages. A still image and silence may conceal problems that become visible once your actual content runs.
Diagnose failures by layer. If ffmpeg -version fails, you have a local installation or path problem. If FFmpeg starts but cannot open the input, check the path, permissions, and media. If an encoder is reported unavailable, revisit the installed build and the selected codec. If encoding falls behind, reduce the processing demand or reconsider the target output. If the connection drops or YouTube reports ingest errors, review the key, destination, network stability, and the messages in Live Control Room. An APT success cannot resolve any of these later-stage problems.
A broken pipe or a remote close is a symptom, not a complete diagnosis. Save the FFmpeg log around the failure and compare it with YouTube's status message and the machine's network conditions. The guide to FFmpeg YouTube broken pipe errors can help organise that investigation. Do not treat automatic restart as the diagnosis: a loop of brief reconnects may hide a persistent key, input, bitrate, or network issue.
After the initial test, deliberately stop and restart the supervised process, then verify that YouTube receives the stream again and that audio and video recover as expected. Test host restart recovery separately if you need the channel to resume after a power cut or maintenance reboot. Watch the broadcast for long enough to observe load and network behaviour, and check YouTube's health indicators rather than relying only on a local message that says the process is running.
The operational comparison is not simply “manual versus automatic”. A local Debian machine gives you direct control over files, command lines, and logs, but you own the host, connection, restarts, and maintenance. A managed workflow reduces the need to keep your own computer running, but still depends on preparing compatible input and monitoring YouTube. For a checklist before moving an established channel, use how to test a YouTube streaming service before moving an always-on channel.
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 installing FFmpeg mean my YouTube stream is ready?
No. It confirms that the package was installed, and the version checks confirm that the local tools start. You still need to verify the input, encoder support, output settings, stream key, upload path, and YouTube's stream health.
Which command installs FFmpeg on Debian?
Refresh package metadata with sudo apt update, then run sudo apt install ffmpeg. After installation, check ffmpeg -version and ffprobe -version; package versions and build details depend on your Debian release and repository state.
Should I use RTMPS or HLS?
YouTube recommends RTMPS in its encoder guidance for RTMP/RTMPS workflows, including CBR and a two-second keyframe interval that should not exceed four seconds. HLS may suit a workflow that accepts higher latency; check YouTube's current guidance and select the protocol your Live setup supports.
How do I keep FFmpeg running after I close the terminal?
Run it under a service manager such as systemd, with a suitable restart policy, startup behaviour, permissions, and logs you can check. Test the service and a controlled restart; supervision can relaunch a process, but it cannot fix an invalid key, unavailable input, insufficient upload, or an ingest problem.