If you are asking how to make FFmpeg reconnect to a YouTube live stream without starting the playlist over, first identify what FFmpeg is doing: reading a live HLS playlist, or sending a local playlist-based programme to YouTube. HTTP reconnect options can retry eligible connection failures, but they do not save a durable playlist-position checkpoint.
The side that failed determines which controls matter. For HLS input, initial live start and segment retries are demuxer concerns; for a local playlist sent to YouTube, preserving the current item across a process restart requires your scheduler or wrapper to save and restore it.
First identify whether FFmpeg is reading or sending
Look at the FFmpeg command and label each URL before changing anything. A URL following -i is an input: FFmpeg reads from it. A destination URL at the end of the command is an output: FFmpeg sends media to it. This small distinction prevents a common mistake: input-side HTTP options cannot repair a failed output connection.
For example, if the command reads https://example.invalid/live.m3u8 after -i, FFmpeg is consuming an HLS feed. That may be YouTube's live stream, another HLS source, or a test playlist; the fact that the destination is YouTube is a separate question. If instead -i points to a local video and the final destination is YouTube's ingest URL, FFmpeg is publishing a local programme. A playlist file or a wrapper may decide which local clip is played next.
Some setups do both: FFmpeg reads an HLS source and sends the decoded or copied media to a separate destination. In that case, failures on either connection have distinct symptoms and need distinct remedies. Write down the input, output, and process that owns playlist selection before applying flags.
If your goal is an always-on channel made from recorded videos, it helps to separate content scheduling from the act of sending a live broadcast. The guide to building an always-on channel from pre-recorded videos covers the broader workflow. For this specific problem, keep asking whether the lost position belongs to an HLS source or to your own item list.
Determine which connection failed first
Start with the first failure, not the last visible message. FFmpeg logs can show input read errors, output write errors, protocol timeouts, or an orderly end of input. A downstream error may only be the consequence of an earlier failure. If the input ended and FFmpeg then closed the output, reconnecting the YouTube destination does not restore the input's place. If the output dropped while the input continued or was stopped, an input reconnect flag is not the right fix.
Record the timestamp, the URL or stream direction involved, the error line immediately before shutdown, and whether the FFmpeg process stayed alive. Then note what happened to the programme: did the same process resume, did a supervisor launch a new process, or did a playlist controller select a new item? Those cases have different state boundaries. A process that remains alive may retain some demuxer state; a newly launched process starts with whatever state its command and wrapper provide.
For a YouTube publishing setup, distinguish the local encoder-to-ingest connection from the YouTube viewer-facing live event. The operator may see a connection warning in streaming software while the event remains open, or the event may end independently. Do not infer a YouTube-specific resume guarantee from FFmpeg's HTTP options; the available FFmpeg documentation does not establish one. Check the current official YouTube guidance for the ingest workflow and interpret the stream health indicator separately from local playlist state.
This diagnosis also helps when designing a channel around unreliable local internet. A stream generated away from a home computer may avoid the local machine's power and connectivity dependencies, but it does not change how FFmpeg defines input retries or playlist state. See the practical discussion of keeping a lecture stream running during internet outages in India for the separate question of where the broadcast process should run.
What HTTP reconnect options actually retry
FFmpeg's HTTP protocol options address transport-level recovery for HTTP operations. The reconnect option is documented to reconnect when disconnected before EOF. reconnect_streamed applies to streamed or non-seekable inputs, where ordinary seeking back through the source is not available. reconnect_on_network_error can address TCP or TLS errors while establishing a connection. These options can help an eligible HTTP input recover from some failures, but they do not encode the identity of a playlist item or a media sequence position.
The options are not interchangeable with an application checkpoint. A reconnect may take place while a single FFmpeg process still has useful context, but that is not the same as writing a durable cursor to disk and restoring it after a process restart. Nor does a retry policy establish whether replaying some media is acceptable. Depending on the source and failure point, a resumed read can include repeated content, skip content, or fail to continue at all. Test the actual source and output path before relying on a particular outcome.
reconnect_at_eof deserves special care. It treats EOF as an error and triggers reconnection, which can be useful when an apparently ended HTTP resource is meant to continue as a live or endless stream. It is wrong when EOF means the file or programme genuinely finished. For a finite recorded clip, blindly reconnecting at EOF may make it repeat rather than advance to the next playlist item.
HTTP status retries should also be selective. reconnect_on_http_error lets you choose status codes that may merit retrying, but an authentication problem or an unavailable resource usually needs a different remedy from a transient response. Retrying every HTTP error can hide a configuration problem and create a loop without progress. Consult the FFmpeg HTTP protocol options for the option semantics supported by the installed version.
Retry bounds are operational choices, not continuity guarantees. The protocol provides controls such as reconnect_delay_max, reconnect_max_retries, and, in supported versions, reconnect_delay_total_max. The implementation defaults described by current FFmpeg material can differ from packaged builds, so inspect the installed binary rather than assuming a default. Set a finite policy appropriate to your monitoring and failure response: an unlimited retry can leave a dead source appearing superficially active, while a short limit may give up during a longer outage.
HLS start position and segment behaviour
When the input is HLS, HTTP reconnect flags are only one layer. The HLS demuxer sees a playlist of media segments and has its own controls for the initial live position and for retrying an errored segment. The starting segment is not the same concept as the point at which a previously running process stopped, and neither is automatically a saved restart checkpoint.
live_start_index chooses the segment index from which a live stream starts. Negative values count from the end of the current playlist, so the choice can express a position relative to the most recent listed segments rather than a fixed item from the beginning. That is useful for choosing a starting offset when opening a live playlist; it does not promise that an older segment will still exist after an outage or process restart.
The playlist may carry an #EXT-X-START tag. With prefer_x_start enabled, FFmpeg prefers that tag over the configured live_start_index. This means the source's playlist can influence where FFmpeg begins. If the observed start surprises you, inspect the playlist and the demuxer settings together rather than changing an HTTP retry flag.
For a segment that fails to load, seg_max_retry controls how many retries the HLS demuxer makes before moving on according to its behaviour. The documented default is zero retries. Increasing it may allow a temporarily inaccessible segment another chance, but also adds delay; it does not force the playlist to retain that segment indefinitely. A live playlist normally represents a moving window, so older media can disappear while FFmpeg is offline.
The HLS controls and HTTP controls solve related but separate problems: protocol reconnection concerns the HTTP connection, while demuxer settings concern starting and handling playlist segments. Review the FFmpeg demuxer documentation and check -h demuxer=hls or the relevant help output for your build. Documentation on the FFmpeg site is rolling; an older distribution package may not support every option shown in current references.
Preserve a local playlist position explicitly
If FFmpeg is sending a local programme to YouTube, the playlist position is usually owned by a playlist driver, shell wrapper, scheduler, or media application. FFmpeg's output reconnect behaviour does not know that your programme was on item four rather than item one. If the process restarts and the command always begins at the first file, it will do exactly that unless the surrounding application supplies a different starting item.
Persist state outside the process. A small controller can store the current playlist item identity and update it when a clip completes or when policy says to advance. When launching FFmpeg, the controller can select that item or reconstruct the appropriate input sequence. For an HLS source you control, a media sequence or other stable segment identifier may serve as a checkpoint, but only if the source and workflow make it meaningful. A moving third-party live playlist may no longer contain the recorded position by the time you attempt recovery.
Decide what “resume” means for your channel before implementing it. If your priority is avoiding gaps, you might prefer to restart the current clip from its beginning and accept a repeat. If you want to avoid duplicates, you may prefer to advance, accepting that a portion could be missed. If the priority is minimising downtime, restarting from a known item may be simpler than trying to recover an exact timestamp. No policy can guarantee gapless or duplicate-free output without source-specific state and testing.
A practical controller should make its choice inspectable. Log the item identity it saved, the reason a new process started, and the item it selected on restart. Store state atomically so a power loss does not leave a partly written cursor. Keep a known-good fallback for missing files, and decide whether an incomplete current item should replay or be skipped. These are workflow rules, not FFmpeg reconnect flags.
For a long-running radio or devotional channel, the playlist logic and broadcast transport deserve separate monitoring. The guide to running a 24/7 internet radio station on YouTube is relevant to the programme side, while monitoring an FFmpeg YouTube stream on a VPS addresses watching the process and output. Neither monitoring nor transport retries replaces saved item state.
Test recovery without assuming a checkpoint
Test on a private or otherwise appropriate test broadcast before changing a live channel. Use a short, known playlist and record the starting item and approximate playback point. Introduce one failure at a time: interrupt the input network path, interrupt the output path, stop the FFmpeg process, and, where applicable, make one HLS segment unavailable. Observe the logs and actual output after each case. Do not treat a successful transient retry as evidence that a later process restart will restore the same position.
Use a test matrix to make the differences visible:
| Failure or change | Likely control boundary | What to verify |
|---|---|---|
| HTTP input disconnects before EOF | HTTP protocol retry | Whether the same process reconnects and reads useful media |
| HLS segment request errors | HLS demuxer segment retry | Whether retries delay or skip the segment, and whether it remains listed |
| Live HLS process starts again | HLS live-start policy | Which current segment is selected after restart |
| YouTube output connection fails | Output transport and publishing workflow | Whether output recovers, and whether the input/player kept its place |
| FFmpeg process is relaunched | Wrapper or scheduler state | Which item identity the new process receives |
Repeat tests with the exact FFmpeg build and command that will run in production. Preserve logs around failure and recovery; compare the programme content, not just whether a process exists. A process can be running while publishing no useful frames, and a reconnect message does not establish that the intended playlist position was restored. Review the stream's status using the current official YouTube Live streaming help as well as your local logs.
Write down the accepted compromise. For example, a bhajan channel might choose to replay the current track after an uncertain restart, because that is more intelligible than beginning halfway through a track. A local news loop might instead prefer to skip a stale item and carry on. The right policy depends on content and audience; the test tells you what the mechanisms do, while the policy tells your wrapper what to do with that information.
If your operational pain is keeping a computer switched on and recovering a broadcast process after a drop, StreamNeo removes that specific burden by turning an uploaded file into a continuing YouTube live stream without relying on your own computer to stay running. It does not change the distinction between HLS input controls and a saved playlist cursor, so choose it for the hosted broadcast workflow rather than as a claim of exact FFmpeg playlist resumption.
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
Do FFmpeg reconnect flags preserve the playlist position?
No. HTTP reconnect options retry eligible connection failures; they are not a durable cursor for a playlist. HLS start and segment options control separate demuxer behaviour, while exact state across process restarts must be supplied by the application or wrapper.
Should I use reconnect options on the YouTube output URL?
First confirm that the output connection is what failed and check the destination's current guidance. Input-side reconnect flags do not fix an output failure, and FFmpeg documentation does not establish a YouTube-specific promise that an output reconnect resumes the same programme position.
What is the difference between live_start_index and seg_max_retry?
live_start_index chooses an initial segment offset for a live HLS playlist; negative offsets count from the end of the playlist. seg_max_retry concerns retrying a failed segment, not selecting the initial position or restoring a position saved by a previous process.
How can I resume the same local playlist item after a restart?
Have the scheduler or wrapper save the current item identity and pass that state into the next FFmpeg launch. Decide whether to restart that item, advance, or accept possible gaps or repeats, then test the policy with the same files, FFmpeg build, and output workflow you intend to use.