Set the keyframe interval to 2 seconds in the encoder that actually sends your stream to YouTube. YouTube recommends that cadence and says not to exceed 4 seconds; if OBS feeds a relay or another encoder, the final sender may be the place to change it.
Then test the stream in YouTube Live Control Room and review its health messages. The setting is a focused fix for a keyframe-frequency warning, not a guarantee against every stream-health problem.
What YouTube means by a missing-keyframes warning
YouTube checks the incoming video stream and shows messages beside the stream health indicator in Live Control Room. Its live streaming error guidance describes a keyframe-frequency problem as keyframes arriving too often or not often enough. “Missing keyframes” is a common way to describe the latter, but the actual message may refer to frequency rather than a literal missing frame.
A keyframe, also called an I-frame, gives a video decoder a complete picture from which it can begin or recover playback. Other video frames can describe changes relative to nearby frames. The interval between keyframes therefore affects how frequently a player or decoder can encounter a fresh reference point. If the cadence is too long, viewers may have to wait longer for a useful point to begin decoding after joining or recovering from a disruption; YouTube says keyframes sent too infrequently can cause buffering.
YouTube recommends a two-second interval and a maximum of four seconds for the relevant encoder guidance. This is a cadence instruction, not a bitrate setting and not a promise that a stream will be healthy once the interval is changed. At 30 frames per second, two seconds works out to 60 frames; at another frame rate the corresponding count changes.
There is an important diagnostic caveat. YouTube notes that ingestion errors can result in incorrect GOP sizes, which can affect the reported frequency. GOP, or group of pictures, is the span of video between keyframes. If your encoder already shows the recommended interval, do not keep changing unrelated settings blindly: check which device sends the final feed, and inspect the stream path and other health messages.
For a looping channel, a warning might appear during an overnight devotional playlist, a study stream or a local news loop. The fact that the file plays smoothly on your own computer does not establish what cadence reaches YouTube. The relevant signal is the encoded stream arriving at YouTube, not simply the media file’s playback in OBS.
Set a two-second keyframe interval
Start with the encoder’s streaming output settings. Look for a control called Keyframe Interval, Keyframe Frequency, or a similar label. Set it to 2 seconds if it accepts seconds. If the control is expressed in frames, calculate the corresponding value from the output frame rate rather than entering “2” and assuming the units are seconds.
For example, at 30 fps, two seconds corresponds to 60 frames. At 25 fps it corresponds to 50 frames, and at 60 fps it corresponds to 120 frames. Those are conversions of the same two-second target, not separate YouTube recommendations. If an encoder accepts a time value, using seconds avoids ambiguity; if it requests frames, confirm the output frame rate and enter the equivalent frame count.
YouTube’s encoder settings guidance covers recommended settings for sending a live stream. Use it alongside the selected encoder’s own documentation, since controls and units vary. OBS’s advanced recording settings guide lists a keyframe interval of 2 in several encoder examples, but it is specifically a recording guide. It does not establish one streaming-menu path that applies to every OBS version and encoder combination.
Avoid treating a numeric field as self-explanatory. A value of 2 could mean two seconds in one control and two frames in another. Read the field label and, where available, its help text. If the selected encoder exposes an interval control with a units choice, make the units explicit and re-open the settings before a test to confirm the saved value.
A keyframe interval is also distinct from frame rate, resolution and bitrate. Changing those together makes it harder to see whether the warning changed because of the cadence or because something else about the feed changed. Keep the test focused: correct the interval at the relevant sender, preserve the other intended output settings, then check the result.
Find the active OBS streaming encoder
OBS can offer different output modes and encoder choices, so first identify the encoder used for streaming, not merely one listed elsewhere in OBS. Open the settings area for output and look at the streaming section. Depending on OBS version and output mode, you may see a simple or advanced view, and the available controls may differ. The exact path and wording are not uniform enough to prescribe one menu sequence for every setup.
Check which encoder is selected for the streaming output. If the selection is a hardware encoder, the keyframe control may be exposed through that encoder’s settings; if it is a software encoder, it may have a different set of fields. The name of an encoder available for recording does not prove that it is the one currently sending the live output. Recording and streaming can use different output choices.
If you use an OBS profile or scene collection for different channels, check the one active for this stream. A profile prepared for a daytime test may not be the profile used for an overnight loop. Likewise, if a channel has a separate streaming workflow, verify the actual running instance rather than relying on notes from an old setup.
A practical check is to start a private or otherwise controlled test stream, then inspect the streaming output configuration while the stream is in use. Confirm the selected encoder, its interval field and the frame rate of the output. You can note those together in a small run sheet: encoder, protocol or relay path, frame rate, keyframe interval and the date tested. That record is useful when someone else maintains the channel or when a future OBS update changes the available settings.
Do not infer that OBS is the final sender just because you start the process there. OBS may send to a relay, a cloud workflow or another encoder, which then forwards a new feed to YouTube. In that arrangement, YouTube receives the downstream output, so the downstream sender’s interval matters most. The next step is to map the whole route before changing settings.
Check relays and external encoders
Write down the path from source to YouTube in order. A simple case may be OBS directly to YouTube. A more layered case could be OBS to a relay, then the relay to YouTube. Another setup may use a separate application or appliance after OBS. The last device or service that encodes and sends video to YouTube is the final sender for this diagnosis.
A relay can forward an existing encoded stream, or it can decode and re-encode it; those behaviours are not interchangeable. If it re-encodes, its output cadence can differ from what OBS produced. If it only forwards the stream, a change in OBS may carry through, but you still need to verify the final result in YouTube rather than assume the relay preserved every property. Consult the documentation for the specific relay or encoder in your path.
This is why a setting that appears correct in OBS may not clear the warning. If a downstream encoder creates the YouTube feed, adjust that encoder’s output configuration. If the relay exposes no interval control, establish whether it preserves or changes the input stream and use the vendor’s documentation or support materials to understand its behaviour. Do not enter an OBS value into an unrelated field simply because its label sounds similar.
If you are running a long loop, also consider whether your process restarts or switches sources during the day. A new sender process may load a different profile or preset. For example, you might test a 30 fps OBS profile in the afternoon, then have an automated job restart an external encoder with a separate preset overnight. A short test of the daytime path would not validate the overnight sender.
For broader continuity issues, it can help to understand how FFmpeg reconnect options for YouTube RTMP streaming relate to recovery after a connection break. Reconnection and keyframe cadence are separate concerns: reconnect behaviour does not set the keyframe interval, and an appropriate interval does not ensure that a broken connection will recover. Keep those checks distinct while troubleshooting.
Apply the setting at the final sender
Once you have identified the final sender, change only its keyframe interval first. Set the value to two seconds, or to the equivalent frame count if the control requires frames. Save or apply the configuration, then verify that the sender is actually using it. Some applications require a restart of the output before a changed encoder setting takes effect; follow the selected encoder’s instructions rather than assuming a setting changed a stream already in progress.
If OBS sends directly to YouTube, make the change in the active OBS streaming encoder settings. If a relay or separate encoder is downstream, use its output settings instead. If both systems encode, confirm the interval on the final encoding stage; changing an upstream encoder can be useful, but it may not determine the cadence that reaches YouTube.
Avoid simultaneous changes to resolution, bitrate, frame rate, codec and keyframe interval unless the test reveals another reason to alter them. YouTube’s recommended bitrate varies with codec, resolution and frame rate, so a single bitrate figure is not appropriate for every stream. The relevant YouTube guidance also discusses codec and bitrate choices; use the recommendation for your actual output rather than copying a setting from an unrelated format or channel.
When a two-second value is not available, pause before choosing an approximation. Check whether the interface expects frames, whether a preset locks the control, and whether you are editing the streaming rather than recording output. YouTube says not to exceed four seconds, but the two-second target is the recommendation. A value below the maximum is not automatically equivalent to the recommended cadence, so use two seconds where the sender allows it.
For a channel that runs unattended, keep a record of the exact final sender and the setting used. A concise note such as “OBS direct, software encoder, 30 fps, 2 seconds” is more useful than “OBS fixed”. If you later move the output through a relay or change the frame rate, revisit the note and retest, because the stream path or frame conversion may have changed.
Test the stream and monitor health
Test before an important broadcast, not for the first time as a programme goes live. Start a controlled test through the same route, with the same sender and output configuration you intend to use. Open YouTube Live Control Room and watch the stream health indicator and its messages. Confirm that the keyframe-frequency warning no longer appears, or note whether it remains and what else is reported.
A brief local preview is not enough to validate delivery. YouTube evaluates the incoming stream, and a path that includes a relay must be tested end to end. If the channel normally runs overnight, include the steps that will run overnight: the same profile, automation, source switching and final sender. The aim is not to simulate every possible failure, but to test the actual configuration that will feed the broadcast.
Monitor the stream after making the change. YouTube’s guidance for encoder settings recommends testing before going live and monitoring stream health. Check messages at the start and during the broadcast, especially after a reconnect, output restart or change of source. A healthy reading at one moment does not establish that the rest of the stream will remain healthy.
Keep observations specific. Record when the warning appears, the encoder that was sending, whether the feed passed through a relay, and any other messages shown in Live Control Room. If the warning returns only after a restart, compare the running configuration with the one you tested. If it appears while other ingestion messages are present, investigate the path and connection as well as the interval.
For a long-running stream, continuity questions are worth treating separately from encoding settings. The guide to running a 24/7 YouTube stream without OBS is relevant if you are weighing whether OBS should be part of an always-on workflow at all. That is a workflow choice, not a correction for the keyframe warning; whichever arrangement you use, test the sender that reaches YouTube.
Check remaining warnings without guessing
If the two-second interval is in place and the keyframe warning remains, work from evidence. Re-check the final sender and its active output configuration. Confirm whether the field is measured in seconds or frames, and make sure the tested stream uses the same profile and path as the live broadcast. A mismatch between a saved configuration and a running process is a more useful lead than repeatedly changing values without checking them.
Then read the other Live Control Room messages. YouTube’s error guidance notes that ingestion errors can lead to incorrect GOP sizes, so a frequency message may not be solely an encoder setting problem. A connection issue, a relay behaviour or another input problem could be relevant. Investigate the reported message and the stream route; do not assume every health alert is fixed by changing keyframes.
Also separate a keyframe issue from an unrelated viewing complaint. If the health indicator is clear but some viewers report delay, that may involve latency or playback conditions rather than the interval. The article on acceptable streaming latency for live broadcasters can help frame that different question. Avoid using a keyframe setting as a catch-all remedy for buffering, disconnections or delayed playback.
If you use HLS rather than the ordinary RTMP/RTMPS path, use YouTube’s HLS-specific documentation. Segment and protocol requirements are different, and switching protocols is not necessary just to address the usual keyframe-frequency warning. Keep the protocol you have unless there is a separate reason to change it, and test against the guidance for that protocol.
When the warning persists, preserve the evidence before making another change: capture the exact message, note its time, record the sender and path, and compare the interval control with the stream’s actual frame rate. Then consult the official documentation for OBS, the final encoder or relay, and YouTube. This creates a repeatable diagnosis rather than a series of unexplained setting changes.
If your actual problem is that a long-running broadcast should continue while your local computer is off, that is a separate operating question from the keyframe setting. StreamNeo turns an uploaded video into a YouTube live stream that keeps running with your computer off, which removes the need to leave an OBS machine running for a file-based channel; the sender’s stream still needs to be tested and its health monitored.
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
What keyframe interval should I use in OBS for YouTube?
Use two seconds in the streaming encoder that sends the feed to YouTube. YouTube recommends that interval and says not to exceed four seconds. If the setting uses frames, convert based on the output frame rate; at 30 fps, two seconds is 60 frames.
Where is the keyframe setting in OBS?
It is in the output settings for the active streaming encoder, but the exact control and menu path vary by OBS version, output mode and encoder. Make sure you are looking at streaming output rather than recording output, and check the field’s units before entering a value.
Why does the warning remain after I set two seconds?
OBS may not be the final sender: a relay or external encoder can alter or re-encode the feed. YouTube also notes that ingestion errors can cause incorrect GOP sizes, so verify the downstream path and review all stream-health messages rather than assuming the interval is the only issue.
Does a two-second interval fix every YouTube stream-health warning?
No. It addresses the recommended keyframe cadence, not connection faults, bitrate suitability, relay behaviour or every other ingestion problem. Test the complete stream path in Live Control Room and monitor health during the broadcast.