FFmpeg’s progress output can tell you whether the encoder process is continuing to report work; it cannot tell you whether YouTube is receiving a usable stream. A watchdog should monitor the process and its progress feed, while you verify ingest and viewer-facing quality separately in YouTube Live Control Room.
That distinction matters during an unattended broadcast: a live FFmpeg process can be stuck, and a process that is advancing can still be sending a stream with ingest errors or poor audio and video. Use separate signals, define what action each one should trigger, and test the recovery path before relying on it overnight.
Process progress and ingest health are different
Think of monitoring as several checks at different points in the path. FFmpeg’s progress records describe activity inside the encoder. The operating system tells you whether its process still exists and whether it exited. YouTube’s Live Control Room reports what YouTube sees at ingest, and playback inspection gives you a view of what an audience may actually hear and see.
These signals answer different questions. A process can remain present without producing new progress records. It can produce fresh progress records while failing to deliver a healthy stream to YouTube. YouTube may receive the stream and report a technical issue, or the broadcast may look acceptable in the dashboard but have a source problem that is apparent only in playback.
| Signal | What it can tell you | What it cannot establish by itself |
|---|---|---|
| FFmpeg progress update | FFmpeg emitted a completed update recently | That YouTube is receiving the stream or that viewers get good audio and video |
| Process state and exit code | Whether the child process is still running or has terminated | Whether an active process is making useful progress or the ingest is healthy |
| FFmpeg stderr | Diagnostics FFmpeg wrote, including reported errors | A complete picture of YouTube’s ingest status |
| Live Control Room status and stream health | What YouTube reports about the incoming stream | That every viewer’s playback, device or network is trouble-free |
| Playback check | Whether the stream can be seen and heard at the check point | That every part of a long broadcast will remain healthy |
Avoid collapsing these into a single boolean called “live”. Instead, decide what each observation means. A stale heartbeat might justify an alert or a controlled process restart; an ingest warning needs investigation of the stream and encoder settings; an exited process needs its exit status and logs examined. For a playlist stream, a frozen or black interval is a different symptom again; see the FFmpeg playlist black-gap checklist for that specific case.
Enable and read FFmpeg progress output
FFmpeg provides the machine-readable -progress option. It emits records as key=value lines and closes each update with a progress key whose value is continue or end. The documentation describes -stats_period as controlling the reporting interval and lists a default of 0.5 seconds. That is a reporting default, not a watchdog timeout or a promise about how quickly a stream failure will be detected. Check the FFmpeg command-line documentation for the behaviour of the version you run, since installed builds can differ from current documentation.
For an unattended process, a useful starting pattern is to direct progress records to a dedicated channel, such as -progress pipe:1, and send ordinary diagnostics to standard error. For example, an operator might choose -progress pipe:1 -stats_period 1 -nostdin for a process that reports progress on standard output, uses an illustrative one-second update interval, and does not wait for interactive input. The one-second interval is an example configuration choice, not an FFmpeg requirement. -nostdin is useful when no person will be at the terminal to respond to a prompt.
Keep machine-readable progress separate from human-readable diagnostics. Parsing status text from stderr is brittle: wording and formatting meant for people are not a stable record format. Conversely, progress records are not a replacement for stderr. Preserve both streams with timestamps so that an alert or restart can be traced to the conditions that caused it.
The parser should buffer key-value lines into a record and count an update only when it reaches the terminating progress line. Do not reset the heartbeat on every line: a partial record may be delayed or interrupted and is not a complete update. Treat progress=continue as a completed update and progress=end as an end-of-encoding indication, not automatically as a fault. The watchdog should also observe the child process exit and capture its exit code; normal completion, a failed exit and a still-running process with stale output are separate outcomes.
A shell pipeline can make this more complicated than the option syntax suggests. If you place FFmpeg behind a reader or parser, understand which process your supervisor is tracking, how signals reach the child, and how the pipeline reports exit status on your target shell. A production monitor must also handle cleanup when the supervisor itself is stopped. Avoid copying a short loop into a service and assuming it has solved child-process ownership or shutdown behaviour.
Choose signs of a stalled process
A watchdog needs a definition of “stale” that fits the source and operating conditions. Track the wall-clock time when the most recent complete progress record arrives. If the elapsed time exceeds an operator-selected threshold, mark progress stale. FFmpeg does not prescribe a universal threshold, and the reporting period alone cannot determine one.
Allow for normal variation. A file-based loop, a live input, a heavily loaded host and a network interruption can behave differently. If the timeout is too short, ordinary delays can trigger repeated restarts. If it is too long, an actual stall can remain unnoticed. Consider the consequences of both mistakes, then validate a threshold under conditions similar to the real broadcast rather than treating an example from another setup as a rule.
Use more than one condition to classify the event. If the child has exited, record that fact and its exit status; do not describe it as a stalled live process. If the child remains present but no complete records arrive, report a stale-progress condition. If complete records continue but YouTube reports an ingest issue, the process heartbeat is not the relevant fault signal. A quiet source or an intentionally static image can also make visual content look unchanged while the encoder still progresses, so do not use “the picture did not change” as a process heartbeat.
Make the alert tell you which evidence triggered it: process missing, process exited, progress stale, or YouTube status requiring attention. Include timestamps and recent stderr rather than merely saying “stream down”. This makes it easier to distinguish a source-read problem, encoder failure and delivery issue, and reduces the chance that an automatic restart erases useful context.
Design watchdog checks and restart behaviour
A practical watchdog has a small set of responsibilities: own or reliably identify the FFmpeg child, parse complete progress records, record the latest heartbeat time, observe process exit, and take an explicit action when a condition is met. That action may be an alert, a restart, or a stop pending human review. Which choice is suitable depends on whether the stream is unattended, whether interruption is costly, and whether the cause is likely to clear on its own.
Set restart policy separately from detection policy. A stale record is evidence to investigate, not proof that restarting will fix the cause. A restart can help when the encoder is wedged; it may not help when the input file is invalid, the network is unavailable, the stream key is wrong, or YouTube is rejecting the incoming format. Bound retries or use increasing backoff so a persistent fault does not create a tight restart loop. Notify an operator when the retry allowance is exhausted rather than cycling indefinitely.
Before restarting, preserve the previous process’s exit information and diagnostic output. Then stop the child cleanly, allow for shutdown, and ensure the old process is no longer publishing before starting another instance. The correct signal handling and process cleanup depend on the operating system and how the supervisor launches FFmpeg; validate them on the actual host. Protect the stream key as a credential: do not print it in command logs, alert messages or publicly visible scripts.
A recovery policy should also distinguish the end of a planned file or job from a failure. If FFmpeg emits progress=end or exits normally because the input reached its end, an endlessly restarting watchdog may turn intended completion into an unwanted loop. For a 24/7 channel, decide explicitly whether end-of-input should lead to a new playlist cycle, a restart of the same job, an alert or a clean stop.
Test failure handling before the broadcast matters. Simulate a child exit and a stale progress feed in a safe test environment, confirm that alerts identify the right condition, and verify that a restart does not leave duplicate encoders running. Also check the shutdown path: a watchdog that exits while leaving FFmpeg alive can continue sending after the monitoring has disappeared. YouTube’s live streaming tips recommend testing a backup encoder by stopping the primary encoder or disconnecting its Ethernet and checking the player’s rollover. A watchdog test and a failover test are related but not interchangeable.
A progressing process can still have an unhealthy stream
The central limitation is simple: a fresh FFmpeg update says that FFmpeg emitted a progress record. It does not verify the path between the encoder and YouTube, the acceptance of the incoming format, or the quality of the result in playback. Do not configure a green heartbeat indicator as if it were a green ingest indicator.
When you create the broadcast, obtain the stream URL and key from YouTube Live Control Room and keep the key private. YouTube documents RTMP and RTMPS encoder streaming and recommends RTMPS; its RTMPS setup instructions explain that RTMPS is RTMP over TLS/SSL and how to obtain connection details. A correct connection address and protected key are necessary setup details, but neither proves that the current broadcast is healthy.
Likewise, encoder settings should be checked against YouTube’s current guidance for the actual codec, resolution and frame rate. YouTube’s encoder settings and bitrate guidance covers supported codecs, frame rates, bitrate tables and keyframe intervals. Its recommended keyframe interval is two seconds and should not exceed four seconds, but use the current page for the complete settings applicable to your output. These are configuration recommendations, not a watchdog reliability measurement.
If you are operating a long video rotation, distinguish a healthy encoder from healthy content. For example, FFmpeg may be steadily encoding even though the source has a silent section or the playlist has failed to advance. Monitoring should combine process evidence with dashboard status and a separate playback check at sensible intervals. For a 1080p playlist, the YouTube 1080p 30fps settings guide can help you review the output configuration, while still leaving ingest health to the dashboard.
Verify in YouTube Live Control Room
Keep Live Control Room available during setup and while validating the stream. YouTube says the Control Room exposes stream status, metrics and stream-health information; its live stream metrics guide describes the dashboard information. Read any specific status or error message there rather than inferring ingest from FFmpeg output alone. YouTube’s settings guidance also advises monitoring stream health and reviewing messages during the event.
A useful response to a stale heartbeat is to check process state and logs first, then inspect the YouTube dashboard before concluding that the audience-facing broadcast has ended. If FFmpeg is progressing but the dashboard reports a problem, investigate connection, stream settings, source and any message YouTube provides. If the dashboard indicates a healthy incoming stream but your playback check is silent or frozen, inspect the content and playback path rather than treating the process as proof of sound and picture.
For a small channel, this does not require building a large monitoring system. Keep a concise log with timestamps for progress updates, process exits, restart decisions and dashboard observations. Arrange a human check for the conditions the watchdog cannot observe. YouTube’s own live-streaming guidance calls for continuous audio and video quality monitoring; a process monitor cannot listen to the broadcast on your behalf.
Choose an operating model you can maintain
A local FFmpeg watchdog gives you control over the command, logs and restart policy, but you also own the machine, network path, process supervision, credential handling and testing. That can be appropriate when you already operate FFmpeg reliably and can respond to alerts. If the machine sleeps, loses connectivity or reboots without the supervisor returning, the script alone does not keep the channel running.
A hosted approach can remove the need to leave your own computer running, but it changes which tasks you manage and what platform constraints apply. StreamNeo is useful when the specific pain is keeping a personal computer on and checking that an FFmpeg job restarts after a drop: you upload a video, provide your YouTube stream key, and the broadcast runs while your computer is off. It is YouTube-only, so it does not suit a workflow that must publish to several platforms. Whichever model you use, keep the distinction between process activity and YouTube’s reported ingest status.
If you are weighing a self-managed Windows host against a hosted option, the Windows VPS setup guide sets out the former kind of workflow. Your choice should reflect who will notice and diagnose a failure, how often the content changes, and whether you can test recovery before leaving the channel unattended. No operating model removes the need to check YouTube’s current status and your actual playback.
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
How do I know if FFmpeg is still streaming to YouTube?
FFmpeg progress tells you that the process is producing progress updates, not that YouTube is receiving a healthy stream. Check that the process is alive, inspect recent complete progress records and stderr, then verify stream status and health in YouTube Live Control Room. A separate playback check helps assess what viewers may hear and see.
How can I restart FFmpeg if the stream stalls?
Have a supervisor track complete progress records and the child process, then take a defined action when progress is stale or the process exits. Choose and test a timeout for your source and host, preserve logs, clean up the old child, and use bounded retries or backoff. A restart may not resolve an invalid source, connection or ingest problem.
What does progress=end mean?
It marks the end of an FFmpeg progress sequence; it is not automatically evidence of a fault. Check the process exit status and whether the input was expected to finish. For a continuous channel, define whether normal end-of-input should begin another cycle, alert an operator or stop.
Can a watchdog guarantee that my YouTube stream recovers?
No. A watchdog can detect certain process conditions and attempt an action, but it cannot guarantee recovery from every stall or confirm YouTube ingest health from FFmpeg progress alone. Pair it with Live Control Room checks and test your restart and failover procedures before relying on them.