MediaMTX bitrate and keyframe settings for YouTube Live are easier to get right when you separate encoding from forwarding. Set bitrate, codec, rate control and keyframe interval in the software or device that encodes your video; use MediaMTX to forward the resulting stream to YouTube.
Use a 2-second keyframe interval, then select a bitrate from YouTube’s table for your actual codec, resolution and frame rate. The right value is not universal: a 1080p stream at 30 frames per second has a different recommendation from a 1080p stream at 60 frames per second, and codec choice matters too.
Decide which settings belong to the encoder
An encoder turns your picture and sound into a stream of compressed video and audio. It may be OBS, another streaming application, a camera, or a different source device. That is where you normally choose the video codec, output resolution and frame rate, bitrate, rate-control mode, keyframe interval and audio format.
MediaMTX has a different job in the usual forwarding arrangement. It receives a stream from an upstream source and routes or forwards it to another destination. Its introduction describes it as a live media server and proxy; its forwarding guide shows how to set a destination for a path. Neither task is the same as deciding how the upstream encoder compresses each frame.
That distinction answers a common question: does MediaMTX set bitrate when forwarding to YouTube? For a stream that MediaMTX receives and forwards, configure bitrate and keyframes in the encoder before the stream reaches MediaMTX. Do not search for a general MediaMTX setting that changes the bitrate or keyframe interval of every forwarded stream.
There are source-specific exceptions, which make it worth reading the setting’s context before using it. The MediaMTX configuration reference, identified as version 1.21.1 in the research checked for this article, includes Raspberry Pi camera options such as rpiCameraBitrate and rpiCameraIDRPeriod. Those apply to that camera source; they do not turn into general controls for a stream that another encoder has already created.
For example, if OBS sends an encoded stream to MediaMTX and MediaMTX forwards it to YouTube, think of two separate legs: OBS creates the audio and video; MediaMTX passes the stream along. A bitrate adjustment belongs on the first leg. A destination or stream-key change belongs on the second.
Set a 2-second keyframe interval
A keyframe is a complete reference picture from which a decoder can start or recover, rather than a picture that depends on earlier frames for all of its information. The encoder sends keyframes at intervals. YouTube’s live encoder requirements recommend a keyframe frequency of 2 seconds and say not to exceed 4 seconds.
Set the interval in the encoder in time, where possible. Some applications show a time interval; others ask for a number of frames. If the encoder asks for frames, the conversion depends on the chosen frame rate: at 30 frames per second, two seconds corresponds to 60 frames; at 60 frames per second, it corresponds to 120 frames. These are conversions of the two-second interval, not separate YouTube recommendations.
If your output frame rate changes, check that the encoder’s keyframe setting still represents about two seconds. A value entered as a number of frames does not remain the same duration when the frame rate changes. For instance, leaving a 60-frame interval after changing from 30 to 60 frames per second changes the time between keyframes.
Do not confuse keyframe interval with bitrate. A shorter interval does not simply mean “more quality”, and a longer one is not a remedy for unstable upload capacity. Treat it as its own encoder setting, set the recommended two seconds, and check the encoder’s output rather than trying to alter it in MediaMTX’s forwarding configuration.
Choose bitrate for the actual format
YouTube’s recommended bitrate varies with ingest codec, resolution and frame rate. Start by identifying what the encoder will actually send, not the dimensions of a source file or the quality setting in a video editor. A 1080p file encoded for a 720p stream should be matched to the 720p output row, for example.
The following figures are YouTube’s recommended targets in Mbps, reproduced from its current encoder guidance. Use the row and codec column that match your outgoing stream. YouTube’s table also gives minimums; a minimum is not the same as the recommended target.
| Ingest resolution and frame rate | AV1 or H.265 recommended | H.264 recommended |
|---|---|---|
| 2160p at 60 fps | 35 Mbps | 50 Mbps |
| 2160p at 30 fps | 30 Mbps | 42 Mbps |
| 1440p at 60 fps | 24 Mbps | 34 Mbps |
| 1440p at 30 fps | 15 Mbps | 21 Mbps |
| 1080p at 60 fps | 12 Mbps | 17 Mbps |
| 1080p at 30 fps | 10 Mbps | 14 Mbps |
| 720p at 60 fps | 6 Mbps | 8 Mbps |
| 720p at 30 fps | 6 Mbps | 8 Mbps |
At 1080p60, for example, YouTube lists minimums of 4 Mbps for AV1 or H.265 and 6 Mbps for H.264, while the recommended targets in the table are higher. At 1080p30, the listed minimums are 4 Mbps and 5 Mbps respectively. Check YouTube’s live table before configuring a stream, because the values and supported formats may change.
A recommended target only helps if your encoder and stable upstream connection can sustain it. If they cannot, do not force a bitrate that causes the connection to struggle. Consider a lower output resolution or frame rate, or a lower supported bitrate, and test the result. YouTube advises choosing a quality that is reliable for your connection, checking connection speed, testing before going live and monitoring stream health.
If you are weighing a lower setting against a higher one, our guide to choosing between low and high streaming bitrates explains the trade-off. The useful comparison is not a universal number; it is the format you intend to send and the sustained capacity available to send it.
Check codec and rate control
For RTMP or RTMPS, YouTube’s current encoder guidance lists H.264, H.265 (HEVC) and AV1 video, with CBR (constant bitrate) as the rate-control mode. It lists AAC or MP3 audio. Match your encoder’s available options to the format you intend to send, and check YouTube’s page for current requirements rather than assuming every encoder supports every codec or setting.
CBR aims to keep the output bitrate steady. It is useful to select it when following YouTube’s stated encoder guidance, but it does not make a limited connection more capable. If your connection cannot sustain the selected rate, a nominally constant output can still be interrupted or lost on the way to YouTube. Choose a viable format and test it over the connection you will actually use.
Codec choice changes which bitrate column applies. If you select H.264, use the H.264 recommendation; if you select H.265 or AV1, use the AV1/H.265 column. Do not take a bitrate from one codec column and treat it as a universal setting. For HDR over RTMP(S), YouTube recommends H.265; its guidance says AV1 is not supported for HDR.
Audio deserves the same check as video. Confirm the encoder is producing an audio track in a format YouTube lists, and that the sound is present in the source. A quiet or missing sound source cannot be corrected by changing video bitrate. If you are using OBS with a desktop sound source, the practical checks in this desktop-audio troubleshooting guide may help you find where audio stops entering the stream.
Configure MediaMTX to forward to YouTube
Once the encoder is producing the intended stream, configure MediaMTX’s forwarding destination. YouTube Live Control Room supplies the ingest URL and stream key for the broadcast. Use the current RTMPS destination shown there; do not assume a URL copied from an old setup, example or saved configuration is still the one to use.
MediaMTX’s forward guide documents a pattern like this in a path configuration:
paths:
mypath:
forward:
- dest: rtmps://a.rtmp.youtube.com/live2#streamKey
Here mypath represents the MediaMTX path, and the text after # represents the stream key. This is a configuration pattern, not a promise that the example destination remains current. MediaMTX says to check the URL reported by YouTube because its example reflects the URL available when that documentation was updated. Get both destination and key from the current Live Control Room details before going live.
Treat the key as a secret. Do not publish it in a screenshot, paste it into a public post or include it in a public configuration example. If you share a configuration to ask for help, replace the key with a placeholder first. Check the guide to where the YouTube live2 address is pasted and why it can fail if the URL/key distinction is causing confusion.
Use rtmps:// for the downstream YouTube leg so traffic is encrypted in transit, as MediaMTX’s instructions describe. If OBS is the source, remember that its connection to MediaMTX is a separate leg. MediaMTX documents OBS publishing over RTMP or WebRTC and recommends RTMP; its TLS requirements for RTMPS on an upstream leg are separate from the YouTube forwarding destination.
Keep the encoder and forwarding settings in separate notes. Record the source path, output codec, resolution, frame rate, rate control, bitrate and keyframe interval with the encoder configuration. Record the current YouTube destination and which MediaMTX path forwards to it separately, without writing the real key into a shared note. This makes it easier to find whether a future change belongs to the encoding or routing side.
Verify that audio and video reach YouTube
Before investigating bitrate or keyframes, confirm that both audio and video tracks exist. MediaMTX warns that YouTube requires both and silently rejects video-only streams. A picture that is visible in a local preview does not prove that YouTube is receiving the necessary audio track.
Check each point in the chain: the source has sound, the encoder is capturing it, the stream arriving at MediaMTX includes it, and the forwarded stream appears in YouTube Live Control Room. Use a controlled or private preflight where possible. Include representative audio and movement in the picture; a motionless test screen and a silent meter do not exercise the same conditions as a music, devotional, ambience or news loop.
YouTube’s guidance is to test before starting a live stream, with audio and movement similar to what the actual stream will contain. During that check, look at YouTube’s stream health and messages as well as the local encoder preview. If audio is absent, trace the audio path before changing video settings. If video is absent, check the source, encoder output and MediaMTX path before adjusting bitrate.
For a long-running channel, a successful preview is a useful check, not a guarantee that the whole night will be trouble-free. Recheck the connection and stream health after any change to the encoder, source, destination, key or network. Keep a short checklist available to whoever starts the broadcast, so an operator can verify the actual tracks and current destination rather than relying on memory.
Diagnose ingest and setting problems in order
When YouTube does not show an incoming stream, start with the simplest forwarding issues. Confirm the stream key and RTMPS URL are current and belong to the intended broadcast. Check for a copied key with missing characters, an old destination in the MediaMTX configuration, or a path that is not forwarding the stream you expect.
Next confirm that both tracks are present. Then verify protocol and codec, the encoder’s CBR mode, the bitrate row for the actual output codec/resolution/frame rate, and the two-second keyframe interval. This order helps avoid changing multiple settings at once. If the problem clears after several simultaneous changes, you will not know which setting mattered.
If YouTube receives the stream but reports a health warning, compare the format you are sending with the relevant YouTube guidance and inspect the encoder’s own status. A lower actual output resolution than expected can make you select the wrong table row. A frame-rate change can make a frame-count keyframe value represent a different duration. An audio input that was muted or never selected can explain a video-only rejection without any bitrate fault.
If the format matches but the connection is unreliable, consider whether the chosen output can be sustained on the upload connection. YouTube recommends testing and monitoring rather than relying on a speed-test result alone. Lowering resolution or frame rate may be a more useful correction than repeatedly raising or lowering bitrate without checking the stream health messages.
Keep one known-good configuration before experimenting. Change one item, run the same test, and note what YouTube reports. The guide on recovering a pre-recorded live stream after a power cut covers a different failure, but the same operational habit applies: a clear recovery process is easier when you have not lost track of the last working configuration.
If managing an always-on encoded file from a computer that must remain powered is the burden, StreamNeo removes that specific dependency: you upload the video and provide the YouTube stream key, then the 24/7 broadcast can continue with your computer switched off. It is YouTube-only, and you still need to prepare the video, use the current channel details and check the live result.
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 set bitrate when it forwards to YouTube?
For a normal forwarded stream, set bitrate in the upstream encoder or source device. MediaMTX forwards the encoded stream to its configured destination; source-specific camera options in its configuration do not apply as general controls to every forwarded stream.
What keyframe interval should I use for YouTube Live?
YouTube recommends a 2-second keyframe frequency and says not to exceed 4 seconds. Set that in the encoder, taking care to convert the interval if the application asks for a number of frames rather than time.
What bitrate should I use for YouTube Live?
Choose the recommended row in YouTube’s current table for the codec, resolution and frame rate you are actually sending. If the connection cannot sustain that target, adjust the output format or choose a lower supported bitrate and test rather than assuming a single bitrate suits every stream.
Can I forward video without audio?
No. YouTube requires both audio and video tracks, and MediaMTX’s forwarding guide says video-only streams are silently rejected. Check that audio is being captured and included before troubleshooting bitrate or keyframes.