To relay an existing HLS live source to YouTube through MediaMTX, configure a MediaMTX path to pull the source playlist, then have a separate publishing client read that path and send the output to YouTube. The exact client command depends on the source’s codecs and timestamps, the YouTube ingest details, and whether the client must transcode; there is no universal command for every HLS source.
The route is: HLS origin → MediaMTX path → local MediaMTX read URL → FFmpeg or another encoder → YouTube RTMP(S) ingest URL and stream key. MediaMTX handles acquiring and exposing the source; the separate client creates the publishing connection to YouTube.
Map the HLS-to-YouTube relay
It helps to think of this as two connections, not one. First, MediaMTX fetches an HTTP or HTTPS HLS playlist and makes its tracks available on a named path. Second, an encoder reads that path and publishes to YouTube. Enabling MediaMTX’s HLS support does not by itself send a stream to YouTube.
A simplified diagram is:
HLS source playlist
│ MediaMTX pulls the source
▼
MediaMTX path: /relay
│ FFmpeg or another compatible reader connects
▼
Publishing client ── RTMP(S) URL + stream key ──► YouTube Live
The MediaMTX project describes its software as a media server and proxy that can publish, read and proxy live streams. Its documentation also describes HLS sources and clients that read or publish RTMP streams. Those are useful building blocks, but they do not establish that every incoming HLS track can be passed unchanged to YouTube. See the MediaMTX project documentation and its HLS source configuration guide for the current syntax and behaviour.
Before configuring anything, identify the source you actually have: its full playlist URL, whether it is reachable from the MediaMTX host, its video and audio codecs, and whether it is a stable live playlist or a playlist that ends. If you do not control the origin, ask its operator about authentication, access restrictions, and expected availability. A playlist URL that opens in your browser is not proof that a server-side process can fetch it continuously.
This arrangement is useful when you already have a live HLS feed but need a distinct publishing client for YouTube. If your real requirement is instead to play a prepared video continuously without keeping your own computer on, a different workflow may be simpler; see how a cloud-based 24/7 YouTube stream works without leaving a PC on.
Pull the HLS playlist into MediaMTX
MediaMTX uses a path name to identify a stream. In the configuration, that path can be assigned an HTTP(S) HLS playlist as its source. The basic shape, with deliberately fictional values, is:
paths:
relay:
source: https://origin.example/live/index.m3u8
This is a configuration shape, not a complete deployment recipe. Replace the example URL with the source playlist you are authorised to use, and check the syntax against the version of MediaMTX you are running. The official HLS source documentation covers supported source forms and options. If the origin requires credentials, use the documented method for them; URL characters such as @, ? or # may have special meaning and may need percent-encoding when placed in a URL.
The path name relay is chosen by you. It is not a reserved name, and the path name is not the same thing as the HLS playlist filename. Later, the client will use a URL that points to the running MediaMTX instance and this path. Keeping the name short and descriptive helps when you inspect logs or manage multiple inputs.
Check the configuration actually deployed, rather than assuming defaults. The project’s rolling configuration has shown HLS on port 8888 and RTMP on port 1935, but a version, a configuration override, container port publishing, firewall, or hosting network rule can change what is reachable. A listener being enabled inside the process is not sufficient if the relevant port is not exposed to the client. For a relay hosted on a VPS, the VPS comparison for a 24/7 YouTube playlist may help you think through where the process runs, but it does not replace checking your own network rules.
Do not put a real source URL containing credentials into a public configuration example, screenshot, or support post. Treat credentials used to access the origin as secrets, just as you would treat a YouTube stream key.
Read the MediaMTX path with a client
Once the path is configured and MediaMTX is running, the publishing client needs a read URL for that path. For example, a client on the same machine might read an RTSP URL such as rtsp://127.0.0.1:8554/relay, if RTSP is enabled and reachable in the running configuration. A client on another machine would need the correct host address and a network route to that listener. The protocol and address must match what MediaMTX exposes and what the encoder can read.
This is a separate handoff from the HLS pull. MediaMTX can fetch the source while a client still fails to read the path because it is using the wrong hostname, port, protocol, path name, or credentials. Equally, a successful connection to the MediaMTX path only shows that the client can connect; it does not prove that the tracks can be encoded in a form accepted by YouTube.
The project’s RTMP documentation explains the server’s publish and read workflows. Consult the documentation for the version in use, particularly if you choose RTMP as the MediaMTX-to-client leg rather than RTSP. Avoid assuming that the incoming HLS protocol dictates the protocol the client must use to read from MediaMTX: those are independent choices.
For a separate FFmpeg publishing stage, you can first plan the command in two parts: an input that reads the MediaMTX path and an output that targets YouTube. Whether the input can be stream-copied or needs decoding depends on the actual tracks, timestamps, and output requirements. Do not copy a command from a different source and assume its input flags or codec settings apply to yours.
If your next step is to configure FFmpeg and YouTube Live Control Room, the FFmpeg connection guide covers the publishing side. Keep the distinction clear: that client should read the MediaMTX path here, not accidentally connect directly to the original HLS source unless that is an intentional alternative architecture.
Set YouTube’s ingest URL and key
In YouTube Live Control Room, create or select the live stream and use the server URL and stream key supplied for that stream. YouTube’s encoder guidance says to enter the Live server URL and stream key in the encoder. The destination is separate from MediaMTX’s source configuration: the HLS URL belongs on the MediaMTX path, while the YouTube ingest URL and key belong in the publishing client’s output configuration.
Prefer RTMPS where your encoder supports it. YouTube describes RTMPS as the secure extension to RTMP and recommends it for streaming. The exact URL format can depend on the connection details YouTube gives you and the encoder’s accepted syntax. Use the URL shown for the live setup rather than constructing a destination from a remembered example. See YouTube’s encoder settings and bitrate guidance and its guide to creating a live stream with an encoder.
Treat the stream key as a password. Do not paste it into public documentation, screenshots, or a command example that will be shared. Be aware that shell history, process inspection, and logs may expose arguments in some environments. Use a private configuration method appropriate to your encoder and host, restrict access to it, and avoid printing the full destination in troubleshooting output. If you think a key has been exposed, use YouTube’s key management controls to reset it and update the publishing client.
The client’s output needs to combine the destination URL and key in the manner that the encoder expects. Do not assume that every encoder represents them identically or that the stream key is interchangeable with an account password. Follow the current instructions in Live Control Room and the client’s documentation, then verify that YouTube recognises an incoming feed before relying on it.
A YouTube RTMP(S) destination is not the same as YouTube’s HLS ingest mode. YouTube describes HLS ingest as segmented delivery with higher latency than RTMP. Choose the destination mode deliberately; the fact that your source arrives over HLS does not mean you should send HLS to YouTube. YouTube’s HLS ingest instructions describe a separate workflow and constraints.
Check codecs and timestamps
An HLS playlist is a delivery format, not a guarantee about the codecs or timing inside it. Inspect what the source actually carries before deciding how to publish it. Note the video codec, audio codec, resolution, frame rate, and whether audio is present. Also check whether the playlist is live and advancing, whether segments are available for long enough to be fetched, and whether timestamps progress consistently.
YouTube’s current RTMP(S) guidance lists H.264, H.265 (HEVC), and AV1 video support, AAC or MP3 audio, and up to 60 frames per second. It recommends constant bitrate encoding and a two-second keyframe interval, with a maximum interval of four seconds. These are destination-side requirements and recommendations, not proof that the source can be passed through unchanged. Confirm the current official guidance before configuring a stream, because platform specifications can change.
For H.264, YouTube’s table lists 14 Mbps for 1080p at 30 fps, 17 Mbps for 1080p at 60 fps, and 8 Mbps for 720p at 30 fps. These are YouTube’s recommended bitrate values for those particular resolution and frame-rate rows, as accessed in 2026; they are not universal targets for every stream. Pick the row for the output you intend to send and consider the available upload capacity and stability on the publishing host. A higher setting does not repair a source that is already missing segments or has irregular timestamps.
If the source has no audio, do not assume that an audio track will appear by configuring a destination. If it contains an audio format the output path cannot carry, you may need to encode audio. If audio and video drift apart, inspect timestamp handling before treating it as a bitrate issue. The same principle applies to discontinuities: a live HLS origin may change timestamps or restart, and your client’s behaviour across that transition depends on the source and encoder.
For keyframe planning, see the OBS keyframe interval guide. It is useful for understanding YouTube’s output expectation, though the settings in an OBS workflow do not automatically configure an FFmpeg command or fix the timing of an upstream HLS source.
Decide whether transcoding is needed
Stream-copying means passing encoded tracks from the input through the publishing client without decoding and re-encoding them. It can reduce processing work and avoid an extra lossy encode, but it is only appropriate when the source tracks and timing are compatible with the chosen output and YouTube’s requirements. The label “HLS” alone tells you none of that.
Transcoding means decoding and encoding one or more tracks again. It gives you control over output codec, resolution, frame rate, bitrate, audio format, and keyframe interval. It also consumes processing capacity and can add latency or introduce quality loss. If the source uses an incompatible codec, has troublesome timestamps, or needs a different output profile, transcoding may be necessary. There is no single switch that makes every source suitable without checking the output.
| Choice | What it does | When it may fit | What to check |
|---|---|---|---|
| Stream-copy tracks | Passes encoded tracks through without re-encoding | Source video and audio already match the destination needs | Codec support, container/transport compatibility, timestamps, keyframe cadence |
| Transcode video and/or audio | Re-encodes selected tracks to chosen output settings | A track or timing needs conversion for the planned output | Host capacity, output quality, bitrate, frame rate, keyframes, audio sync |
| YouTube RTMP(S) ingest | Sends the encoder output as a live RTMP-family feed | You want the standard low-latency publishing route and support encrypted RTMPS | Current YouTube URL, key, and encoder settings |
| YouTube HLS ingest | Sends segmented HLS output to YouTube | Your workflow specifically calls for YouTube’s HLS ingest mode | Its separate segment and upload constraints, and higher latency than RTMP |
These choices are not all alternatives at the same layer. Transcoding is a decision about what the publishing client does to tracks; RTMP(S) versus HLS is a decision about how the client sends the output to YouTube. You can choose RTMPS and still need to transcode, or choose RTMPS and stream-copy if the source is already suitable. YouTube’s settings page is the authority for the current accepted output settings.
If you plan to stream-copy, verify the source tracks and run a test through the actual client. If you plan to transcode, choose a target format and bitrate from YouTube’s current table for the intended resolution and frame rate rather than borrowing a value from a different preset. Do not add transcoding merely because the source is HLS; first determine which track or timing constraint requires it.
Test each handoff and inspect logs
Test the stages separately before scheduling a long broadcast. First confirm that the HLS playlist is reachable from the MediaMTX host and that its media segments continue to arrive. Then inspect MediaMTX’s logs and path status to determine whether the configured path becomes available or reports fetch, authentication, or parsing errors. These are practical checks to perform; they are not results of an end-to-end test of this guide.
Next, connect a compatible client to the MediaMTX read URL. Check whether it receives the expected audio and video tracks and whether playback continues through source updates. If the path is not readable, check the configured listener, path spelling, address, ports, authentication, and host firewall before changing the YouTube output settings.
Only after the input side is understood should you configure the publishing client’s output. Check that it can decode the incoming tracks if encoding is required, that its output settings match the intended YouTube profile, and that it connects to the supplied destination with the correct key. Do not post logs containing a key or credential while asking for help; redact sensitive values first.
Finally, look in YouTube Live Control Room for an incoming preview and stream health indicators. Check continuity, audio, motion, and the reported input format. A process that remains running is not enough: the source can stall, the encoder can lose its connection, or YouTube can report a problem even while a local process continues. Keep a person available to inspect the preview during the initial test and have a recovery plan if the source or publishing client stops.
If the pain is repeatedly managing an encoder process and keeping a computer available around the clock, StreamNeo removes that specific burden by letting you upload a video once and run it as a YouTube stream with your own computer switched off. It is for uploaded-video playback, not a replacement for this live HLS-to-YouTube relay architecture.
For a test checklist, verify one point at a time: the origin responds; MediaMTX fetches the playlist; the named path is readable; the client receives the intended tracks; timestamps remain usable; YouTube receives the feed; and the preview has the expected picture and sound. Change one variable per troubleshooting attempt and record the result without recording secrets. That gives you a useful fault boundary instead of changing source, codec, and destination settings together.
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
Does MediaMTX send the HLS source directly to YouTube?
Not in this relay design. MediaMTX pulls the HLS playlist into a named path, and a separate compatible client reads that path and publishes to YouTube. You must configure and check both handoffs.
Can I stream-copy every HLS source to YouTube?
No. HLS describes how media is delivered, not whether its codecs, audio, timestamps, and keyframes suit the planned output. Inspect the tracks and test the actual publishing client; transcode only if the source needs conversion or the output settings require it.
Is YouTube HLS ingest the right destination because my source is HLS?
Not necessarily. The incoming source protocol and outgoing YouTube ingest mode are separate choices. YouTube’s HLS ingest is a segmented workflow with higher latency than RTMP, so check its current official requirements before choosing it.
What should I do if YouTube does not show a preview?
Trace the route in order: confirm the source playlist and MediaMTX path, confirm the client can read the path, then check its output URL, key, codecs, and connection. Use Live Control Room and the relevant logs to locate the failing handoff, while keeping stream keys and origin credentials out of shared diagnostics.