A YouTube radio stream needs two jobs done separately: Liquidsoap builds the audio programme, while FFmpeg encodes the combined audio and video for YouTube Live. YouTube then receives that encoded feed through the server URL and stream key created in YouTube Studio.
For an audio-first channel, you still need a video signal. A still image, branded loop or other suitable visual can accompany the music, but the exact Liquidsoap syntax depends on the installed version and the way your audio files are arranged. Treat the examples below as a workflow to adapt and test, not as a script guaranteed to work everywhere.
1. Understand the division of labour
Liquidsoap is the programme layer. It chooses tracks, applies playlists and schedules, switches between sources, handles transitions, and can provide fallback audio if the main source is unavailable. It can also accept a live input, although you do not need a live DJ source for a playlist-only radio stream.
FFmpeg is the encoding and transport layer. It takes the audio and video supplied by the programme, encodes them into formats accepted by YouTube, combines them into one stream, and sends that stream to YouTube’s ingest address. It does not decide which song plays next unless you build a separate playlist system around it.
YouTube Live is the destination and monitoring layer. You create or select a live event in the Live Control Room, obtain the server URL and stream key, and inspect the preview and stream-health messages before making the broadcast public. YouTube also performs its own processing for viewers, so a locally clean feed can still require attention if the Live Control Room reports a problem.
This separation makes troubleshooting more orderly. If the wrong track plays, investigate Liquidsoap. If the audio is present but the video is missing, inspect the visual source and muxing stage. If the local output looks correct but YouTube does not receive it, check FFmpeg’s output address, authentication details and network connection.
The FFmpeg or OBS comparison for 24/7 streaming is useful if you are still deciding whether this split workflow suits your channel. FFmpeg and Liquidsoap offer control, but they also give you more separate parts to test than a single desktop broadcasting application.
2. Create the continuous programme in Liquidsoap
Start with the part that should remain true even before YouTube is involved: the audio programme. Put the music or spoken-word files in a known directory, check that you have the right to use them, and decide how the channel should behave when a file cannot be read.
A simple Liquidsoap design normally contains:
- a playlist source that reads files in sequence or according to its configured ordering
- optional scheduling rules for recurring blocks, announcements or jingles
- transitions between items
- a fallback source for an empty playlist or failed input
- an output that sends the resulting audio towards the encoding stage
The basic pattern is deliberately simple because it gives you a known starting point. A playlist may look conceptually like this:
radio = playlist("/path/to/audio")
radio = fallback([radio, blank()])
This is not a complete station configuration. Function names, supported options and playlist behaviour should be checked against the documentation for the Liquidsoap version installed on your machine. The Liquidsoap quickstart explains the source-and-output model, while the source and output reference is the better place to check current details.
The fallback deserves attention. A silent fallback can prevent the pipeline from stopping, but it may produce a silent broadcast that appears healthy at first glance. A short legal station ident, a spoken holding message or another approved source may make an operational failure easier to notice. Whatever you choose, make sure it is content you are permitted to broadcast.
Scheduling is where a radio stream becomes more than a folder played repeatedly. You might use one source for devotional music during the morning, another for a local news loop, and a third for overnight ambience. Build and test these rules separately before adding encoding. A schedule error is easier to identify when you are listening to Liquidsoap’s output directly rather than looking through FFmpeg and YouTube at the same time.
If you expect to change the playlist while the stream is running, decide how those changes should be detected and whether the current item should finish. Do not assume that every playlist service or script updates an active source in the same way. The explanation of playlist updates while live covers the operational question from another angle, but the same principle applies here: test an update during a controlled broadcast before depending on it overnight.
3. Add a visual source for an audio-first channel
YouTube Live is a video broadcast, so audio alone is not enough for the conventional encoder workflow. Add a visual source before you ask FFmpeg to send the programme to YouTube.
The least complicated visual is a still image containing the station name, current programme information and any wording you genuinely need viewers to see. You could also use a slow visual loop or a separate video source, but additional motion introduces more encoding work and more things to inspect. A still image is often suitable for a devotional, lofi, study or local information channel when it is clear and readable.
The image should have the dimensions and format you intend to encode. Avoid testing with an unusually large source and then changing it at launch. If the image contains small text, view it at the same resolution you plan to send to YouTube. A title that is legible in an image editor may be difficult to read in a mobile player.
Liquidsoap’s FFmpeg cookbook demonstrates the general process of creating video from an image, selecting an FFmpeg encoder, and combining the video with audio. The FFmpeg cookbook is version-sensitive documentation, so compare its current examples with the syntax accepted by your installation.
Conceptually, the pipeline is:
audio playlist → Liquidsoap programme
still image or video → visual source
programme + visual → FFmpeg encoder and muxer
muxed stream → YouTube Live
The important point is that the visual source is not a decoration added after YouTube receives the broadcast. It is part of the feed that FFmpeg must encode and mux. If it is absent, incorrectly sized or not connected to the output, YouTube may report that the video signal is missing even though Liquidsoap is playing audio normally.
You can also use a video loop, but check its duration and behaviour at the join. A loop that freezes briefly or changes resolution can create an avoidable test failure. For a station whose main value is audio, start with the least complicated visual that meets your viewers’ needs, then add motion only if it serves a clear purpose.
4. Pass the programme to FFmpeg
Once Liquidsoap can produce audio and a visual source is available, connect them to the FFmpeg output path. This is the point at which the radio programme becomes a YouTube-compatible media stream.
Liquidsoap documentation shows more than one way to use FFmpeg. Its YouTube-related output reference includes an FFmpeg encoder, while the cookbook also demonstrates an output URL with an RTMP address. These examples explain the structure of the workflow, but they are not a promise that one block of code will run unchanged across Liquidsoap releases, operating systems or package builds.
Before copying an example, check:
- the installed Liquidsoap version
- the matching reference documentation
- the FFmpeg version available to that installation
- the names and arguments of the encoder and muxer functions
- whether the chosen output accepts the audio and video source types you created
- whether the output expects a URL directly or receives it through a separate FFmpeg configuration
Keep the first test local if possible. You want to know whether Liquidsoap and FFmpeg can create a valid combined feed before adding YouTube authentication. Depending on your setup, this might mean writing a short local media file or sending the output to a controlled local endpoint. The exact command is environment-specific, so the purpose is more important than a universal copy-and-paste line: verify that audio and video are both present and remain synchronised.
The roles should stay visible in your configuration. Liquidsoap should determine what the station is playing. FFmpeg should encode and transport that programme. If you put playlist logic, visual generation and remote delivery into one opaque command, a failure becomes harder to isolate and a future version change becomes harder to manage.
Use a configuration file or environment-specific secret file rather than placing every value in a command typed into a shell. Keep the programme settings, visual settings and delivery settings separate where practical. That makes it easier to change the YouTube event without accidentally changing the station schedule.
5. Choose encoder settings from YouTube’s current guidance
YouTube’s encoder requirements are not a single universal bitrate. The suitable value depends on the selected resolution, frame rate and video codec, as well as the upload capacity available to the sending machine. Use YouTube’s current encoder settings, bitrates and resolutions rather than treating a value from an old tutorial as a permanent rule.
For the general RTMP workflow, YouTube’s guidance supports H.264, H.265/HEVC and AV1 video, with frame rates up to 60 frames per second. It calls for constant bitrate encoding and recommends a two-second keyframe interval, with no more than four seconds. For stereo audio, its advanced settings list AAC or MP3, a 44.1 kHz sample rate and 128 Kbps audio bitrate.
Those figures are configuration guidance, not evidence that a particular setting will improve audience growth or reliability. A radio station with a still image may not need the same visual treatment as a channel showing fast-moving footage, but you should still select a resolution and bitrate pairing from YouTube’s current table. Lowering the resolution can reduce upload demand, while raising it increases the amount of data that must reach YouTube consistently.
| Decision | What changes | What to check |
|---|---|---|
| Resolution | The size of the video frame and the corresponding bitrate range | Whether text in the visual remains readable |
| Frame rate | How often video frames are sent | Whether your visual source and encoder need a higher rate |
| Codec | The way video is compressed | Whether the selected Liquidsoap and FFmpeg path supports it |
| Keyframe interval | How often full reference frames are inserted | YouTube’s recommended two seconds and four-second maximum |
| Audio format | The codec, sample rate and bitrate used for sound | That the setting matches the current YouTube guidance |
Run an upload test from the location that will actually send the stream. YouTube advises leaving 20% headroom rather than operating at the full measured upload capacity. Include the combined audio and video bitrate in your planning, and account for any primary and backup feed where that applies. An internet connection that looks adequate for browsing can still be unsuitable if other devices consume its capacity overnight.
If you choose HLS instead of the RTMP or RTMPS workflow, stop and read the relevant HLS instructions. HLS has its own ingestion requirements, segment behaviour and latency considerations. Do not copy RTMP settings into an HLS configuration without checking the current documentation.
6. Connect FFmpeg to YouTube Live
In YouTube Studio, create or select the live stream in the Live Control Room. YouTube supplies a server address and a stream key for the encoder connection. Its encoder setup guidance describes this process and the information your encoder needs.
The stream key functions as a credential for the broadcast. YouTube describes it as an address and password for the stream, so handle it accordingly. Do not paste it into a public tutorial, commit it to a public code repository, include it in screenshots, or leave it in a shared terminal history.
The final output configuration needs to combine the correct server URL with the key in the form expected by the selected Liquidsoap or FFmpeg output. Some examples place the key in a URL; others read it from a separate file. The Liquidsoap cookbook demonstrates the latter approach. Follow the syntax for your installed version rather than assuming that a key-file option has the same name everywhere.
YouTube recommends RTMPS for encrypted ingestion. However, the Liquidsoap YouTube-specific reference may show an RTMP default, and support for a particular RTMPS arrangement can depend on the installed build and output method. Verify the endpoint, protocol and build support before claiming that your connection is encrypted or correctly configured.
In the Live Control Room, keep the stream private or unlisted while testing if that matches your purpose. Check the preview before making the event public. If YouTube reports that it is not receiving data, return to the local output and then inspect the server address, key, firewall, protocol and network route in that order.
7. Test the exact stream before leaving it unattended
A short local test is useful, but it is not enough. Test the same Liquidsoap programme, visual source, FFmpeg settings, YouTube event type and network connection that you intend to use for the live channel. Changing several of these at launch makes a failure difficult to diagnose.
Start Liquidsoap and listen to the programme. Confirm that the playlist advances, scheduled items appear when expected, transitions are sensible and the fallback behaves as intended. Then confirm that FFmpeg sees both audio and video. Look for errors rather than assuming that a process which remains open is healthy.
Next, start the YouTube output and wait for the Live Control Room preview. Check that:
- the audio is audible without clipping or long silent gaps
- the visual is present and readable
- audio and video stay aligned
- the selected resolution and frame rate are reported as expected
- stream health does not show a recurring ingestion or encoding warning
- the programme continues when one track ends
- the network connection does not repeatedly reconnect
YouTube’s streaming tips recommend testing and monitoring the broadcast. Keep the Live Control Room open during the first full trial rather than checking only that the initial preview appeared. A stream can begin normally and fail later when a playlist item changes, a scheduled rule runs or an input becomes unavailable.
Test the failure cases you can reproduce safely. Remove or rename one test audio file and observe the fallback. Use a deliberately short visual loop and watch its join. Restart FFmpeg while keeping the event available. These checks do not prove that every future failure will recover, but they reveal whether your configuration has a defined response instead of silently stopping.
If the exact test passes, document the versions, file paths, output settings and YouTube event configuration. Save the working configuration privately. When a package is upgraded, repeat the local and YouTube tests before treating the new version as suitable for an unattended broadcast.
For comparison, a desktop setup has different failure points. The guide to setting up OBS on a low-end PC in India is relevant if your priority is a visual interface rather than separating programme scheduling from encoding. Neither approach removes the need to test the exact stream.
8. Protect the key and plan for unattended operation
Treat the stream key as you would any other password. Store it outside public configuration examples, restrict access to the file that contains it, and replace or reset it in YouTube Studio if you believe it has been exposed. Do not ask a helper to send it through a public chat when a private credential-sharing method is available.
Keep logs useful but safe. A log should help you identify a failed connection, encoder error or missing input without printing the complete stream key. Review the first logs after launch to make sure the credential is not being echoed by a wrapper script or error message.
Unattended operation also needs a recovery plan. Decide who will notice a stopped process, who can access the machine or service, and what should happen after a reboot. Automatic process restarts can help with a crashed process, but they do not correct a bad Liquidsoap schedule, an expired credential, a failed disk or an unsuitable upload connection.
If your computer must remain on and connected for the whole broadcast, compare that responsibility with a cloud-based arrangement. StreamNeo is intended for the specific case where you upload the prepared file, provide the YouTube key, and let the broadcast run while your own computer is switched off, with monitoring and automatic restart for a dropped broadcast. It is YouTube-only, so it does not replace a Liquidsoap and FFmpeg installation when you need local programme logic or a different destination.
Do not describe any arrangement as guaranteed continuous uptime. Monitor the live page, keep a copy of the station configuration, and decide how you will communicate with viewers if the channel has to stop. YouTube’s archive behaviour also has limits: YouTube says streams under 12 hours are automatically archived, so do not assume the same treatment for a longer broadcast.
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
Can Liquidsoap send audio to YouTube without FFmpeg?
Liquidsoap can manage the audio programme, but a conventional YouTube Live broadcast needs a video signal and an encoded audio-video output. FFmpeg is the part of this workflow that encodes and muxes those media streams for delivery. The exact integration depends on the Liquidsoap version and output method.
Do I need Harbor for a playlist-only radio stream?
No. Harbor is relevant when you want to accept a live input such as a DJ or presenter source. A playlist-only station can use a playlist and other Liquidsoap sources without making Harbor part of the design.
Can I publish the stream key in a script?
Do not publish the real key. Keep it in a protected file or secret mechanism supported by your setup, and use a placeholder in documentation. Reset it in YouTube Studio if it has been exposed.
Will the stream run continuously overnight?
The workflow can be designed for unattended operation, but no script guarantees continuous uptime across all versions, machines and networks. Test the exact feed, monitor YouTube’s stream health, and plan for failures in the programme, encoder, connection and host.