A Raspberry Pi can run MediaMTX to receive video from a camera or another publishing source and forward it to YouTube Live. The Pi and MediaMTX provide a relay path, not a guarantee that the source, network or YouTube broadcast will stay live without interruption.
The practical task is to verify each hand-off: source to Pi, source into a MediaMTX path, and that path onward to the current YouTube ingest URL and stream key. You will also need to confirm that the outgoing stream contains audio as well as video, and test what happens after a source, network or power interruption.
How the Raspberry Pi-to-YouTube path works
MediaMTX describes itself as a media router: it accepts streams and routes them between supported protocols and destinations. In this arrangement, the camera or publisher creates the video feed; MediaMTX receives that feed on the Pi and forwards it to YouTube. The distinction matters when troubleshooting. A relay cannot restore a camera feed that has stopped producing video, and a working local feed does not by itself prove that YouTube is receiving it.
For a native Raspberry Pi camera, MediaMTX can use a configured path such as cam with source: rpiCamera. The camera feed is then available through the corresponding local path, /cam, for a client or forwarding rule to use. A different publishing source might send a feed to that path over a protocol MediaMTX supports. The source must be configured to publish; installing the relay alone does not create video.
The end-to-end route is therefore: camera or publisher → local MediaMTX path → forwarding destination → YouTube Live Control Room ingest. At each stage, check the address, protocol and whether the feed is present. MediaMTX’s introduction and feature guide explains its routing role and related monitoring features. Those features can help you inspect a stream, but they do not establish that every fault in the complete route will recover automatically.
Before choosing hardware or configuring the destination, decide what must be true for your channel to count as live. A devotional camera view may need only a stable picture and soundtrack; a local news loop may need a publisher that changes programmes on schedule. Write down whether audio comes from the camera, a separate microphone or an existing encoded feed. This makes it easier to test the actual source rather than merely seeing a stream name appear in a control panel.
Choose a camera or publishing source
MediaMTX documents native Raspberry Pi camera support, including Raspberry Pi OS Trixie and Bookworm in 32-bit and 64-bit versions. Its built-in camera example uses rpiCamera. For a standalone installation, choose the MediaMTX binary matching the Pi’s operating-system architecture; the current camera guide specifies arm64 for a 64-bit OS. Check the guide again before installation, since the supported builds and instructions can change.
A compatible camera is not the only option. MediaMTX’s camera guide also describes taking input from an external rpicam-vid process, and other supported publishers can send video into MediaMTX using a compatible protocol. In every case, identify which program or device is responsible for capturing and encoding the picture. MediaMTX forwards media; it should not be confused with the camera or source encoder.
Do not assume every camera marketed for a Raspberry Pi works with the precompiled build. MediaMTX notes that some products, including certain ArduCam models, require a custom libcamera and may require building MediaMTX from source. If your camera has a special driver or capture utility, check its compatibility before making it part of a long-running setup. A source that works only after a manual desktop action is also a poor fit for unattended operation unless that action can be made reliable after reboot.
Audio needs its own decision. A camera feed may be video-only, while YouTube’s requirements for the forwarded stream include both audio and video. If your source already produces an audio track, verify that it survives the path. If it does not, MediaMTX documents a USB microphone workflow using GStreamer and ALSA utilities. A separate microphone adds another device, cable and input configuration to check; it is not enough simply to plug it in and assume the outgoing stream includes its sound.
For a loop of prepared video rather than a camera view, a publishing application can supply the feed to MediaMTX. The job is still divided: the publisher chooses and emits the content, MediaMTX routes it, and YouTube receives it. If you are deciding between a custom Pi relay and a managed file-based workflow, the trade-offs in choosing a flexible YouTube streaming setup are relevant. Keep the source choice separate from the forwarding configuration so a change to one does not obscure problems in the other.
Install and configure MediaMTX on the Pi
Start with the current MediaMTX Raspberry Pi camera guide rather than an old copied configuration. Download the build appropriate to your operating system and architecture, retain the example configuration file, and make one change at a time. If you use Docker instead of the standalone binary, MediaMTX documents a Raspberry Pi image and the associated device and privilege requirements; follow those instructions rather than assuming a container can access the camera automatically.
In the configuration, define the path that represents your source. For the native camera example, that means a path named cam with source: rpiCamera. The details may need adjustment for camera mode, resolution or bitrate. For a different source, configure the path and publishing method it expects. Keep a copy of the working configuration before changing it, and record which source address is meant to publish to which path.
Avoid selecting a high resolution or frame rate just because the camera offers it. The Pi must capture or accept the feed, and the complete route must encode and upload it at settings suitable for the network and YouTube. Codec support in YouTube’s guidance does not mean every Pi can encode every listed codec in real time. Begin with a configuration the source and chosen publishing software can produce, then assess the result in YouTube’s stream health checks.
If you need to reach the local stream from another application, use the protocol and path MediaMTX is configured to expose. Protect the stream key and any credentials used by a source; do not put them in a public post or screenshot. For a broader account checklist, see how to secure your YouTube and streaming accounts. The YouTube stream key is a credential for publishing, so treat it accordingly and rotate it if it is exposed.
Publish the source into a MediaMTX path
A path is the hand-off point between the camera or publisher and MediaMTX. With the native camera source, MediaMTX opens the camera through its built-in integration. With an external publisher, configure that application to send its output to the Pi’s MediaMTX address and the intended path. The exact protocol and URL depend on the publisher and the MediaMTX configuration; use the current documentation for both rather than borrowing a URL from an unrelated example.
Test this local leg before adding YouTube forwarding. Confirm that the source starts after a deliberate stop and that a client can read the path. If the local view is blank, silent or intermittent, resolve that problem first. Check camera permissions and device selection, publisher output settings, the path name, and whether another process has taken exclusive access to the camera. A dashboard or running process is not evidence that useful media is arriving.
For a video loop, the source process must also handle the end of the file or playlist in the way you intend. If it exits at the end, the relay may have nothing to forward until it is restarted. If a transition card is part of your programme, the FFmpeg title-card workflow covers one way to build that into a source sequence. Whatever creates the programme, verify that the feed continues through a file boundary rather than checking only a short section in the middle.
MediaMTX can expose metrics and performance monitoring that help you see whether a stream is present. Use these as diagnostic signals alongside the source application’s own logs and a real playback check. A local viewer establishes only that the feed reached the Pi; it does not confirm that the forwarded destination, YouTube ingest or public playback is healthy.
Forward the path using YouTube’s current ingest details
In YouTube Live Control Room, open the stream settings and retrieve the current stream URL and stream key. MediaMTX’s forwarding configuration uses a destination URL with the key appended after #. Its documentation includes an example, but explicitly cautions that the example endpoint is historical. Do not copy its hostname as though it were guaranteed to be current. YouTube’s live streaming setup help explains where to obtain the stream URL and key in the control room.
Prefer RTMPS where YouTube provides it. YouTube describes RTMPS as RTMP over a TLS/SSL connection, which encrypts the feed while it travels to the ingest point. The YouTube RTMPS instructions explain how to obtain the RTMPS URL. If you encounter a certificate or SSL error, check that the protocol and server address match the current control-room details. YouTube’s guidance says port 443 may be appropriate in some cases; do not copy an old certificate fingerprint from a tutorial as a universal setting.
Keep the stream key private and confirm that the forward rule points at the intended path. Before starting a public broadcast, check the control room’s preview and status. An RTMPS connection can be established while the media itself is wrong or incomplete; in particular, MediaMTX warns that YouTube can silently reject video-only streams. Confirm both audio and video at the destination.
YouTube recommends testing upload bitrate and stream health with representative audio and picture movement. Its encoder guidance recommends constant bitrate (CBR), a two-second keyframe interval and not exceeding four seconds. The recommended bitrate depends on codec, resolution and frame rate. For H.264, YouTube’s current guidance lists these ranges:
| H.264 output | YouTube recommended bitrate range |
|---|---|
| 720p at 30 fps | 3–8 Mbps |
| 1080p at 30 fps | 5–14 Mbps |
| 1080p at 60 fps | 6–17 Mbps |
These are YouTube’s recommendation ranges, not a measured requirement for a Raspberry Pi and MediaMTX installation. Choose a setting the source can encode and the internet connection can sustain; test upload performance rather than treating the top of a range as a target. Check YouTube’s encoder settings and bitrate recommendations for current codec-specific guidance. A stable lower setting is more useful than a higher setting that regularly overwhelms the available upload capacity.
Plan for power, network, heat and restarts
A Pi used as a relay depends on more than its software configuration. Power interruptions, a loose camera cable, a router restart, an internet outage, heat or storage problems can each interrupt a different part of the chain. Consider the physical setup before leaving it unattended: use a suitable power supply, keep the device ventilated, secure connectors, and avoid placing it where dust or heat can build up. These are precautions, not a promise that hardware will never fail.
Upload capacity is the part of the internet connection that carries the stream out. Test it at the location and time when the channel will run, and leave practical headroom for normal variation and other devices using the connection. YouTube specifically recommends testing upload bitrate. A speed test at a quiet time does not show what happens when other users begin a video call or upload a large file, so observe the stream under representative conditions.
The path can fail in layers. If the camera stops, MediaMTX may still be running. If the Pi loses internet access, the local path may remain viewable while YouTube loses the feed. If the Pi reboots, the source and MediaMTX need to start again in the right order. Configure your operating system’s service startup deliberately, then verify it by rebooting and checking both the local path and YouTube preview. Do not infer restart behaviour from a process that was started manually in a terminal.
MediaMTX documents configuration reloads and monitoring features, but that is not a guarantee that the complete route will reconnect after every interruption. Decide how you will notice a failure: a local log check, YouTube’s stream health display, or a human reviewing the channel. For a more detailed look at diagnosis at the source end, the guide to FFmpeg input-read stalls can help distinguish an input problem from a destination problem.
Do not plan around an assumed maximum broadcast duration or assume that a stream can be left open indefinitely. The official material covered here does not establish a duration limit or a forced-reset policy for this exact setup. Check YouTube’s current rules and your own Live Control Room status, and plan a way to resume or re-create a broadcast if a platform or connection event ends it.
Test recovery and confirm audio and video
Test each segment separately, then test the complete route. First, view the local MediaMTX path and confirm the camera or publisher is supplying a picture. Next, start the forward to YouTube and inspect the control-room preview and stream health. Listen for the audio at the destination, not only at the microphone. A video-only stream can appear to have a live connection while YouTube does not accept it as a valid broadcast.
Then simulate failures you can safely reproduce. Stop and restart the source; disconnect and restore the network; reboot the Pi; and check what starts automatically. Observe logs and YouTube’s status at each point. Note the time needed to resume and any manual step required. A successful test shows how this installation behaved in that test, not how every future outage will behave.
If you see pauses while using UDP, MediaMTX’s Raspberry Pi guide notes that insufficient UDP receive-buffer space can drop data and cause visible interruptions. It describes system buffer settings as a possible intervention, including a configuration-file distinction for Raspberry Pi OS Bookworm. Apply that guidance only when the path uses UDP and the symptom fits; it is not a universal fix for a silent source, a saturated upload link or a YouTube ingest problem.
Keep a short recovery checklist beside the Pi: verify camera or publisher output, confirm the MediaMTX path, check the forward destination, inspect the YouTube control room, and verify audio and video again. If you change a bitrate, camera mode, operating-system package or forwarding URL, repeat the relevant tests. The goal is not to claim uninterrupted service; it is to know which part failed and what recovery step is appropriate.
For a channel built from a fixed video file rather than a live camera, compare whether the maintenance burden of this source-to-relay path suits your needs.
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 create the video feed?
No. A camera or publishing application supplies the media, and MediaMTX receives and forwards it. If the source stops capturing or publishing, you need to diagnose that source separately from the relay.
Can I use a Raspberry Pi camera directly?
MediaMTX documents a native Raspberry Pi camera source, using source: rpiCamera, for the supported operating systems and architectures in its current guide. Check compatibility for your exact camera, since some models need custom libraries or a different build approach.
Why is YouTube not showing my stream if MediaMTX is forwarding it?
Check the current URL and key in Live Control Room, then confirm the outgoing feed has both audio and video. Also inspect YouTube’s stream health and the source and MediaMTX logs; an active forward does not by itself prove that YouTube is receiving acceptable media.
Can this setup be left running continuously?
The workflow can be configured for a long-running broadcast, but the cited guidance does not establish a maximum duration or guarantee uninterrupted operation for a particular Pi. Test recovery from source, network and power interruptions, and check YouTube’s current requirements rather than assuming the stream will run indefinitely.