Efficient Streaming: Advanced Video Compression Reduces Costs

By DeHub Team — 2022-04-05

In Q2 2022 we implemented advanced video compression that reduced bandwidth costs by around 60%.

This is the least interesting-sounding milestone in the archive and one of the most consequential.

The economics problem

Video platforms have an unusual cost structure: success is expensive. Every additional viewer of every additional stream costs real money in egress, and unlike storage or compute those costs do not flatten out with scale in any way that saves you.

We had just shipped a stream app with 4K support, which multiplies the problem. High resolution is exactly where bandwidth costs escalate fastest.

Meanwhile the model we were building towards gave creators the overwhelming majority of the revenue — which became 90% of ad revenue on tokenised uploads the following year. If you are keeping a small share of revenue and paying the full delivery cost, your margin is the delivery cost. Compression is not an optimisation in that model. It is the business.

What 60% actually bought

It changed which decisions were possible.

At the previous cost profile, offering 4K broadly would have meant either capping it, charging for it, or taking a smaller share from creators. All three were on the table. None of them happened, because the delivery got cheap enough that we did not have to choose.

That is the pattern with infrastructure work generally — it rarely produces a feature. It removes a constraint that was about to force a bad product decision, and the evidence it worked is a compromise nobody ever had to see.

The part users notice

Nothing, ideally. Compression work that users can perceive has failed.

The honest tension is that every codec decision trades bitrate against quality, and the temptation when you are cost-constrained is to take the saving and let the picture soften. We had just told creators their 4K would be delivered properly. Softening it to save money would have been a straightforward breach of that.

So the constraint was one-directional: reduce cost without a visible change at the same source quality. That is a considerably harder brief than "reduce cost", and it is why this took a quarter rather than a sprint.

Where it led

The same pressure produced the custom CDN with sub-200ms global latency and the Livepeer integration for 50,000+ concurrent viewers in early 2025. Each is the same question at a larger scale: how do you serve more video, to more people, further away, without the cost curve deciding your product for you.

Three years on, DeHub still runs streaming at a cost profile that lets creators keep the large majority of what they earn. That is not a coincidence, and it starts here.

Why this kind of work gets deprioritised

Because it competes for time against features, and features are visible.

A quarter spent on compression produces nothing anyone can point at in a release note. A quarter spent on a new surface produces something to announce, something to screenshot, and a measurable spike in engagement. Every incentive inside a company favours the second.

The reason we did the first is that we had already committed to the revenue share, which converted an invisible engineering problem into an existential commercial one. The constraint forced the priority.

That is generally how infrastructure work gets funded honestly: not by arguing it is important, which everyone agrees with and nobody schedules, but by making a promise elsewhere that cannot be kept without it.