A “Bad video settings” warning does not, by itself, mean YouTube rejects H.265. YouTube lists H.265 (HEVC) as a supported video codec for RTMP and RTMPS, but the warning can refer to other parts of the encoded stream, including its resolution, container, GOP structure or number of video tracks.
Start with the complete health message, then compare the encoder’s actual output width and height with the resolution selected in Live Control Room’s Ingestion Settings. YouTube detects resolution and frame rate automatically by default; if you have chosen a manual resolution using a custom stream key, check that setting against the output you are sending.
Read the resolution-related warning, not just its summary
Live Control Room can show a short health label such as “Bad video settings”. That is a summary, not a diagnosis. Look for the expanded message or issue type attached to it before changing the encoder. The YouTube Live API health reference describes configuration issue types that can underlie video-setting alerts, including resolution, bitrate, codec, container, GOP and primary/backup mismatches.
If you have API access, the stream’s health status exposes configuration issues with a type, description and severity. You do not need API access to troubleshoot, but the same principle applies in Control Room: record the precise wording and any detail shown alongside the summary. If it identifies a resolution mismatch, investigate dimensions first. If it names an open GOP, codec, container or another condition, address that condition instead.
H.265 being supported does not guarantee that every encoder configuration using it is valid. The selected preset name may not describe the emitted stream accurately, and a warning may be triggered by a separate setting. YouTube’s encoder settings guidance lists H.265 alongside H.264 and AV1 for RTMP/RTMPS, so switching codecs before reading the detailed warning is not a sound first step.
Write down what you know before editing anything: the full health message, the encoder’s selected resolution and frame rate, the output container and codec, and whether you send a primary and backup stream. This short record helps you change one relevant setting at a time, rather than swapping codecs or lowering quality without knowing what the warning means.
Compare the actual encoded width and height
The resolution you select in an encoder interface is only a clue. To compare like with like, find the dimensions of the video that the encoder actually emits. A preset labelled “1080p” may be altered by a scaling option, source input, filter or separate output setting. Check the encoder’s output or status panel, and, where available, inspect a short recording or stream probe that reports the encoded video dimensions.
Think in terms of width × height. For example, a common landscape Full HD frame is 1920 × 1080, while a 1280 × 720 frame is lower resolution. A portrait stream reverses the shape: its width is smaller than its height. The label alone is not enough, especially if the source is portrait, cropped, or scaled. Note the exact two values and their orientation.
Next, find the resolution shown in Live Control Room’s Ingestion Settings for the stream. The key question is whether the dimensions you are actually sending match that selection. If Control Room is set to expect one format while the encoder emits another, the resolution warning has an actionable mismatch to investigate. Do not infer a mismatch simply because the stream looks soft in the preview; inspect the values.
If you cannot see output dimensions in the encoder interface, look for an output report, stream information panel or a way to inspect a brief local recording made with the same settings. Be careful that a local recording may use different settings from the live output. Verify that you are checking the live encoder profile, not a separate recording profile.
This check also helps distinguish resolution from other conditions. A video may have the expected dimensions and still produce a bad-settings warning because of its codec, container, GOP structure, bitrate or an additional video stream. YouTube’s health reference categorises these separately. Matching dimensions is useful evidence, not proof that every other setting is valid.
Match output dimensions to Ingestion Settings
Once you have the actual width and height, compare those figures directly with the selected resolution in Ingestion Settings. If the two do not match, determine which side should change: the encoder output or YouTube’s selected ingestion resolution. The right answer depends on the stream you intend to deliver, the source material and available upload capacity, not on the warning label alone.
For example, suppose the encoder is sending 1920 × 1080 but the manual Ingestion Settings selection is 1280 × 720. You have a clear mismatch to resolve. If the intended stream is Full HD and the upload can sustain it, adjust the selected resolution to match the encoder. If the source is 720p or your connection cannot reliably support Full HD, consider reducing the encoder output to 1280 × 720 and selecting that same resolution in Control Room.
The reverse can happen as well: the encoder may scale a higher-resolution source down to 720p while Control Room has a higher manual resolution selected. In that case, changing the source file will not necessarily help; check the output scaling and the manual selection. Use the dimensions of the video sent to YouTube, not the original file’s properties.
Avoid changing several settings together. If a resolution mismatch is confirmed, change the relevant output or selection, then check the dimensions again and watch the health message. If the detailed warning remains, investigate the issue it names. This approach makes it easier to tell whether the resolution change mattered and avoids attributing unrelated alerts to the change.
A practical live-streaming checklist for YouTube creators can help you keep the output profile, Control Room configuration and pre-stream checks in one place. For a looped prerecorded source, see how to use FFmpeg to loop meditation videos for YouTube Live; when using a command-line workflow, make sure the output dimensions you set there are the ones you compare with Ingestion Settings.
Consider bandwidth before lowering resolution
Lowering the selected resolution may be appropriate when your encoder sends a smaller frame, or when a lower-resolution output is a better fit for your connection and source. But do not lower it simply to make an alert disappear. The stream’s resolution, frame rate and bitrate are related, and a change can affect picture detail as well as network demand.
YouTube’s encoder guidance gives bitrate ranges according to codec, resolution and frame rate. Its current table includes separate recommendations for H.265 and H.264, so do not apply H.264 figures to an H.265 stream. For instance, YouTube lists different recommended bitrates for H.265 at 1080p and 4K, and the recommended value differs again between 30 and 60 frames per second. Check the current YouTube encoder settings and bitrate table for the format you plan to send rather than relying on a remembered number.
A lower resolution can reduce the amount of detail in the picture and may allow a more modest bitrate, but the actual requirement still depends on codec, frame rate and content. A static devotional image with gentle movement behaves differently from fast local news footage or a study stream with scrolling text. Do not assume that a bitrate which works for one source will suit another, and do not confuse a low bitrate warning with a resolution mismatch.
Assess upload capacity under the conditions in which the channel will run. YouTube recommends testing upload bitrate and testing the stream before going live. A speed test gives a useful indication, but it cannot guarantee that the connection will remain stable overnight. Leave room for normal variation rather than configuring the encoder at the very edge of the measured upload capacity. If a household connection is shared, account for other devices and uploads that may compete with the stream.
If you change resolution to reduce network demand, revisit the encoder bitrate and check the detailed health status again. Keep the frame rate and codec in view, too. The goal is a consistent profile that fits the source and connection; lowering one value does not automatically correct a separate GOP, container or codec problem. For a home connection under sustained load, our guide to fixing YouTube stream buffering during a JioFiber home-server upload covers a related network-side check.
Understand automatic resolution and frame-rate detection
YouTube’s default recommendation is to let Live Control Room detect resolution and frame rate automatically. This reduces the chance that a manually selected expectation differs from the stream actually arriving. Automatic detection is a starting point, not a promise that every encoder setting is correct or that a stream will run without interruption.
With automatic detection, the encoder sends its configured output and YouTube identifies the incoming resolution and frame rate. If the detected values are not what you intended, check the encoder’s actual output and scaling. Do not assume that automatic detection has changed the encoder’s output; it concerns how YouTube identifies the incoming stream.
This default is useful when you want to make the encoder profile authoritative and avoid maintaining a separate manual resolution choice. It is particularly worth considering after a source, scene or output profile change. If a warning appears, still read the full message and compare actual dimensions with the displayed ingestion settings. Automatic detection does not tell you whether the container, GOP or other aspects are valid.
There are trade-offs. A manual selection can make your target format explicit, which may suit a controlled setup where you have verified the exact output profile. But it adds another value to keep aligned if the encoder profile changes. Automatic detection removes that particular matching task; it does not remove the need to test and monitor stream health.
If your channel uses one stable output profile, set it deliberately and document its width, height, frame rate, codec and bitrate. That record makes it easier to recover after an encoder update or a power interruption. If you regularly switch between landscape and portrait, or between different resolutions, automatic detection may be simpler than repeatedly changing a manual expectation, provided the resulting format suits your broadcast.
When manual selection uses a custom stream key
You can use a manual resolution selection through a custom stream key. That setting is relevant when you need to specify an expected resolution rather than rely on automatic detection. Before choosing it, confirm that your encoder can consistently send the selected dimensions. A manual value that does not match the live output can create the very mismatch you are trying to remove.
Use manual selection only when you have a reason to control the expected format and can keep it aligned with the encoder. For example, an operator with a fixed 1280 × 720 output profile may choose to specify that resolution and then verify that the stream arrives at that size. If the encoder later changes to 1920 × 1080, update the relevant selection or return to automatic detection. Do not assume that changing the key alters the encoder’s output dimensions; it is the actual encoded stream that must be checked.
If you use a primary and backup stream, compare their settings as well. YouTube can report a mismatch between them, and matching the main encoder to Ingestion Settings may not address a discrepancy in the backup. Check codec, profile, resolution, frame rate, keyframe interval and audio configuration where applicable. If there is no backup stream, do not spend time changing backup settings that your setup does not use.
After any custom-key change, verify the stream in Control Room before relying on it for a scheduled broadcast. The selected setting is only one part of the path; the encoder still needs to emit a supported stream. Keep the key private and follow YouTube’s current instructions for managing it. Do not paste a live key into a public support post or share it in screenshots.
Test the change without destabilising the stream
Make the diagnosis outside the period when viewers depend on the channel, where possible. Record the present encoder profile and Control Room setting, then alter one relevant item. Start a test stream with representative content and audio, and observe both the incoming dimensions and the health messages. YouTube recommends testing and monitoring rather than relying on the encoder’s preset name alone.
Use content that resembles the actual broadcast. A static test card may confirm the basic connection but will not show whether movement, scrolling text or changing scenes behave well at the chosen bitrate. For a bhajan channel, include the usual artwork and audio. For a news loop, include moving footage and titles. Check the Control Room preview and status, while remembering that preview appearance is not a substitute for reading the diagnostic message.
If the warning clears, note the final settings and keep the test record. That outcome indicates that the change may have addressed the reported condition, but it is not a guarantee of uninterrupted streaming. A channel that runs overnight still depends on the encoder, connection, source and other configuration being stable over time. Continue to monitor the stream and have a recovery plan appropriate to your setup.
If the warning remains, return to its detailed wording. Check for an open GOP and keyframe interval; YouTube recommends a two-second keyframe interval and says not to exceed four seconds. Its guidance also flags open GOP as unsupported. Then verify that the encoded stream contains one video track, uses a supported codec and container combination, and has appropriate bitrate settings. Do not change all of these at once: follow the issue type and test each correction.
If the warning says badContainer, inspect the emitted container rather than relying on a file name or encoder preset. If it reports multipleVideoStreams, confirm how many video tracks are being sent. If it identifies videoCodec, verify the actual bitstream’s codec. A warning around resolution does not prove that these other conditions are absent, and a resolution change alone will not fix every warning.
For a 24/7 prerecorded channel, the encoder and test process are only part of the operating plan. If the particular pain is needing a computer to stay on and recover the broadcast after a drop, StreamNeo turns an uploaded video into a YouTube live stream that can continue with your computer switched off and restart automatically if it drops. It is YouTube-only, so it is not a solution for a channel that needs to publish to another platform.
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 “Bad video settings” mean YouTube does not support H.265?
No. YouTube lists H.265 (HEVC) as supported for RTMP and RTMPS ingestion. Read the complete issue detail because the summary can refer to other settings, and support for a codec does not validate every part of an encoder’s output.
What should I compare if Control Room reports a resolution problem?
Compare the encoder’s actual output width and height with the resolution selected in Ingestion Settings. Check that you are reading the live output profile, not a separate recording profile or the dimensions of the original source file. Then decide which setting should match the intended stream.
Should I choose automatic detection or set a manual resolution?
Automatic detection is YouTube’s default recommendation for resolution and frame rate. Use a manual selection through a custom stream key when you have a reason to specify the expected format and can keep it aligned with the encoder’s actual output.
Will changing resolution clear the warning and keep a 24/7 stream running?
Not necessarily. The warning may identify a container, codec, GOP, bitrate or multiple-video-stream issue instead, and a resolution change alone does not fix every condition. Test changes before relying on them, monitor the health messages, and do not treat a cleared warning as a guarantee of uninterrupted operation.