MediaMTX can receive an RTMP stream on Ubuntu, while a separate publishing programme sends a stream to it. To reach YouTube, configure the programme responsible for the second hop with the RTMPS URL and stream key from your own Live Control Room; MediaMTX is not a YouTube encoder preset.
That separation matters because the official MediaMTX publishing guide and YouTube’s ingest instructions describe distinct tasks, not one integrated forwarding recipe. This guide tests each hop separately so you can see which programme handles it, and where a failure occurs.
What MediaMTX does in this workflow
MediaMTX is a self-hosted media server and proxy. Its official introduction describes a system for publishing, reading, proxying, recording and playing back real-time audio and video. For this setup, think of it as a place on your Ubuntu machine where a publishing client can send a stream and other clients can access it.
There are three roles to keep straight:
| Role | What it does | Example in this guide |
|---|---|---|
| Source publisher | Creates or reads the video and sends it to a destination | OBS or FFmpeg publishing to MediaMTX |
| MediaMTX | Receives a stream on a path and makes it available to clients | The local path /mystream |
| YouTube publisher or relay | Takes the stream and sends it to YouTube’s ingest endpoint | A configured encoder or forwarding programme |
A single application can sometimes take more than one role, but do not assume it does. In the test-first sequence below, OBS or FFmpeg first sends a stream to MediaMTX. Only after that local hop works do you configure a publisher or relay to send the source onwards to YouTube. If you point OBS directly at YouTube, MediaMTX is not handling that broadcast.
This distinction is also why a public YouTube RTMP address does not automatically belong in a MediaMTX YAML file. The reviewed official documentation shows how to publish to MediaMTX and how to set YouTube ingest details in an encoder; it does not give a single official MediaMTX-to-YouTube forwarding configuration. Use the documentation for the particular programme you select to perform the second hop.
Install MediaMTX on Ubuntu
Start at the current MediaMTX installation documentation and its linked releases. The project documents a standalone executable and Docker. For a direct Ubuntu trial, download the current release bundle for the operating system and architecture shown for your machine, extract it, and run the executable. Do not copy a version-specific download command from an old tutorial without checking that release still exists and matches your machine.
The architecture choice is important. An Ubuntu machine may use an x86-64 or ARM processor, for example, and the corresponding bundle must match. If you are unsure, check the machine’s architecture before downloading rather than assuming linux_amd64. The release page is the place to confirm the current filename and available builds.
Once extracted, follow the project’s current instructions to start ./mediamtx from its directory. Keep the terminal visible for the first test: its output can help establish whether the service started and whether a client connected. The programme is the MediaMTX server; it is not yet a video source and it is not sending anything to YouTube.
Docker is the other documented installation route. The official guide recommends it for production environments, while also documenting the standalone executable. A container can make a deployment more repeatable and isolated, but it asks you to understand container commands and persistent configuration. The executable is a more direct way to try the local workflow. Neither is a universal fit for every Ubuntu machine.
| Install route | Useful when | Consider before choosing |
|---|---|---|
| Standalone release executable | You want to test MediaMTX directly on Ubuntu | You must choose the matching release and architecture, and manage how the process starts and restarts |
| Docker | You already manage services as containers or want a repeatable container setup | You need to be comfortable with Docker and its configuration and lifecycle |
The project’s guidance is rolling, so do not treat an older article’s version number as current. For a channel intended to stay on continuously, plan how the process will start after a reboot and how you will notice a stopped service. First prove the stream path manually; then make the operating arrangement durable.
Publish a test stream to a MediaMTX path
The first test is deliberately local: prove that one publishing client can reach MediaMTX before adding YouTube. MediaMTX’s RTMP client documentation gives rtmp://localhost/mystream as an example publishing address. Here localhost means the same machine on which MediaMTX is running, and mystream names the path. The stream is available at /mystream within MediaMTX.
In OBS, open the stream settings, choose the custom service option, and use the local RTMP address as the server. The MediaMTX OBS guide describes this local publishing setup and leaves the stream key empty for that path. Start with a simple test scene or source, then start streaming. FFmpeg is another documented RTMP publishing client; use its current instructions if you prefer a command-line source.
Watch the MediaMTX terminal while the client connects. A connection there is evidence that the local publishing client has reached the server; it is not evidence that YouTube is receiving video. If the client rejects the address or the server shows no connection, stop and check that MediaMTX is running, that OBS has the local address rather than YouTube’s address, and that the path spelling agrees.
If OBS and MediaMTX are on different computers, localhost is no longer the right address. Use the Ubuntu machine’s reachable network address and confirm that the chosen port is allowed by the host and network firewall. Keep the test on a trusted local network first where possible. Exposing a media service to the public internet involves access control and network decisions beyond this basic publishing check.
A useful next test is to read or preview the path with a compatible client, following MediaMTX’s reading documentation. That confirms a second client can retrieve what was published. Treat each result narrowly: publisher-to-server works if MediaMTX receives it; server-to-reader works if a reader can access it. Neither confirms that an onward YouTube publisher has been configured.
Get the current RTMPS URL and key from Live Control Room
When the local path behaves as expected, prepare the YouTube destination. Create or schedule the live stream in your YouTube Live Control Room, then open Stream settings. YouTube’s RTMPS Help page explains how to reveal and use the RTMPS URL. Copy the current Stream URL and the stream key shown for that stream into the encoder or relay that will publish to YouTube.
Do not hard-code a URL or key from this article, another channel, or an old configuration. YouTube provides the destination details in Live Control Room, and the default URL shown may be ordinary RTMP rather than RTMPS. Check that the selected URL actually uses RTMPS when you intend to use the secure ingest option. YouTube describes RTMPS as RTMP over TLS/SSL.
The stream key is a credential. Keep it out of screenshots, public configuration files, chat, and examples you share. If it has been exposed, review the available controls in Live Control Room and replace or reset it as appropriate. A key is not the same thing as a stream URL: the URL identifies where to connect, while the key identifies the stream configuration. The distinction is explained further in this guide to what a YouTube stream key and URL each do.
YouTube may show controls and labels differently over time. Follow the current official page and the interface in your own account, rather than treating screenshots in a third-party tutorial as authoritative. Also check that your channel is able to start the planned live stream and that the stream has been created before testing the destination.
Configure the upstream publisher or relay for YouTube
Now identify the programme that will perform the second hop. It must be able to take the source stream and publish it to YouTube’s RTMPS URL with the stream key. This could be a separate encoder or relay, or a publishing application configured to read from the MediaMTX path and send onward. Check that programme’s own documentation for its supported input and destination settings.
There are two common arrangements, and they are not interchangeable:
- Direct publishing: OBS or another encoder sends its output straight to YouTube. In this arrangement, MediaMTX is not in the broadcast path. It can still be useful for a separate local test, but the direct stream does not prove MediaMTX forwarding.
- Two-hop publishing: One client sends a stream to MediaMTX, and a separate publisher or relay reads that stream and sends it to YouTube. You need a programme capable of both reading the MediaMTX output and publishing to the YouTube destination, or another documented way to bridge those tasks.
The official pages cited here do not specify one integrated forwarding recipe for MediaMTX and YouTube. Do not invent a YAML key or paste a YouTube URL into an arbitrary MediaMTX configuration field on that assumption. MediaMTX has configuration options, but you should only use a forwarding setting when the current official documentation for the relevant component confirms it.
If a relay’s configuration includes fields for an input path and an output destination, confirm their meaning in that relay’s documentation. The input should refer to the stream that MediaMTX actually provides; the output should use the current RTMPS URL and key from Live Control Room. Check whether the relay expects the key appended to a URL or entered separately, rather than guessing. Keep credentials private in whichever configuration the programme requires.
For anyone editing MediaMTX configuration, consult its current configuration documentation. The guide documents file-based configuration as well as environment variables and the Control API, and gives a validation command in the form ./mediamtx --validate-conf=/path/to/mediamtx.yml. Use the actual path to your file. Validation can catch configuration errors; it does not prove that a separate relay can read a path or that YouTube will accept a broadcast.
A channel that uses a fixed video loop may be served by a different publisher arrangement from a live camera feed. Choose based on what creates the source and what must remain running. For a broader look at a persistent local loop, see running a YouTube live loop with systemd and FFmpeg. It covers a different operating pattern, not a MediaMTX forwarding recipe.
Test each hop and verify the live preview
Run tests in order, changing one connection at a time. First, start MediaMTX and confirm its process is active. Second, publish a test source to the local MediaMTX path and confirm the server registers the connection. Third, use a reader or preview client to check the MediaMTX output if your setup requires it. Finally, configure and start the programme responsible for YouTube ingest, then check YouTube’s Live Control Room preview and stream status.
| Test | What you are checking | What a pass does not prove |
|---|---|---|
| Publisher to MediaMTX | The client can connect to the server and named path | That a reader can fetch the path or YouTube can receive it |
| MediaMTX to reader | A compatible client can access the published stream | That the onward publisher is configured correctly |
| Publisher or relay to YouTube | The destination accepts the connection and the Live Control Room receives a signal | That the final public viewing experience is ready or will remain uninterrupted |
| Live preview and channel check | YouTube shows the expected video and audio before you make the stream public | That every later restart or network condition will work |
If you have a private or unlisted test stream available, use it to inspect picture, audio and timing before relying on the setup. Confirm you are looking at the intended scheduled stream, not a previous broadcast. A preview can be delayed, so wait for the interface to reflect the new connection and inspect the actual output before changing settings.
For a two-hop setup, note which programme reports each connection. If MediaMTX logs the first publisher but the YouTube preview stays empty, the first hop may be healthy while the relay, destination details or second network connection is not. If there is no local MediaMTX connection, troubleshooting YouTube keys will not fix that earlier failure. This simple separation saves repeated edits to unrelated settings.
Once a test succeeds, write down the actual addresses, path name and which application owns each connection, but redact the stream key. If you later change the source, restart a service, or move the server, test again from the earliest affected hop. A setup that works once is a useful baseline, not a guarantee of uninterrupted operation. For channel continuity checks, overnight Punjabi music stream guidance can help you think through what to observe during a longer run.
If your real goal is a 24/7 channel but you do not want to keep a self-managed Ubuntu process and relay operating, StreamNeo can take an uploaded video and run it as a YouTube live stream without keeping your own computer switched on; this avoids having to maintain this particular local publishing chain, though it does not replace MediaMTX for other uses.
Troubleshoot connection and destination issues
No connection appears in MediaMTX. Check first that MediaMTX is running, then check the publishing client’s server field, path spelling and whether it is targeting the Ubuntu machine. localhost only reaches the same machine, so it will fail when the publisher runs elsewhere. If the clients are separate, check reachability and firewall rules before changing YouTube settings.
MediaMTX receives the stream, but a reader cannot open it. Confirm that the reader is using the right protocol and path for the way MediaMTX is configured. Look for a publishing disconnect or path mismatch in the server output. Test a known compatible reader according to MediaMTX’s documentation, and avoid changing several settings at once.
The local test works, but YouTube has no preview. That points to the second hop or destination configuration rather than the first one. Confirm which programme is sending to YouTube, and check that it is reading the MediaMTX stream rather than an empty or different source. Retrieve the current URL and key again in Live Control Room, verify RTMPS where intended, and check the relay’s own logs for connection or authentication errors.
YouTube shows the wrong stream or rejects the connection. Make sure the key belongs to the scheduled stream you are monitoring and that the destination URL and key have not been swapped or copied with extra characters. A key is sensitive; do not paste it into a public support post while asking for help. Consult YouTube’s current ingest guidance and the encoder’s documentation rather than relying on an old hard-coded endpoint.
The stream starts but picture or sound is wrong. Inspect the source before the relay: a local MediaMTX reader can help establish whether the original feed already has the problem. If it looks and sounds correct locally, inspect the relay’s input and output settings, then the YouTube preview. Keep a note of which stage first shows the fault; otherwise a source issue, encoding setting and destination problem can look alike.
A YAML edit prevents MediaMTX from starting. Restore the last known working file if needed, then validate the intended configuration with the command documented by MediaMTX before restarting. Use the current configuration reference for the exact option names. Do not assume a field accepted by another streaming tool is also valid in MediaMTX.
For problems that only appear after a YouTube connection, compare the status shown in Live Control Room with the publisher’s report and the MediaMTX log. YouTube’s status can point to an ingest or stream-quality concern, while MediaMTX’s log only reports its own side of the workflow. If the broadcast is stuck processing after the ingest stage, this checklist for a YouTube broadcast stuck processing covers another set of destination-side checks.
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 MediaMTX a YouTube streaming encoder?
No. MediaMTX is a media server and proxy, and it can receive and provide streams. You still need a publishing programme that can send to YouTube, and a two-hop arrangement requires a documented way for that programme or relay to read from MediaMTX and publish onwards.
Can I paste YouTube’s RTMPS URL into MediaMTX YAML?
Do not assume that you can. The official materials covered here describe MediaMTX publishing and YouTube ingest separately, but do not document one integrated forwarding configuration. Check the current documentation for the exact component that will perform the second hop.
Should I use RTMP or RTMPS?
Use the destination URL supported by your encoder and follow YouTube’s current Live Control Room instructions. RTMPS adds TLS/SSL transport security; check that the URL is actually RTMPS rather than assuming the default displayed address uses it.
Do I need Docker to run MediaMTX on Ubuntu?
No. MediaMTX documents both a standalone release executable and Docker, and recommends Docker for production environments. Pick the method you can operate and maintain, then test the stream path before relying on it for a continuous channel.