To loop an MP4 through MediaMTX to YouTube Live, use FFmpeg to repeat and publish the file to a MediaMTX path, then configure a separate hand-off from that path to YouTube’s ingest URL and stream key. The localhost address in MediaMTX’s example is the local publishing destination, not YouTube’s server URL.
These are distinct jobs: FFmpeg reads the file, MediaMTX receives and exposes a stream, and YouTube Live receives the final feed. The official pages reviewed document the loop into MediaMTX and YouTube’s encoder setup separately; they do not provide one official command that joins both ends. Keep that boundary clear as you build and test the workflow.
What each component does
An MP4 is a container: it can hold video and audio encoded in different formats. FFmpeg opens that file, reads its tracks and publishes a stream. In the MediaMTX example, the -stream_loop -1 option repeats the input indefinitely, while the destination URL identifies a MediaMTX server and path.
MediaMTX is the receiving and routing step in this example. It accepts the published stream at a path such as mystream. Another publisher or relay can then consume that path, depending on the tools and configuration you choose. MediaMTX is not interchangeable with YouTube’s ingest endpoint simply because both may use RTMP.
YouTube Live is the destination where viewers watch. YouTube Studio’s Live Control Room supplies the stream URL and key for an encoder to send a feed. The stream key is sensitive: treat it like a password, do not post it in screenshots or logs, and reset it in Studio if it has been exposed.
A useful way to picture the intended flow is MP4 file → FFmpeg → MediaMTX path → a separately configured forwarder or relay → YouTube Live. The local MediaMTX step is useful if you want to route or inspect a stream in your own setup. It also adds a component that can fail, so if you do not need MediaMTX’s routing role, a simpler workflow may suit you better. For a different continuous-playback arrangement, see this guide to playing a podcast playlist continuously with OBS.
Get YouTube’s current URL and stream key
In YouTube Studio, open Live Control Room and create a stream or select the one you intend to use. YouTube’s encoder setup guide explains where to find the stream URL and key. Copy the values from the current stream’s settings into the encoder or relay that sends the feed to YouTube; do not substitute the MediaMTX example URL for either value.
YouTube may offer a primary stream URL and an RTMPS option. YouTube recommends RTMPS; its RTMPS instructions explain how to reveal the encrypted ingest address from the lock icon in stream settings. Choose the URL that matches the transport your sending tool supports. The encryption choice applies to the YouTube-facing connection; it does not change the meaning of the local MediaMTX publishing URL.
Before starting a broadcast, confirm that you are editing the right stream in Studio and that its settings match the intended title, audience and schedule. Avoid pasting a key into a public tutorial, shared command history or support message. You can keep a local record in a protected place, but use the current Studio value if you rotate or replace a key.
YouTube’s workflow includes a preview stage. Sending a signal does not, by itself, mean that you have made the stream public: check the preview and status in Live Control Room, then choose Go live when you are ready. If your programme is intended to start at a particular time, account for the distinction between the feed arriving and the operator actually starting the live broadcast.
Loop the MP4 with FFmpeg
MediaMTX’s FFmpeg publishing page shows this RTMP example for publishing a repeated local MP4:
ffmpeg -re -stream_loop -1 -i file.mp4 -c copy -f flv rtmp://localhost:1935/mystream
Replace file.mp4 with the path to your video. The command is an example of FFmpeg publishing to MediaMTX on the same machine, using the path mystream. It is not a YouTube command and does not contain a YouTube URL or key.
The options describe the input and the publishing format. -stream_loop -1 asks FFmpeg to repeat the input indefinitely. -re reads the file at its intended real-time pace rather than pushing it as fast as possible. -i file.mp4 identifies the input file. -c copy copies the existing encoded tracks without re-encoding them, and -f flv selects the output container used for this RTMP publishing example.
That copy mode is efficient when the source tracks already suit the next stage, but it does not convert incompatible codecs or repair a problematic file. It may also preserve an unsuitable audio or video profile. If your source does not fit the ingest settings you intend to use, you may need to encode it to a compatible format rather than copy it unchanged. Do not infer that an MP4 extension guarantees YouTube compatibility.
Before running a long loop, check that FFmpeg can read the file and identify its audio and video tracks. Test a short representative segment through the route you plan to use. Listen for silence, clipping or an unexpected audio gap, and check for a visible picture in the YouTube preview. This is a test of your actual file and configuration, not a guarantee based on the example command.
If you are choosing between a MediaMTX-based pipeline and a more direct FFmpeg workflow, the trade-off is control versus simplicity. MediaMTX can provide a reusable local path for other tools, but each additional step has its own configuration and monitoring. A direct publishing route can be easier to understand when no intermediate routing is needed; the FFmpeg switch guide for an always-on music channel discusses that kind of change in a different setup.
Publish into the local MediaMTX path
The documented command sends output to rtmp://localhost:1935/mystream. Here, localhost means the machine where the command is running, port 1935 is the RTMP listener in the example, and mystream is the path being published. This only works as written if MediaMTX is reachable at that local address and accepts the publishing connection with the relevant configuration.
If FFmpeg runs on another computer, localhost points to that other computer, not to the machine running MediaMTX. You would need to use an address reachable from the FFmpeg machine and configure access accordingly. The exact network address, authentication and firewall rules depend on your environment; the example is not a universal public URL.
MediaMTX’s documentation also describes publishing with other protocols, and its FFmpeg page presents an RTSP pattern as well as RTMP. Compare what your installed MediaMTX setup accepts with what the next tool can read. The MediaMTX basic usage documentation is a sensible reference for the server’s role and paths, but it does not turn the local publishing destination into YouTube’s endpoint.
At this point, test the local leg separately. Confirm that the FFmpeg process stays running, that the server accepts the stream, and that the expected path is available to a consumer. If publishing fails, inspect whether MediaMTX is running, whether the address is correct from FFmpeg’s machine, and whether the path and protocol are configured as expected. Do not troubleshoot the YouTube key until this local publishing step is known to work.
Forward the MediaMTX path to YouTube
The local publish command ends at MediaMTX. To reach YouTube, a separate encoder or relay must read the MediaMTX path and send the feed to the YouTube stream URL using the stream key. Configure that sending step in the tool you have chosen, then verify that it can access the path and that its output is directed to the correct YouTube stream.
The reviewed MediaMTX and YouTube pages explain their respective parts of the workflow, but they do not supply one official end-to-end command joining the loop and relay. There are multiple possible topologies: a separate FFmpeg process might read a MediaMTX output, or another compatible tool might perform the forwarding. Which approach fits depends on the protocols available in your setup and the encoder’s input and output options.
For that reason, avoid copying a guessed combined command as though MediaMTX or YouTube officially recommends it. An improvised command can contain a wrong source path, the wrong output URL, unsupported options or an exposed key. If you create your own relay configuration, label the input and destination clearly, keep credentials private, and test it with the Live Control Room preview before relying on it.
There is also an operational choice behind the extra hop. MediaMTX can be useful where you already use it to route streams or where another process needs a stable local path. If your goal is only to send one prerecorded video to YouTube, an intermediate server may add work without solving a problem you have. For a comparison of a different always-on hosting approach, this guide to looping videos on an Indian cloud VM may help you think through where a continuously running publisher belongs.
Check compatibility and preview the stream
YouTube’s encoder settings guidance lists supported ingest codecs and recommended settings for RTMP or RTMPS. For video, the listed options include H.264, H.265 (HEVC) and AV1; for audio, AAC or MP3. YouTube also provides recommendations that vary by resolution and frame rate, including a two-second recommended keyframe interval and an interval not over four seconds. Check the current guidance rather than treating these values as a promise that any file will work.
The bitrate row you choose should match the actual output resolution, frame rate and codec. A bitrate copied without its matching row can be inappropriate for the feed. YouTube recommends constant bitrate encoding and RTMPS; consult its live settings page for the current combination that suits your intended output. The guidance can change, so verify it when you prepare the stream.
Since the MediaMTX example uses -c copy, the output retains the file’s existing track encodings. Check those codecs and compare them with the ingest profile you plan to send. If they do not match, re-encoding may be necessary. The research for this guide did not test a particular file or setup, so treat the published command as a documented pattern, not a compatibility test for your material.
YouTube recommends testing with representative movement and audio, checking the Live Control Room preview, and watching stream health messages during the broadcast. Do not rely on a still frame or a silent opening to establish that the whole programme behaves correctly. A devotional loop, local news slate or study channel should be checked for the transitions, spoken sections and audio levels that actually occur in its file. For other continuous audio troubleshooting, see the guide on fixing silence between videos in a lesson stream.
Once the preview looks and sounds right, keep Live Control Room open long enough to notice warnings or changes in stream health. YouTube says streams shorter than twelve hours are automatically archived when ended; do not assume an indefinitely long stream will be saved as one continuous video. Decide separately how you will keep a copy of the source file and any records you need for the channel.
Know where the official workflow stops
There are two documented legs and one connection you must configure yourself: FFmpeg publishes a looping file to MediaMTX, then a suitable forwarder must send a MediaMTX output to YouTube. YouTube’s encoder instructions show how to supply the YouTube URL and key and move through preview to Go live. Neither page, as reviewed for this article, publishes a single official command that performs both legs together.
This distinction matters when a stream fails. If FFmpeg cannot publish, investigate the file, FFmpeg process and local MediaMTX destination. If MediaMTX receives the stream but the YouTube preview stays blank, inspect the separate consumer or relay, the YouTube URL and key, and the output format. If preview works but the broadcast is not public, check the Live Control Room status and whether you selected Go live.
A 24/7 broadcast also needs a process that stays available. A local machine must remain on and connected for a locally run pipeline; an unattended run needs a plan for monitoring, restarts and recovery if the computer or connection fails. If leaving a personal computer on overnight is the pain point, StreamNeo removes that particular burden by letting you upload a video, provide the YouTube stream key and run the broadcast with your computer switched off; it is YouTube-only, and you still need to check your content and live preview.
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 rtmp://localhost:1935/mystream YouTube’s server URL?
No. It is the destination in MediaMTX’s FFmpeg example: a local MediaMTX RTMP address and path. YouTube’s own stream URL and key are shown for the selected stream in Live Control Room.
Does -stream_loop -1 make the YouTube stream live automatically?
It makes FFmpeg repeat the input file indefinitely in the documented example. It does not configure the separate forwarding step to YouTube or click Go live in Live Control Room.
Will every MP4 work with -c copy?
No. MP4 is a container, and -c copy preserves the encoded tracks rather than converting them. Check the source codecs against YouTube’s current ingest recommendations and test the resulting preview and stream health.
Is there one official end-to-end MediaMTX command for this?
The reviewed official pages do not provide one command that both publishes the loop to MediaMTX and forwards it to YouTube. Treat those as separate configuration steps, and verify the relay you choose before relying on it.