AzuraCast provides the radio audio; a separate encoder must turn that audio and a still image into a video stream for YouTube Live. The AzuraCast documentation reviewed here does not describe a native YouTube video destination or a complete supported recipe for that end-to-end setup.
The practical route is to take the station’s listen stream as the audio input, loop an image as video, then send the combined output to YouTube’s ingest endpoint. Whether you are forwarding AutoDJ or a live DJ input, the separate encoder is still needed. Plan to test the whole path before making it a channel’s overnight broadcast.
Identify the AzuraCast station audio output
First decide which audio you want viewers to hear. If AzuraCast’s AutoDJ is playing the station, use the station’s public listen stream or a suitable mount point as the encoder’s audio input. If a live DJ is on air, that DJ’s audio reaches AzuraCast through compatible broadcasting software; the downstream video encoder still needs an audio URL it can read. The source changes, but the requirement to create video does not.
Use the station’s own displayed connection information rather than copying a host, port, mount or credential from a tutorial. AzuraCast’s documentation describes Liquidsoap as part of its AutoDJ audio handling and broadcast frontends as distributing the station output. Mount points can offer different audio formats or bitrates, so select one the encoder supports and that is appropriate for your connection. See AzuraCast’s station and broadcasting documentation.
A normal radio listen URL carries audio, not a picture. YouTube Live expects an audio/video stream, so the URL by itself is not a complete input for the final broadcast. Treat it as one component of a new output stream, not as a YouTube destination.
If your encoder cannot reach a DJ input or AzuraCast endpoint, verify server address, port, mount and any required credentials. AzuraCast notes that reverse proxies can interfere with broadcaster connections and advises using the direct server address for broadcaster software where applicable. Do not expose DJ passwords or stream keys in a public configuration, screenshot or command shared with others.
Prepare the static image for the video scene
Choose a visual you have permission to use: a station logo, a designed background, or suitable cover art. Check that small text remains readable on a phone screen and that the image has enough resolution for the output size you intend to send. A still image may look simple, but the encoder must repeatedly produce video frames from it while the audio continues.
Keep the scene calm and useful over a long session. A logo, station name and perhaps a short description can identify the broadcast without making a claim that is no longer true. Avoid placing time-sensitive programme details in a visual that will stay unchanged overnight. If you want to use a recurring nature visual, consider the practical points in this guide to using the same loop on YouTube Live — remove the space after the opening parenthesis when pasting this link.
For a static image, there is no need to animate it merely to satisfy the encoder. The video output still needs a continuous frame rate, while the underlying picture can remain identical. Check how the image is cropped or padded at the chosen resolution: stretching a square logo across a wide frame can distort it, while a correctly composed background can keep important details away from the edges.
A changing track title or artist name is a separate feature, not something the still image or audio mount creates automatically. AzuraCast exposes a now-playing JSON endpoint that updates periodically; a separately implemented overlay can read that information and draw it into the encoder’s video. The endpoint alone is metadata, not a finished YouTube overlay. Begin with a fixed visual unless the changing information is important enough to justify building and maintaining that extra layer.
Use a separate encoder to combine audio and image
The encoder’s job is to read two logical inputs: the AzuraCast radio audio and a still image that it loops as video. It then encodes both into a supported audio/video output and sends that output to YouTube. This is the key distinction: AzuraCast supplies station audio, while another tool constructs the video stream. The documentation reviewed for AzuraCast does not establish a native YouTube video destination or an end-to-end supported static-image recipe.
Software such as FFmpeg can be configured for this kind of media workflow, but a complete command depends on the installed build, the image dimensions, the station stream format and the current YouTube settings. The FFmpeg documentation describes its options; it does not make an untested command safe for every station. Treat any command found elsewhere as something to adapt and test, not as a drop-in guarantee. In particular, confirm that the image input is looped and that the output continues to generate video frames while audio is present.
Choose where the encoder will run based on access and continuity. An existing always-on machine or server may work if it can reach both the listen stream and YouTube’s ingest endpoint, has enough upload capacity, and can remain available. A local computer is easier to inspect during setup but will stop the stream if it sleeps, loses power or drops its connection. A hosted machine can avoid dependence on your home computer, but it still needs maintenance, reliable access to the source and secure handling of the stream key. These are practical considerations, not a hardware requirement specified by AzuraCast or YouTube.
| Encoder location | What to check | Main trade-off |
|---|---|---|
| Existing local computer | Sleep settings, power, network stability and upload capacity | Easy to access, but the broadcast depends on that computer and connection |
| Existing always-on server | Reachability of the listen URL and YouTube ingest, plus key security | Can run independently of your desktop, but needs ongoing administration |
| Hosted machine | Access to the station stream, sustained outbound capacity and credential storage | Separates the broadcast from your premises, with another system to configure and maintain |
For a radio stream intended to continue with your computer off, an approach that removes the need to leave that computer running can address a specific continuity problem; StreamNeo turns an uploaded video into a YouTube live stream, so it is not a relay for an AzuraCast live audio feed. For the separate-encoder route described here, confirm explicitly that your chosen encoder host can reach the station’s audio and keep the broadcast running as intended.
Retrieve YouTube Live ingest details
In YouTube Studio, create or select the live broadcast and retrieve the ingest settings for that stream. You need the server or ingest address and the stream key associated with it. The YouTube Live API documentation explains that live streams have ingest configuration and supported codecs; use your own Studio settings rather than a copied example. YouTube’s Live Streaming API overview is a primary reference for the stream-specific configuration.
A stream key is a credential. Keep it in the encoder’s private configuration and do not publish it in a guide, shared command, screenshot or public log. A placeholder such as YOUR_STREAM_KEY is appropriate in an example; your actual key belongs only in your own configuration. If you suspect the key has been exposed, review the current controls in YouTube Studio and replace it as appropriate.
Check that the selected broadcast is the one you mean to test. It is easy to prepare one event in Studio and have the encoder publish to a different stream key or scheduled broadcast. Keep the broadcast private or otherwise unlisted during initial checks if that suits your channel plan, and verify the visibility and scheduling choices in Studio before making it public.
Apply YouTube encoder guidance and test
YouTube’s current encoder guidance recommends RTMPS for encrypted ingest and documents accepted video and audio codecs, including H.264, H.265 and AV1 video and AAC or MP3 audio. Its guidance also recommends constant bitrate and a keyframe interval of two seconds, not exceeding four seconds. Settings can change, so review YouTube’s live encoder settings before publication rather than treating a profile in this article as permanent.
For a straightforward H.264 SDR example, YouTube’s page recommends 3 Mbps for 720p at 30 frames per second and 5 Mbps for 1080p at 30 frames per second. It recommends stereo audio at 128 Kbps and 44.1 kHz. These are platform recommendations, not promises that every channel or uplink should use those exact values. Choose a profile your outbound connection can sustain and that the encoder can produce consistently. A still background often does not need the higher resolution to communicate a station identity; test legibility on the devices your viewers use.
Run a private test with the same sort of audio and settings you expect in the real broadcast. Start the encoder, then wait for YouTube Studio to recognise the incoming stream. Confirm that the picture appears, audio is audible and in sync, and the intended broadcast is receiving the feed. YouTube advises testing and checking stream health; its help for live streaming is also useful for Studio-side setup and monitoring.
A successful start is not a complete test for an always-on channel. Leave the test running long enough to notice interruptions, buffering or a reconnect problem. If a local machine will host the encoder, check what happens when its display is off and whether power-management settings interrupt the process. If the encoder runs elsewhere, check that it can continue if you close your usual desktop session.
Check audio, image and stream health
When there is no audio, check that the encoder can reach the public listen URL from its own location, not just from a browser on your laptop. Confirm the mount point and whether that mount’s format is supported by the encoder. If the station itself is silent, inspect AzuraCast’s station and Liquidsoap logs as well as the encoder output; an encoder cannot forward audio that it is not receiving.
If a DJ feed is missing, revisit the DJ connection details, credentials and port. A reverse proxy may serve the public site while not forwarding broadcaster connections; AzuraCast’s guidance on direct server addresses may apply. Separate the diagnosis: first establish whether AzuraCast has the intended audio, then whether the encoder receives it, and finally whether YouTube receives the encoded output.
If YouTube sees no video, verify that the encoder is continuously creating frames from the still image and that the outgoing video codec and ingest protocol match YouTube’s current guidance. A command that successfully reads audio can still fail to produce an acceptable video stream. If the image is visible but soft or cropped, check the source image dimensions, the chosen output size and scaling behaviour before raising the bitrate.
For crackling or intermittent audio, compare what the station’s listen stream sounds like with what YouTube receives. That helps distinguish a source or mount issue from an encoder or uplink issue. This practical guide to crackling audio in a looping stream covers symptoms worth checking on the output side. For a stream with a playlist, scheduling and source continuity are also worth planning; see how to schedule a 24/7 stream playlist.
Watch YouTube Studio’s stream-health notices while testing. If health is poor, reduce the output demand or improve the available connection, then test again; do not assume a nominal connection speed is fully available to the encoder at all times. Check that reconnection behaves as expected after a deliberate, controlled interruption, and confirm that the encoder has not exposed the stream key in logs. Do not make the stream public until the image, audio and broadcast selection are right.
Plan for the version you will actually maintain
The simplest durable setup is usually the one with few moving parts: a known AzuraCast audio URL, one fixed image, a documented encoder configuration, private key storage and a clear way to tell whether the feed is live. Save the settings without saving credentials in a place others can access. Record the station mount, output profile and recovery steps so that someone else can diagnose a silent stream if you are away.
Only add a dynamic now-playing overlay if it improves the viewer experience enough to justify maintaining it. A custom overlay has to fetch the station metadata, render it into video and continue working when tracks change or metadata is missing. AzuraCast’s endpoint can inform such a build, but it does not draw or transmit the overlay on its own. A fixed image is less informative, but also easier to keep consistent through a long broadcast.
If you are comparing an encoder on your own machine with a cloud-based way to keep a channel running, weigh who will notice and repair a failure, what source the system can accept, and whether it is designed for an uploaded file or a live radio feed. For other always-on video workflows, the discussion of hosting options for an always-on YouTube stream may help frame the operational questions. It is not a substitute for checking whether a given service supports the AzuraCast source you need.
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 AzuraCast send a static image to YouTube by itself?
The AzuraCast documentation reviewed here describes station audio output, not a native YouTube video destination or a complete supported static-image setup. You need a separate encoder to pair station audio with a video signal made from the image, then send that combined stream to YouTube Live.
Does the setup change if I use a live DJ instead of AutoDJ?
The audio source changes: AutoDJ uses the station’s listen output, while a live DJ connects to AzuraCast through compatible broadcasting software. The separate encoder still has to receive audio, combine it with the image and produce the YouTube audio/video stream.
Can I display track titles over the image?
Yes, but the now-playing endpoint is metadata, not a ready-made visual overlay. A separately implemented tool must read that data and render it into the video output; test how it behaves when metadata changes or is unavailable.
What should I test before making the broadcast public?
Confirm that the intended broadcast receives the stream, the image appears, audio is present and in sync, and YouTube reports acceptable stream health. Also test that the encoder continues or reconnects as expected and that the stream key remains private.