The Red Button Reality

Chapter 1: The Last Pint

There comes a point in any fever dream where you have to put the crimping tool down, pour yourself a pint, and admit there is still one job left to do.

This is that point.

We have been at this a while now. We started with a phone on a tripod in a pub that could not afford a tripod, and we have ended up — somehow, without anybody formally agreeing to it — standing in a room with sixteen decoders, eight encoders and a switcher big enough to park a car on, wondering whether all of it will ever be watched by a single person who is not one of us.

That is the question that has been sitting underneath everything else. Not whether any of this works. It works. We have spent an entire series proving that it works. The question is what happens after it works.

The ladder, one more time

Before we get to the awkward part, it is worth remembering what we actually built, because the shape of it matters more than the price of it.

The Harbour Tavern still runs on a phone, a laptop and an app that costs nothing. It produces a picture that is not perfect and is completely honest, and it feeds the same hub as everything else over the same transport, arriving as the same kind of rectangle as everything else. The Black Lion runs on roughly £26,807.55 of kit and produces something that feels like a real broadcast operation rather than a camera pointed at a stage. Sewerby Hall sits between the two, spending just enough to be credible without pretending to be a network.

The Priory and The Spa Gardens made the venue itself part of the design — one with a production core that uses local SDI where that stays practical, the other running a full local IP environment where sources, destinations and protected paths became the way people thought. And then The Royal Hall, at £826,903.33, asked the only question that matters when the performance carries the festival’s greatest expectation: what happens when it cannot fail?

Then we put all of it in a room. The Command Nexus received sixteen contributions, decoded them, switched them, recorded them, mixed them and sent them back out again as eight live services. And the single most satisfying fact of the entire project is still true: the hub could not tell the difference between the phone and the cinema camera. Sixteen feeds, sixteen decoders, one wall. The ladder was real, and the ladder was irrelevant.

That was the point.

The thing nobody warns you about

Here is what nobody warns you about.

Building the thing is the easy part, and I mean that as someone who has spent a lot of hours in a small room watching a wall of screens trying to keep sixteen rectangles alive. The building is engineering. The building has answers. A feed drops, you find out why. A switch fails, you route around it. A stream will not lock, you check the buffer settings and the clock and the path between the two points, and eventually it locks. Every problem has a shape. You can hold the shape in your head and work on it.

Getting it to a stranger’s phone has no such comfort.

Everything we have built so far has been a conversation between people who all know the system. The venue operator knows their encoder. We know their encoder. The production coordinator knows which decoder belongs to which room and roughly what time the set ends. When something goes wrong, there is a phone call, and the phone call gets answered, and someone says “we’re losing the feed from the back room” and everybody understands what that means and what to do about it.

That entire social contract evaporates the moment a member of the public opens a link.

They do not know your encoder. They do not know that the buffer is set to 800 milliseconds because the venue’s internet wobbles at half past eight. They do not know that the pub’s contribution is technically weaker than the headline stage’s and is also, quite possibly, the thing they most want to watch. They are standing on a seafront in the dark with one bar of signal and a decision to make, and they will make that decision in about four seconds. Everything we have built has to survive that. Everything we have built has to be findable in that.

The bit where I got it wrong

I want to tell you about a moment that changed how I think about this, because it happened long before this series and it has been sitting in the back of my mind ever since.

I was watching two feeds side by side on a multiview, years ago, and they arrived from two completely different sources. One was cinema quality — beautiful, sharp, the kind of picture that makes you realise how much you have been missing on everything else. The other was a phone. A phone, on a stick, in a room that was too dark, pointed at a stage from an angle that somebody had clearly guessed at rather than chosen.

And on the multiview they were the same.

Not similar. Not comparable. The same. Two identical rectangles, side by side, both labelled, both locked, both carrying a stream that arrived by the same mechanism and landed in the same place. There was nothing on that screen that told you which one was worth ten times the other. That was the moment the whole idea became real to me, and it has stayed with me ever since: the mesh does not care. The mesh genuinely, structurally, permanently does not care.

And here is the uncomfortable part of that lesson, which I did not understand at the time and understand now.

The mesh not caring is a triumph for the contribution side of the system. It means a volunteer with a phone can be part of a town-wide broadcast. It means the ladder is genuinely permeable. It means the small stage is not technically consigned to being the small stage. All of that is good, and all of it is true, and none of it is sufficient.

Because when those two rectangles leave the truck, something has to decide which one a stranger is shown first. And that decision is not technical. That decision is editorial, and it belongs to a person, and it is much harder than picking a source on a switcher.

We spent this whole series building a system that could not tell the difference. The next job is being the thing that does tell the difference, on purpose, every time, for an audience that will never know we had a choice.

What this post is about

So here is what this post is about, and it is narrower than the last five.

Not building. We are done building. The mesh exists on paper and it exists in a plan and it could exist in a town with a weekend and a budget. What we are talking about now is the last mile: the bit between the encoder bank and somebody’s hand.

Three things, roughly. First, how eight finished services from the Command Nexus become something that plays reliably on a phone on a bad connection — and why that is a genuinely different discipline from the one we have been practising, not a final chapter of the same one. Second, what we do with all the material we recorded, which is a great deal of it, and which has a life beyond the live cut. Third, the bill.

The bill is last on purpose.

Not because it is unimportant — it is important, and it is the number this whole thing gets judged on — but because you cannot have a useful conversation about money before you have decided what the thing is. A cost figure is meaningless without knowing whether you are buying a demonstration or a festival. And that distinction turns out to be the single most important idea in the entire series.

So: distribution, then highlights, then the money, then some shouting about the Cloudflare-shaped part of the story, and then we will put the whole thing down.

There is a pint to finish. It has been waiting patiently while we did all of this, which is more than can be said for the crew in the truck.

Where the punters come in

One more thing before we start, because it is the thing that reframes everything.

Every single decision we have made in this series has been made from inside the system. I have been standing in the nexus looking at a wall. I have been looking at a decoder that will not lock. I have been listening to a Fairlight and watching meters and worrying about a routing table.

The punters have been somewhere else entirely.

They have been on the seafront with the wind coming off the water. They have been in the pub garden at the Black Lion trying to hear the band over the conversations. They have been at The Royal Hall for the headline and at The Priory for something quieter and at the Harbour Tavern for something that was not on anybody’s running order but that they will remember for years. They have been holding a pint, standing in a doorway, sitting on a wall. And if they watch any of this at all, they will be watching it on a phone, in one hand, with the other hand occupied.

That is the real audience for this post. Not a broadcast engineer in a rack room. Somebody stood on a seafront at half past nine wondering whether the music is going to reach them.

Everything below is written for them. The queue that has formed behind the working is about to be served.

A note before we begin

Imagine a festival — not Bridlington, somewhere else entirely — where every one of these decisions goes wrong at once.

The selector app takes ninety seconds to load on a phone. The venue’s internet blinks during the changeover and four thousand people get a buffering wheel instead of a band. The headline stage is beautiful, and the pub with the folk duo is what people actually wanted to watch, and none of them can find it because the interface buried it under a dropdown. And on top of all of it, the CDN quietly charges by the gigabyte, so the festival that everyone loved is also the one that broke the budget.

That festival is entirely possible. Almost everything in this post is an argument for how to avoid it.

Right. The pint is poured. The tab is open, and it is going to hurt.

Let’s talk about how eight streams leave the truck and actually arrive.

Chapter 2: From Truck to Audience

There is a moment in every broadcast build where somebody says “we’ve made it — it is working” and everybody claps, and then about forty minutes later somebody else says “…but can anyone actually watch it?” and the temperature in the room drops.

That gap between those two sentences is where this chapter lives.

Contribution is not distribution

Throughout this series, every venue has been feeding the Command Nexus over SRT across the public internet. We have been comfortable with that, and we were right to be. Contribution is a conversation between two endpoints we both control. We know where the encoder is. We know which decoder it is supposed to land on. We chose the buffer settings. When a stream blips, we tolerate the blip, and when it does not tolerate it, engineering fixes it. There is a human being on both ends of that pipe, and both of them are paid to care.

Public distribution is the exact inverse of that.

The moment a stream leaves our side of the fence, the number of endpoints stops being knowable. It is not one truck on the other end any more. It is every viewer, each behind their own connection, on their own device, on their own network, at their own distance from whoever happens to be serving them the file. And each of those viewers will decide, without warning and without telling us, whether to stay.

The difference is not scale in the abstract. It is that the failure modes change shape.

A contribution failure is a technical problem. It has causes, it has symptoms, it has a fix, and the people who can apply that fix are standing in a room with the equipment. A distribution failure is a vague problem. The viewer knows something is wrong — there is a wheel, or a black rectangle, or a message about a codec — and they know nothing about what to do about it, and they will solve it by closing the tab. You get exactly one attempt at that viewer and you will not get a diagnostic.

The second thing scale changes

There is a second difference, and it is the one that actually keeps people up at night.

Every problem we have handled so far gets worse gradually as more people watch. A decoder struggling with one contribution is struggling a bit. The same decoder with four contributions is clearly unwell. Engineering can see the difference between a load problem and a fault, because engineering can see the load.

In distribution, the load curve is the audience, and the audience has no schedule. A festival with sixteen venues does not accumulate viewers at a predictable rate. It accumulates them in a spike — the headline starts, or a band turns up, or somebody posts a clip and the whole town decides to watch the Black Lion at the same moment. Every other system in this series has a capacity you can reason about. This one has a capacity that arrives from outside, without notice, and it does not care what your origin server looks like.

Imagine a festival — not Bridlington, somewhere else — where the headline act walks on at nine, and the seagulls start arriving on every beach in the county simultaneously.

The venue’s contribution might be four megabits and beautiful. The point is that the beautiful four megabits have to be delivered, repeatedly, to a number of people that is determined by how good the band is, and the better the band is the more likely you are to fall over. Success and failure share an axis. Almost nothing else in broadcast works like that.

What “delivering a stream” actually means

Here is the part that surprised me when I finally understood it properly, and it is worth stating plainly because it is not obvious from the outside.

Pushing a stream somewhere is easy. The encoder bank can put a stream to any destination that will accept it. That is not the hard part. The hard part is what happens next, and there are three separate jobs hiding inside the word “delivery.”

The first job is ingest. Somebody has to accept our stream. In practice that means a platform that speaks a protocol our equipment can push — RTMP or SRT over a connection we can open and hold — and that will sit there and receive it patiently for six hours while we do not crash it. This is a solved problem. There are several good options and we do not need to have a strong opinion about which one.

The second job is transcoding. Our encoder gives us one clean stream at a bitrate that suits a fibre connection. A viewer on the seafront, on a phone, halfway through a bar of signal, cannot use that stream. They need something smaller, something the phone can decode without heating up, something that arrives in segments rather than as one enormous file that either completes or does not. This is the job of turning one master into a ladder — several versions at different sizes, so the player can pick the one the connection can carry right now.

The third job, and the one nobody thinks about until they have seen it fail, is delivery. The transcoded segments have to get from the platform to the viewer’s phone, over whatever path exists between them. This is the part a CDN exists for: caching copies close to the audience so that the file does not travel the whole distance from one origin every single time somebody presses play.

Those three jobs are genuinely different, they live in different places, and almost every confusing decision in this area comes from conflating them. When somebody says “we’ve got a CDN”, they have usually solved two of them. When somebody says “we’re streaming to YouTube”, they have solved all three but given away a great deal in the process. Neither is the wrong answer. They are different bargains, and the bargain is the decision.

A technical biography: what a CDN actually does

The abstraction I have been handed in the past is that a CDN is “where you put the video”. That is wrong in a way that matters, so let me describe what it actually does.

We push one stream in. That is the origin. The origin is a single machine, in a single place, and it is directly responsible for every byte that leaves. On its own it would work — right up until it does not, because a single origin has a single point of failure, a single uplink, and a single geography. Every viewer pulling from it means every byte crossing the same wire, and the further away they are the worse it gets.

The CDN’s first move is to stop that happening. Ingest lands on the origin, and then copies of the content are pushed out to a large number of edge locations — points of presence, spread across the physical world. Those edges hold the material close to the people who want it. When a viewer in Leeds presses play, they are served from an edge that is geographically near Leeds, and the origin is not involved at all. If the origin then falls over, the edges keep serving what they already have. That is the resilience argument for a CDN, and it is a good one.

The second move is the transcoding ladder, which is where the CDN earns its keep. A single high-bitrate master is useless to a phone on a poor connection. The platform transcodes the master into a set of renditions at different resolutions and bitrates — the ladder — and packages them for delivery in a segmented format that a player can request piece by piece. HLS and DASH are the two dominant packaging approaches, and they are worth knowing about, because the whole design rests on them: instead of one file that must arrive complete, you have a playlist of short segments that the player fetches continuously. A viewer with a good connection pulls large segments. A viewer having a bad time pulls small ones. Same content, same platform, no decision required from the user.

The third move is the cache. An edge that has already served a segment will hold onto it, and the next viewer asking for that same segment gets it without touching the network again. For a live festival this is subtly interesting, because a live stream’s segments are mostly requested once — there is no repeat viewing of the same ten seconds by everyone — but the caching still matters enormously at the edges nearest the audience, and it is what turns “one origin serving a county” into something that behaves.

The result is a system that is genuinely unremarkable to use and remarkably complicated to build. From the outside, a viewer gets a picture. From the inside, there is an origin, a set of edges, a transcoding pipeline, a ladder, a segment format, a manifest describing the ladder, and a player negotiating with all of it in real time while standing in the wind.

Our job is to hand that system one clean stream and then get out of its way. The Cloudflare Stream approach is the obvious candidate for this festival specifically, because it ingests via RTMP — which is exactly what our Streaming Encoder 4Ks can push — and then handles the transcode, the packaging and the edge delivery as one product. YouTube’s RTMP ingest does the same job and will happily accept unlisted streams, which makes it genuinely viable for a community festival where the budget is not really there. Both are defensible. Neither is free in the sense that matters, and I will come back to what “free” means here when we talk about money.

The important thing to hold onto is that the architecture is what you are choosing, not the vendor. Ingest, transcode, edge. Every option on the table does those three jobs in some arrangement, and the differences between them are differences of control, not of capability.

Why your NAS is not a distribution platform

I want to be direct about this because it is the most common mistake in the space and it is tempting every single time.

You have a NAS. It has a lot of storage. It has a fast connection. You could, if you wanted to, expose it to the internet and point a link at it, and for an audience of about forty people on decent broadband on the same street, that would work.

It will not work for a festival, and it will not fail in a way that makes the cause obvious.

The problems are structural. A home connection is behind NAT — your router has a private address and the internet cannot reach it unless you punch a hole in the firewall and hope. Your uplink is a fraction of what the audience’s combined demand would be. You have no transcoding capability at all, so you would be streaming one rendition at master bitrate to everyone regardless of what their connection could actually carry. And critically, you have no second copy: the moment your connection drops, your origin does, and unlike an edge cache there is nothing behind it holding a copy of anything.

Imagine if an event organiser points a public link at a NAS in a spare room and it works beautifully for the first two hours.

Then the headline band comes on, four thousand people open the link in the space of a minute, the uplink saturates, the whole thing stalls for everyone at once, and the person watching it sees a spinning wheel rather than a stage. There is no partial failure and no useful information. It is not that the good bits get through — it is that nothing does, and nobody can tell why.

That is the difference between a file server and a distribution platform. One is a place to keep something. The other is a machine for absorbing demand you did not control. And it is worth being blunt that this is a genuinely different engineering discipline from the one we have been enjoying — our contribution network fails in ways that tell you what happened, and a distribution platform fails in ways that tell you nothing.

When the YouTube option is genuinely the right one

I would be doing you a disservice if I only described the trade-off from one side.

There is a version of this festival where the honest answer is YouTube, and it is not a compromise. RTMP ingest, unlisted or restricted streams, and an infrastructure distribution network that is genuinely world-class and requires from you exactly nothing beyond the stream itself. For a lot of community events that is the difference between happening and not happening. The scale at which a small festival can be broadcast for free of marginal cost is a genuinely astonishing thing and it should not be sneered at.

Where YouTube becomes awkward is specifically the multi-channel, choose-your-venue experience this post is about. Publish eight separate streams and you get eight separate video pages. That is not a Red Button. It is eight tabs. To get the festival to feel like one thing you have to build something in front of those streams — a selector, a player, some state management — and at that point you are maintaining software, which is a different commitment from maintaining a box.

That is a real consideration, but it is not a disqualification. Plenty of festivals run on a selector app over somebody else’s streams and it works perfectly well. The trade is: less control over the delivery layer, in exchange for not having to build or maintain one.

And the reason Cloudflare Stream keeps coming up in this conversation is that it sits in the middle of that trade. It is a distribution platform rather than a video host, which means you keep the multi-channel experience as your own problem to solve, but you do not have to solve transcoding, edge delivery and cache behaviour as well. It is a smaller, better-defined job.

The rule underneath all of it

Whatever the choice, one rule holds, and it is worth stating because it is the whole reason this chapter exists.

The private mesh gets you to the truck. The distribution platform gets you to the audience. Those are two different systems solving two different problems, and the moment they blur together everything gets confusing.

Our eight encoder outputs are finished services. That is what they are — the output of an editorial process, not a raw feed. From the moment they leave the encoder bank, they are somebody else’s infrastructure doing somebody else’s job, and the game being played is a different game. Contribution is a tieline you control. Distribution is a firehose you do not.

And the test of whether you have got it right is not technical at all.

It is this: will it play on your mate’s phone, on 4G, stood on a seafront, at high tide, with one bar of signal and a pint in the other hand?

Because if it will, the rest of it is engineering. And if it won’t, no amount of bitrate maths is going to save you.

Now, once eight streams are reliably arriving on eight thousand phones, you have immediately created a much more interesting problem: a menu. And menus, as any publican will tell you, are harder than they look.

Chapter 3: The Red Button Architecture

The phrase “Red Button” has done a lot of work in this series and it deserves a moment of honesty, because in Britain it carries a specific memory that is not really about television at all.

It means sitting on a sofa on a Sunday afternoon, remote in hand, pressing a button on a set-top box because something other than the teletext was on. It means choice. It means there is more than one thing happening in this building and you, the person on the sofa, get to decide what is in front of you right now. It was never a technical feature. It was a promise that someone with a broadcast tower had thought about what a viewer might want.

That promise is exactly what we can make here, and the whole architecture falls out of it fairly quickly once you accept it seriously.

Eight services, one idea

The Command Nexus produces eight live services from its eight Streaming Encoder 4Ks. We described that in detail when we built the truck, so let me restate the shape rather than the mechanics: one main programme that is a curated festival-wide cut, six fixed venue services that each run one room continuously regardless of what the main cut is doing, and one flexible path that can be pointed at a pop-up, a roving reporter, or used to protect a fixed service when something fails.

Look at what that list actually is. It is not eight channels of a television channel. It is one shared broadcast plus six ways to go and watch a room directly, plus a spare.

And that is the entire Red Button proposition in a single sentence: we are not asking the audience to take our word for what matters. We are giving them the tools to go and look for themselves.

That is a genuinely different proposition to a linear channel. A linear channel makes a promise on the viewer’s behalf: this is what you should be watching. The Red Button makes the opposite promise: here is everything we have, you decide. Those are different relationships, and the interface has to reflect the second one honestly or the whole thing collapses back into being a linear channel with extra tabs.

The six fixed services are what makes this real rather than theoretical. Without them, the Red Button is just a main cut with a couple of alternates, and the alternates will sit there unchosen forever because nobody will find them. With them, there is a folk duo in a back room at The Black Lion and the audience can go and stand in that room instead. That is the promise. Everything else is plumbing.

A technical biography: the selector

Let me describe what this thing actually is, because “app” undersells it and “website” oversells it. It is a small piece of front-end software with one serious job and three annoying ones.

The serious job is switching. Each of the eight services, once it is in the platform, exposes a playable URL — and for live streaming, that URL is not a file. It is a manifest: a small document describing a ladder of renditions at different bitrates, updating as the stream runs, pointing at segment files that the player fetches continuously. The selector holds eight of those manifests, one per service, and swaps which one is attached to the player element when the viewer picks a venue.

That sounds trivial and it is not, for reasons that will become clear in a moment. But it is also genuinely simple in implementation terms. There is no video processing in this application. There is no transcoding. There is no storage. The application does not touch a single byte of video. It points a player at a manifest and gets out of the way.

The three annoying jobs are where the real work is.

State. Where was the viewer? If somebody taps The Black Lion, then gets distracted, then refreshes the page — or worse, the page refreshes itself because their phone decided to reclaim memory — what should happen? Going back to the main programme is hostile. It throws away a choice the viewer deliberately made. But going back to The Black Lion is also wrong if they have since wandered off to check what is happening at The Royal Hall. You cannot simply restore “the last thing” and assume it is still relevant.

The pragmatic answer is that the choice has to be deliberate and reversible in an obvious way. Default to the main programme for a first-time visitor. Remember the choice once they have made one. Make the current selection visibly selected so the state is never ambiguous. And give them a big, obvious way back to the main feed that does not feel like a navigation — something that says “festival” rather than “home”.

Latency. This one is genuinely awkward and it is worth being honest about rather than pretending it away.

Every platform has some glass-to-glass delay. Different services in the same platform will have slightly different delays, and those differences do not stay constant, because the ladders adapt and the buffering changes. So if a viewer switches from The Royal Hall to The Black Lion, they may land about a second or two behind or ahead of where they were.

That is fine. Genuinely fine. Nobody watching a live stream can tell that they are two seconds behind the moment, and the alternative — chasing frame-accuracy across independently encoded services — is not something you can buy, and would not be worth buying if you could.

What matters is that the delays are consistent enough. If someone switches to The Black Lion and lands mid-song, that is a pleasant experience. If they switch and land three seconds before the band starts or misses the moment entirely, that is a broken experience. The difference is not the amount of latency, it is the amount of variance. Which is another way of saying that a well-behaved platform matters more than a fast one.

There is a nice detail here that costs nothing: offer a small amount of buffer on the way in. A player that starts a second or two behind but starts reliably feels far more professional than one that starts instantly and stutters. People forgive delay. People do not forgive stutter.

Failure. This is the one that actually matters, and it is the one that will decide whether the Red Button feels like a service or like an experiment.

Eight services, one of which is a pub with intermittent internet. Somewhere, at some point on the night, a venue feed is going to stop. Not fail gracefully — stop, and either hang on a frozen frame or fall over into an error. And somebody is going to be watching it, because the whole promise of the Red Button is that a viewer might deliberately choose the small venue over the main stage. They will have chosen it because they wanted that room. And then it dies on them.

What should happen?

Almost nothing visible. The player should notice the stall, hold the last good frame rather than blanking, and quietly start trying to reconnect. If it recovers within a few seconds, the viewer may never know anything happened. If it does not recover, they should be offered a graceful way out — a message that says this venue has gone quiet and offering the main programme or another room — rather than a spinning wheel and a browser error.

The failure message matters as much as the failure handling, because it is the only part of the Red Button that a significant number of people will ever see. Design it as if it is the most important screen in the application. It is.

Restraint is the actual feature

I keep coming back to this because it is the thing that most reliably separates a good Red Button from an embarrassing one.

Think about who is actually using this. Somebody is standing outside in the dark. They have a pint. They have one hand free. They are not going to read instructions, they are not going to explore nested menus, and they are certainly not going to fiddle with a settings panel while a band is on.

So: the venue selector needs to be obvious, needs to load fast, and needs to take one thumb press. If it needs a manual, it has already failed. If the main programme is not what arrives when they tap the link, we have confused the two ideas and the whole thing reads as a fussy little website rather than a festival broadcast.

The restraint extends to what is not on screen. Do not put the running order on the player. Do not put sponsor logos on the venue buttons. Do not put a chat window in the middle of the viewer’s face while they are trying to watch a band. A viewer who has chosen The Black Lion is there to watch The Black Lion, and every piece of interface between them and that room is a reason to close the tab and go and stand at the actual bar.

This is the exact opposite instinct to the one most people bring to building something for the public, which is that public-facing things need more explanation, more guidance, more visible features. For a live event viewer already holding a drink, every one of those is friction.

Accessibility is not an afterthought here

I want to put this in because it is genuinely a build requirement for this application and not a nice-to-have.

The people using this are standing outside, at night, on a phone, in a hurry. Some of them will be navigating with a screen reader because that is how they use a phone. Some will be one-handed, or wearing gloves, or squinting at a screen with the brightness turned down to save battery. Some will be colour-blind and relying on the selected state being distinguishable by something other than colour. Some will have motor impairments that make a small touch target genuinely hard to hit while the band’s second song is starting.

Every one of those is a real person who will decide in four seconds whether this festival is welcoming or is a tech demo, and all of those problems are solved by the same discipline: proper landmarks and headings so a screen reader can navigate the venue list; visible focus states so keyboard and switch users can see where they are; generous touch targets sized for a thumb in the dark; a selected state that is not just a colour change but has a shape, weight, or label change as well; and text that meets contrast requirements on a screen that might be dimmed to save power.

None of that is difficult and none of it is visible when it is right. That is the point. The audience for this application is, by definition, a general public audience, and the general public is not a set of broadcast engineers with good eyesight and fast connections.

The screen-reader label on each venue button should genuinely say what is happening there — the venue name, what is on, and enough state that the viewer knows whether they are looking at the band or at a bar — rather than a generic label repeated eight times.

Building it is not the hard part

I want to be honest about the effort here, because this is the point where the fever dream touches the ground and the ground is slightly damp.

This application is not difficult. It is a list of eight buttons, a player, some state handling, and a fallback screen. For somebody who writes front-end code for a living, it is a weekend. Maybe two, if you want the accessibility done properly rather than retrofitted, and if you want the failure states to be genuinely good rather than an alert dialog.

Which raises an honest question about a series that has been entirely about broadcast engineering: why is the concluding technical chapter about writing a web application?

Because the Red Button genuinely is where the audience meets the system, and it genuinely is not a broadcast problem. Everything else in this series has been a media problem — where does the signal go, how does it get there, how do we keep it alive. The Red Button is a software product problem, and it has a completely different failure vocabulary. A broadcast failure is a dropped packet. A software failure is an empty state, a dead button, a focus trap, a screen reader announcing nothing at all.

If you have never built anything that a stranger is going to touch, this is a useful thing to discover. The bar is not the bitrate. The bar is whether the person can find the button with a thumb in the dark.

Reality against the dream

The dream version of this is frictionless: eight flawless channels, sub-second switching, everything recoverable, a viewer who wanders between rooms all evening and comes away with a picture of the whole festival rather than one stage.

The realistic version is: eight channels that mostly work, switching that takes a moment, one venue feed that drops at some point and comes back, and a viewer who finds three rooms, likes two of them, and goes home having watched most of The Royal Hall and some of a pub they heard about from a friend.

That realistic version is worth building. That is the important thing to hold onto. The gap between the dream and the reality is not a failure of ambition — it is just the normal distance between a thing being described and a thing being operated. Every system we have built in this series has that distance. The decoder wall was never going to be beautiful. The Fairlight is never going to be intuitive for a first-timer. The Command Nexus is a room full of rack gear in an argument with the heat.

The Red Button will have the same distance. What matters is that the realistic version works, and that it works for somebody holding a pint.

Because here is the thing nobody tells you about live distribution: you do not get to know whether it worked. Not really.

Somebody in a truck has a meter. Somebody in a rack has a decoder. Even at the platform, there is a dashboard showing how many connections are open. But that dashboard tells you how many people are connected. It does not tell you whether they are watching, whether they can hear anything, whether the pub’s stream is buffering on their phone right now, or whether they gave up twenty seconds ago and are standing inside anyway.

Picture an event where the numbers look perfect all night and the whole thing was quietly broken for half of it.

Your own dashboard would have said the streams were healthy. Eight services, all locked, all delivering. And the entire audience experience would have been a buffering wheel on a windscreen, and you would not have known until somebody told you the next morning.

That is the strange position we are in: having built an entire system to make the audience’s experience good, we have less ability to observe the audience’s experience than we had at any point in the previous five posts. We could watch every decoder we ever built lock in real time. We cannot watch a stranger’s face when the video stalls.

I do not have a solution to that, and I have thought about it more than I expected to. The best answer I have found is the least technical one available: put a human being somewhere who can watch the chat, watch the platform, watch the reports, and pick up the phone when a venue says their viewers are struggling. In a town this size, that person could be the production coordinator, and they would have to be told, clearly, that watching the audience is now part of their job.

The mesh works. The services are healthy. The switches are correct. At some point, the only measurement that counts is whether somebody in a doorway can actually hear the band.

Which raises the other thing we recorded, and forgot about, while we were all busy watching rectangles.

Chapter 4: The Highlights Factory

Six HyperDeck ISO Recorder 100Gs are sitting in a room somewhere, writing everything, and nobody has said thank you to them yet.

We built that recording layer because it was the responsible thing to do — because “the performance happened once and the festival owns the material to tell the story again” is a principle you can sign up to without needing a reason. And then the live show happened, and the streams went out, and all of that carefully preserved material quietly became a storage problem with a capacity number attached to it.

Which is a shame, because it is the best material we have.

The two versions of the festival

Here is the distinction that makes this chapter worth writing, and it is easy to miss.

The live cut is one version of the festival. It is a curated sequence of decisions, made live, under time pressure, by a director who was also carrying sixteen other feeds and a running order and a production coordinator in their ear. It is the version we argued about in the previous chapter — the one where the small venue deserved more airtime and maybe did not get it.

The ISO recordings are every version. Every camera, every angle, every venue feed, every clean output, recorded continuously and without judgement. They contain the takes that were never selected. They contain the moments the director cut away from. They contain the band before soundcheck, the crowd arriving, the thirty seconds of somebody tuning a guitar badly before the good version.

The live cut is the festival as we understood it while it was happening. The ISO recordings are the festival as it actually was.

You cannot get the second one any other way. Once the live cut is mixed and sent, that editorial decision is permanent and unrecoverable — you can re-cut around it, but you can never recover the angle that went unused, because that angle was never sent anywhere.

That is what the recorders are for. Not as insurance. As memory.

A technical biography: why this archive is unusually easy

There is a specific reason the Blackmagic ecosystem makes this workflow pleasant, and it is worth describing because it is a genuine advantage rather than a branding claim.

The HyperDeck ISO Recorders record discrete, self-contained source files rather than a single mixed programme stream. Each recorder takes a source from the 100G IP environment and writes it as its own file — no matter that source being a camera, a programme, or a clean output. They land on the Cloud Store Ultra, which is a fast local storage system sitting in the same rack, not somewhere else on the internet.

So when a highlight editor opens DaVinci Resolve, the material is already there, already local, already accessible, and already in a form the software understands. There is no ingest queue, no overnight transfer, no file format negotiation. You are not pulling media from a NAS over a slow link at 2am. You are opening a project on the same machine the recorders wrote to.

The absence of a transcode step is the important part, and it is worth understanding why it is unusual. In a lot of broadcast workflows, the recorded files live in a format that your editing software would like to be something else, so you transcode on import — which takes time, generates heat, produces a second copy of everything, and occasionally produces a copy with something subtly wrong with it. In this workflow the recorded files are the files. The editor is choosing which of them go next to each other on a timeline, not preparing them for use.

That single property is what makes rapid turnaround possible at all.

What the ISO layer actually holds

It is worth being concrete about what is on those recorders, because the volume surprises people and the composition is more useful than the volume.

Six recorders, each capable of taking up to eight sources from the 100G environment. In practice that means the sixteen incoming venue contributions are all preserved as they arrived, alongside the central main programme, any clean or graphics-free outputs worth keeping, and possibly a selection of the outbound services. The theoretical channel count is enormous. The useful count is much smaller and depends entirely on the channel map somebody wrote before the show.

That distinction matters more here than it did in the truck, because in the truck the recording was insurance and insurance only has to exist. Here the recording is a working asset, and a working asset has to be navigable. Recording forty channels because the hardware could hold forty channels is not diligence — it is the same error as every other “we might need it” decision, dressed up as thoroughness.

The venues that record locally complicate this further, and rightly so. The Royal Hall’s camera files preserve far more than its SRT contribution can carry, because the contribution is a compressed programme feed and the local files are the raw sources. So there are two archives of the same evening at different fidelities, and they are not redundant. The central record shows what the audience actually received, including any compression artefacts. The local files show what the cameras captured. An editor working from both can replace an artefacted section from a source the audience never saw.

Keeping both is defensible. Keeping both and not knowing which is which is not, which is why the channel map is not paperwork.

Dead air kills audiences

The practical case for all of this is unglamorous, and it is the case that actually justifies the workflow.

A venue channel that goes silent during a changeover is a channel that loses viewers. Not eventually — immediately. If somebody has chosen The Black Lion and the band has finished and there is two minutes while the next one plugs in, and that channel is showing nothing, then the sensible thing they do is close the tab and go and stand in the actual pub. They may well come back, but you have lost them, and you have taught them that choosing the smaller venue is a slightly worse experience than choosing the main one.

And that is a genuinely corrosive outcome for the whole idea, because the small venues are exactly who the Red Button exists to serve.

So: something has to fill that gap, and it has to be from that venue, and it has to be ready immediately, without anyone in the Command Nexus going and making it.

Here is what you can make. A band that started well. A singer doing something you would not have got from the main cut. The room itself, packed, at the moment it packed. Ninety seconds of the best thing that happened at The Black Lion tonight, already cut, already graded, already sitting in the Media Player 10G waiting for the gap to happen.

The same trick works on the main programme, and for a different reason. When something goes wrong centrally — a contribution drops, a transition goes wrong, engineering needs ninety seconds — a highlights package on the main feed means the audience sees a piece of the festival rather than a holding slide telling them we will be right back. It buys the same ninety seconds. The difference is what the ninety seconds are spent looking at.

What “fast” means here

The temptation with highlights is to make them well. That is the wrong instinct for this use.

A festival highlight that plays in a changeover has one job: it must be ready now, and it must make the viewer glad they are watching this channel rather than the main one. It is not a documentary. Nobody is grading it. Nobody will ever see it outside the moment it was made for. Its entire lifetime is about two minutes on a venue channel between two sets.

So the edit is fast and it is rough and it does not matter. The thirty seconds that actually happened — the moment where the room went up, the bit where the crowd took over the chorus, the two bars where the band and the audience were indistinguishable. Cut around it. Two or three of those, strung together, get a title card, a level pass so it does not sound broken. That is a package, and it can be built in a few minutes by somebody who knows what they are doing.

The real skill is not in the editing. It is in the judgement about which thirty seconds. That is an editorial decision made by somebody who was in the room, or who was watching the feeds, and it cannot be delegated to a template.

The tension worth naming

There is a real conflict underneath this workflow and it is worth being honest about rather than smoothing over.

The live show demands immediate turnaround. Someone needs to spot a good moment, pull it, cut it, and have it ready before the next gap — which might be ninety seconds away and might be four minutes away and is never negotiable.

Post-production wants considered material. The good version of a festival film — the one somebody would pay to watch at a festival two years later — needs held shots, needs structure, needs the arc of a night rather than a pile of the best bits. That takes days, and it cannot be done by somebody who is simultaneously watching for gaps.

Trying to do both with one workflow means the fast version sets a standard the considered version cannot meet, and the considered version never gets made at all.

The honest answer is that they are different jobs with different deadlines, and they should not be done by the same person at the same time. During the festival, the live material is for gaps — fast, rough, disposable. Afterwards, the same archive is the raw material for something that will be made properly, by somebody with time.

What the archive must not do is get treated as though the second job will happen automatically. It will not. An archive nobody has ever looked at is not an archive. It is storage.

Archive first, edit later

And that is the part that connects this chapter to the cost chapter and the rant that follows.

The archive is the only part of this entire project that is yours.

Everything we have built — the mesh, the venue kit, the truck, the streams — is a means of producing something. The archive is the thing you produced. It sits on hardware you own, in a rack you own, in a building you control, in a format that DaVinci Resolve reads without complaint and that will still be readable in ten years when every platform and every codec from the year this was built has been retired.

The naming discipline for it is not complicated, and we covered the mechanics of it when we built the recording system: venue, service, date, time, source type. What matters here is not the exact scheme. It is that whoever comes back to this in three months — and it will be you, probably, at 2am, some years later, trying to remember whether that brilliant bit at The Black Lion was on channel 2 or channel 4 — can find it in under a minute.

The alternative is the default outcome, which is a Cloud Store holding six hundred files called something like Programme_20260909_1830.mov, none of which tell you which venue, which act, or whether it is the clean feed or the main cut. That is a real outcome. We have all seen it. An editor opening that folder and giving up is not a hypothetical failure mode; it is what actually happens.

So the naming is not bureaucracy. It is the difference between an archive and a cupboard.

A second life, and a caution

The archive does not stop at the festival, either.

There are uses for it that nobody plans for at build time and everybody wants afterwards. A venue might want clips of their own night for their social media. A local film maker might want to make something about the town. Somebody might want to know what a festival looked like two years ago. A future festival might want to show what came before it. The material is a resource with a much longer half-life than the live programme, and that is worth knowing when you decide how carefully to label it.

What is worth being careful about is the assumption that you will get to any of it. There is a particular kind of optimism in a plan that says “we’ll do the festival film afterwards”. There is a crew, there are costs, and there are a hundred other things that need doing. The archive is the thing that makes the film possible, not the thing that makes the film happen.

Which is really the argument of this whole chapter, stated plainly: we recorded it so it could be used, and using it is a separate decision that happens later and probably does not happen by itself.

It could quite honestly be that you end up in a situation where the ISO recordings are perfect, complete, correctly named, and never opened again.

That is the most common possible outcome. Not because anything failed — nothing failed, every file is there — but because using an archive requires somebody to decide to use it, and nobody was ever going to be on shift for that job.

Which brings us to the thing I have been putting off since Chapter 1, which is the number.

Chapter 5: The Bill

We have been circling this one since the beginning, and there is an obvious reason for it, which is that the number is genuinely large and genuinely awkward in a way that most numbers are not.

So here it is, and then we will spend the rest of the chapter taking it apart.

The full ladder

If you add up every tier we have specified across this series the total comes to £1,246,923.10.

The Royal Hall at £826,903.33. The Priory and The Spa Gardens professional tier at £149,628.61. The prosumer tier at £56,850.07. The Black Lion at £26,807.55. Sewerby Hall at £6,733.54. The Harbour Tavern and the South Beach pop-up at nothing, because they genuinely cost nothing. And the Command Nexus at £180,000.

Which is very close to the £1.2 million we mentioned at the start. That figure was not plucked from thin air and it was not a scare figure either. It is what it costs to demonstrate the entire ladder, at the spec we specified, all at once.

The caveat that matters more than the number

Here is the thing I actually want to say about that £1,246,923.10, and it is the most important idea in this entire series.

That total only applies if you build every venue exactly as we specified it.

This series has never been a shopping list. From the very beginning the point has been the spectrum — that a festival can range from a phone on a tripod to a four-camera 12K production with box lenses and pedestals, and that the difference between those two things is not quality of television but scope of ambition. We picked different kit for different venues on purpose. That was the demonstration. If we had specified identical kit everywhere we would have proved nothing except that we can copy and paste a spreadsheet, which is not a thesis.

The £826,903.33 Royal Hall exists to show what full certainty costs at the top of the ladder. It is not a recommendation. A festival with one good room and four phones is not doing it wrong — that is a festival making a decision about scope, and the decision is entirely legitimate.

What happens if you standardise

Here is the useful bit, and it is the bit I would put in front of anybody who read this series and felt slightly ill.

Take the Black Lion’s build — £26,807.55 per venue — and use it at every venue in the mesh. Seven venues at that price comes to around £187,653. Add the Command Nexus at £180,000 and you are looking at roughly £368,000 for an entire town-wide mesh with a capable, consistent specification at every venue.

That is a third of the full-ladder figure. And it is not a degraded festival. It is a festival where every room has proper cameras, proper audio, proper monitoring and a real production, and where the Royal Hall is a good stage rather than an immovable object with a protected set.

Or lean the other way. If your festival is genuinely small and community-shaped, you spend most of your money at the Black Lion tier and leave The Royal Hall at the Harbour Tavern configuration. If you have one enormous headline and six supporting rooms, you do the opposite. The spectrum is not a ladder you have to climb in order. It is a set of rungs and you choose which ones you need.

The costs that never make it onto a spreadsheet

But it would be dishonest to stop at the capital figure, because capital is the part that is easy to count.

Power draw is the first one. This entire system runs for six hours on the night. Cameras, switchers, the 100G fabric, six recorders, storage, conversion, monitoring, the computers, the audio — all of it converting electricity into pictures and heat continuously. And the Royal Hall tier alone has equipment that generates enough heat to change the room it is in. That cost does not appear on a kit list and it does not appear in the capital total, and it is real every single time.

Crew is the second one, and it is the one that surprises people most. Every tier in this series needs a director, a technical director, an audio engineer, a recording operator, a distribution operator, a network engineer, graphics and a production coordinator. Some venues will share roles — a small one might be two people doing four jobs — but the work does not disappear because you have combined the titles. It just becomes the job of fewer people who are more tired, which we spent an entire chapter in the truck talking about.

Transport and cases are the third. Those Duvo box lenses need specialist transport. Every camera, every pedestal, every case has to go there and come back. A rack that is reused across festivals becomes defensible over several years; a rack built once for a single weekend is a cost with a very short life.

Insurance, spares, connectivity, contingency — the ordinary overheads of running any event at all, multiplied by the number of venues and the ambition of each one.

And then there is the cost we have been carefully not mentioning until now, because it behaves differently from everything else: distribution egress.

Eco-Reality — the bill that arrives after the audience arrives

Every other cost in this series is known in advance. You buy the kit. The kit costs what it costs. You can look at it in a spreadsheet, plan around it, and stop when you have bought it.

Egress does not behave like that.

Egress is the cost of sending the data, and it scales with how many people watch. That means the most successful version of this festival is the one that costs the most to distribute — and the failure mode is not that you under-budget, it is that you succeed.

Think about what that does to a plan. You can model everything else in advance. You can say with confidence what the cameras cost, what the truck costs, what the crew costs. But nobody knows how many people are going to press play on the main programme at The Royal Hall at nine o’clock, and the distribution bill is a direct function of that number.

It also inverts the usual relationship. Every other system in this mesh gets cheaper per unit of value as it gets bigger — a bigger switch serves more sources more efficiently, a bigger archive costs the same to fill. Distribution is the opposite. The bigger your audience, the more you pay, and the more you pay for the privilege of having been right about the band.

There is a second environmental cost here that is not on anybody’s spreadsheet at all. The transcoding is compute. Every rendition in that ladder — every resolution, every rendition, for every service — is a machine somewhere doing work to make the same content watchable in eight different ways. That work exists only because the audience is distributed rather than co-located. And the reason we are all watching eight renditions rather than one high-quality feed is that our devices are scattered across a county on connections of wildly varying quality.

None of that makes it wrong. It makes it real, and it means the honest version of this festival’s footprint includes a compute cost that scales with reach — which is worth a great deal more thought than broadcast engineers usually give it, because it inverts the usual green argument. Bigger audiences are usually better on every environmental measure. Here, bigger audiences mean more compute and more network, and the environmental argument and the commercial argument point in opposite directions for the first time in this series.

Money does not buy magic

I want to land this properly, because “the bill” is a chapter that can easily slide into either defensiveness or cynicism, and neither is useful.

Money does not buy magic. It does not buy the moment where a folk duo in a pub back room turns out to be the best thing anyone saw all night, and nobody in the truck could have predicted it. It does not buy the fact that a stream from a phone and a stream from a 12K camera arrive at the hub as exactly the same rectangle. It does not buy the thing that makes a festival worth doing, which is that a town of this size produces an evening that no single room could have produced alone.

What money buys is options, headroom and certainty. That is genuinely worth having and it is genuinely expensive, and the price tag goes up steeply as you approach the point where the headline stage cannot fail under any circumstances.

That is a legitimate thing for a festival to want. Some festivals are funded for it and should spend it. The Royal Hall build is not a vanity purchase — it is a system that buys the ability to protect the most-watched two hours of the weekend.

But the trick is not spending the most money possible. The trick is spending enough to buy the level of certainty your particular show actually needs, and being honest about which level that is.

The Black Lion at £26,807.55 does not need a protected fibre path and a redundant power feed and a switcher with four M/Es. It needs good cameras, good audio, and somebody who knows what they are doing. That is what the money is for.

And the Harbour Tavern at £0 does not need anything except a phone that works and somebody who does not mind pointing it at a band. That is also what the money is for.

Same festival. Same mesh. Same hub, which cannot tell the difference between any of them.

That is the thesis, and the number is just the bill for demonstrating it.

The part where somebody asks me whether it was worth it

People do ask that. Sometimes it is a genuine question and sometimes it is a polite way of saying the number is too big, and both deserve a real answer.

The honest answer is that the £1,246,923.10 has bought a demonstration, and a demonstration has a specific and somewhat self-referential value. It exists to show that a tiered town-wide broadcast is technically coherent — that the ladder works, that the hub genuinely does not care, that a pub and a main stage can coexist in one mesh on equal terms. As an engineering argument, it succeeds completely. As a return on capital, it does not, and nobody sensible should pretend otherwise. Nobody is going to build a £1.2 million festival broadcast and get the money back.

What that means is that the full ladder was never a plan. It was a proof, and the proof is finished, and the festival it describes would cost whatever your festival actually costs.

The number that matters is not the one at the top. It is whichever rung you actually need.

And here is the thing I have found genuinely uncomfortable about writing this post: the money is the easiest part of the whole series to explain. It is a spreadsheet. The tier is a number, the total is a sum, the caveat is a sentence. Every venue is a budget, every budget is defensible, and the argument holds together.

The stuff that actually makes the thing work is much harder to talk about, and none of it is on the spreadsheet. It is that the Harbour Tavern volunteer who points a phone at a band is treated with exactly the same seriousness as the Royal Hall crew with four box lenses. It is that the person running the audio in a pub has a real production discipline around them rather than an apology. It is that a small venue’s set is given time because somebody in the Command Nexus thought it deserved time, rather than because it had the budget to demand it.

None of that appears in a kit list and all of it determines whether the festival works.

The tiering philosophy is not really about money. It is about what it says a small stage is worth. And the answer the system gives — a rectangle on a wall, indistinguishable, available to be chosen by anyone — is the most generous answer available to a venue that will never be able to afford the alternative.

Which leaves the question we have been avoiding all post, which is whether the thing that lets other people watch any of this is a thing we get to keep.

Chapter 6: ☕ Digital Sovereignty — A Jim Rant

Right. I have been building to this for the entire series, and I am going to try to get it out without being unfair, which I realise is going to be difficult, because the thing I am angry about is not stupid. It is well-built, competently run, and it works. That is almost worse.

Let me say the fair thing first

The Cloud Store Ultra is 48TB of storage hardware sitting in a rack in a building I have physical access to. Blackmagic sell it to me. I own it. My festival’s entire recorded night is on it, and if every company on earth went out of business tomorrow, those files would still be there in a shed in Bridlington, readable by any editing software that has ever existed.

That is genuinely, unusually good. I want to be clear about that because the rant that follows is not about pretending otherwise.

The camera manufacturers have been getting steadily worse about this for years. Buy a camera now and your footage lives on a card, the card lives in a camera, and the camera is leased, and the software that reads it requires an activation server, and the answer to “can I still open this in ten years” is increasingly a shrug. Meanwhile some companies will look at the footage on your drive, because their business model is not selling you storage. Their business model is knowing what you made.

The Cloud Store does not care what you made. It is a box of disks with a very good network interface. That is a genuinely radical thing in this industry and I would like it noticed before I complain about anything.

The turn

Here is where it turns, and I promise I get there eventually.

Everything I have just described is about your archive. The masters. The ISO recordings. The files that matter.

None of it is about the eight streams.

To get those streams to a stranger’s phone you need a distribution platform, and distribution platforms are rented. You do not run one. You rent access to somebody else’s, and the moment you do, your festival’s audience is subject to somebody else’s terms of service, somebody else’s pricing, somebody else’s moderation policy, and — this is the bit that should make you uncomfortable — somebody else’s decisions about what your content is and whether it stays up.

I own the best part of this project and rent the part that touches the audience. That is the deal. There is no version of this where you get to keep both.

The thing that actually makes me angry

I have watched this pattern from the outside for long enough to be bored of pretending I do not understand it.

It is never a single dramatic betrayal. It is never “they deleted your videos”. It is a hundred small reasonable decisions that each make sense on their own and add up to a completely different relationship than the one you thought you had.

A term changes so that things you uploaded as a condition of payment may be used for something new. A policy changes so that a category of content is treated differently. A feature is removed from a free tier — taken away, from people who are relying on it — and the replacement is worse but available. A sudden drop in reach, explained in a post that says nothing useful. And never any individual moment that you could point at and say “that was the day they betrayed us”, just a slow accumulation of decisions made by people who individually did not do anything wrong.

You never leave. That is the genuinely clever part and it is not a conspiracy, it is just how services work. Leaving is work. Migrating your archive is work. Finding another platform that does the thing you need, at a price you can afford, with the reach you currently have, is work — and the moment you start paying attention to that work, you notice how much you are relying on the current arrangement, and by then it is very hard to leave.

And through all of it, the language is always about convenience. Somebody always ends an email by telling you how much simpler their platform is, how much work they have saved you, how you should not have to think about any of this. And the thing they are actually describing is the fact that they now hold the only copy that matters, at the moment of maximum dependence, at a price they set.

That is not a conspiracy either. That is just a business model doing exactly what it was designed to do.

The apology I owe the small venues

Before I go further I want to say something uncomfortable, because the rant is easy and the honesty is harder.

If you had asked me a year ago whether a £0 pub should put its stream on a platform, I would have said of course not. Of course you keep your own stuff. I would have been confident, and I would have been wrong.

The Harbour Tavern runs on a phone and a laptop. The person running it is a volunteer, or nearly a volunteer. They do not have a compliance department. They do not have someone whose job it is to check terms of service for changes. They do not have the ability to migrate anything, because they do not know there is something to migrate until it is gone.

And the platform terms will apply to them exactly as they apply to me. A volunteer in a pub is not exempt from a moderation policy, an automated enforcement system, a takedown they do not understand or appeal, or a price change they cannot absorb. The person running the Harbour Tavern’s stream is the most vulnerable actor in this entire project and they are the one I would be least able to help if it went wrong.

That is the actual argument for sovereignty, and it is not a philosophical one. It is that the people with the least capacity to absorb a platform decision are the people a platform decision hits hardest.

The reframe

So here is where I land, and it took me embarrassingly long.

Convenience and control are not opposites on one scale. They are different axes entirely, and I spent years treating them as a single dial.

The useful move is to stop asking “do I own my distribution?” as though it is one question with one answer, and start asking it per-layer.

The archive: own it. Always. Hardware on your rack, files in a format that outlives the software, no dependency on anyone’s continued existence. This is settled, it is cheap relative to everything else, and the Cloud Store already does it.

The distribution: rent it. Absolutely rent it. Do not build a CDN. Do not host a video platform. Do not spend a month of your life and a meaningful fraction of your budget trying to be the person who serves video to a county from a spare room. You will lose, and you will lose in the specific way that loses in front of an audience.

Then know what you have signed up for. Know that the terms can change and you cannot vote. Know that your terms of reach and your cost are both set by somebody else. Know that the day you would want to leave is the day leaving is most expensive. And make sure that if that day arrives, the thing you are protecting is not behind that door.

That is the whole position. Own the archive, rent the pipe, never let the only copy live on somebody else’s disk. The masters are yours. The delivery is a service you are paying a stranger for, and you should treat it like one — use it because it is the right tool, not because it is where your stuff happens to be.

The bit I will actually remember

The thing I will remember about all of this is not the policies or the prices. It is watching somebody’s work disappear and not being able to do anything about it, and realising I had no idea how much of my own work was in the same position.

I found out after the fact. That is the part that stays. Not the loss — the lag. The weeks afterwards, finding out what had actually changed, which decisions had actually been made, and that the thing everybody would have told me was standard practice — everybody does this, everybody backs it up, it is fine — was a single point of failure that had been there the whole time, quietly, wearing a friendly face.

I was not angry at anybody. There was nobody to be angry at. That is the actual lesson and it is worse than being betrayed: the failure is not malicious, it is structural, and it will happen to you again if you do not build the alternative before you need it.

So build the alternative before you need it. That is genuinely all I have.

What this costs to hold both

It is tempting to present this as a free virtue — keep your masters, rent your delivery, feel good. It is not free and I would rather be honest than tidy.

Holding a real archive means hardware you own and space for it and somebody who understands what is on it. The Cloud Store does not fill itself, does not describe its own contents, and does not care whether the naming convention was followed. Keeping a second copy off-site — which is the actual protection, because a single Cloud Store in one building is one flood away from being an interesting story rather than an archive — costs bandwidth and storage and somebody’s attention every single time it runs.

And there is a subtler ongoing cost, which is the discipline. Sovereignty is not a purchase, it is a habit. The archive has to be labelled as it is written, not afterwards. The backup has to be verified, not assumed. The channel map has to exist before the show rather than being reconstructed from memory at midnight after one. None of that is expensive. All of it is easy to skip, and skipping it produces a folder of files that technically contains everything and practically contains nothing.

That is the trade I would make without hesitating, and I want to be clear that it is a trade rather than a victory. We are choosing to be dependent on somebody else’s infrastructure for the delivery of our festival, having decided — deliberately, with eyes open — that owning our own would cost more than it is worth. That is a reasonable engineering decision for a community festival. It is also exactly the kind of decision that looks reasonable right up until the moment it stops being reasonable, and the defence is not a better argument at the time. The defence is the archive, existing, somewhere we control, before we ever need it.

Your archive should be on your hardware. Your backup should be somewhere else. And the distribution can be somebody else’s problem, as long as you know precisely which somebody is holding what, and you have decided on purpose that it is acceptable.

Money does not buy magic. But it does buy the ability to walk away, and after this series, I think that is the part of the price tag that actually matters.

Now let us put the whole thing down properly.

Chapter 7: The Mesh, Wrapped

There is a particular quiet at the end of a build.

Not the quiet of an empty room — you have been in that room, you know it is not empty, it is full of warm racks and spinning fans and the smell of hot electronics that has taken twelve hours to build up. The quiet of a project that has stopped being a project.

Somewhere in this town, right now, if any of this were real, there would be a phone on a tripod in a pub that cannot afford a tripod, and a rig at The Black Lion that cost £26,807.55, and a room at The Priory, and a production environment at The Spa Gardens where sources and destinations are handled as a matter of course rather than as an adventure, and four cameras and four box lenses at The Royal Hall that could not fail. And a room somewhere — a room, not necessarily a truck, because the bandwidth is what matters and never the vehicle — with sixteen decoders lit up and eight encoders running and a wall of screens showing a town performing in seven places at once.

And every one of those feeds would arrive at that wall looking identical.

That is the thing. That is still, after all of this, the thing.

What we actually proved

It is worth stating plainly, because we have spent a long series and it is easy to lose sight of the argument.

We did not prove that you need a 12K camera. We did not prove that a festival needs a hundred thousand pounds to be broadcast. We did not prove that broadcast engineering is more important than editorial judgement, or that the main stage deserves the best camera, or that quality is a function of spend.

We proved that the ladder is permeable.

That is the whole claim, and it is a smaller claim than it sounds, and it took seven posts. That a venue can be anywhere on the spectrum from nothing to everything and still be part of the same broadcast. That the hub’s refusal to distinguish between sources is not a limitation to be engineered around — it is the design. That the moment you start building tiers of importance into the network, you have lost the thing that made it interesting.

Every venue in this mesh makes its own programme. The Royal Hall director chooses between four cinema cameras and knows why they cut when they did. The Black Lion team knows their room. The Harbour Tavern knows their audience is eleven people and their camera is a phone and they are going to point it at the band anyway, and their feed arrives at the hub as a rectangle indistinguishable from the headline’s.

And then one person — the director in the Command Nexus, or a stranger on a seafront with a pint — decides what to do with that undifferentiated set of rectangles.

That is where the editorial work is. That has always been where the editorial work is. The network does not make the decisions. It just makes every decision equally possible, which is the most a network can do.

The final image

The last cut has been made. The headline has finished. The applause has gone up and come back down and the stage crew are already coiling cables.

Across town, in a pub with no budget, somebody is closing a laptop. At The Black Lion, somebody is striking a small desk setup and packing a switcher into a case that will be opened again next weekend in a different room. At The Priory, the SDI runs are being tidied. At The Spa Gardens, somebody is checking that the IP environment has powered down in the right order. And at The Royal Hall, four cameras on four pedestals are being made small again by a crew that has done this before and will do it again.

In the Command Nexus — in the room, wherever it is — the rack is still warm and the monitoring wall has gone dark and somebody is coiling cable in the specific quiet way of people who are tired and satisfied at the same time. The Cloud Store is full. The live streams have stopped.

Somewhere, an editor is going to open that archive in six weeks and find something in it they did not know had been recorded.

And on a beach, in the dark, about forty people are walking back from the festival having watched the pub feed on their phones, because they heard that the back room was where it was happening tonight.

That is the whole thing. That is what £1,246,923.10 bought, if you were being silly enough to build the entire ladder — a town, on one evening, in a handful of rooms, doing several things at once and being watched by people who could not be in more than one of them.

What this series was for

I want to be honest about why I wrote it, because it has taken six posts and one very large spreadsheet to get to a point that could have been made in a paragraph.

The technical part was the easy part, and I loved it. The ladder is a genuinely beautiful idea and it works, and the moment where you realise a phone feed and a cinema feed are the same rectangle on a multiview is a real moment, and I have written a lot of this series just to be in that moment again with somebody.

But the thing I keep coming back to is that none of it is the point.

The point is that a festival is a thing that happens in a place. It happens in The Royal Hall and The Black Lion and The Priory and The Spa Gardens and Sewerby Hall and a pub called The Harbour Tavern and on a beach at South Beach, and none of those rooms are interesting because of what is inside them technically. They are interesting because a band played well in one of them on a Friday in a particular year, and somebody who was there remembers it, and nobody else ever will unless somebody records it and hands it back.

The network is not the story. The network is how the story gets to the people who were not in the room.

Which is why the last chapter of a series about infrastructure should end with a person on a beach, and not with a switcher.

A closing note on the fever dream

I have called this a fever dream throughout, and it has been, and I am aware that a fever dream is not normally something you plan carefully with a spreadsheet and a spreadsheet appendix.

But here is the thing about this one. Every single decision in it was a real decision. The camera really does cost that. The tier really does produce that result. The hub really cannot tell the difference. The egress really does scale with success, and the archive really is on your hardware while the audience really is on someone else’s.

None of the engineering was hypothetical. The festival is. And I have found that I do not entirely mind, because the festival is the part that would be worth doing.

So: a pub, a beach, a main stage, a room with a wall of screens in it, a man in the back room of The Black Lion who is about to play something good to eleven people, and a television somewhere with a phone next to it so that person can be heard by a county. Build it, test it, break it on purpose in a rehearsal, label every cable, and keep the only copy of it.

Thank you for coming along on this journey with me. Whilst the idea is just that an idea, and the mechanics of it all may be somewhat crazy, if my random thoughts help you then the weeks a months writing this series have been total worth it. 

If you have read the full series then there is one thing I’m pretty sure of… you deserve a pint for somehow keeping up with the meandering ramblings of a mad man with a blog.

Go to your local, support h up and coming band, have a pint. You have earned it.

---

Protocol Glossary — New For This Layer

Everything in this list is new to the series. SRT, NDI, SMPTE 2110, PTP, NMOS and Dante were all covered earlier, at the points where they first appeared.

RTMP — Real-Time Messaging Protocol. The push-based ingest most streaming platforms accept, and the natural output for our Streaming Encoder 4Ks. An encoder that can send RTMP can feed a platform directly. Its weakness is that it is an older protocol built around unreliable networks, which is exactly why SRT exists — so expect the two to coexist for a long time, doing similar jobs at different levels of paranoia.

HLS — HTTP Live Streaming. Apple’s segmented delivery format, and the reason a live stream survives a bad connection. Instead of one file that must arrive complete, the video is chopped into short segments and described by a playlist manifest that updates continuously. The player fetches segments as it needs them, which means a poor connection loses a little smoothness rather than losing everything.

DASH — Dynamic Adaptive Streaming over HTTP. The MPEG equivalent to HLS, and the reason you can pick one packaging approach without being at the mercy of one company’s ecosystem. Functionally similar, different ecosystem, worth knowing both exist.

ABR — Adaptive Bitrate. The transcoding ladder itself: one master stream turned into several renditions at different resolutions and bitrates, with the player choosing per segment based on current conditions. This is why a viewer on the seafront and a viewer at home can watch the same channel and both be satisfied, and why a festival does not need to guess in advance what its audience can carry.

CDN — Content Delivery Network. Distributed points of presence that hold copies of your content close to your audience, so the file does not travel the full distance from a single origin on every play request. Also the source of the cost that scales with your success, which is the entire reason it is discussed at length above.

WebRTC — Low-latency browser-based video transport. Genuinely useful for two-way contribution where someone in a studio needs to see and be heard by someone in the field with minimal delay. Deliberately not part of this design: our contribution is one-way and already handled well by SRT, and our delivery does not need sub-second latency, so adding it would be a solution to a problem we do not have. Worth knowing about so that you recognise when it is the answer — which is usually when a presenter is having a two-way conversation across a distance.

Egress — The cost of data leaving a service. The one line item in this entire series whose size is determined by an audience rather than by a purchase order, and therefore the only cost that gets more expensive when the festival works.