To send a MediaMTX stream to YouTube Live, configure outbound forwarding on the path that carries your source and set its destination to YouTube’s RTMPS ingest address with the current stream key. This is separate from MediaMTX’s inbound RTMP listener settings: those determine where a publishing client connects to MediaMTX, not where MediaMTX forwards the stream.
The forwarding shape documented by MediaMTX is rtmps://a.rtmp.youtube.com/live2#<stream-key>. Treat the key as a password: copy it from the relevant YouTube Live Control Room, keep it out of public examples and shared logs, and check the configuration format for the MediaMTX release you actually run.
Inbound publishing and outbound forwarding are different jobs
A useful way to reason about the setup is as two links in a chain. First, an encoder such as OBS or FFmpeg publishes a feed to a MediaMTX path. Then MediaMTX forwards the feed arriving on that path to YouTube. The incoming connection and the outgoing destination are configured for different purposes.
MediaMTX configuration options including rtmpAddress and rtmpsAddress describe the server’s RTMP listener addresses. They affect how a client can publish into MediaMTX, along with related server-side options such as whether RTMP or RTMPS is enabled and the server certificate settings. They are not the YouTube destination. Changing a listener address does not, by itself, tell MediaMTX to send a stream to YouTube.
For example, your OBS publishing URL might point to MediaMTX and identify a path called radio. In that arrangement, OBS sends the source to MediaMTX under radio; the forwarding rule for radio then points onward to YouTube. The YouTube stream key belongs in that outbound destination, not in a public URL or a listener address.
Keeping the distinction clear also helps when diagnosing a blank YouTube preview. If OBS cannot publish to MediaMTX, the source path may never become active. If the source is present in MediaMTX but YouTube shows no incoming feed, the outbound rule, key, network access or YouTube ingest status may be the problem. Check each connection separately rather than changing the listener setting at random.
If you are deciding whether to keep a local encoder running overnight or move the continuous part of the job elsewhere, this comparison of a low-cost PC setup in India gives useful context about the local-computer route. It does not change the MediaMTX distinction: whichever system creates the feed, the path and forwarding destination remain separate.
Find the path carrying your source
Before editing forwarding, identify the exact MediaMTX path your encoder publishes to. A path is the name under which MediaMTX makes a stream available. It might be live, radio, devotional, or another name chosen for the local configuration. Use the name that is actually active in your installation, not a name copied from an unrelated example.
If the publishing URL in OBS or FFmpeg includes a path after the MediaMTX address, that is a good first clue. Then check the running MediaMTX logs, status view, or Control API if enabled, to confirm that the source has connected and the expected path is active. The project documents RTMP client publication examples for software such as FFmpeg and OBS; the exact URL format depends on the configured listener and path.
Do not assume that the name in a YouTube event or the name of a video file is also the MediaMTX path. They can be entirely different. Write down the path, the publishing client, and whether the feed is currently arriving before adding the forward. A small note such as “OBS publishes to radio; MediaMTX forwards radio to today’s YouTube event” is enough to prevent mixing up the two ends.
In a multi-channel setup, confirm which source belongs to which path. If several encoders publish separate programmes, a forwarding rule attached to the wrong path can send the wrong material even when the YouTube key is valid. When you use a playlist or prerecorded rotation, verify that the playlist is producing the intended continuous source before investigating YouTube. The guide to scheduling prerecorded videos in a continuous cloud livestream explains a different operating model, but the same practical check applies: establish what is producing the feed before troubleshooting its destination.
Copy the current YouTube stream key
Open YouTube Studio and go to the Live Control Room for the channel and event you intend to use. Select or create the relevant stream and locate its current stream key and ingest details. YouTube’s LiveStreams API reference describes ingestion information associated with a live stream, while the control room remains the practical place for a channel operator to manage the live setup.
Use the key belonging to the intended event or reusable stream, as appropriate for your channel’s workflow. Do not rely on a key remembered from an earlier broadcast, an old configuration backup or an online sample. If you regenerate or replace a key, update the MediaMTX forwarding configuration as well. A mismatch can leave the local source running normally while YouTube receives nothing.
The key is a credential, not an ordinary setting to paste into a support forum or include in a screenshot. Anyone who obtains it may be able to send a feed to the associated YouTube ingest. Copy it directly into the private configuration mechanism you use, restrict access to that file or secret store, and redact it before sharing logs or examples. In this article, <stream-key> is only a placeholder; it is not a usable credential.
YouTube’s help guidance recommends RTMPS, which encrypts the RTMP connection in transit. Its encoder settings and bitrate guidance is also worth checking when preparing the source. Choosing a secure destination does not make a reused or exposed key safe, so key handling and transport encryption are separate precautions.
Set the RTMPS forwarding destination
MediaMTX documents YouTube forwarding with a destination in this form: rtmps://a.rtmp.youtube.com/live2#<stream-key>. The protocol and host identify YouTube’s RTMPS ingest, while the portion after the # is replaced with the key copied for your channel or event. Keep the placeholder in any documentation or configuration example you share; never substitute a live key in public material.
In your MediaMTX configuration, apply the forwarding destination to the path that carries your source, following the forwarding syntax documented for your installed release. The project’s forwarding documentation shows the feature and its documented YouTube destination. Its configuration reference describes the broader configuration structure. Because names and syntax can change between releases, use those documents alongside the version you have installed rather than assuming an example from the latest online page matches an older binary.
The conceptual mapping is straightforward: identify a path, then give that path an outbound destination. Do not put the YouTube URL into rtmpAddress or rtmpsAddress; those options control listener addresses for incoming publishers. Likewise, do not set a listener’s server certificate options as a substitute for configuring the outbound destination. A certificate used by MediaMTX as a server and an encrypted connection from MediaMTX to YouTube solve different sides of the connection.
If you maintain the configuration as a file, make a private backup before editing and keep the key out of any example repository. MediaMTX also documents configuration through environment-variable overrides and the Control API, where enabled. Choose one method that fits your deployment and avoid accidentally defining conflicting values in multiple places. If the configuration is generated by a deployment tool, change its source of truth rather than only editing a generated file that may be overwritten.
Check the path and forwarding configuration
After making the change, confirm that the forwarding rule is attached to the same path your encoder publishes to. A valid destination on an inactive path will not forward a stream. A live source on one path will not be sent by a rule attached to another. Compare the actual publication URL, the active path shown by MediaMTX, and the path named in the forwarding configuration.
Validate configuration syntax using the validation mechanism available for your MediaMTX release before relying on a reload or restart. MediaMTX documents configuration validation and reload behaviour; check the project’s configuration instructions for the current approach. Validation catches malformed YAML or unsupported fields, but it cannot confirm that your key is current, that the network can reach YouTube, or that the incoming media format is suitable.
Then apply the configuration using the supported reload procedure for your installation, or restart MediaMTX if that is the required method in your setup. Observe the logs for the expected path becoming active and for an outgoing connection attempt. Keep the log review private and redact credentials. A clean configuration parse is only the first check; you still need to verify that the source arrives and the destination accepts it.
YouTube should show an incoming feed in the Live Control Room when the chain is working. Allow enough time for the control room to reflect the connection, then check its stream health messages. If you operate a continuous devotional or ambience channel, inspect a representative section with the same audio and motion patterns as the overnight programme. The article on choosing video bitrate for a 24/7 devotional stream can help frame the source-encoder decision, but forwarding itself should not be assumed to transcode or repair unsuitable media.
Protect credentials and validate the feed
Treat a stream key as sensitive wherever it appears: configuration files, environment variables, command history, screenshots, logs, backups and support tickets. Limit who can read the relevant file or account, use a private method to distribute the key, and redact the value before sending diagnostic output to someone else. If you believe it has been exposed, replace it through YouTube’s controls and update the forwarding configuration promptly.
The destination uses RTMPS, but transport protection is only one part of the security picture. It protects the connection in transit; it does not prevent a person with access to the key or configuration from using it. Nor does it guarantee that YouTube will accept the feed or that the video will meet the channel’s rights, policy or event requirements. Check the current official YouTube guidance for the live event and content you intend to broadcast.
A successful connection is not the same as a healthy programme. YouTube’s encoder guidance lists H.264, H.265/HEVC and AV1 for RTMP/RTMPS video and recommends constant bitrate, with a two-second keyframe interval that should not exceed four seconds. It also lists AAC or MP3 audio, with AAC required for 5.1 surround over RTMP/RTMPS. Check the current table rather than relying on a remembered preset.
For a concrete comparison, YouTube’s current encoder guidance recommends different H.264 bitrates for 1080p30 and 1080p60. The figures below are YouTube’s recommendations, not guarantees of picture quality or a substitute for checking the full table against your actual codec, frame rate, motion and upload capacity.
| H.264 video mode | YouTube recommended bitrate | What to keep in mind |
|---|---|---|
| 720p30 | 8 Mbps | A lower frame rate may fit a less demanding source and connection. |
| 720p60 | 8 Mbps | More frames do not remove the need for a stable, correctly configured source. |
| 1080p30 | 14 Mbps | Choose this only if the encoder and sustained upload can support it. |
| 1080p60 | 17 Mbps | Higher frame rate and bitrate need to be tested together. |
These figures are from YouTube Help’s encoder table, checked in 2026. They are operating recommendations rather than promises. The right setting depends on the chosen mode, available upload bandwidth and the nature of the picture; a static devotional image and a moving street scene do not stress encoding in the same way. Run a representative test and watch the stream health indicators during the test, not just the local encoder’s “connected” status.
Troubleshoot a missing forward
Start with the simplest question: is the source present on the expected MediaMTX path? If not, investigate the encoder-to-MediaMTX link first. Confirm the publishing URL, listener address, credentials if configured, path spelling and client status. The outbound YouTube destination cannot forward a source that MediaMTX has not received.
If the path is active, check that the forwarding rule names that exact path and that its destination follows the documented RTMPS format. Confirm that no accidental whitespace or stale key was introduced when copying the credential. Validate the configuration again, then look at MediaMTX logs for a connection error or rejected destination. Do not paste unredacted logs into a public issue or chat.
If the connection attempt reaches YouTube but the control room does not show a healthy feed, check the key and the selected YouTube event first. Then inspect the source encoder’s codec, bitrate, frame rate, keyframe interval and audio format against YouTube’s current guidance. A forwarding setup relays the source; do not assume it converts an unsupported or badly timed feed into a compliant one.
When the feed is intermittently missing, distinguish a source dropout from an outbound connection problem. Watch whether the MediaMTX path itself disappears, whether forwarding reports a reconnect, and whether YouTube reports a stream-health issue. If the local source stops after a computer sleeps or restarts, the fault is upstream of the forward. For a Windows-based encoder, this guide to keeping Wirecast streaming after an update or restart covers the separate problem of keeping the publishing application running.
A practical troubleshooting order is therefore: verify the source; verify the path; verify the destination and current key; validate configuration; check connection logs; then confirm YouTube’s ingest and encoder health. Change one element at a time and note what changed. This is slower than replacing several settings at once, but it preserves a clear cause-and-effect trail when a channel has to run unattended overnight.
If you want to avoid leaving a local computer responsible for keeping a prerecorded feed alive, StreamNeo can take the uploaded video and channel key, then keep the YouTube broadcast running while your computer is off. That addresses the specific operational burden of a machine at home needing to stay on; it does not replace choosing the correct YouTube event, protecting the key or checking stream health.
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
Is rtmpsAddress where I enter YouTube’s ingest URL?
No. rtmpsAddress is a MediaMTX listener setting for incoming RTMPS publishers. Put the YouTube RTMPS destination in the outbound forwarding configuration for the active path, using the current key from YouTube.
Can I forward any MediaMTX path to YouTube?
Forward the path that actually has your source, and use the syntax supported by your installed MediaMTX version. A rule on an inactive or differently named path will not send the source you expect. Confirm the path is active before troubleshooting the destination.
Does MediaMTX forwarding change the source bitrate or codec?
Do not assume it does. Forwarding sends the source onward; check the source encoder against YouTube’s current codec, bitrate, frame-rate, keyframe and audio guidance, then monitor YouTube’s stream health during a representative test.
Is RTMPS enough to keep my stream key private?
No. RTMPS encrypts the outbound connection, but you still need to keep the key out of public examples, screenshots and unredacted logs. Restrict access to its configuration and replace it through YouTube if you suspect it has been exposed.