How we make a WNGLTS live stream: the invisible technology behind three hours of watching the sky

From the outside it can look simple enough: a camera, a tripod, an internet connection and aircraft going past.

And in a way, it should look simple. If all you notice when you join a stream is an aircraft emerging out of the haze, the sound of engines spooling up and a steady image, that means everything else is doing its job properly.

Because there is quite a lot of "everything else".

Every WNGLTS broadcast means temporarily deploying a small audiovisual production environment, setting up communications, checking the stability of the connection, preparing video and audio, bringing up our information systems, and making sure that the whole thing can keep running for several hours without interruption.

And doing it outdoors. With wind, with heat, with cold, with the light changing, and — many times — without the option of saying "let's stop for a moment".

In this article we want to open the hood and show you how a live stream is actually built. We won't be going into specific equipment models, telecom operators or exact locations, because some of that is part of how we operate and we'd rather keep it in house. But we will go into something we find far more interesting: how the pieces fit together so that the image reaches your screen.

A live stream starts long before the record button

The first important decision has nothing to do with technology. It has to do with the air.

Before each broadcast we look at how the airport is expected to be operating: which runway configuration is likely, how the wind is behaving, where the sun will be at each hour, what kind of traffic we can expect, and which time slot makes the most sense.

Madrid-Barajas is a big airport with a lot of character. A position that is superb for watching certain approaches can become far less interesting if the operating configuration changes. And a spot that works perfectly in mid-afternoon can turn into a problem once the sun starts dropping right where we wanted to be looking.

None of those variables is under our control. All we can do is read them properly and adapt.

So before heading out, we spend some time deciding which setup makes the most sense for that particular broadcast. Sometimes the conclusion is "not today". That is a technical decision too.

Meanwhile, another part of the stream is being prepared in front of a keyboard: the YouTube event, the title, the description, the thumbnail, the information our systems will use, and the graphic elements that will appear during the broadcast.

By the time we arrive at the location, a good part of the stream is already built. But everything else still has to be put up.

A small television studio that travels with us

We don't have a permanent installation. There is no shed with equipment waiting for us, no rack sitting powered up next to the runways. Everything we use arrives with us and leaves with us.

That single fact shapes every technical decision we make.

Each element has to meet three conditions at once: do its job well, be transportable, and be possible to set up and take down in a reasonable amount of time. An excellent piece of equipment that takes an hour to become operational is no use to us. A lightweight one that falls over with the first gust of wind is no use either.

The result is a system designed to deploy quickly: camera, supports, production system, audio, communications, power, cabling, and a surprising number of auxiliary items that never appear on screen but without which there would be no broadcast.

There is also a rather unglamorous part to all this: organisation. Knowing exactly what goes in each bag, in what order everything is assembled, and what connects to what isn't fussiness, it's what makes a setup repeatable. In an environment where the light fades, the wind picks up and the traffic doesn't wait, muscle memory is worth as much as the equipment itself.

Following an aircraft is nothing like shooting a locked-off shot

The main camera occupies, logically, the central position in the setup. And in spotting it faces a difficulty that doesn't exist in most broadcasts: the subject moves fast, is far away, and appears from different directions.

We can't calmly set up a frame and wait for something to happen inside it. Here the frame is built while the aircraft is already moving.

During a landing we might start following an aircraft that is still several kilometres out, hold it through the entire approach, follow it down to touchdown, and continue through deceleration and taxi. On a departure it's exactly the opposite: we start relatively close, with the takeoff roll filling the frame, and end up following an object that is moving away at speed.

Camera, lens, support and operator therefore form a single system. If one of those four fails, you notice immediately.

There's a detail that tends to surprise anyone who hasn't worked with long focal lengths: errors are multiplied. A tiny movement, essentially invisible in a wide shot, becomes obvious shake when you're working at heavy zoom. Mechanical stability and smooth movement matter as much as the image quality of the sensor.

So when you see a clean track of an aircraft coming in over the threshold, there's technology behind it, but there are also a lot of hours of craft.

From the camera to the production system

The video signal doesn't travel directly from the camera to YouTube. It goes through our field production system first.

You can picture it as a small portable control room. It's the point where the image, the audio and everything else come together before the final signal we send out to the internet is assembled.

Having that intermediate layer gives us three things we consider essential: control over what goes out, visibility of the state of each source, and the ability to react without touching the camera. If something starts behaving oddly, we can see it before it reaches your screen.

WNGLTS normally broadcasts in 4K, and that adds a significant layer of complexity.

A signal at that resolution carries far more information than a conventional broadcast. And spotting happens to be one of the most demanding kinds of content there is for a video codec: fast movement, small details at long range, complex backgrounds and, very often, skies with smooth gradients where any aggressive compression shows up immediately.

To keep the image reasonably clean we need to generate a demanding video stream and, above all, sustain it consistently for hours.

And that's where our biggest challenge appears. It isn't the camera. It isn't the codec.

It's the internet.

The problem with broadcasting from somewhere there is no internet

In a studio you order a fixed line and then more or less forget about it. We don't have that option: we broadcast from where the aircraft are, not from where the fibre is.

Our connectivity depends on wireless networks, and a wireless network doesn't behave like a fixed connection.

The signal bars on a phone are only part of the story, and probably the least relevant part for us. For a broadcast we need something considerably harder to get: stable, sustained upload capacity over a period of hours.

Those are two different things that get confused all the time. A one-off speed test can give an excellent result, and twenty minutes later the situation can be completely different. Network congestion, the number of users connected in the same area, the radio conditions at that moment, or even a small change in our position can all affect performance.

When you're sending high-resolution video continuously, a sustained drop in upload capacity isn't a minor inconvenience: it can mean loss of quality, freezes, artefacts, or the broadcast going down altogether.

That's why communications are a critical part of the deployment for us, not an accessory. Before we start we run tests and monitor how the connection behaves, and the architecture is designed so that alternatives exist if the primary path stops offering the conditions we need.

We also accept something that may not be obvious: in certain situations we would rather reduce the demands of the broadcast than risk losing it.

Because streaming comes with a fairly simple rule. A spectacular image that doesn't reach the viewer is worth nothing.

A stable stream at lower quality always beats a perfect stream that dies after twenty minutes.

The sound is the airport too

This is one of the questions we get asked most often: why can't you hear the communications between the tower and the aircraft, the way you can on channels from other countries?

The answer is straightforward, and it has nothing to do with our preferences: in Spain, regulations do not allow aeronautical communications to be rebroadcast. They aren't transmissions addressed to the general public, and distributing them falls outside what the law permits. In other countries, the United States being the best-known example, the legal framework is different, and that's why you'll find channels that do include them.

So what you hear on a WNGLTS stream is the real sound of the place: engines, reversers, wind, taxiing, and whatever ambience exists around us at that moment.

Over time we've become convinced it's better this way. That ambience is a large part of what makes a spotting stream feel like being there. But capturing it well is anything but trivial.

Aircraft can be very far away, while other sounds are much closer. We work outdoors, where wind quickly becomes the worst enemy of any microphone. And the dynamic range is enormous: we can go from near silence to the full power of engines spooling up in a matter of seconds.

The aim of the audio treatment is to strike a balance: to bring you closer to the aircraft without the result sounding artificial. To keep the difference audible between something still far out and something passing right overhead. To have the sound accompany the image rather than compete with it.

And there's a detail you only notice when it fails: image and sound have to stay in sync across the entire chain. From the moment an aircraft passes in front of us to the moment it appears on your screen, the two have travelled through several different systems. Arriving together at the end is one of those things nobody applauds, but which everybody spots instantly when it breaks.

The information on screen doesn't come from the camera

One of the elements that has evolved most at WNGLTS over the past few months is the information layer.

When a piece of flight-related data, weather information or a channel notice appears on screen, that element isn't being generated by the camera. There's a completely separate infrastructure behind it.

WNGLTS runs its own services that retrieve, process and present information from a range of sources. A good part of our graphics actually runs on technologies very similar to the ones you'd find behind any modern web application.

We like to explain it by splitting the stream into two worlds.

On one side there's the audiovisual environment, which captures and produces: camera, audio, vision mixing, encoding, transmission.

On the other side there's the data environment, which prepares the information we want to show: receiving, filtering, normalising and transforming it.

The two worlds meet at the production system, where the output of the second is composited as a graphics layer over the video from the first.

This separation has an enormous advantage, and it's the reason the on-screen information has changed so much in so little time: we can develop new features without touching the camera or replacing the production system. If we want to change how a piece of data is displayed, create a new information card or add a function, most of the work happens in software and can be tested calmly at home before it ever goes near a live broadcast.

It will keep changing. It's probably the part of the project with the most room to grow.

When the airport becomes data

There's an important difference between knowing that an aircraft is approaching and turning that event into information a system can actually use.

The data we work with can come from different origins, not always in the same format, not always with the same refresh rate, and not always with the same reliability. That last point is key: on a live stream, showing an incorrect piece of data is worse than showing nothing at all.

Our backend acts as the intermediary. It receives the information, selects what we actually need, processes it, and hands the graphics environment only what is going to be used on screen.

That way we avoid having every graphic element talk directly to multiple external services, and we gain something very valuable during a broadcast: a single place to look when something doesn't add up.

Simplified considerably, the path looks something like this:

data sources → WNGLTS services → processing → graphics interface → production → live

That separation also lets us keep building. The same ecosystem could eventually feed parts of wnglts.live, internal tools, new stream features or other projects.

What started out as "putting information on top of the video" is gradually turning into a small platform.

The pre-flight check: looking at what the viewer actually gets

Once video, audio, data, graphics, communications and power are ready, we reach one of the most important moments in the whole process, and also one of the least exciting: checking the complete system.

We go through camera signal, framing, audio, connectivity, graphics and broadcast status. And we check something that might sound obvious but turns out to be essential: what the viewer is actually receiving.

Because our local output can be working perfectly while a problem exists at any later point in the chain. Looking only at the production monitor is a remarkably effective way to have a problem without knowing about it.

That's why, during a broadcast, we aren't only watching aircraft. There's continuous technical supervision going on as well: transmission status, network stability, video behaviour, audio, platform.

While someone is tracking an aircraft that has just started its takeoff roll, there are systems working in the background so that you can see it a few seconds later.

The silent enemy: power

There's one more thing we need, and out in a field it doesn't exactly come out of a wall socket.

Cameras, the production system, communications and everything else draw power continuously for several hours. Endurance isn't a last-minute detail: it's one of the constraints that shapes the design of the entire deployment.

And it isn't enough to calculate how long a battery lasts under ideal conditions, because ideal conditions don't exist. You need margin, you need to account for different loads, and you need to be able to swap or feed certain components without interrupting the broadcast. A battery running out is a problem. A battery running out exactly when the interesting traffic starts arriving is a story that gets told for months.

There's also a piece of arithmetic that works out worse than it looks: a three-hour broadcast means considerably more than three hours of runtime. Setup starts earlier, the tests consume power, and the system has to be fully operational before the countdown appears on screen.

The stream starts, and nothing stays still

When we finally hit the button, the part you see begins. But technically the work doesn't stop. If anything, it intensifies.

Over the following hours the conditions can change completely. The light shifts. The wind picks up. The airport configuration changes and traffic stops arriving from where we were pointed. The connection degrades. A data source fails. A shot needs reframing or an element of the production needs rearranging.

And all of that has to be dealt with while affecting you as little as possible.

That's probably the biggest difference between producing a video and producing a live stream.

In a video you can stop, redo, fix and re-edit. Live, everything happens while you're watching. The mistake, if it comes, comes with an audience present.

It's also, honestly, a big part of what makes this so addictive.

How long does an image actually take to reach you?

When we watch an aircraft pass overhead and then read a comment from you about that same aircraft almost immediately, we're actually looking at two slightly different moments in time.

There is latency. Always.

The camera captures the image and converts it into a signal. The production system processes and encodes it. It's then broken into data that crosses a wireless network, travels across various internet networks, arrives at the platform's infrastructure, is processed again there, and is finally distributed to your television, computer or phone.

All of that happens in a matter of seconds.

When you stop to think about it, it's still fairly remarkable. An aircraft can be lifting off from Madrid while its image is being encoded some distance from the runway, sent by radio to an antenna, carried across the internet and redistributed simultaneously to viewers who might be a few kilometres away, or thousands.

Every second of latency is, in reality, a great deal of work happening very fast.

And when it's over, the studio comes down

When the stream ends, all of it disappears.

We shut down the broadcast and pack up the camera and supports, communications, power, audio, cabling and production systems. The small studio we built over the course of a few hours turns back into a set of bags and cases, and the spot is left exactly as we found it.

But the digital infrastructure stays up.

Servers, web services, automations and internal tools keep running, processing and preparing the ground for the next broadcast. That part never gets packed away.

Because WNGLTS is less and less a camera plugged into YouTube, and more and more a small technological ecosystem built around live aviation.

What comes next

A good part of the project's evolution is happening precisely behind the camera.

We're working on improving the redundancy of our communications, expanding what the production setup can do, continuing to develop the on-screen information, and making our systems more autonomous and more automated.

Some improvements will be obvious from the very first stream. Others you'll probably never notice.

And, somewhat paradoxically, those tend to be the ones that worked best. Because when all this technology does its job properly, what it's supposed to do is disappear.

In the end, what we're after is something very simple: that you sit down in front of a screen, hear the engines rising, watch an aircraft appear out of the haze, and for a few minutes feel like you're out there with us.

Everything else — cameras, networks, servers, code, graphics, batteries, protocols and an indecent number of megabits travelling across the internet — is simply working to make that happen.

See you on the next stream!