Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
Recently, I sat down with Katerina “Kate” Dobnerova and Juraj Kacaba of CDN77 to discuss one of the largest recurring line items that every video publisher faces: CDN costs. By way of background, CDN77 is a video-focused global CDN that’s been in the market for 14 years, running a network with more than 300 Tbps of capacity and daily peaks around 85–90 Tbps, with roughly 90% of it video, both live and VOD. Their traffic is split across Europe, the US, APAC, and emerging markets, and they walk customers through exactly this kind of cost analysis all the time.
Without question, CDN delivery is critical infrastructure; get it wrong, and you don’t have customers. But it’s also expensive, and there’s real money to be saved without touching the quality of experience. This conversation looks at the problem from two directions: cutting the bits you create and deliver, and cutting the cost of the CDN itself. It’s lightly edited for length and clarity.
Here’s a link to the video, which I’ve embedded below.
Contents
Cutting the Bits
Jan Ozer: Let’s start our cost-cutting journey with encoding. Per-title encoding lets you cut the bits you store and deliver. How many of your customers are using per-title encoding, and how many are moving to CMAF packaging to reduce storage and delivery costs?
Juraj Kacaba: We see a decent number across the whole scale. We serve customers from what we call growth plans, which are the smaller customers, up through large enterprise solutions. Especially at the higher end, we see either per-title encoding or some form of smart bitrate optimization across the board. Most customers are doing at least some type of optimization.
Jan: Where’s AI showing up in that?
Juraj: It comes down to the specific customer, because every use case, implementation, and device mix is different. What we currently see is a prevalence of AI-driven tools for CRF or similar approaches that are built on open-source standards and then fitted tightly into the ecosystem the client already uses.
Jan: What about codecs? How much advanced-codec usage are you seeing? H.264 versus HEVC versus AV1?
Juraj: It’s heavily use-case specific. On mobile you want to stick to the format that’s most widely supported across devices, and you have mobile networks in play. On standard OTT platforms, we increasingly see AV1 and other cutting-edge codecs. If I had to put rough numbers on it, I’d still say about 80% is H.264, with the rest split among the newer formats. Clients implement the new codecs but keep H.264 to support all the older devices.
Jan: And CMAF?
Juraj: For all new standardized applications, CMAF is now quite prevalent. Having one data source for both HLS and DASH is clearly the way forward. In practice, it’s roughly half the traffic. Most major clients have their own pipelines; even for those using our encoders, we still see them keep DASH for legacy devices. And in heavily customized pipelines you’ll see even more obscure formats. But about half the traffic is CMAF today.
Making Caching More Efficient
Jan: Once you’ve done what you can on the encoding side, improving caching efficiency seems like the most effective way to cut delivery costs. If I’ve got the encode side covered, is caching where you’d start?
Kate Dobnerova: Let me give the bigger picture first, then narrow it down. More often than not, companies go straight for squeezing the per-gig rate, which can make sense. But it’s always worth running a full cost analysis of the entire workflow first, not just the CDN line item.
Start with origin and processing. What do you actually spend to prepare and serve the content before it even hits the CDN? Very often clients spend more on storing, processing, and getting data to the CDN than on the CDN traffic itself. Egress — the traffic between the origin and the CDN — is often the single biggest source of hidden costs. So the first question we ask is: how do we eliminate egress in the first place? Could some of these operations move to the edge?
Then there’s cache efficiency, which moves the needle most for VOD-heavy platforms. Every cache hit means content is served from cache; every cache miss means a trip back to origin, which — as I said — often costs more than the CDN traffic itself. In practice, getting your cache hit ratio from, say, 92% to 97% can save you more than anything you’d negotiate on the per-gig price. After that come device-specific manifests, capped CRF, and smarter ABR ladders. And only once you’ve worked through all of that do you get to the commercial levers: committed contracts, multi-CDN leverage, and renegotiation.
Jan: You mentioned 92% versus 97% for cache hit ratio. Is 97% achievable? Is that a common number?
Kate: It’s always client- and use-case specific — the target for live is different from VOD, because VOD comes with different challenges. With VOD, you have huge libraries, content growing exponentially, and content lifecycles that change dramatically, while the demand on the cache ratio stays high. So there’s no universal formula. But for VOD-heavy platforms, we’re usually aiming for something like 97–98%.
“Getting your cache hit ratio from, say, 92% up to 97% can save you more than anything you’d negotiate on the per-gig price.”
— Kate Dobnerova, CDN77
There are different strategies to get there. One is a multi-layer CDN architecture, or a hierarchical network of servers with more layers between the edge servers closest to end users and the origin. The most popular, “hot” content is cached closest to the end users, on edge servers in many locations. In CDN77’s case, that’s more than 200 locations.
If content isn’t cached at the edge, you fetch it from anywhere in the infrastructure rather than from origin: mid-tier layers in fewer, bigger locations, all the way down to an origin shield, which is typically a single location in front of the origin server. So if you publish a new series, instead of 200 edge locations each fetching from origin, you ideally fetch it once from the origin shield.
On top of that, there are cache-optimization strategies at the server level: admission and eviction algorithms, so only content likely to be requested repeatedly gets cached; consistent hashing, so only unique content is cached; and Bloom filters, which, in short, means the servers talk to each other and know what’s cached on each layer. There are dozens of these optimizations; those are just a few.
Choosing a CDN
Jan: Once a streamer has done everything they can on caching, they’re looking at either another CDN or getting the cost down on their current one. If I’m thinking about switching, what should I look for in pricing?
Kate: A few boxes to check. First, transparency and simplicity — I want to understand the big picture of what I’ll actually pay, not a thirteen-page pricing script. Some providers still charge for requests, which we don’t, and clients often only realize it at the very end because it wasn’t stated transparently.
Then: if I migrate, does it create cost elsewhere? What’s their caching strategy, and how cache-efficient can they be? Is my egress cost going to stay the same, go down, or go up? I’d also look hard at the provider’s financial stability. We’ve seen four CDNs exit the market, and prices going up. I want predictability. Migrating to another CDN is not a simple DNS change; it’s a major engineering effort, so I want to know the CDN will still be here in five years. And can they handle my use case entirely, or am I so locked in that I have to keep part of my services with another provider?
“I want to understand the big picture of what I’ll actually pay, not a thirteen-page pricing script.”
— Kate Dobnerova, CDN77
Jan: How do you even estimate cost without knowing the cache hit ratio, which varies by provider?
Kate: When a client comes to us, we start by looking at the cache hit ratio they’re getting with their existing provider — that tells us a lot. But the most important thing is testing. We always ask for a sample of traffic so we can see the traffic structure and exactly how cache-efficient we can be. We can’t hand someone a price tag until we understand the traffic structure and cache efficiency, so seeing a sample is absolutely crucial.
Jan: Do CDNs handle ABR with different levels of proficiency, or is it just bits you deliver?
Juraj: From a pure CDN standpoint, it makes no difference to us whether a chunk is high- or low-bitrate. But we build the whole stack with video in mind, and we approach VOD and live differently — even at the hardware level.
With VOD you usually have large archives and latency isn’t as critical, so you tend to have a large cache space. With live, we cache the chunks in RAM rather than on SSDs or hard drives, because live viewers are almost all watching the “live edge” — the same few chunks. You want to pull those into cache as fast as possible and push them straight out, with request coalescing and so on. So the nature of the CDN and the hardware stack differ by use case.
“Live viewers are almost all watching the live edge — the same few chunks. You want to pull those into cache as fast as possible and push them straight out.”
— Juraj Kacaba, CDN77
Jan: What about long-term storage? If I’m a VOD publisher with an asset that’s accessed infrequently, do I store it in a different tier — and does that extend time to first frame?
Juraj: On the origin side, in object-storage terms, there are many providers and offerings. Infrequent-access storage — what AWS and others call it — can save you quite a lot.
We run two storage tiers: a standard one optimized for video using HDDs, and a frequent-access, small-file-optimized tier built on SSDs. The right choice depends on the file formats, the structure, and the use case, because any limiting factor in the pipeline will eventually show up in your QoE and your cost. If your archive is large enough, it makes a real difference — with a few terabytes it doesn’t matter much, but with the very large archives that streaming platforms carry today, it’s definitely worth optimizing on the origin side.
Jan: What about the location of points of presence relative to your target audience — is that a QoE issue, a caching issue, or both?
Juraj: Actually, both. We used to see CDNs quoting crazy numbers—700-plus locations. But the number of POPs is a tug-of-war. You want to be in every corner of the world, as close to end users as possible. But the more edge locations you have, the fewer requests hit each edge server, which means that server is more likely to have to fetch content from the origin shield or even origin.
So a huge number of POPs can actually hurt your cache hit ratio if your traffic isn’t extremely global and dense. We have a substantial number of locations, but for specific regions, we sometimes disable POPs because consolidating to one location can improve the hit rate for that country or state. It really comes down to the nature and structure of the traffic.
“A huge number of POPs can actually hurt your cache hit ratio.”
— Juraj Kacaba, CDN77
Multi-CDN
Kate: Let me bridge from there, because it connects to multi-CDN. When clients have multiple CDNs in their stack, they get coverage across all the interconnections and locations in that combined pool. With global traffic, you often find no single CDN has the ideal combination of price and performance everywhere, so multi-CDN lets you get the best of each vendor. We’ve had many clients come to us for delivery in hard-to-reach markets — Africa, the Middle East, Latin America — where we’ve deployed embedded caches directly inside ISP networks, which often lets us offer better business terms and excellent performance thanks to the local deployment.
Jan: One way to get a good price is to commit to volume. When does it make sense to go multi-CDN, given I’ll still have to hit thresholds to keep my price on the CDN I’m already with?
Kate: You’ve named one of the drawbacks: splitting your volume across CDNs reduces your volume-based discount leverage. But commercially, it also creates a very direct competitive situation, which is an advantage. Then there’s reliability — resilience and redundancy — which makes sense from a risk-management perspective. And coverage, as I mentioned.
For large-volume clients, multi-CDN comes naturally; the question isn’t whether to do it but how many vendors to have and how to manage the stack. That said, you’re multiplying your workflows — commercially, because you negotiate with each vendor, and technically, on implementation. It gets more complicated if you’re doing edge computing, where there’s a lack of standardization. Some clients get creative here: they deploy one primary CDN that serves as both the origin shield — which reduces egress — and the edge compute platform, while the remaining CDNs act purely as delivery proxies.
Jan: How do I actually control a multi-CDN setup? If I’m a small company with limited engineering, should I use a service, license software, or build it myself?
Kate: Both approaches work — third-party services that manage multi-CDN based on configurable rules, or in-house allocation setups. Some clients split traffic equally with a round-robin approach, every third, fourth, or fifth request to a given CDN.
But more often we see clients allocate based on a combination of performance and price, controlling volume shares and geographic distribution at the country or ISP level using actual QoE data. That’s typically a regular evaluation — monthly or quarterly. More recently, some clients move traffic close to real time: if you feed CMCD data, CDN real-time logs, and player data into your system, you get log-based visibility into what’s actually happening on the performance level, which lets you make quick decisions and manage QoE through near-real-time actions.
Jan: Every CDN reports differently. How hard is it to integrate and analyze those logs together?
Juraj: It comes down to the fact that no two providers standardize on anything — logging included. We have our own real-time logging, which we stream into whatever log-processing pipeline or object storage the client uses; they then match the log formats and move on. Or, in enterprise implementations, clients ask us to match their log format, and we’re happy to if it lets them focus on other parts of the integration.
The same goes across features — signed URLs, for instance, use a different format at every CDN. When several CDNs exited the market around the same time, we saw a wave of new clients whose platforms were already built around a specific URL format, and changing the whole URL structure is a serious task. So we actually implemented several competitors’ formats into our platform to ease the switch. It can be an endeavor, and this is where Kate’s and my teams try to take on as much of the customization as possible to keep the client’s work smooth.
Jan: You said multi-CDN is natural for most of your large customers. Redundancy, price, QoE — what’s the biggest motivation?
Kate: It’s a combination of all of them, plus the current market situation. Clients tell us it’s part of their risk-management strategy — with CDNs exiting the market and raising prices, they don’t want to rely on a single provider.
Jan: If I’m a small publisher on a single CDN and I come to you wanting to cut costs this way, is that a service you provide — the integration layer — or is that on me?
Juraj: We help with specific parts of the implementation. Where we can make an easy change on our end — say, a tweak in the Nginx configuration — we’re happy to, because a small change for us can save days or weeks of development on the client side. The overall integration platform is usually handled by the client, but wherever we see a chance to help, we do. A lot of that happens in shared Slack channels, where we stay on top of the process and help clients in real time as challenges come up.
Deciding to go multi-CDN is always a combination of factors. Price-wise, if your traffic allows it, having multiple CDNs is a good thing. But there’s also resilience — you get local network disruptions where some CDNs are affected, and others aren’t. When there isn’t a huge engineering effort behind it, it’s at least worth looking into: mixing and matching CDNs across regions based on what works best for your use case.
Kate: I’d just add that you really need to check your boxes and see what works for you. For a smaller publisher, it may not make sense because you lose the volume-based discount and end up with a higher per-gig price simply from spreading traffic across more CDNs. It’s very individual. We consult each client based on their traffic volume, geographic distribution, and usage patterns.
Jan: That’s all I have. You’ve both been great — I appreciate the time and a genuinely cohesive, valuable discussion.
Kate: Thanks, Jan. Great questions, and hopefully useful.
Juraj: Thanks a lot.
