If your radio source is an HTTP(S) stream, FFmpeg can be told to reconnect after a disconnect or when a live feed ends unexpectedly. The options belong before the input URL, and they only apply to the HTTP protocol; first confirm what kind of source you actually have.
If your goal is a YouTube broadcast from a Windows PC, reconnecting FFmpeg is only one part of the setup. You also need an audio path OBS can capture, a channel that is eligible to stream, permission to rebroadcast the station, and a test that proves recovery works under your conditions.
Check YouTube live eligibility
Before configuring audio, check the channel’s current live-streaming eligibility in YouTube Studio. YouTube may require live streaming to be enabled and can apply account or feature restrictions. Requirements and interfaces can change, so use the current YouTube Help instructions for enabling live streaming rather than relying on an old tutorial or a successful test from another channel.
Eligibility is separate from the technical ability to send a signal. OBS can show a healthy connection while YouTube refuses the broadcast, or a channel can be approved while the audio setup is silent. Confirm that the account you intend to use can create a live stream, and resolve any notice shown in Studio before leaving a PC unattended.
For an always-on channel, consider whether the stream needs to remain live through a brief interruption or whether a fresh broadcast must be created after a longer failure. YouTube’s ingest and live control-room behaviour is not the same as FFmpeg’s handling of a radio input. A reconnect flag can restore the source audio to OBS; it cannot correct a disabled live feature or repair the YouTube destination.
Identify how the station audio reaches the PC
There is no single FFmpeg command that fits every radio station. Start by identifying the actual audio source and how it reaches Windows. A station may provide a direct HTTP(S) stream URL, a web player in a browser, an app, a local audio device, or a feed using a different protocol. These paths have different capture and recovery behaviour.
If the station provides an HTTP(S) URL intended for a player or encoder, FFmpeg can open it directly. Check the station’s own documentation for the URL and permitted use; a page URL is not necessarily the media stream URL. A playlist such as M3U or M3U8 can point to another resource, but its format does not by itself establish which transport or options apply. For background on the distinction, see how an M3U8 file is used in live streaming.
If you are listening through a browser or station application, Windows may expose that program’s output as an application audio source, depending on your OBS version and Windows environment. If you are feeding an external mixer or audio interface, you may instead capture a device input. A virtual cable or other routing tool can create a bridge, but it adds another component to test. Do not assume that FFmpeg reconnect settings will fix a browser that stops playing, a device that disappears, or a local routing error.
The key diagnostic question is where a dropout begins. If FFmpeg’s log reports an HTTP disconnect or EOF while it reads a direct URL, reconnect settings may help. If the station player continues but OBS meter activity stops, investigate Windows or OBS capture. If OBS meters continue but YouTube goes offline, investigate the encoder-to-YouTube connection. A guide to troubleshooting a 24/7 stream that stops in India can help distinguish a source problem from a broadcast interruption.
Use Application Audio Capture when applicable
Application Audio Capture is useful when the station audio is played by a desktop application or browser and you want OBS to capture that application rather than all computer sound. In OBS, add the source to the scene and select the station player process where available. Start playback, then watch the source’s audio meter. A moving meter tells you that OBS is receiving signal; it does not confirm that the correct station is selected or that YouTube will receive it.
This path differs from opening the radio URL with FFmpeg. Application capture records the audio output of a chosen application after playback has begun. FFmpeg’s HTTP options instead govern its own network connection to an HTTP(S) input. If you use the browser path, FFmpeg’s reconnect flags do not control the browser’s buffering, login, autoplay, or playback behaviour. You may need to configure the player itself to resume, or choose a direct source and a suitable input workflow instead.
Avoid capturing both the application and the same audio through a desktop-audio source unless you deliberately want both. Duplicate routes can create doubled sound, echo, or a level increase. Mute unrelated applications and notification sounds, and check whether a microphone or desktop device is also active in the scene. For a mixed programme with station music and spoken links, make the intended balance clear before testing; a practical OBS guide to placing music between videos covers one related audio arrangement.
Application Audio Capture may not be available or suitable in every setup. It depends on the OBS and Windows environment and on how the application exposes audio. If you do not see the source type, cannot select the player, or get no meter response, verify the documented requirements and use a supported capture path rather than assuming a particular Windows audio configuration will work.
Confirm the documented Windows requirement
Check the current OBS documentation for the Windows version required by Application Audio Capture before building your scene around it. The feature has a documented Windows requirement; it is not a promise of compatibility with every release of Windows, every OBS build, or every audio driver. Use the OBS Project’s Application Audio Capture guide as the authority for current compatibility and setup details.
If your PC does not meet that requirement, consider a different route: use a supported device capture, a virtual audio device that you have tested, or a separate encoder workflow. Each adds its own failure modes. A device may change names after an update; a virtual cable may not start after reboot; a browser may pause or prompt for interaction. Record what source you selected and test again after restarting the PC.
Do not solve a compatibility issue by blindly updating a production machine in the middle of a live run. Check OBS release information and the requirements for the version you plan to use, then test the change off-air. If an upgrade is necessary, verify audio meters, scene transitions, stream key, and recovery before relying on the new setup overnight.
Configure the OBS scene and YouTube destination
Create a scene for the broadcast and add only the sources needed: the station audio path, a static image or visual loop if appropriate, and any other deliberate elements. Set a sensible audio level and monitor the meter without clipping. If the station is stereo or includes quiet speech, test on headphones and on a separate device; meter movement alone cannot tell you that the audience will hear the right balance.
In OBS, configure the YouTube service and destination through the stream settings or the current YouTube integration flow. YouTube Studio provides the stream key or connection details for the event you create. Treat a stream key as a credential: do not paste it into a public post, screenshot, or command shared with others. If it is exposed, replace it through Studio. The YouTube Live encoder setup guide explains the current broadcast setup process.
Choose output settings supported by the source, PC, and YouTube’s current recommendations. Avoid copying settings from a different project without checking resolution, frame rate, audio format, and available bandwidth. For a radio-led channel, a static or simple visual may be sufficient; encoding a complex moving scene adds load without improving the audio. Keep the OBS log and a note of the settings you tested so a later change can be compared with a known working setup.
If you are using an HTTP stream directly with FFmpeg, the command line is useful for a separate capture or relay workflow, but it is not automatically an OBS source just because it plays audio. You need a deliberate bridge between FFmpeg’s output and OBS, such as a supported input method or local audio route, and must test that bridge. If your actual aim is to run a prepared video continuously rather than keep a radio player alive on a PC, that is a different operating problem; a comparison of cloud GPU costs for a 24/7 YouTube channel may help frame the trade-off.
Set FFmpeg reconnect options for HTTP(S)
For an HTTP(S) radio input that FFmpeg reads directly, a starting example is:
ffmpeg \
-reconnect 1 \
-reconnect_streamed 1 \
-reconnect_at_eof 1 \
-reconnect_on_network_error 1 \
-reconnect_on_http_error 5xx \
-reconnect_delay_max 30 \
-reconnect_max_retries 20 \
-i "https://radio.example/stream" \
-c copy output.mp3
The sample uses illustrative retry policy values, not a guarantee or a recommendation for every station. The reconnect options are placed before -i because they configure the following input. With multiple inputs, keep each option adjacent to the input it is intended to affect. Replace the example address with a documented stream URL and choose an output appropriate to your workflow; -c copy is shown as an example, not a universal way to feed OBS.
The core options cover related but distinct events. -reconnect 1 enables retries after disconnection before EOF. -reconnect_streamed 1 permits reconnection for streamed or non-seekable inputs, which describes many live radio feeds. -reconnect_at_eof 1 treats an unexpected end of input as a failure worth reconnecting from. The FFmpeg Project explains that EOF handling is useful for live or endless streams in its HTTP protocol documentation.
The remaining options are more targeted. -reconnect_on_network_error 1 covers TCP or TLS errors during connection establishment. -reconnect_on_http_error 5xx asks FFmpeg to retry selected HTTP responses; the protocol accepts individual codes and classes such as 4xx or 5xx. Pick only statuses that could be temporary for your source. Retrying an authentication failure or a permanently removed URL does not make the source valid.
-reconnect_delay_max bounds the maximum individual delay under the retry policy, while -reconnect_max_retries bounds attempts. The documentation also describes -reconnect_delay_total_max for capping total waiting time. These bounds matter if a process must terminate or be supervised rather than retry forever. FFmpeg documents respect_retry_after as enabled by default: where supported, it honours a server’s Retry-After instruction instead of relying only on exponential backoff, with 429 and 503 among relevant cases.
| Configuration choice | Failure it addresses | What to check |
|---|---|---|
| Core reconnect flags | Disconnects, streamed input errors, and EOF | Confirm the source is live and HTTP(S) |
| Add network-error retry | TCP or TLS connection failures | Check whether logs show connection establishment errors |
| Add selected HTTP statuses | Recoverable server responses | Retry only statuses the station may resolve |
| Bound attempts and delay | Long or supervised jobs | Decide how long a silent source may be tolerated |
Before using any example, check the installed binary. FFmpeg options and defaults can vary by release; run ffmpeg -h protocol=http and read the output and logs from the version you actually use. These options belong to FFmpeg’s HTTP protocol. Do not transfer the command unchanged to RTSP, RTP, SRT, or another transport just because the address looks like a stream.
Check rights and channel allowlisting where needed
Technical access to a radio stream does not grant permission to rebroadcast it on YouTube. Confirm that you have rights for the station audio, recordings, underlying music and any other material in the feed, for the intended platform and territory. A station name in a title or an available stream URL does not establish those rights or the territory in which they apply.
Ask the station or rights holder for terms that cover the actual use: continuous live retransmission, the relevant channel, the platforms, and the territories you intend to reach. Keep written permission and note any conditions, such as required attribution, restrictions on monetisation, or a limit on the content you may carry. If you are relying on a licence or agreement, check its wording rather than inferring scope from a past broadcast that remained online.
If a rights holder or distributor operates a YouTube allowlist or Content ID policy, ask whether your channel needs to be added and what identifiers they require. Allowlisting can affect how claims are handled, but it is not a substitute for permission. YouTube’s copyright and Content ID help is a starting point for understanding platform notices; for a disputed claim or unclear licence, get advice from the relevant rights holder or a qualified professional.
A station feed may include adverts, announcements, guest segments or music beyond the material named in an agreement. That can create a mismatch between the rights you have and what the encoder actually sends. Monitor what goes to air and agree with the station how changes in programming are handled. Keep a contact route for the person who can clarify a claim or temporarily ask you to stop the relay.
Test and monitor the broadcast
Test each layer separately before relying on the channel. First confirm that the station plays from the chosen input. For direct FFmpeg input, inspect its logs and verify the audio reaches the intended output. For application capture, confirm the correct process is selected and the OBS meter moves. Then check the OBS programme output, start an unlisted or otherwise controlled test if suitable, and listen to the resulting YouTube playback from a separate device.
Simulate a recoverable interruption only in a controlled test. For example, briefly disconnect the source network or stop the player, then observe whether FFmpeg reports a reconnect attempt and resumes, or whether the browser or device path needs separate action. Do not assume that seeing a reconnect message proves the stream recovered: listen for sound and inspect both the local meters and the YouTube playback. Note the time and log message so you can compare a later failure.
When the test fails, classify the evidence before changing flags. EOF suggests the source closed cleanly; TCP or TLS errors point to connection establishment; an HTTP status indicates a server response; authentication errors or a changed URL require correction rather than more retries. If audio reaches OBS but the YouTube broadcast drops, the radio-side reconnect policy is not the relevant control. Keep a simple incident note covering the symptom, likely layer, and change made.
For unattended operation, decide who will notice silence and who can respond. A PC can sleep, reboot for updates, lose a device, or lose internet even when FFmpeg’s retry policy is sensible. Set the Windows power behaviour deliberately, consider the effect of updates, and check that the station player or encoder starts again after a reboot. Review logs and playback at intervals that suit the channel; no retry flag replaces a person or alerting method noticing a persistent failure.
If keeping the PC on and checking it is the pain point, StreamNeo can run an uploaded video as a 24/7 YouTube stream without keeping your own computer switched on; that addresses a different workflow from relaying a live radio URL, so check whether your source and rights fit before choosing it.
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 FFmpeg reconnect when a live radio stream reaches EOF?
It can if you enable -reconnect_at_eof 1 for an HTTP input. That treats EOF as an error and asks FFmpeg to reconnect, but the source must still be reachable and permitted to serve the stream again.
Do these options work for every radio stream protocol?
No. The options discussed here are documented for FFmpeg’s HTTP protocol, so identify the transport first. A different protocol needs its own documentation and may use different reconnect behaviour.
Does Application Audio Capture work on every Windows PC?
No. OBS documents a Windows requirement for the feature, and availability also depends on the OBS build and audio setup. Check the current OBS guide, then test the exact player and PC you plan to use.
If OBS captures the station, do I have permission to stream it?
No. Capture is only a technical route for audio; it says nothing about copyright, licence scope or territory. Confirm the rights with the station or rights holder and check whether channel allowlisting is required.