A mixed-frame-rate playlist is not, by itself, a proven cause of YouTube RTMP stream health warnings. Start with the exact warning in Live Control Room, then check what your encoder is sending, whether frames are being dropped on the network, and whether the computer is keeping up.
YouTube’s published guidance concerns the incoming stream’s codec, output frame rate, bitrate and keyframe interval. OBS documents separate network and computer-performance problems. The sources do not establish that clips with different source frame rates inherently cause warnings, so treat that connection as a hypothesis to test rather than a platform rule.
Read the exact YouTube Stream status warning
Open YouTube Studio’s Live Control Room and note the complete warning text and the time it appeared. A screenshot or a short written log is useful if you are changing settings later: “stream health was bad” is much less useful than a message about keyframe frequency at a known time. YouTube says errors are shown beside the Health Indicator, with red indicating critical errors and yellow indicating moderate ones. Read the Live Control Room guidance and stream health messages rather than trying to diagnose from colour alone.
The wording points to a stage of the path. Messages about an unsupported format or codec, an excessive frame rate, resolution mismatch, or incorrect video keyframe frequency concern the incoming stream YouTube receives. A local OBS warning about dropped frames or rendering lag is a different observation. Viewer buffering is different again: it may reflect playback conditions and is not, on its own, evidence that the source clips have incompatible frame rates.
YouTube’s error guidance notes that frame rate and keyframe frequency are linked. For example, its documentation says that a 30 fps stream should send a keyframe every 60 frames for a two-second interval. The actual warning and your output settings matter; do not infer a keyframe problem merely because the playlist includes a 30 fps clip and a 25 fps clip.
Keep a small event log during troubleshooting: time, YouTube message, encoder statistic, and any change made. If a warning begins at 02:10 and OBS reports a network drop at the same time, that coincidence is worth investigating. It does not prove the root cause, but it is stronger evidence than guessing from the source file’s properties. If the warning persists after the triggering event, record that too.
Check the incoming codec, frame rate, bitrate and keyframe interval
The encoder’s outgoing configuration is the first technical check when YouTube reports an ingest-setting problem. YouTube’s recommended encoder settings for live streaming list H.264, H.265/HEVC and AV1 for RTMP/RTMPS, a frame rate up to 60 fps, constant bitrate (CBR), and a recommended keyframe interval of two seconds, not exceeding four seconds. Use the current official page for the full requirements and settings; do not rely on an old preset copied from a forum.
Write down the actual output codec, output frame rate, bitrate mode, target bitrate, resolution and keyframe interval in your encoder or streaming application. A source clip’s reported frame rate is not necessarily the same thing as the outgoing stream’s configured frame rate. The troubleshooting question is what the encoder sends at the RTMP output, not simply what a file inspector reports for one item in the playlist.
Bitrate is not a single universal target. YouTube’s recommendations vary with codec, resolution and frame rate. As examples, YouTube lists H.264 1080p at 30 fps with a 5 Mbps minimum and 14 Mbps recommended, and H.264 1080p at 60 fps with a 6 Mbps minimum and 17 Mbps recommended. These are YouTube’s recommendations, not a guarantee that a particular connection can sustain the chosen rate or that viewers will never buffer. Check the matching row in YouTube’s current table rather than carrying those examples over to another resolution, codec or frame rate.
If you use a custom stream key or manually configured encoder, compare each outgoing value with the current YouTube guidance. Where you have no reason to set manual values, YouTube recommends allowing Live Control Room to detect resolution and frame rate automatically. Do not change codec, frame rate, bitrate and keyframe interval all at once: if health changes, you will not know which change mattered. Correct a concrete mismatch first, then observe the stream.
Keyframe interval deserves a specific check when the warning mentions “incorrect video keyframe frequency”. YouTube recommends two seconds and sets a four-second maximum in its RTMP/RTMPS guidance. Its error documentation also says ingestion errors can affect GOP size and that a closed GOP is needed for optimal transcoding. Use the encoder’s own output settings or logs to verify the interval; do not assume that a nominal setting proves the output is arriving as intended.
Look for network-related dropped frames
If OBS reports network-dropped frames, investigate the connection and the configured bitrate before investigating source frame rates. OBS explains that network drops can mean the connection is unstable or cannot keep up with the bitrate. Its dropped frames troubleshooting guide recommends a wired connection for streaming and lists possible hardware issues such as faulty cables, routers or network cards. A Wi-Fi connection that works for browsing may still be inconsistent under a sustained upload.
Check the encoder statistics while the warning is happening, not only afterwards. Note whether the network-dropped-frame count rises, whether the connection recovers, and whether the warning occurs at the same time. If your streaming software lets you view connection or bitrate history, save that information. You are looking for a pattern across the event, not merely a non-zero number from an earlier test.
A configured bitrate must be sustainable on the actual upload path over time. If it is not, a lower bitrate may reduce network pressure, though the resulting image quality may also be lower. Compare the setting with the appropriate YouTube recommendation and with your observed connection, and make one controlled change at a time. A speed test taken once does not establish that the connection will remain stable through an overnight stream.
For a local setup, test a wired connection if practical, then check cables and network equipment if drops continue. Avoid making a chain of unrelated changes—router, encoder preset and playlist edits together—because a temporary improvement will be hard to explain and harder to reproduce. If your channel relies on an unattended loop, a plan for monitoring a 24/7 YouTube stream when you are away from your computer is part of diagnosis: you need a way to know when a warning began and whether the connection recovered.
Network drops and YouTube ingest warnings can occur together, but one does not automatically explain every other message. A network problem may interrupt delivery; a codec or keyframe warning points to the stream format. Match the encoder’s statistics to the exact YouTube warning before deciding what to change.
Check rendering and encoding load
A computer may be unable to render scenes or encode output smoothly even when its internet connection is stable. OBS’s performance troubleshooting guide identifies GPU workload, frame rate, output resolution, scene complexity, sources and filters as factors that can affect rendering or encoding performance. Look for rendering-lag or encoding-overload indicators in OBS, and note whether they rise during the same period as the YouTube warning.
For a scene-based setup, inspect what is active in the scene: browser sources, animated overlays, filters, captures and other media can all contribute to workload. A scene that looks simple to you may still ask the computer to decode and composite several sources continuously. The guide to managing multiple scenes in OBS for YouTube streaming can help you identify whether the active scene structure is adding work you do not need for a long-running loop.
Use the OBS statistics window and logs as evidence. Rendering lag points towards the work of composing frames; encoding overload points towards preparing output frames for transmission. They are not interchangeable with network-dropped frames. If one counter climbs while the others remain stable, that distinction gives you a better starting point than changing the playlist blindly.
When performance is the issue, reduce workload in a controlled way. OBS advises that lowering output frame rate or resolution can help, at the cost of motion smoothness or picture detail. You can also test a simpler scene or remove a demanding filter, then compare the relevant counters. Keep the outgoing settings suitable for the channel and YouTube guidance; the goal is not to make a warning disappear by sacrificing quality without understanding why it appeared.
If the channel runs on a personal computer, check what else is using the machine during the test. A scheduled backup, browser workload or another video application may coincide with a slowdown. Record what was running rather than assuming the playlist is responsible. A test run should use the same machine and scene you intend to leave on overnight, because a short lightweight preview may not reflect sustained load.
Test the playlist while monitoring output
Once you have captured the warning and checked the obvious output, network and performance paths, test the playlist in a repeatable way. YouTube recommends testing before going live with audio and movement similar to what the real stream will contain. A controlled comparison is a practical extension of that advice, not a special procedure published by YouTube.
Keep the test representative: use the same playlist order, audio, scene, output settings and relevant duration as the normal broadcast. Monitor both YouTube’s Live Control Room and your encoder statistics. Record the start and end time, warning text, network drops, rendering lag and encoding overload. If possible, let the sequence run long enough to include the portion where the warning usually appears; a brief opening sample may miss a later transition or workload change.
Then change one variable that is relevant to the evidence. If YouTube identifies keyframe frequency, correct that output setting and repeat the test. If OBS reports network drops, test the connection or a sustainable bitrate. If it reports encoding strain, simplify the scene or reduce output load. Do not simultaneously make a normalized export, change resolution, replace the router and adjust the keyframe interval. That would leave you with no clear result.
A useful comparison might be the same loop with the same output settings, first as-is and then with a consistently framed export, while watching the same counters. If the warning changes, note what else changed and repeat before drawing a conclusion. If it does not change, that is also useful evidence. Keep the original files and settings so you can return to a known baseline.
For a playlist whose main challenge is what happens at file boundaries, check that the sequence itself behaves as intended: audio continues, the next clip starts, and no unintended gap or end card appears. That is separate from ingest health, but it helps rule out a content transition being mistaken for a dropped stream. For example, the practical checks in keeping a children’s storytelling livestream running when a video ends concern continuity at the end of a video, not a proven frame-rate cause.
If you are not beside the encoder for the whole test, arrange a way to capture the warning and local statistics remotely. A screenshot of the Live Control Room alone may not show what the encoder was doing at that moment; the timestamp is what lets you compare the two records afterwards.
Treat source frame-rate effects as a hypothesis
A playlist can contain clips created at different source frame rates, but the official YouTube and OBS material covered here does not say that such a mix inherently causes a YouTube RTMP health warning. It does not specify a required source-file frame rate for looped playlists, and it does not document how a particular encoder handles every clip transition. Do not present a theory about normalization, conversion or looping as established behaviour without documentation for the software you are using.
There is still a reasonable question to test. Perhaps one file, transition or combination of media coincides with a warning or with a rise in local workload. The evidence could be a repeated warning at the same point in the playlist, a matching change in encoder statistics, or a controlled test where one file is substituted and the remaining conditions stay the same. Those observations make a useful lead; they do not establish a general YouTube rule.
First address a concrete output mismatch if the warning names codec, frame rate, resolution or keyframe frequency. If OBS reports network drops, focus on the connection and bitrate. If OBS reports rendering or encoding strain, focus on computer load. Only after those paths are understood should you compare the original playlist against a consistently framed export, changing no other relevant input. Label that comparison as a diagnostic test, not proof that YouTube rejects mixed-frame-rate clips.
If a particular file appears implicated, repeat the test and preserve the warning timestamp and encoder log. Check the documentation for the player or encoder in use if you need to know what it does with source files. A single apparent correlation may reflect another change at that time, such as a network interruption or a demanding scene, so avoid converting one night’s observation into a platform-wide claim.
For unattended channels, the operational problem is often not only finding the cause but noticing that the broadcast needs attention. StreamNeo removes the need to keep your own computer running for a file-based loop, which addresses that specific burden; it does not change YouTube’s ingest requirements or make health warnings impossible. Keep the same habit of checking the exact warning and the outgoing stream, whatever method you use to run the channel.
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
Do mixed-frame-rate videos cause YouTube stream health warnings?
The reviewed YouTube and OBS documentation does not establish mixed source frame rates as an inherent cause. Check the outgoing stream settings and encoder statistics first, then test the playlist under controlled conditions if a particular file seems relevant.
What should I check first when YouTube reports incorrect video keyframe frequency?
Record the exact message and timestamp, then verify the encoder’s output keyframe interval and frame rate. YouTube recommends a two-second interval, with a four-second maximum for RTMP/RTMPS; check its current official guidance and confirm the actual output rather than relying only on a preset label.
Are network-dropped frames the same as encoding overload?
No. OBS describes network drops as a connection that is unstable or unable to sustain the configured bitrate, while rendering and encoding strain concern the computer’s work. Compare the separate statistics at the warning time before changing settings.
Should I convert every clip to one frame rate?
Not as a platform requirement based on the sources covered here. A consistently framed export can be one controlled diagnostic comparison if other likely causes have been checked, but change one variable at a time and treat the result as evidence about your setup, not a universal rule.