The bitrate ceiling of every quality rung dcast encodes at, what to send from your own encoder for talking heads, events and fast motion, and why lowering the resolution beats lowering the bitrate when your connection is the problem.
Join thousands of creators monetizing their content with DCAST.
Get Started FreeIf you only came for the number, it is in the table below, under "What to send us". Everything around it explains why that number stops helping past a certain point, and what to change instead when your upload cannot carry it.
When your stream reaches dcast, it is re-encoded into a ladder of quality rungs — 360p, 480p, 640p, 720p, 1080p, 1440p, 2160p — so that a viewer on a phone in a lift and a viewer on fibre both get something watchable. Each rung is encoded up to its own bitrate ceiling, and those ceilings are a platform setting rather than something you send.
Two things follow from that, and they are the two people most often have backwards.
The ceilings are ours, not yours. You cannot raise a rung by sending more, and you cannot lower one by sending less. What your ingest bitrate decides is how much real detail the ladder has to work from — a different question, and the one the next section answers.
The ceilings do not change with your subscription. A plan buys the height of the top rung, not the bitrate of any rung. A 720p rung is encoded the same way whether it is the top rung of a free account or the middle of a large one.
We retune those ceilings as the fleet and the encoders change, which is why this article deliberately does not print a table of them: a number published here would be stale long before it stopped being quoted. The shape is stable, the digits are not — and, as the rest of this article argues, the digits on our side are not the ones your picture actually depends on.
Your encoder sends one stream. We build the ladder from it. So the only decision you actually make is what that single ingest stream looks like, and the useful way to think about it is: send us enough that the top rung has real detail to work with, and no more.
| Your source | Sensible ingest bitrate | Why |
|---|---|---|
| Talking head, slides, interview at 1080p | 4 000 – 6 000 kbps | Little motion per frame; the encoder spends the budget on faces and text, and more data buys almost nothing |
| Mixed content, events, stage, panel at 1080p | 6 000 – 9 000 kbps | Cuts, moving lights and audience shots raise the cost of every frame |
| Fast motion — sport, gameplay, handheld — at 1080p | 9 000 – 12 000 kbps | Every frame differs from the last, so nothing can be reused and every frame costs close to full price |
| 720p, any content | 3 000 – 6 000 kbps | The 720p rung is comfortably fed well inside this range; past it you are spending upload for detail that rung cannot hold |
These ranges are a starting point, not a law. The one rule that always holds: whatever you send, your upload must be able to carry it continuously, not on a good minute.
Bitrate is a budget of data per second, not a quality slider. The encoder is given that budget and has to describe every frame within it. When the picture barely changes — a person talking against a static background — describing the next frame is cheap, and a larger budget simply goes unspent. When the picture changes everywhere at once — a camera pan across a crowd, a goal, confetti — the encoder cannot describe all of it and starts coarsening: it sends one averaged colour for a block of pixels instead of what is inside the block. That is what blockiness is. It is the visible edge of the budget.
This is why the same number produces different-looking results for two people. Your neighbour with the identical settings is streaming a static overlay and a webcam; you are streaming a moving stage. Same budget, very different bill.
It also explains the shape of the advice above. Raising the bitrate helps right up to the point where the budget stops being the constraint, and after that it costs you upload headroom and buys nothing. There is no setting that makes a static talking head look better than it already does at 6 000 kbps.
Each rung is encoded with a buffer as well as a ceiling — a window the encoder may overshoot into for a moment and then pay back. On our live ladder that window is currently twice the rung's ceiling. It is not slack; it is the thing that keeps the expensive moments intact.
Real video is not evenly expensive. A hard cut to a new scene costs far more than the second of static frame before it. If the encoder were held to its ceiling in every single instant, it would have to butcher exactly those moments — the cuts, the flashes, the fast pans — which are the moments a viewer is actually looking at. A buffer of two seconds' worth of data lets it spend above the ceiling for a moment and come back under, so the average holds while the peaks survive.
The same logic applies to your own upload, and this is where most broken streams actually break. If your measured upload is 10 Mbps and you set your encoder to 10 000 kbps, you have left nothing for the peaks — and nothing for the rest of the building using the same line. A stream configured at the exact ceiling of its connection is a stream that will drop frames on its first hard cut. Leave room. If your upload tests at 10 Mbps, sending 6 000 kbps is not timidity, it is the setting that survives the whole broadcast.
This is the single most useful reversal in the whole topic, and it is the opposite of what most people try first.
Suppose your upload can only carry 3 000 kbps reliably. You have two ways to fit inside it. You can send 1080p at 3 000 kbps, or you can send 720p at 3 000 kbps. Same data per second. But 1080p has more than twice as many pixels to describe per frame as 720p, so at the same budget each pixel gets less than half as much attention. The 1080p version is not a sharper picture with less bandwidth; it is a mushier picture at a bigger size. The 720p version, given the whole 3 000 kbps for far fewer pixels, looks clean.
So the order of operations when your connection is the problem is: drop the resolution first, and only then adjust the bitrate to fit comfortably inside what the line will carry on a bad minute rather than a good one.
On the live path the cadence of the ladder is a platform setting, not a per-account one, and at the time of writing every live broadcast is encoded at 30 fps whatever you send us. Your subscription does not participate in that decision at all — a free account and a top account get the same cadence from the same source.
That is useful to know before you configure anything, because it points your upload budget in a definite direction: there is nothing to gain on the live path from pushing your encoder to 60 fps. The extra frames are not carried through, and at a fixed ingest bitrate they cost you detail in the frames that are. If your content is fast motion, spend the budget on bitrate rather than on frame rate.
Uploaded video is a separate path with its own frame-rate rules, and none of this applies to it.
Worth stating plainly, because it is the part people most often assume wrongly. On the live path a plan determines the height of the top rung — the highest quality a viewer can select — and nothing else about the picture. Free accounts top out at 720p, and the paid tiers extend that ceiling up through 1080p, 1440p and 2160p.
What a plan does not change: the bitrate of any rung, the buffer, the frame rate, the keyframe structure, or the encoder settings. A 720p rung is encoded identically whether it is the top rung of a free account or the third rung of a large one. There is no reduced-quality version of the encoder.
One setting on your encoder does interact with ours: the keyframe interval. dcast cuts the live stream into segments of 4 seconds, and each segment contains 2 keyframes — one on the boundary and one in the middle — so the internal keyframe interval is 2 seconds, computed from the final frame rate rather than pinned to a frame count.
You do not need to match this. The encoder re-encodes what you send, so it builds its own grid. But if you set an unusual keyframe interval on your side in the belief that it will reduce latency downstream, it will not, and a very long interval on the ingest side makes the first moments after a reconnection worse. A 2-second keyframe interval on your encoder is a safe, boring choice.
Blockiness that appears only during motion and vanishes on static shots is a bitrate problem: the budget ran out where the content got expensive. Raise the ingest bitrate one step, or lower the resolution one step.
Blockiness that arrives in waves regardless of what is on screen, often with audio artefacts and a rising dropped-frame counter in your encoder, is not a bitrate problem — it is your connection failing to deliver what you promised it. Lower the bitrate until the dropped-frame counter stays at zero for a full ten minutes.
A picture that is soft everywhere, all the time, including on static shots, is usually a source problem rather than an encoding one: a camera shooting at a lower resolution than you think, a capture device negotiating a lower mode, or a scene scaled up somewhere in your chain. No bitrate fixes an upscale — enlarging a picture adds data, not detail.
And if viewers report problems that you cannot see locally, remember that you are watching your own preview, not your own stream. The preview never left the building.
For fast motion, sit near the ceiling: 9 000 to 12 000 kbps. For conversational content 4 000 to 6 000 kbps is enough even at 1080p. The 1080p rung is encoded with a 12 000 kbps ceiling, so sending more than that gives the encoder nothing extra to work with.
No. On the live path a plan sets the height of the top rung — 720p on free, then 1080p, 1440p and 2160p on the paid tiers. The bitrate ceilings, the buffer, the frame rate and the encoder settings are identical on every plan.
Because bitrate is a budget per second. When most of the frame changes, the encoder cannot describe all of it inside the budget and coarsens the detail, sending averaged blocks instead. A static frame changes little, so the same budget is more than enough.
Resolution first. At a fixed bitrate, 1080p spreads the same data across more than twice as many pixels as 720p, so it looks worse, not better. Drop to 720p and give the whole budget to fewer pixels.
No. Rungs above the height of your source are not created — an enlarged copy carries no new detail, only more data. The top rung is the lower of your source height and your plan's ceiling.
Professional video streaming experts helping creators succeed.
