Years ago, a conference speaker pulled up a graph like this – video players all switching renditions at the same time for the wrong reason – and called the behavior “drunken teenagers”.

It stuck. I’ve been over-using it ever since – throwing it at every vaguely similar incident across platforms, to mostly confused looks. This is the explanation I never gave.

Your players are working exactly as configured

…and it’s usually the default config

As you grow, that may no longer be good enough. If it was ever good in the first place.

To name just a few ways it goes wrong:

• Error handling surfaces a generic message and stops – no retry, no fallback, no reload.
• Retry logic hammers the origin on a failed segment request instead of backing off.
• Players switch down on a single slow segment, not a trend – one bad measurement tanks the quality.
• The initial rendition is hardcoded, ignoring whatever bandwidth estimate the browser already has.
• Stall recovery drops to the lowest rendition and crawls back up too slowly.
• Time-to-first-frame inflated because the player preloads more than it needs.
• DVR window set too short – viewers who pause for two minutes come back to a dead stream.
• Heavy rendering or decoding blocks the video pipeline on low-end devices, causing stalls that look like network issues.
• Buffer sized for a lab connection. Stalls on the first 4G hiccup.
• Players preload the next segment in the background while the viewer is paused, burning data for no reason.

What the player actually does

The player buffers ahead. It picks a rendition. It decides what to do when things break. Three decisions, happening continuously, driven by config values you set once and forgot.

The buffer is how much video it preloads before it starts playing, and how much it tries to keep ahead. Too small and any jitter stalls the stream. Too large and you’ve added latency you didn’t need and memory pressure on cheap devices.

ABR picks the rendition. It estimates bandwidth from recent segment download times – a lagging indicator at best. On a degrading connection it’s optimistic too long. On a recovering one it’s cautious too long.

Stall recovery kicks in when the buffer runs dry. Drop to the lowest rendition and fill fast, or hold and wait. The wrong call compounds the problem.

Wrong in many different ways

The default buffer is a single number applied to every viewer regardless of where they are, what they’re watching, or what device they’re on.

On a variable cellular connection, it’s too small. One hiccup and it empties. The stall isn’t a network failure. It’s a sizing failure.

On a live stream, it’s too large. Every second of buffer is a second of latency. A buffer sized for VOD puts live viewers that many seconds behind. The stream is technically live. The experience isn’t.

On a low-end device, it’s expensive. Buffered video sits in memory. Size the buffer for a flagship and you create memory pressure on the mid-range Android most of your viewers are actually using. That pressure causes frame drops. Frame drops look like network problems. The player reacts accordingly.

A stall isn’t always a network problem. On a low-end device, it can be a decoding problem.

Hardware decoders have caps. A budget Android from two years ago might handle 720p without issue and fall apart at 1080p – not because the network can’t deliver the data, but because the chip can’t process it fast enough. The player doesn’t (always) know the difference. It sees dropped frames, reads it as a buffer problem, and switches the rendition down.

That sounds like correct behavior. It isn’t. The player switched down on false signal. When the buffer refills, it tries to climb back up. The device struggles again. You get an oscillation loop that has nothing to do with network conditions.

When defaults become contagious

A cohort of viewers starts the same stream at roughly the same time. A few things align. They’re on the same CDN point of presence. Their segments are the same size. Their ABR algorithms are running the same evaluation on the same schedule. Something goes wrong – a CDN hiccup, a keyframe boundary that triggers a quality re-evaluation, a momentary spike in origin response time. Every player in that cohort hits it at the same moment and makes the same decision.

Rendition switches in lockstep. Stalls at the same second. Recovery in waves, because they all dropped to the lowest rendition simultaneously and are climbing back at the same rate.

Rendition layers cycling in near-sync. Players all moving together for no obvious network reason. That’s what drunken teenagers looks like at scale.

Not meant to defame teenagers. Not meant to encourage underage drinking.

What you’re not measuring

Your server-side dashboard shows nothing. CDN healthy. Encoder fine. Origin responding.

The problem is a JavaScript runtime on ten thousand devices making the same bad decision simultaneously, and nothing on your server can see it.

Stall events don’t exist in infrastructure logs.

They exist in the player. If you’re not instrumenting it and shipping those events somewhere, you have no visibility into the part of the stack that actually touches your viewers.

Most teams add player analytics after something breaks badly enough to notice.

By then you’re debugging from memory and user complaints. The signal was there the whole time, unlogged.

Player SDKs vary. Most expose stall count, stall duration, current rendition. Some give buffer level on a timer. Fewer give ABR decision events. Start with what you have. Something beats nothing.

The fix

This is a config problem. You don’t need to rewrite the player, swap the SDK, or file a ticket with your vendor. You need to read the defaults and decide if they make sense for your actual viewers.

Start with buffer size.

Pick a number for live and a different number for VOD. They have opposite requirements. One config for both is already wrong.

Test stall recovery deliberately.

Throttle the connection mid-stream. Pull the network. See what happens. Most teams have never done this and have no idea what their player does when the buffer empties. The default behavior is rarely what you’d choose if you’d seen it.

Test on a real device.

Not your laptop. Not Chrome DevTools throttling. A mid-range Android on 3G or 4G. That’s the device your median viewer is on. If it stalls there, you have a problem. If you’ve never tested there, you don’t know.

The config that ships is the config that runs. At scale, on every device, for every viewer. Treat it accordingly.

Scale makes it worse

At low viewer counts, bad player behavior is noise. One viewer stalls, another doesn’t. It averages out and you never see it in aggregate.

As the audience grows, the randomness collapses. More viewers starting at the same time. More players sharing the same CDN point of presence. More ABR algorithms running the same evaluation on the same segment. Individual failures synchronize into a pattern.

The misconfiguration that was a support ticket at a thousand viewers is a platform event at a hundred thousand.

And you’ll probably blame the CDN.

“It worked every time we checked…”

You have a backup stream. You haven’t checked it in six months, the credentials are probably expired, and the person who set it up left the company. The one time live went down it wouldn’t have made a difference as the failure was elsewhere.

What took you down usually wasn’t the thing you prepared for. Most backup streams are designed for one scenario: the encoder dies, the switch flips, life goes on. That’s the clean failure. It’s also the rare one. What actually happens in production is messier, slower, and harder to call. The stream is alive but broken. The dashboard is green. The audience is already gone.

The mentality

…we probably don’t need it

The primary never failed. Not last week, not last month, not at the big event in March. The encoder is solid. The CDN is enterprise-grade. The team knows what they’re doing.

Hard to argue with. It’s not laziness. It’s a reasonable reading of a track record that hasn’t included a failure yet.

The economics

…it’s not worth the extra money/effort

The backup stream has a cost. Second encoder, second ingest, second CDN, second everything if you do it properly. That’s a real line item on a budget that already has competing priorities.

The outage has a cost too. But it’s theoretical. It might never happen. And if it does, maybe it’s a short one, maybe viewers come back, maybe the client doesn’t notice. 😈

This is the math that kills backup streams. Not negligence. A rational calculation made by people who have never experienced the failure they’re deciding not to protect against.

Single points of failure

…the backup failed too

The backup encoder is on the same switch as the primary? The same venue WiFi? Pushing to the same ingest endpoint, just different stream key? When the network goes down, both go down. When the ingest malfunctions, both fail. The backup existed. It was wired to the same failure.

A backup that fails the same way as the primary isn’t a backup. But…

1. True separation at every layer (encoder, network, ingest, origin, CDN) is complex to build and expensive to run. Most operations can’t justify it and don’t need it.
2. The gaps are rarely invisible. Most engineers can tell you where the stack is fragile. The backup just never got prioritized over everything else that needed building.

Operational readiness

…somebody knows how to switch, I think

The backup stream is configured. The runbook exists somewhere. The vendor console has a button for it. But the one person who knows how it works is not on call tonight. The doc is three product iterations old. Nobody has actually switched to the backup since the initial test months ago. The failure doesn’t wait for the right person to be available.

Automated failover is worse in a sneaky way. You stop thinking about it entirely. The script will handle it. Except the detection logic was written for a clean failure, not a half-dead stream that’s technically alive. The threshold never triggers. The switch never happens. And the humans who could override it manually are asleep, unreachable, or no longer with the company.

What does backup even mean

…we have redundancy

Backup encoder? Backup ingest? Backup origin? Backup CDN? Backup player URL? Each one protects against a different failure. Most teams pick one, check the box, and call it redundancy.

A backup encoder does nothing when the CDN degrades. A backup CDN does nothing when the origin serves a stale manifest. A backup ingest does nothing when the venue network goes down. The stack has layers and each layer can fail on its own.

Knowing which layer to back up requires knowing which layer is most likely to fail for your specific setup. That answer is different for a stadium broadcast, a remote satellite uplink, and a cloud-only pipeline. There is no universal answer. There is just the layer you skipped.

Select your redundancy plan

I’ve been wanting to lay this out as a diagram for a while. Clients always assume backup is a yes/no question. It’s not. Here are your options.

0. No real backup

Cheap until it is not. One failure anywhere takes the stream down. No recovery path, no fallback. A deliberate risk acceptance, not a resilience strategy.

1. Restart-and-recover

Someone notices, someone restarts. No parallel path, just a documented procedure and an operator who knows what to do. About five minutes of downtime if everything goes right. Longer if the right person is not reachable.

2. Fire-exit backup

A separate, deliberately degraded path. Different encoder, different network, different ingest endpoint. Not a mirror – lower quality, simpler setup – but genuinely independent. When the primary goes down, viewers stay on air within about a minute. This is the minimum viable backup for anything with a real audience.

3. Mirrored backup

A full-quality duplicate of the primary path. Separate encoder, separate ingest, separate origin. The CDN is typically still shared, which remains a single point. Recovery is faster and the experience is seamless, but the cost is substantially higher.

4. Full active-active

Both paths running simultaneously. Automated failover routes to the best available path. Viewers never see a switch because there is no switch – continuity is built into the architecture. The right choice when downtime is not an option and the budget reflects that.

Let’s gamify it 🙂

Of all, economics hurts the most, we know it.

This tool gives you a hint of what option you should deploy depending on what you’re doing and how much it costs to fail. Source is here.

“We saw a demo where it was instant.”

You get a brief. The client wants sub-second latency. No viewer complained, no metric moved, the stream is fine. But somehow your head of sales walked out of the vendor pitch having promised something he figured must be simple since their competitor already had it. Now it’s in the contract and it’s your problem.

The myths

“Low latency improves engagement.”

No published study survives scrutiny once you control for quality and reliability. Stall events hurt retention. Latency, by itself, doesn’t move the number.

“WebRTC is always better.”

Only at small scale. Past a few hundred concurrent viewers you need an SFU, then cascading SFUs, then simulcast because browsers don’t do real ABR for WebRTC. It stops being simple fast.

“The CDN is the bottleneck.”

The CDN is almost never the bottleneck. Most of your latency lives in the player buffer, which you control and the CDN doesn’t touch.

“1.2 seconds glass-to-glass.”

The number is real. It was measured in a lab, wired connection, their encoder feeding their player, no ABR ladder, no DVR, no captions, camera six inches from the screen. Add a 3-rendition ladder and a real player buffer and the same stack delivers 4 to 6 seconds in production. The marketing number and the operational number are not the same thing.

“The encoder is where the latency is.”

The encoder buffer sets you back 500ms to 2 seconds.

Network transit to the ingest point adds 100 to 500ms depending on geography.

Transcode adds 1 to 3 seconds.

HLS packaging adds 2 to 6.

CDN delivery is mostly negligible at steady state, 50 to 200ms.

The player buffer adds 2 to 30 seconds.

Optimizing the encoder while leaving the player buffer alone is solving the wrong end of the problem.

Who actually needs it

Live betting and in-play markets. Live auctions and bidding. Competitive esports where the prize pool justifies the engineering. Bilateral conversation: telehealth, synchronous tutoring, trading floor feeds where the other person is waiting on you.

That’s the list. If you’re in it, pay for it. The engineering is real and worth it.

Everything else is one-way passive consumption. The viewer watches. They don’t bid, they don’t respond, they don’t act. That’s most of the streaming market.

Latency is relative, not absolute

Ten seconds of delay is invisible if everyone in your audience is ten seconds behind. Nobody feels late. Nobody is ahead. The stream is the reference.

Broadcast TV has always run 5 to 10 seconds behind. Cable adds more. Satellite adds more still. Nobody complained for decades because there was no faster reference channel – the whole audience was behind together. Viewers feel latency when something faster exists alongside it. A Twitter feed spoiling the goal before it plays. A Discord chat reacting to a moment the video hasn’t shown yet. The neighbor’s TV cheering through the wall. The stadium roar arriving before the replay does on screen.

The problem isn’t the number. It’s the gap between your stream and the next fastest thing your viewer has access to. Close that gap and the latency disappears. Accept it and build around it.

One underused option: delay the chat to match the slowest viewer instead of lowering the video to match the chat. Twitch and YouTube both do this quietly. It costs nothing and solves the spoiler problem for most audiences without touching the streaming stack.

What you pay

Numbers below are for 1000 concurrent viewers, 720p, one hour, North America. Use them as a multiplier reference. They will change.

Setup	Cost/hour	What’s included
Self-managed HLS (Bunny CDN)	~$11	CDN delivery only, you handle encoding
LL-HLS managed (Mux)	~$50	Encoding and delivery
LL-HLS managed (Cloudflare Stream)	~$60	Encoding and delivery
LL-HLS managed (AWS IVS standard)	~$74	Encoding and delivery
WebRTC via SFU (AWS IVS Real-Time)	$72+	Scaling is handled, but cost per viewer stays high

The 5 to 6x gap between self-managed HLS and a managed LL-HLS platform is partly the low-latency premium and partly the managed service premium. Separating the two is hard because no major vendor sells unmanaged LL-HLS delivery at Bunny prices.

WebRTC looks comparable on paper. It isn’t in practice. Because scaling it is painful and not straightforward. Managed services like AWS IVS Real-Time handle that for you, which is what the price reflects.

The mobile brittleness

Tight player buffers are what get you to 1 to 2 seconds on a good connection. On 4G or 5G with variable RTT, the same buffer causes stalls. A viewer on WiFi gets a faster stream. A viewer on cellular gets a broken one. If your audience skews mobile, your audience-weighted experience can be worse on a low-latency deployment than on a standard 6 to 10 second buffer.

The metric you’re probably watching is P50 latency (the median viewer experience). That’s the wrong number. The viewer you lose is the P10 (the bottom 10% – weakest connections, worst conditions) who stalls every 30 seconds. A deployment that improves P50 from 6 seconds to 2 while making P10 rebuffer constantly is a worse product. Instrument your player for stall events and rebuffer ratio, not latency averages.

It gets worse

Building for low latency narrows the stack. Specific ingest formats, specific encoders, specific players, specific CDNs. Every subsequent decision has to respect the latency constraint, including ones that have nothing to do with latency.

DVR is the one that catches people off guard. Standard HLS gives you free DVR because the segments already exist on the CDN. WebRTC has no segments – you need a parallel recording pipeline. LL-HLS keeps segments but partial segments complicate cleanup. The free DVR most operators rely on goes away the moment you pick a low-latency stack.

Why it became a selling point

CDN bandwidth pricing has been collapsing since 2018 and keeps dropping every year. Delivery costs fell, differentiation blurred, “we stream video reliably” stopped being a sellable line.

Latency was a fancy new premium. Technically hard enough to justify the price, easy to demo with a stopwatch on stage; impossible to disprove on a slide because the numbers are real, they’re just measured in conditions that don’t exist in your production environment.

That’s why every CDN suddenly has an ultra-low-latency tier. The feature is real. The widespread demand it claims to address is mostly manufactured.

Should you bother?

Five questions. If you answer yes to most, you’re in the low-latency cohort.

1. Does your viewer act on what they see within seconds – bid, bet, respond?
2. Is there a faster channel they’re comparing against: a second screen, a chat, a neighbor?
3. Does your audience watch primarily on desktop or TV?
4. Would delaying the chat break the experience?
5. Are you willing to accept a narrower stack, higher ops cost, and no free DVR?

The $0 closer

Low latency is worth every penny when the use case demands it. The problem is that most of the industry decided the use case was universal. It isn’t.

There is zero activity in February and August

• 

You’re at that point where your single-server or clustered streaming setup just can’t keep up with the spikes and you know for a fact that you need a CDN, kudos for getting this far. Or maybe you’re already using one but wondering if perhaps you’ve missed out on a better deal from the other guys.

Navigating public price offerings can be challenging. Between the assortment of parameters (ingress, egress, requests, transfer), hidden fees, offers too good to be true, temptation to give into long term commitments etc, one may find it’s quite tough to make a decision. 

This piece will focus on comparing the true pay-as-you-go CDN vendors with public and transparent pricing models. By ‘true pay as you go’ I mean the flexibility to pay zero if you don’t use the service at all in a certain month. That’s important if you’re broadcasting occasionally (festivals, seasonal sporting events), or you just don’t know if your business will still be alive and kicking in a few months from now. 

And here it gets graphed, comparing the few mainstream providers. Just adjust the ckecks and sliders to match your use case and make your pick, today.

Lessons learned

Stick with the big names

Unless you know your game really well that is. Smaller players will do their best to lure you into admittedly appealing deals, yet most of these will be either 

(A) resellers – nothing wrong with that per se, except there may be a better offer from the very CDN they’re reselling; that’s not always the case, as they can negotiate better pricing than you ever could by leveraging big volumes and upfront commitments

(B) maintaining their own infrastructure – nothing wrong with that either, yet do expect inferior throughput due to the reduced footprint and peering capabilities; also they may run out of capacity when you need it most – at peak; sadly cards have been dealt in the industry more than a decade ago there’s no way to stand up to the giants unless you’re a giant yourself

(C) hybrid – relying on both own and 3rd party infrastructure and trying to make the best of each; that’s admirable, still… they need to walk a fine line prioritizing either quality or profit, as it’ll be very tempting to try max out the (usually) inferior inbuilt capacity before racking up the upstream bill

(D) tricksters – still sharing traits with one of the above categories, yet at the very dishonest end of the scale; expect generally poor quality for the buck, slowdowns, interruptions, being throttled in favor of other customers, untruthful traffic measurements

Not meaning to scare you off, and there are surely exceptions; you’ll be able to find gold if you take the time to dig, especially among the local providers.

Always have a backup 

There are many ways a network can fail, get saturated, or otherwise work against your best interest. Be prepared to switch or offload to some other vendor, may it be more expensive. There’s no good excuse for not being able to deliver the service you promised, and the chance to earn back the trust after a big fail may not come easy, if at all.  

Where you deliver matters

While North America and Europe are well covered, providing fast connectivity elsewhere is often not straightforward.  

Geographical regions discussed are those offered commonly by all suppliers. Yet some will cater distinctly to destinations like Africa, Middle East, India, Japan etc. You need to do a more in depth research if you focus anywhere there, look into local dealers too.

What goes into the graphs and what doesn’t?

1. The per-GB egress price – this makes the bulk of the pricing. Varies between $0.02 and $0.466, depending on region and consumption (i.e. the more you use the less you pay per unit)
2. The per-request price – varies between $0.6 and $2.2 per million HTTPS requests depending on region and offering. HTTP requests are cheaper with AWS but have not been considered here.
3. The per-GB ingress price (aka cache fill), where applicable – varies between $0.01 and $0.04 depending on ingress and egress location, only applied to google’s offering
4. The somewhat hidden $0.075 per hour for google’s ‘forwarding rule’ – a must-have paid-for link in their CDN chain.
5. The licensing price for a month in the case of Wowza

What about Akamai, CloudFlare, Comcast, Fastly, Level3, LimeLight etc

They don’t have public pricing, so we won’t discuss them here. Also some will require commitments and/or longer term contracts to have you as a customer. That does make sense for a company that offers this as its main service, as they need to rely on a somewhat predictable income to invest in capacity. 

Do realize that there’s reselling (explicit or not) even at the highest levels, Azure and Wowza among them. 

Can I use more than one?

Most certainly can, and you should if it’s feasible. Also know how much you’re paying each for exactly what, and over time use the information as leverage for a possible better deal. And stay on the lookout, the market continuously evolves and all this may be obsolete in a few months.

We really need to do something about this delay

• 

Since we last brought up the topic, the industry has evolved a bit. Most of the big live streaming and social media players now routinely stream at under 5 seconds end-to-end latency, and your modest platform may be laughed at or lose business if still relying on the good old HLS/DASH and its inbuilt huge delays. 

The technological background hasn’t changed much, yet the emergence of ‘cord cutting’ has emphasized on the annoyingly big delays and pushed OTT providers to adapt and innovate. Where it could, LL-DASH has been implemented with relative success, periscope’s LHLS has had (and still has) its own success stories, and eventually apple had to step into the game and put together its own LL-HLS, currently already a published standard and deployed in the latest iOS. 

As we speak, there are a few factors at play that may set back your roadmap to low latency

• Support for proprietary WebSocket based streaming is going away, most notable possibly being wowza’s announcement to discontinue its ‘ultra low latency’ thing; it makes sense in light of market-driven evolution of alternatives and fact that this was a stand-in solution from the get-go, with obvious drawbacks
• WebRTC is not yet a grownup; while having been standardized and taken a giant step since available in Safari, remarkable implements are taking a while
• Player and server support of LL-HLS is still limited to commercial products
• LL-DASH support is still not ubiquitous

The treat

To the rescue, a friendly wrapped POC solution based on the rather amazing open source OvenMediaEngine. It supports both WebRTC and LL-DASH egress from a RTMP source, amongst other cool stuff. 

The WebRTC output lets you stream with sub-second latencies (!), and the LL-DASH can be configured to use a playback buffer of 1 second or less.

It’s here, to use as such or inspire from, enjoy!

Does it scale?

LL-DASH – scale with ease

As long as you can deploy/make use of reverse proxies that support chunked-transfer, scaling is a breeze. Nginx can do it, as do most CDNs – go for it. 

WebRTC – not as easy but it can be made to

The larger shortcoming of WebRTC is that it’s been designed for peer-to-peer and one-to-one; twisting it to support one-to-many means impersonating multiple one-to-one endpoints, each mildly resource consuming, to the point where it’ll choke any one server. 

Capabilities will largely vary depending on actual hardware, and stream characteristics. Consider just 200 viewers per cpu core when budgeting, any betterment will make your customer happy. 

There’s also the hot topic of transcoding. While AVC is (at long last) ubiquitous in WebRTC, you’ll need to transcode the audio to Opus. That’s surely a breeze for any CPU but it won’t scale, so the number of streams you can run on a server is limited. 

Is it worth it?

If you absolutely need cheap/free low latency, it is. 

Biggest conundrum being that DASH won’t work on iOS and WebRTC is harder/more expensive to scale, may I suggest you use both (have iOS users play the WebRTC feed) and see where your scalability needs take you. Provided you’re running a small/medium platform or just starting up, the odds are you’re better off than giving into commercial offerings. 

What about LL-HLS?

In OvenMedia, it’s reportedly in the works and may be available soon. In general, it may still be a while before we see it thriving. Partly due to its initial intent to mandate HTTP/2, the industry has been slow to adopt it, and the couple implements I’ve seen still get laggy provided near-perfect networking and encoding setups. 

Adaptive bitrate anyone?

Not supported with this product but it may soon be. 

Let me point out though that the two (ABR and extremely low latency) don’t go particularly well together. Think that

• The need to transcode for ABR will add to the latency
• Determining network capabilities and switching between ABR renditions is way tougher to properly plan ahead and execute given sub-second delays and buffers

In the big picture, you’re trading every second of latency for quality of experience or cost. Please don’t make it a whim and seriously assess how bad and how low you absolutely need it. Delivering near-instant high quality uninterrupted video over the open internet requires sophisticated/expensive tech, and even the most state of the art won’t deliver flawlessly to all.

Millions, with an M

You’ve seen it around on big guys’ platforms. But when trying to put together your own you may have hit the price, maintenance, or scalability wall. 

• 

• 

• 

The following solution is no magic fix to these and surely not special, yet it may help you understand the pitfalls and tell apart the clues ahead of time.

How it works

• 

As simple as you’d imagine. Each viewer announces its presence to a central authority, let’s call that the counter. As soon one new such presence is announced, all the viewers are notified that the audience count has increased. Also, as soon as any viewer disengages, the others get notified that the respective count decreased.

Persistent connection

To facilitate instant updates, a continuously open connection is required between any one viewer and the centralized counter. Having the former just ask around for the number every once in a while (i.e. polling) is still an option but won’t be nearly as smooth or fast. 

Sockets

Such connectivity can generally be accomplished by means of sockets. Long story short, a socket is a kind of nearly-instant bi-directional data channel between 2 network-connected devices. 

WebSockets

Many most apps are commonly able to liberally create and make use of regular sockets, however the restrictive context of an internet browser cannot. Special abstractions had to be figured to bring socket-like functionality to the browser, of which the WebSocket has surfaced and is finally widely supported. 

The server

The so called counter is merely a piece of software; it has to reside on a publicly accessible, always-on computer or device that oldsters like to call a server; while it does a lot of things, a server’s main job is to ‘serve’ common needs of various other (not necessarily so public or available) devices, generally referred to as ‘clients’.

The ready to use solution

Is here for grabs. Variations have been implemented on multiple platforms and it’s stood the test of time. 

How cheap is it?

You’ll just be paying for the ‘server/s’. Unless you can run the counter on one of your existing computers [remember it needs to be public] or take advantage of some cloud’s free tier (in which case it’s free, as in beer). 

In production, consider budgeting $1 per 1k simultaneous viewers per month, prorated.

Does it scale?

Not without headaches. 

The boxed solution is well optimized and proven to accommodate some 10k viewers when running onto the smallest available cloud instance (with just 0.5 GB of RAM!)

It can stretch to take up to maybe 4-5 times that much on a single computer but the truly scalable setup takes an autoscaled cluster of ‘servers’. Not too complex really, it has been done a repeatedly and hope to get the time to dust one up and make it public soon.

• 

Is it stable/reliable?

Up to a point…

• You’ll see it hogging the host’s CPU way before it starts being laggy to your viewers. Run it on a more powerful computer next time you expect a similar or larger audience
• Memory use hasn’t been a real concern in any of the implements
• If noticing a rather constant limit your counter never goes above, your setup (either the software, OS or NIC) may be running out of sockets it can simultaneously keep open. There are many ways to mitigate that, details vary with specifics of the environment
• Before WebSockets were ubiquitous, long-polling (and at times its creepier cousin short-polling) was the norm for setting up persistency in the browser; these put a more severe burden on the server and are safe to be avoided, at long last; don’t give in to the likes of socket.io unless you really know what you’re doing

Is it secure?

In the example it’s not. Meaning that if one wanted to impersonate extra viewers into your pool they could easily do so. Also go the (DoS) extra mile and try to bring the ‘counter’ and the server hosting it to its knees, by impersonating a jolly bunch of extra viewers.

Not to say it can’t be made safe. CORS and SSL are the first things to consider. Also some simple way to limit rate and payload size. 

Next up, any extra validation, authentication, tokenization etc. will take a slight toll on the server resources, multiplied by one of the numbers above. So be wary and benchmark each addition. 

Is it fast?

Yesss! As fast as you’d expect an update to propagate over the internet these days, at half the speed of light if lucky. 

Sounds like a simple task, why is it so hard to scale?

Think the following scenario: 100 average viewers, each coming in or out every 10 minutes. That’s 10 updates per minute, to propagate to all of the 100, for a total of 1000 updates per minute.

Now for 1000 average viewers, each also coming in or out every 10 minutes. That’s 100 updates per minute, to propagate to all of the 1000, for a total of 100k updates per minute. 

Take that for 10k average viewers, it’ll be 10M (!) updates per minute. And that’s just averages, real life will show you that the audience tends to flock in the beginning and key moments of an event.

Ok, there are tricks to smooth out the treacherous exponential there, and you know one of them already. Display 1.7k viewers instead of 1745 viewers. That’s a hundred-fold reduction in the number of updates, out of the box! And there’s more to be done of course.

Will they come after me?

• 

There’s a shred of misunderstanding, to say the least, when it comes to grasping and facing the codecs licensing topic. General perception being that if you’re just starting out you don’t need to worry about it, the warning here is that it may crawl up on you as you grow, depending on how you put that codec to good use and especially how you monetize it. Let’s start with the basics though.

Intellectual Property

Many video compression techniques included in a codec are patented inventions. To use the codec, you’d have to license the patents from their creator or representative. Fair enough, except we are talking about a few thousand patents from a few dozen companies.

• 

Patent Pools

To simplify licensing, copyright holders ‘pooled’ the patents through organizations that sell these collectively on behalf of their members. 

While there’s more than a single pool, and some patents are unaffiliated, it is commonly agreed that you only need to reach out to MPEG-LA to license H.264 (aka AVC), while in the case of H.265 (aka HEVC) you need to pay at least the 3 big pools (MPEG-LA, HEVC Advance, Velos), of which the latter does not even publicly disclose prices. 

Known pricing

Terms under which a license is sold are rather complex and highly nuanced. Cost will vary depending on the context respective codec is being used, volume, and revenue you may drive from it. 

• 

Very much notable, some use cases bear no cost, while others carry a generous entry level threshold. Nevertheless, do pay attention, and let’s take these one by one.

Per-Device 

Applies to smartphones, tablets, digital and smart TVs, computers, video players and anything with a hardware encoder or decoder of the respective codec. Royalties are owned by the device supplier and not by the encoding/decoding chip or module manufacturer.

Also applies to software products that include an encoder or decoder. Royalty is owned by the product vendor/distributor, whether the product itself is commercial or free. Notable exception: free products (truly free, like Firefox) may include the OpenH264 binary, in which case royalties will be generously covered by Cisco. 

Per-Title PPV

These include platforms that sell access to content on a per-title basis. Royalties are either (A) a fixed value per sale or (B) a percent from sales to end-users, in some cases the lesser of the two. Note that tiles (i.e. videos) 12 minutes or less are exempt from such royalties.

Subscription-Based PPV

Royalties apply to subscription platforms like Netflix and vary depending on codec and number of subscribers. There’s a zero cost entry level for AVC if one has less than 100K subscribers. 

Free Television Broadcast

Applies to terrestrial, cable and satellite broadcasters, with pricing per encoder or size of the audience

Free Internet Broadcast

You own no royalties if encoding content to be distributed for free over the internet. 

Real world (small) business models, and how much they may own

Mobile apps

We’re obviously talking about mobile apps that either play or broadcast/manipulate video through either one of these codecs.

If you rely on a hardware or OS exposed encoder/decoder to do the job, you don’t owe anybody anything, godspeed!

If you include a software encoder or decoder in your app, you fit into the ‘Per-Device’ category. For AVC you don’t pay anything until you reach 100K units (i.e. actively installed apps). 

For HEVC, you’ll be paying from the ground up, think $1.5 to $4 per unit.

Streaming platforms

You owe royalties if you distribute AVC or HEVC encoded content, unless it’s free as in YouTube.

A TVOD platform (or the live streaming pay-per-title equivalent) should pay MPEG-LA 2¢ or 2% per title sale for H264 and/or 2.5¢ to HEVC Advance for H265. There is no entry level freebie for this model.

A SVOD platform (or the live streaming subscription-based equivalent) starts owing MPEG-LA between $25-100K for AVC after they go over 100K paying customers. HEVC is not as friendly to newcomers and you owe HEVC Advance ¢0.5-2.5 per customer from day one.

Cloud encoding

1. If you operate a service that sells the encoding/transcoding service explicitly (like encoding.com does),  you definitely do owe royalties. How you will be billed is however rather uncertain. You’ll ultimately have to reach out to licensors and ask, I have at least 2 customers being charged very differently for quite similar business models. Common sense would even so dictate that

• If you charge for encoding by the item (title) you will pay royalties per title
• If you charge for encoding via a subscription, you will fit into the subscription-based royalty model
• If you charge for encoding by the minute, you may (possibly) fit into the per-device category, where each encoding server counts as one such device

2. If you transcode video internally, as part of a larger streaming platform, there’s no clear rule/guideline on how licensing works and you also have to ask. A couple customer stories would lead yours truly to believe that

• If the platform distributes paid content (SVOD or TVOD) and already paying per-title or per-subscription royalties in that respect, there is no extra charge for the encoding part
• If the platform distributes free or AVOD content, it may owe per device (i.e. transcoding server or server core/thread) royalties; or it may not 😐

Online TV Stations

If it’s free to watch, you’re in the clear, no royalties. 

If it’s a paid service (i.e. subscription) you do owe it. Even if streaming is powered by a 3rd party platform and/or commercial player, the organization that labels the content also has to license the technology. Now you know.

Will They Come After Me?

Possibly not. Interesting enough, the ‘pool’ organizations cannot and do not deal with litigation. 

Never heard of any small player being anywhere close to indicted but still…

As your startup begins to grow, you should start being aware of how much you owe and consider that you might someday need to pay it all retroactively. Balance your encoding needs and don’t shoot for the mightiest codec unless you really need it. Explore alternatives and know your options.

Are there free alternatives?

Sure! 

AV1 is everyone’s dream: royalty free, and backed by an alliance of 48+ members; but it’s rather new, half baked, and it will probably be long before you’ll find a decoder for it in every device out there; but definitely one to look after in the years to come.

VP8 and VP9 are roughly comparable in quality to AVC and HEVC respectively, and also royalty free; except they’re only supported by google. While they admirably carried out the complex (and expensive) job of bringing these to market and safeguarding them from patent claims, they failed to convince the other big boys to adopt it; so hardware support is still scarce some 10 years later.

Where to go next?

See Jina’s article on the matter of AVC licensing, it may help clear out extra concerns. Also a couple of great articles here and there. 

Perhaps you should. More so if you’re annoyed at the inconsistent latency of RTMP, dealing with packet loss over RTP/RTSP or tired of running long SDI or HDMI cables.

Although rather different, these 2 share common traits, possible reason they’re sometimes discussed together or confused among. They’re both designed for low latency video transmission, both came around in an attempt to fill a gap in existing technology, they’re free and widely adopted. And the similarities stop here. 

Internet vs LAN

By design, SRT is intended to transport video via the open internet and other unpredictable (i.e. prone to bandwidth jitter and packet loss) networks. In turn, NDI works at full potential over consistently fast (read Gigabit or better) internal networks that can guarantee extremely low transmission error and congestion rates. 

UDP vs TCP

You know already, TCP is fully reliable while UDP is not. The former will retransmit lost packets until successfully delivered, the latter will just let them get lost and not retransmit anything. Retransmission introduces delays, and the frequency and length of these delays is unpredictable. 

SRT runs on top of UDP, NDI runs on top of TCP; NDI is arguably faster than SRT. Wait, what?

Latency

SRT allows you to set a fixed latency (120ms by default) for your video transmission. It will retransmit the packets that were lost over UDP only if not too late to stay within that latency margin. Depending on the speed and quality of the network between the 2 endpoints, setting a slightly higher latency may visibly reduce the amount of video and audio ‘glitches’ caused by undelivered packets. 

NDI advertises near-zero latency. It however demands a very fast and non-jittery network, or it’ll degrade ungracefully. Fact that it rides over TCP is therefore rather irrelevant as the low latency is only achievable if the packet loss and retransmission are minimal. 

Encoding

SRT is allegedly codec and format agnostic and only takes care of transporting video payloads across the network. There’s room for debate but let’s just mention that most of the tried and true implements gracefully deal with AVC and HEVC wrapped in MPEG-TS.

NDI manages both encoding, transport and decoding, thus it takes and outputs raw video. Internally a subset of H264 is used, more often than not trying to take advantage of built-in hardware encoders and decoders on host devices. 

Video Quality

In the case of SRT, what you send is what you get. If it’s not well tuned with the network capabilities (or if these degrade beyond ordinary) you’ll see or hear the ‘jerks’ commonly associated with packet loss. 

NDI is so called ‘visually lossless’, meaning the encoding artifacts will be virtually unobservable by the naked eye. Surely at the expense of…

Bandwidth Consumption

For NDI, it’s huge; think 100-150Mbps for a full HD stream and at least double that much for 4K.

With SRT, it’s up to you, as you’d need to figure out how to encode and mux the video before sending it off to transport. Do take into account the overhead introduced by retransmissions, especially if your network is busy.

Can I play with it?

Sure can! Put together a simple low latency streaming platform proof of concept. Based on Nimble (hey, it’s still free, wowza more than tripled their price over the last few), featuring SRT ingress and SLDP egress, you can deploy it in a few clicks and test it in a few minutes. It’s a mere adapt/simplification of the earlier larger scalable low latency project.

Fine, I’m interested, which best suits my use case?

Let’s recap the differences, and this time bring our old friend RTMP into the mix, should help make an educated choice

	RTMP	SRT	NDI
Designed for	Streaming over Internet	Streaming over Internet	Streaming in LAN
Transport	TCP	UDP	TCP
Latency	Higher, Unpredictable	Low, Customizable	Lowest
Signal Quality	High	Good	Nearly Lossless
Deals with	Transport	Transport	Encode and Transport
Bandwidth consumption	Encoding Dependant	Encoding Dependant	High

Are they expensive?

They’re both free, although NDI is proprietary yet royalty free, while SRT is fully open. 

Are they secure?

SRT supports AES encryption. 

NDI has no built in encryption mechanism afaik, if that’s critical you can run it over a VPN of some kind.

Long gone are the days when you could whip up an RTMP broadcast in (sort of) any browser with a few lines of code, not that we honestly really miss those times. Ironically, it’s been more than 10 years since the F word became taboo, and a quick search revealed that Flash (there I said it) will finally start resting in peace at the end of the year. 

Despite, the protocol that’s been built for it – RTMP – lives on and there is no end to it in sight. Actually it’s by all means the de facto ingest standard to all streaming platforms, big and small. And implemented by many hundreds of broadcast products. Because it’s unsophisticated, it works more often than it fails, it’s open (though it hasn’t been from the beginning), offers a relatively low latency, and supports a couple of the most common codecs.

It’s not all good. As it runs on top of TCP, it can’t feasibly be tuned to operate at a fixed/predictable latency, plus it degrades ungracefully under fluctuating, unstable, or otherwise poor connections. And worst of all, there is no browser support for it, now and ever. 

But…

WebRTC is at long last supported in all modern browsers, with some players being particularly late to the game. And while it’s no RTMP (in fact it’s vastly superior to it) it lets you grab a live feed of your camera and transmit it to a fellow WebRTC endpoint, be it a browser or anything else. 

Thus, there’s no stopping us from putting together a proxy that sets up one such WebRTC endpoint (connecting to the broadcasting browser), and also converts and repackages the incoming feed into working RTMP to be pushed to a 3rd party platform or server. Like this

• 

The fabulous perk is that most WebRTC enabled browsers can, according to standard, encode in H264 so there will be no need to transcode the video at all. Audio coming out of the browser is usually Opus and that we’ll want to transcode into AAC for compatibility. That’s still a big win as audio transcoding requires a lot less processing than video would. 

The nugget

As with other solutions, tried to smooth out the learning curve by offering a working prototype to be deployed asap. It sets up the webpage and ‘proxy’ bundle in a few clicks, effectively making it look like you’re broadcasting your webcam to a customizable RTMP address, all from the comfort of your own browser. You’ll still have to go through the hurdle of setting up and providing a key/certificate pair as WebRTC requires HTTPS more often than not.

POC is powered by the amazing MediaSoup framework, and much of the code is recycled from this handy sample. Work is part of a bigger effort to rejuvenate a commercial browser broadcasting enabled product, originally built on top of Kurento.

Does it scale?

With a bit of care and planning it will. Bottleneck being the processing toll it takes on transcoding the audio. Think a midrange computer/server will easily proxy 20 simultaneous streams. 

Also need to take into account that some browsers still won’t encode H264 (e.g. Firefox on Android) and it’ll have to default to VP8/9 which needs transcoded to work with RTMP.

Is it stable/reliable?

Better than the real thing! As the last mile (first actually) is delivered via WebRTC — which features UDP transport, adjustable bitrate, congestion control, forward error correction and other cool stuff — the overall quality of service will be superior to the scenario where you would have broadcast the same camera with (e.g.) Wirecast, given the same encoding profile (i.e. constrained baseline) and resolution, especially over unpredictable networks or when employed by your non-streaming-savvy website users.

Is it fast?

Relatively so. Think sub-second WebRTC browser-to-proxy and 2-3 seconds RTMP proxy-to-platform. Not good enough for a video call but at least bound to be consistent, as compared to an unpredictable 2-30 second direct RTMP connection. There is extra delay introduced by the need to transcode, but that’s like half a second at most. 

Is it expensive?

I say no, but depends on what you’d be using it for, and the scale you’d be using it at. Processing juice for transcoding the audio would set you back under a cent per hour per stream; if it were to be separate that is, yet the proxying and transcoding needs to be thought of as part of the bigger picture and possibly run on a system that’s often idle.

Is it secure?

Yes, actually. WebRTC is always encrypted, unlike RTMP.

But I have 100mbps

• 

Hey, streaming is a complex matter. Broadcasters are ever increasing and so are the options for platforms and equipment. While setting up a FB/IG live session from the app is fairly intuitive, stepping up one’s game to offer a more ‘pro’ gig can be challenging. And no wonder, media acquisition, encoding, transport, processing, delivery have to be well tuned and work in sync to ensure crisp and smooth playback.

Far from able to summarize all it takes to make your transmission crystal clear and free from ‘lagging’ or ‘freezing’, will in turn try to outline the most common rookie wrongdoings when setting up a broadcast. Though the following may come to you as common sense, I still get a huge share of ‘ahaaaa’ moments when I tell people to…

Turn on the lights!

Yes, the difference may amaze you. Blinding lights studios use are no mistake. 

Thing is, regardless of its sensitivity, the digital sensor (and the film before it) of any camera will output a grainy/noisy picture under low lighting. And if streaming it, noise does not encode particularly well and you end up with an unexpectedly poor frame quality, either ‘grainy’, or ‘blocky’, or both. Tech details aside, use the brightest light you can find and see for yourself. Next up if you truly need to shoot in the dark realize you may need specialized (i.e. expensive) gear. 

Bonus: you’ll get a less ‘choppy’ video. Many low-end consumer webcams do not have an adjustable aperture and will in turn vary the exposure time to tune the brightness of a frame; in low light this will lead to longer exposures and reduced framerates.

Get a better connection

Please, stop being convinced your internet is amazing simply because your provider or the default speed test told you so. In the case of the latter, what you’re seeing is merely the speed to the nearest PoP, which is usually way off your true internet speed. There’s a lot more to networking than raw (average) speed unfortunately, and before going scientific at least try running the same test against a farther ‘server’ like one in Australia or South America. 

Moreover, if you’re wireless (may that be wifi or cellular) keep in mind that the quality of your connection varies with position, obstacles, interference, weather, conspiracists’ tinfoils. And unlike browsing or tweeting, streaming works best under constant and predictable network speeds and latencies.

So I beg you, especially since nowadays anyone can whip up a high speed mobile hotspot, try another network, you may be in for a surprise. 

Get a better camera!

Sure, that’s obvious. Yet the characteristics will vary widely, and often the quality/performance of the lens, sensor, and sometimes electronic post-processing will make a remarkable difference, between cameras with identical specs nonetheless.

But you don’t have to break the bank in the process. A used/aftermarket DSLR or ‘handycam’ will output a crisper picture than many high-end webcams or smartphone cameras. There’s no wrongdoing in lending or trying out a few and see what looks/works best for your needs. Or ask around to find what worked for others. Just don’t run your broadcast business around that same camera unless you understand it very well, it may be suboptimal for a million reasons, like having been pointed at the sun.

Reduce the resolution

But hey, isn’t HD and lots of megapixels what everybody’s after nowadays? It is, but the full broadcast chain has to support it in harmony. That is the camera, the capture device, the encoder, and the upload bandwidth. If any of these isn’t up to the task you’ll end up with a sub-par HD picture that is either wasteful or poor. Depending on your setup, a high quality SD may look better and get enjoyed by more.

Bonus: try streaming at 540p. Often unknown or overlooked, you can think of it as near-HD. It’s suitable for most unremarkable needs, and it’ll take slightly more than half of 720p’s bandwidth to encode at the same quality

Reduce the bitrate

I know, it’s counterintuitive. Higher bitrate always means higher quality, given all else the same. But it’s not proportional. Depending on your content (and the equipment, remember?), there will be a sweet spot beyond which increasing the bitrate will result in little to no visual improvement. There are tools and metrics pros use to gauge that (see psnr) but the naked eye can still be a good judge, just run a few tests. 

Don’t beat up your encoder

If using a computer for streaming, make sure its CPU never runs above 80%, ideally even lower. Else, it will drop frames (‘laggy’ again) or otherwise degrade the performance of your stream. Dedicated encoder boxes and smartphone apps tend to automatically pick the encoding profile to match the hardware capabilities so you don’t have to worry that much, but do keep the same in mind and measure it if possible. Now you know. 

Use (better) microphones

This one’s easy. If your sound is poor you’re probably too far away from the mic, or you need a better one. Pay particular attention to the wireless kinds as some may introduce delays, and getting it in sync is kind of an advanced topic. 

Bonus: Be careful not to introduce echo/feedback. Mute all your players and always use headsets if you really need to monitor the transmission’s audio in the vicinity of the microphone. 

Reboot everything

Sketchy topic… For reasons only understood by masterminds, electronics with a reset button don’t just crash and freeze, they may also malfunction in weird, unobvious and unexpected ways, more so if they’re low end and have been running for a longer while. Especially if you’re not an expert, do yourself a favor and take the time to restart that router, computer, smartphone or gadget before the big event.

Expect to fail

Things will go wrong, mercilessly, when and where you least expect it. Ensuring redundancy/failover for every scenario is overkill and overly expensive. Do prepare for the most common mishaps (internet/electricity going out) but not the apocalypse. When it hits the fan, deal with it the best you can and don’t freak out; your viewers are forgiving and your reputation is salvageable. Apologize if the case, be honest about what went wrong and steps you’re taking to avoid that in the future.