Colour Banding on Ambience Loops: Why Gradients Break First, and How to Actually Fix It

Banding is the visible staircase of flat colour bands where you expect a smooth gradient — the sky behind a sunset, the fade at the edge of a fireplace glow, mist thinning against a grey wall. It happens because video compression works by discarding information the eye is assumed not to need, and a clean gradient is one of the few places where that assumption breaks down: there is no texture to hide the join between one shade and the next, so the join becomes the most visible thing in the frame.

On a cut-together video this is a minor flaw that scrolls past in a few seconds. On a 24/7 ambience loop it behaves differently: the same gradient sits in the same part of the frame every time the loop repeats, for hours on end, so a viewer who leaves your channel running in the background sees the same band again and again rather than once.

Why smooth gradients are the hardest thing to stream

Most video is still delivered at 8-bit colour depth, which gives each of the red, green and blue channels 256 possible levels. That sounds like plenty until you spread it across a wide, slow gradient — a dusk sky running from pale orange to near-black across half the frame, say. Two hundred and fifty-six steps divided over that much visual space is not always enough to stay imperceptible, and compression makes the problem worse before a single viewer sees the stream: encoders are built to spend bits where the eye will notice and save them where it will not, and a flat, low-detail gradient looks, to an encoder, exactly like the kind of area it can round off cheaply.

Footage with texture does not have this problem, or not as badly. Grass, water, a crowd, moving hands, even ordinary film grain in the source all carry enough fine, high-frequency detail that a small quantisation error gets masked by the texture around it. Ambience content is disproportionately the kind of footage that has none of that — slow skies, fire glow, fog, gradients built deliberately for a calm loop rather than shot in a busy scene. That is the specific reason this category of channel runs into banding that a gaming or vlogging channel mostly does not.

Where the banding actually comes from

Before fixing anything, it helps to know which of three places is actually responsible, because the fix is different at each one.

The first is the source file itself. If the video was rendered or graded at 8-bit, or has already been compressed once at a middling bitrate — exported from an editor at a default setting, or downloaded from a stock or asset site as an already-lossy file — the banding can be sitting in the pixels before you have touched a single streaming setting. No amount of upload bitrate fixes damage that is already baked into the source.

The second is your own export or encode before the file reaches YouTube: the settings in your editor, in OBS, or in ffmpeg if you are building the file by hand.

The third is YouTube's own side. Every upload is re-encoded into a ladder of resolutions and bitrates so it can be served to different devices and connections, and that re-encode applies its own bitrate ceiling at each rung independently of how clean your original upload was. A source file that looks perfect on your desktop at full bitrate can still show new banding on the lower rung YouTube serves to a viewer on mobile data. It is worth separating this from a different family of problems, too: banding is a picture-quality fault, not a connection fault, so if what you are actually seeing is stalling and rebuffering rather than visible stripes, that is a different diagnosis with a different fix.

Ambience content is exposed to all three of these more than most genres, because it leans so heavily on exactly the footage that bands worst — the slow skies, fire and mist covered in scaling a rain video into a full 24/7 channel.

Banding: the cause, and the two real fixes

The underlying cause is always the same: a continuous gradient gets quantised into a finite number of discrete steps, and with nothing in the frame to mask the join, the eye locks onto the boundary between one step and the next. There are two genuine fixes, and they work on different halves of the problem.

The first is to stop the boundary being perfectly flat in the first place — add a small, deliberate amount of noise or dither to the gradient before it is ever compressed, so what would have been a hard edge becomes a randomised transition the eye reads as smooth. This is the fix with the most control and the fewest downsides, covered in the next section.

The second is to give the compressor enough bitrate, relative to the resolution you are delivering, that it does not need to collapse the gradient into fewer steps to hit its target file size. This genuinely helps and is worth doing properly (see the bitrate section below), but it is not a guarantee on its own. No specific bitrate number can promise banding-free video, because YouTube's own transcode still applies its own ceiling at each resolution rung regardless of your source bitrate, and a completely undithered flat gradient can still show visible steps even at a generous bitrate if there is nothing else in the frame to break up the join. Treat bitrate as reducing the risk, not eliminating it.

One detail that is easy to miss: if your loop carries on-screen elements such as a clock, a "now playing" bar or a LIVE badge, check what sits behind them. A semi-transparent panel placed over a gradient-heavy area can usefully break up a band, or, if the panel has a soft gradient or blur of its own, add a second layer of banding on top of the first. It is worth checking overlay placement against the worst part of your gradient specifically — the approach in baking overlays into a 24/7 loop covers how to place them without fighting the footage underneath.

Dithering and grain as a deliberate tool

Dithering means adding a small amount of noise to a gradient on purpose, so neighbouring colour bands break up into randomised texture rather than sitting as flat steps. It sounds counter-intuitive — adding noise to improve picture quality — but it is a long-standing technique in broadcast and print for exactly this problem, and it works because the eye is far better at ignoring fine random grain than it is at ignoring a straight, regular edge.

There are two practical ways to apply it to an ambience loop. If you are generating the footage yourself, from a render engine, a motion graphics tool or a generative pipeline, check for a dither or noise option at export — many render pipelines apply one by default, but it is worth confirming rather than assuming, since not all of them do at their default quality preset. If you are working from footage shot or sourced elsewhere, you can apply a subtle grain or noise filter across the whole frame in your editor before the final export.

The word that matters here is subtle. You want enough grain to interrupt the band, not enough to be visible as texture in its own right, so check it zoomed in to 100% on the worst part of the gradient rather than on a shrunk-down preview where noise is harder to see. There is also a real trade-off to respect: noise increases the entropy the encoder has to represent, which means a grainy source needs a slightly larger bitrate budget to encode cleanly than a flat one does. If you are already tight on bitrate, heavy grain can end up causing blockiness elsewhere in the frame instead of fixing the gradient, so this is a technique to apply carefully rather than generously.

Bitrate vs resolution for gradient-heavy footage

Compression is a fixed budget of bits spread across however many pixels you are asking it to describe. At a given bitrate, fewer pixels means more bits available per pixel, which means finer gradations survive; more pixels — 4K over 1080p, say — spreads the same budget thinner, which is exactly the condition banding thrives in.

For most content, the extra resolution is worth that trade because it buys sharper detail. For gradient-heavy ambience footage there is comparatively little fine detail to gain from the extra pixels in the first place — a slow sunset or a soft fire glow does not have much texture that 4K reveals and 1080p hides — so if your encode is showing banding, dropping from 4K to a 1080p delivery at a comfortably high bitrate is often a better trade for this specific genre than the reverse.

YouTube publishes its own recommended bitrate ranges by resolution and frame rate for live encoders, and gradient-heavy footage is a good candidate for sitting at the upper end of the range for whichever resolution you choose, rather than the lower end. As listed on YouTube's live encoder settings help page in September 2026:

Resolution	Frame rate	Recommended video bitrate
2160p (4K)	30 fps	13,000–34,000 Kbps
2160p (4K)	60 fps	20,000–51,000 Kbps
1440p	30 fps	6,000–13,000 Kbps
1080p	30 fps	3,000–6,000 Kbps
1080p	60 fps	4,500–9,000 Kbps
720p	30 fps	1,500–4,000 Kbps

Check the current page before you commit to a number, since vendor tables like this do get revised. None of these figures is a promise against banding on their own — they describe the range within which YouTube expects the encode to hold together, and a well-dithered source will still outperform an undithered one at the same bitrate.

The other side of this trade is cost. Running a higher bitrate and resolution around the clock costs more in upload bandwidth and, if you are encoding locally, more in sustained CPU load — the kind of ongoing cost broken down in what 24/7 streaming actually costs. It is worth weighing that against how much the extra resolution is actually buying you on footage that is mostly soft gradients to begin with.

Export and encoder settings that help before you even hit stream

A few settings outside the dither-versus-bitrate trade-off are worth getting right before you upload anything.

Avoid re-compressing the same file more than once. Every additional lossy export — re-encoding an already-compressed file to change its container, trim it, or add a watermark — throws away a little more of the gradient information you started with, and banding compounds with each pass. Do any edits on the highest-quality version of the file you have, and export once.

If your editor or render tool supports a 10-bit intermediate during grading, use it while you are actually colour-grading the footage, even if the final delivery format ends up 8-bit. That gives you more steps to work with at the point where banding is easiest to introduce by accident, and it stops the grading pass itself from adding banding on top of what the source already has.

Chroma subsampling is worth knowing about even if you never change it. Standard consumer encodes, including YouTube's recommended upload settings, use 4:2:0, which keeps full detail in brightness but shares colour detail across blocks of pixels. That costs you more in colour-heavy gradients — the oranges and pinks of a sunset — than in gradients that are mostly a change in brightness, such as fog or a monochrome fire glow. It is not something most people should override, but it explains why two ambience loops with similar bitrates can band differently depending on whether their gradient is mostly colour or mostly brightness.

Finally, if you are encoding with x264 or a similar software encoder, a slower preset gives the encoder more time to decide where to spend bits, which generally helps gradients at the same target bitrate. That is a genuine trade against encode time and CPU load, which matters if a local machine is doing the encoding continuously — one reason some channels move that job off an always-on local box entirely, a comparison covered in running 24/7 on a VPS versus a managed service. Once you have done the work of exporting a properly dithered, correctly bitrated file, the last thing you want is a fragile local encode process undoing it every time it restarts. That is the specific gap StreamNeo is built for: you export the file once, upload it and paste in your stream key, and the broadcast runs from the cloud exactly as you exported it, rather than being re-touched by whatever is running on your own machine overnight.

Checking your own stream for banding on a phone and a TV

Always check the actual live stream, not just the local file. YouTube's re-encode is a separate step from your export, and it is the only version most of your audience ever sees.

Screen matters more than people expect. Phone screens are small enough that banding sometimes disappears simply because the band is only a few pixels wide, but many phones use OLED panels with strong per-pixel contrast that can make a gradient step more visible, not less, than it would be on an ordinary LCD. TVs are usually the least forgiving of the two: you are often close to the screen relative to its size, and a lot of TVs apply their own sharpening or contrast processing by default, which can add contouring on top of banding that was already borderline.

To check properly, watch your live channel, not a preview, on both a phone and a TV, in a dim room, specifically during the smoothest and darkest part of the loop — a dusk transition, the deepest part of a fire's glow, the thinnest edge of fog. Because YouTube serves different viewers different rungs of its bitrate ladder depending on their connection, it is worth checking on a slower mobile connection as well as your usual fast one, since that is closer to what a meaningful slice of your audience actually receives. Watch a full loop cycle rather than the first minute, since banding is often worse in one specific segment of the loop than the rest of it.

If you want to run this comparison without your changes being visible to the public while you iterate, testing as an unlisted or private broadcast first is the more controlled way to do it — the process is covered in testing a live stream without going public.

Once you have picked a resolution, bitrate and dither level that hold up on both a phone and a TV, the encode side of banding is done, and the only variable left is how reliably that exact file gets delivered night after night.

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 shooting or exporting in HDR fix banding?

Not automatically. HDR formats offer more available steps than standard 8-bit SDR, which can help, but only if your grading tool, export settings and the viewer's own screen all support and use HDR correctly — if any link in that chain falls back to SDR, you gain nothing from it. For most 24/7 ambience setups, getting dither and bitrate right on a standard SDR pipeline is a simpler and more reliable fix than adopting HDR for this one problem; if you do want to explore it, YouTube's HDR upload requirements are the place to check current support.

Is banding a YouTube-specific problem, or does every platform do this?

It is a general consequence of how video compression works, not something specific to YouTube. Any platform that re-encodes uploads and serves an adaptive bitrate ladder carries some banding risk on gradient-heavy footage; the exact bitrates and rungs differ by platform, but the underlying cause — quantisation with nothing to mask it — is the same everywhere.

Can I fix banding on a stream that's already live, without re-exporting the file?

Not if the banding is baked into the source file — only a fresh export with dithering applied fixes that. If the source is clean and the issue is purely an encode setting, such as a bitrate too low for the resolution, changing the encode and restarting the stream can help without touching the original footage, but you will still need to re-encode and restart rather than fix it in place.

Will adding grain or dither noticeably increase my file size?

A little, yes, because noise adds detail the encoder has to represent, and detail costs bits. Kept subtle — enough to break up a band, not enough to look like visible texture — the increase is usually small relative to your overall bitrate. It is worth comparing file size and doing a visual check before and after adding it, rather than assuming it is free.