To send an AzuraCast station to YouTube Live with FFmpeg, relay the station’s listener-facing audio mount to the current ingest URL and stream key shown in YouTube Live Control Room. The mount, source format and local FFmpeg build vary, so identify and test those details before you schedule a public broadcast.
YouTube’s live encoder workflow needs a compatible video stream as well as audio; an audio-only station feed may therefore need to be paired with a still image or another visual source. This guide gives you a method for checking each part, not a universal command that can be pasted unchanged into every installation.
Trace the path before configuring it
There are three separate connections to keep straight. AzuraCast assembles the station output, FFmpeg reads that output from a listener-facing URL, and FFmpeg publishes an encoded stream to the specific YouTube ingest endpoint for your event. A problem at any one of these stages can leave YouTube waiting for a signal.
The source should be the broadcast a listener would hear, not an administrative address or a DJ’s input connection. AzuraCast describes Liquidsoap as the AutoDJ backend that assembles station output, while the broadcast frontend serves listeners. A DJ connection is for contributing a live programme to the station; it is not the normal source for relaying the finished station output. See AzuraCast’s station management documentation and streaming software guidance for the distinction.
At the destination, YouTube supplies an ingest address and a stream key. FFmpeg must be able to read the AzuraCast mount and encode a stream YouTube accepts, while the host must be able to reach YouTube’s endpoint. For an audio station, you also need a visual input if your selected live workflow expects video. A static album cover can be enough for a simple radio presentation; the practical choices are explained in our guide to adding a static album cover to a 24/7 Indian music stream.
Draw the path on paper before trying flags: station output, public mount URL, host running FFmpeg, then YouTube’s event-specific ingest. Write down which machine runs FFmpeg and whether it can reach both endpoints. This catches a common false start: configuring the encoder correctly on a machine that cannot reach a private or proxied source mount.
Find the station’s public mount URL
In AzuraCast, open the station’s mount-point or public/listener information and copy the URL presented for the mount you intend listeners to hear. The mount is the connection point for a broadcast stream. AzuraCast documents a default pattern of {HTTP/HTTPS}://{BASE_URL}.TLD/listen/{STATION_URL_STUB}/{MOUNT_POINT_URL}, but this is a pattern, not a promise about your own hostname, port, station stub or mount filename. An administrator may have configured a custom mount URL. The AzuraCast mount-points documentation explains how mount points are presented and configured.
Use the actual listener URL surfaced by your station or its public page. Do not construct one from an example and assume it is right. Avoid copying the AzuraCast admin panel URL, an API or now-playing endpoint, or a DJ source/login URL. Those may look like station addresses, but they do not necessarily deliver the listener audio you want to forward.
If the station has more than one mount, decide which one represents the public output you mean to rebroadcast. Different mounts may be associated with different formats or quality settings. Check the station’s public page, listen to the selected URL in a player, and note any authentication information the installation requires. Do not publish credentials in a command you later paste into a public forum or screen-share.
Keep the source and destination notes separate. Label the AzuraCast address source, and leave a separate, private place for YouTube’s key. That small habit makes it less likely you will reverse the two URLs or accidentally copy a secret into a config file that is shared with others.
Confirm the mount is reachable from the host
A URL working on your phone does not prove it works from the machine that will run FFmpeg. The relay host makes its own connection, so test the exact listener URL there using a browser, media player or a simple connection check already available on that system. Confirm that the response is live audio rather than a station page, an error page or silence.
If it does not connect, check the hostname and DNS resolution, the path, whether the URL uses HTTP or HTTPS, and whether the host can reach the required port. A reverse proxy may prevent direct connections to broadcaster ports, and the correct route depends on the installation. AzuraCast’s guidance notes that reverse-proxy arrangements can affect direct broadcaster access; do not guess a replacement port or disable protections to get around the problem.
Check whether the mount expects credentials, whether its certificate is trusted by the host, and whether the host is on a network allowed to reach it. If the URL is reachable only from inside a private network, a computer elsewhere will not be able to relay it without an approved route. Ask the AzuraCast administrator to confirm the public listener address and network policy rather than exposing a private service.
A useful test is to play the mount from the host for long enough to hear it transition between station items. Listen for continuity and confirm the audio format with tools available on that machine. The purpose is not to judge programme quality; it is to establish that the relay has a stable source and that FFmpeg will receive the expected media. If you are setting up a machine to run continuously, our guide to restarting a YouTube music stream with systemd covers a separate reliability layer. It does not solve a blocked source mount or a bad encoder configuration.
Get the current YouTube URL and key
In YouTube Studio, open or create the live event in Live Control Room, then use that event’s Stream settings. Copy the Stream URL and stream key associated with the event you are preparing. YouTube calls the stream key the stream’s “password and address”, so treat it as a secret: do not include it in a public article, shared screenshot, chat message or support post. YouTube’s streaming setup guidance explains where the key is managed.
For an encrypted connection, use the RTMPS URL shown in Live Control Room. YouTube may show the ordinary RTMP URL by default; use the lock control under Stream settings to reveal the RTMPS address, then copy that exact URL. YouTube recommends RTMPS in its encoder settings guidance, but your encoder must support the endpoint you select. Do not substitute a URL remembered from an older event or copy an example from another channel.
The event-specific key belongs to the destination configuration, not the AzuraCast station. Keep the key out of a shared command history where practical, and use a private configuration method supported by your operating system and FFmpeg workflow. If the key is exposed, reset it in Live Control Room and update the encoder with the replacement. Do not assume a key is permanent or safe to reuse without checking the current event settings.
Before starting FFmpeg, compare the source URL with the destination URL character by character. The source should be the AzuraCast listener mount. The destination should be the YouTube RTMPS ingest URL for this event, with the key supplied in the way your FFmpeg invocation expects. If you are unsure whether your local build supports encrypted publishing or a particular protocol, check that build’s help output and documentation instead of inferring support from another machine.
Choose compatible FFmpeg input and output settings
First establish what the mount actually provides. An audio mount may deliver a compressed audio format directly, while another installation or mount may provide a different format. FFmpeg can often decode an input and encode a different output, but the exact demuxer, options and filter chain depend on the URL response, codecs available in your build, and the video source you add. Do not copy a command merely because it worked for a different station.
YouTube’s current encoder guidance supports RTMP or RTMPS, AAC or MP3 audio, and constant bitrate encoding. For stereo audio it recommends 44.1 kHz and 128 kbps. Treat these as output targets to check against YouTube’s current page, not as evidence that the AzuraCast mount already has those properties. FFmpeg may need to decode and re-encode the source audio to meet the selected output settings.
An audio-only radio feed generally needs a video component for the YouTube workflow. That might be a still image that loops as a video source, or another permitted visual file. Choose an image you have permission to use and prepare it at a sensible resolution for the output you intend to send. Our static album-cover guide discusses the presentation choice; here, the important technical point is that an audio mount alone does not create a video track.
If you configure video, select an encoding that YouTube accepts and that your host can produce continuously. YouTube’s encoder page includes current video bitrate recommendations and a recommended two-second keyframe interval, with a maximum interval of four seconds. These are video settings, not properties to apply blindly to an audio-only source. Match the video resolution and bitrate to your upload capacity, the chosen visual and the current official guidance. Leave headroom for fluctuations in the host’s internet connection.
A safe command design is a template with placeholders, not a claim that one invocation is tested for your station. Conceptually, FFmpeg needs an input for the looping visual, an input for the AzuraCast mount, output mapping that combines the video and audio tracks, compatible encoders and settings, and the exact YouTube RTMPS destination with the event key. The order and syntax of options can matter. URL escaping, reconnect behaviour, input timestamps and stream mapping can all vary with the FFmpeg version and inputs.
Before building that command, check ffmpeg -version and the local help or build configuration for the protocols, demuxers, filters and encoders you plan to use. Confirm that the required H.264 video and AAC audio encoders are available if those are the formats you choose. If you cannot identify the mount’s media format, inspect it with a local media probe or ask the station administrator. A guessed -f setting can make a valid URL look broken, and an option accepted by one build may not exist in another.
Test the relay and inspect errors
Test privately before the public broadcast. Start with the source alone if that helps isolate a problem, then add the visual and output stage. Keep the first test short enough to inspect but long enough to establish that the mount remains connected, the tracks are being encoded, and data reaches the YouTube endpoint. Do not use a public event as the first place you find out the source URL is wrong.
Read FFmpeg’s output from the beginning, not only the final error line. A connection refusal or timeout points towards reachability, hostname, port or proxy behaviour. An HTTP error or unexpected response can indicate that the URL is a page or an endpoint other than the audio mount. A demuxing or decoder error suggests the input format does not match what FFmpeg expects, or the source is not providing usable media.
An encoder-not-found message means the selected codec is not available in that FFmpeg build. A stream mapping error often means FFmpeg did not find the video or audio track you thought it would, or the mapping options do not match the inputs. An authentication or publish rejection at the destination calls for rechecking the exact event URL and key in Live Control Room. Keep these categories separate: changing codecs will not fix a blocked port, and changing network settings will not fix an unavailable encoder.
Make one change at a time and rerun the same test. Record the exact source mount, FFmpeg version, relevant error text and YouTube event settings without recording the key itself. Redact credentials from logs before asking for help. If a relay drops after working, distinguish a source interruption from an output failure by checking whether FFmpeg still receives the station audio and whether YouTube still receives the encoded stream. For broader continuity issues after the stream is running, see how to fix YouTube stream disconnects during a 24/7 ambience broadcast.
Do not add reconnect flags at random. Their behaviour depends on FFmpeg version, protocol and input type, and they can obscure a source that is repeatedly failing. First verify a clean, stable test with the installed setup; then choose a recovery approach suitable for the machine and service arrangement you actually use.
Verify the preview before going live
Once FFmpeg is publishing, open the event in Live Control Room and wait for YouTube to register the incoming signal and show a preview or health information. Confirm that the picture is the intended still or video, and that the audio is audible, continuous and not distorted. A connected encoder does not prove that your audience will hear the right station output.
Listen for a real transition between station items and compare the sound at the source with the YouTube preview. Check that both audio channels are present if you intend stereo. Look at YouTube’s stream health messages for warnings and allow time to correct them before selecting Go Live. YouTube advises testing before starting and monitoring health messages; its live encoder settings and health guidance is the place to confirm current requirements.
Decide who is responsible for the final go-live action and what viewers should see while the test is running. If you are using an unlisted test event, confirm its visibility and audience before sharing the link. If you created a public event, remember that a signal arriving at the event and the event being publicly live are distinct actions in the control room. Check the current YouTube workflow rather than relying on an old screenshot.
After the test, write down the working source mount and non-secret encoder settings so a restart does not depend on memory. Store the key privately and make sure anyone who may restart the relay knows where to retrieve or rotate it. If you change the mount, visual file, FFmpeg build or YouTube event, repeat the test; a previously working command is not proof that the changed setup still works.
For a relay you do not want tied to a home computer staying switched on, StreamNeo removes that particular operational burden by letting you upload a video for a YouTube broadcast and leave your computer off; that is a different workflow from relaying a live AzuraCast mount through your own FFmpeg setup.
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 use the AzuraCast DJ URL as the FFmpeg input?
Usually you want the listener-facing mount, which carries the station output, rather than a DJ connection used to contribute a programme to the station. Find the public mount URL shown for the station and confirm that it plays from the FFmpeg host. If your installation has a special routing arrangement, ask its administrator which listener endpoint represents the output you intend to relay.
Is the default AzuraCast mount URL pattern guaranteed?
No. AzuraCast documents a common pattern, but the hostname, path, port and mount can be customised. Copy the URL surfaced by your station or public page and test it from the host that runs FFmpeg rather than constructing it from the pattern.
Why does YouTube show no picture when the audio is working?
The station mount may contain audio only, while the YouTube encoder workflow expects a video stream. Add a compatible still-image or other video input, then verify that FFmpeg maps both tracks and that the Live Control Room preview shows the visual. Check YouTube’s current encoder requirements before publishing.
Can I reuse a YouTube stream key permanently?
Do not assume that a key is permanent or safe to reuse. Copy the key attached to the event or stream configuration you are using, keep it secret, and reset it in Live Control Room if it is exposed. Always confirm the current URL and key in the control room before a new test.