If you already have a Liquidsoap radio source, you can send it to YouTube Live by adding a video track, encoding and muxing audio and video, then handing the resulting stream and your key to Liquidsoap’s YouTube RTMP output. The exact commands depend on your installed Liquidsoap and GStreamer versions and plugins, so treat examples as a design to validate, not a universal recipe.
YouTube Live receives a video broadcast, not an audio-only radio feed. A still station image can supply the video track; an animated visual is another choice, but adds work and processing. Before you build, confirm which tools and codecs your installation actually provides and test the complete route in YouTube Live Control Room.
Check versions and installed components
Liquidsoap’s documented YouTube destination is output.youtube.live.rtmp. It takes a source, an encoder and a stream key; its reference documents an RTMP URL default. The details around encoder construction and available operators can change between Liquidsoap releases, so first record the installed version and use the reference documentation for that release rather than copying code from development documentation.
This matters particularly when your design uses GStreamer. GStreamer is a framework with separately installed elements for reading files, decoding, encoding and transport. A system may have the GStreamer command-line tools but lack the particular demuxer, codec or sink your planned pipeline needs. Liquidsoap’s FFmpeg integration is also an external build/package capability, not something to assume merely because Liquidsoap runs.
Check the installed versions using the package manager or version commands appropriate to your operating system. Then inspect available GStreamer elements with gst-inspect-1.0 and the relevant element name, where that utility is installed. Check Liquidsoap’s own help or matching reference for output.youtube.live.rtmp, FFmpeg support, and the syntax used to construct a source and encoder. The Liquidsoap source and output reference is a starting point, but choose documentation matching your installed release.
A useful inventory is practical rather than exhaustive: can the system read every playlist item you intend to use; can it decode those formats; can it provide a video source; can it encode the selected audio and video codecs; and can it mux and send the output over the protocol supported by your chosen Liquidsoap route? If any answer is uncertain, prove that step on a short test before assembling the full channel.
GStreamer and Liquidsoap do not have to perform identical jobs. One may manage playback while the other encodes or transports, depending on your existing setup and supported integrations. Avoid building a second playback system just because a sample uses it. Keep a clear boundary: one component supplies continuous audio and a video track, and the output path encodes, muxes and sends them.
Prepare local or remote playlist items
A playlist is only dependable if its entries resolve consistently. For local files, use paths the streaming process can read, not merely paths visible to your desktop user. If the service runs under a separate account, check ownership and permissions. For remote URIs, verify that the host is reachable from the machine that runs playback and that the URI continues to work without an interactive login.
Keep the playlist format simple enough to inspect. A plain ordered list of URIs is easier to troubleshoot than a generated catalogue whose contents are unclear. Test representative entries: a short file, a longer file, and any format with different sample rate or channel layout. If your source mixes local and remote items, test both kinds rather than assuming that success with one proves the other.
The playback layer must know when an item ends and what comes next. Some playlist or source constructions expose one item at a time; others manage a queue internally. Decide where the ordering, fallback and error policy live. For a station, decide whether a failed URI should be skipped, retried, or replaced by a known fallback. A silent stall is worse than an explicit log message because it can leave YouTube showing a live but silent picture.
Do not expose private URLs or credentials in a public script, logs, or a shared playlist. If remote media requires credentials, use the applicable secret-handling method for your runtime and keep diagnostics from printing them. Retain a small set of known-good local files for testing, so a network outage does not prevent you from checking encoding and muxing independently.
If your programme is a devotional or folk playlist, track ordering and transitions matter as much as connectivity. The practical planning in building a YouTube radio channel from an audio playlist is relevant before you automate playback. Treat that as editorial planning; the pipeline still needs its own checks for file access, decoding and transitions.
Build playback and queue the next URI
Think of playback as a sequence of items feeding one continuous audio source. For a maintainable design, the current item should continue while the next URI is resolved and prepared before the current item finishes. That gives the player a chance to open and decode the next media in advance, rather than discovering a bad path or slow remote response at the boundary.
The exact mechanism depends on the playback component and its version. In a GStreamer-based design, a playbin-style element can handle an item, while application logic or a suitable playlist element decides what URI follows. Other pipelines use a source that emits a new URI when the current item finishes. Whichever route you choose, identify the event that indicates end-of-item, the point at which the next URI is assigned or queued, and how errors are reported. GStreamer’s official application development documentation describes the framework’s pipeline and application concepts; element-specific behaviour belongs in the documentation for the elements installed on your system.
A queue is not automatically gapless. A URI may take time to open, a decoder may need to initialise, and the next file may have different audio properties. Even if the player can queue an item early, the hand-off behaviour must be tested with your actual files and build. Do not promise seamless transitions until you have listened to repeated transitions in the installed configuration.
For a small station, keep queue policy visible. Log the current item, next item, transition start, and any failure without logging secrets. Decide whether a missing next item leaves the current track playing, advances to another item, or switches to a fallback. Test a missing file and an unreachable URI deliberately. The goal is not to make failures impossible; it is to make the next action predictable.
Avoid coupling the playlist scheduler tightly to YouTube connection state unless you have a clear recovery design. A transient ingest disconnect need not mean restarting the music queue from the beginning. Conversely, restarting the output may restart or disrupt playback if the components are combined. Decide whether playback and transmission recover together or independently, then verify that behaviour before relying on the channel overnight.
Encode audio and provide a video track
The audio source needs an accompanying video source for a conventional YouTube Live broadcast. For a radio station, a still image with the station name or programme identity is often the simplest visual. It still has to be emitted as video frames for the whole broadcast; a single image file is not necessarily a continuous video source by itself. An animated or audio-reactive visual can be used where supported, but it adds rendering and resource considerations.
Liquidsoap’s documentation demonstrates combining audio and video, then encoding with FFmpeg. Its example uses H.264 video and AAC audio, both recognisable choices in YouTube’s live guidance. The Liquidsoap FFmpeg guide is useful for understanding composition and encoding, including the source.mux.video concept. Check your installed version and build before adapting its syntax.
YouTube’s live encoder settings list multiple accepted codecs and transport options. Settings are not interchangeable across codecs, frame rates and resolutions. For example, YouTube’s current H.264 guidance lists 5 Mbps for 1080p30 and 3 Mbps for 720p30; those figures apply to those listed configurations, not every output. Its guidance recommends a 2-second keyframe interval and sets a 4-second maximum. Use the live table at the time you configure the stream rather than assuming a remembered value is still current.
For audio, the same YouTube guidance recommends 128 kbps stereo AAC or MP3. A radio source may be mono or have a different sample rate, so check that the encoder produces the intended output layout and that the audio is audible without clipping or unintended silence. The codec and bitrate are only part of the result: listen to the output and check the levels through track transitions.
Choose a visual resolution and frame rate your machine can sustain while leaving capacity for audio playback and the rest of the pipeline. A still image does not make encoding free: the output still has to maintain a video stream. If you use an audio-reactive visual, test the load and output under normal playlist operation, not just with one short file. YouTube recommends leaving upload headroom; its streaming tips advise capacity above the total stream bitrate, with 20% headroom.
Mux the stream for YouTube ingest
Encoding creates audio and video elementary streams; muxing packages them into the transport expected by the destination. Liquidsoap’s YouTube output is an RTMP use case and the reference identifies an FLV/RTMP path. This is why the output configuration is more than “send the audio encoder to YouTube”: the video track, encoded audio, timing and container must agree.
A useful conceptual pipeline is: playlist items feed a continuous audio source; a video source supplies frames; the sources are combined; audio and video are encoded; the encoded streams are muxed; and the resulting stream is handed to output.youtube.live.rtmp with the destination key. Liquidsoap’s official YouTube output example illustrates the operator with an FFmpeg encoder. Do not treat that brief example as a complete recipe for a different release or plugin set.
For one destination, direct encoding at the output can be easier to reason about. Sharing already encoded data across destinations may save repeated encoding, but it creates additional container and global-header compatibility considerations. Liquidsoap’s FFmpeg guidance discusses those issues. Unless you actually need multiple outputs, begin with the simplest single-output design you can inspect and test.
YouTube recommends RTMPS for encrypted transport. Liquidsoap’s documented operator describes RTMP and a default RTMP URL, so do not silently replace the URL with an RTMPS address and assume it works. Confirm that the version, output operator and underlying build support the protocol you intend to use, and verify the resulting connection in Live Control Room. For protocol background, the RTMP and RTSP comparison can help distinguish transport choices, but YouTube’s current documentation should decide the destination requirements.
The stream key is a password-like secret: it identifies the ingest destination and allows the encoder to send to it. YouTube’s stream key guidance explains its role. Keep it out of source control and public logs. Liquidsoap’s book illustrates reading a key from a separate file and trimming whitespace; adapt the exact file-reading syntax to your installed version, and restrict access to that file. If the key is exposed, reset it in Live Control Room and replace the value used by the encoder.
Configure Live Control Room details
Create or select the intended stream in YouTube Live Control Room before starting the output. Copy the stream URL and key shown for that destination into the matching Liquidsoap configuration. Take care not to confuse a stream key with the URL, or use a key from another event. A configuration that points to a different event can appear technically healthy while sending the wrong programme to the wrong place.
Set the event’s title, description, audience and visibility deliberately. Those are channel decisions, not encoder settings. Check the current options shown in Control Room, especially if you are scheduling an event rather than using a persistent stream. Avoid publishing the event until you are satisfied with the image, sound and metadata in preview.
The broadcast path is YouTube-only if you are using this destination operator; it is not a general multi-platform output. If you later need several destinations, compare the extra encoding and operational complexity with your actual publishing needs. For an always-on loop with one destination, the YouTube-only versus multi-platform decision guide can help frame that choice without changing the Liquidsoap mechanics.
Keep a written recovery note that does not include the key itself: where the protected key file lives, how to restart the output, which Control Room page to inspect, and who can reset access. This is particularly useful when another person has to respond while you are away. If you rotate the key, update the protected configuration and verify the new incoming feed before treating the change as complete.
Test transitions and stream output
Test the complete route before announcing or relying on it. Start with a short programme using representative audio and the intended video source. Confirm that YouTube receives the feed, displays the expected picture, and reports stream health. Then listen to the preview and watch at least several track changes. YouTube advises testing before going live and monitoring stream-health messages; do not assume a successful connection alone proves the broadcast is usable.
Use a checklist that follows the data path:
| Check | What to verify | If it fails |
|---|---|---|
| Playlist access | Each test URI opens under the actual process account | Check paths, permissions, URI reachability and decoder support |
| Queue transition | The next URI is ready before the current item ends | Inspect queue timing, item errors and format changes; test rather than assuming gapless behaviour |
| Audio/video source | Both tracks are present continuously | Confirm the video source emits frames and the audio source remains active |
| Encoding and muxing | YouTube preview has picture and intelligible sound | Check codec, frame rate, bitrate, container and build support against current guidance |
| Ingest and network | Control Room receives a stable feed | Recheck URL and key, outbound capacity, headroom and connection stability |
When YouTube reports no incoming feed, first confirm that the output is actually running, then recheck the copied URL and key. Inspect Liquidsoap logs for the first relevant error, and verify the installed build has the needed FFmpeg support if your output depends on it. If there is sound but no picture, check that the source supplied to the output has both tracks rather than only audio.
If YouTube reports an encoder issue, compare the actual live output with the guidance for its codec, frame rate, bitrate and keyframe interval. Do not copy settings from a file upload export and assume they are valid live settings. If ingest drops or buffers, check outbound upload capacity rather than download speed, reduce the stream bitrate if needed, and retain headroom. For an additional explanation of frame warnings, see how to fix dropped frames reported by YouTube.
Keep a short test record of the versions, relevant plugins, chosen output settings and the files used at transitions. This gives you a baseline if a package update changes behaviour. Repeat the test after changing Liquidsoap, GStreamer, FFmpeg, an encoder plugin, the playlist format or the output protocol. A pipeline that ran once is not proof that a changed installation will behave the same way.
If maintaining the playback host through the night is the pain point, StreamNeo can take an uploaded video and keep a YouTube broadcast running without your computer on; it is useful for a prepared video loop, but it does not replace this Liquidsoap live-radio route.
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 I send Liquidsoap audio to YouTube without video?
A conventional YouTube Live broadcast needs a video track as well as audio. For a radio feed, provide a still image or another continuous video source, then confirm both tracks appear in the preview. A picture-free audio source is not the complete video broadcast path described here.
Is there one GStreamer command that works for every Liquidsoap installation?
No. Available elements, plugins, Liquidsoap operators and FFmpeg integration depend on installed versions and build choices. Check the local tools and matching documentation, then validate each stage with your own files; do not rely on an untested all-in-one command.
Will queuing the next URI make playback gapless?
Not necessarily. Early queuing can give the player time to open and prepare the next item, but decoder startup, file differences and pipeline behaviour affect the hand-off. Test transitions on the installed version and listen for gaps, overlap, silence or level changes.
What should I do if the stream key is exposed?
Reset the key in YouTube Live Control Room, then update the protected value used by Liquidsoap. Check logs and configuration repositories for copies, and avoid printing the replacement key during troubleshooting.