Media Servers 101

Introduction

Behind the band, behind the keynote speaker, behind the actor on a film stage, there is a wall of light showing something somebody made months ago. A media server is what puts it there, at the right moment, in the right shape, without a frame missing.

This book is that machine and the work around it: the content and the codecs that actually play, the canvas that describes the screens, the mapping that fits one to the other, the timeline and the cues, the clock everything runs to, and the hour before doors when every clip is checked one more time.

What this book covers

• What a media server is, where it sits, and its three jobs: store, play, map.
• The machine itself — why it is not a laptop, and what actually limits it.
• Content: playback codecs, resolution, frame rate, alpha, and the specification you send a designer.
• The canvas, layers, and mapping content onto walls, projectors and objects.
• Outputs, EDID, the LED processing chain, warping and soft-edge blending.

• Timelines against cue lists, and triggering from timecode, MIDI, OSC, DMX and Art-Net.
• Genlock, frame sync, tearing and latency through a video chain.
• Playing to camera: refresh, shutter, scan, moiré and film frame rates.
• Live inputs, generative content, previsualisation and redundancy.
• Pre-flight checks, troubleshooting playback, rehearsal discipline and archiving a show.

Who this is for

Video technicians moving towards screens work, operators handed a server for the first time, and anybody who has been asked why the wall is stuttering. It assumes LED Video Basics for what a wall is made of and Video Switching & Screen Management for how sources reach screens.

How to Use This Book

Read it once through, then take one chapter at a time to a real machine. The order follows the work: what the server is, what it plays, where it plays it, when it plays it, and what keeps it playing.

Test everything on a machine

Nearly every chapter can be practised on a laptop with a free or demo version of a server platform. Build a canvas, import a clip in the wrong codec and watch it stutter, re-encode it and watch it stop. Ten minutes of that teaches what a paragraph cannot.

Keep a notebook

Write down which version of each piece of content is on the machine and where it came from, the output map and the resolution of every screen, the cue numbers and what each one fires, and how long a render actually took. Content changes right up to the show, and the only way to know which version is on the wall is to have written it down.

A note on the words

Every platform names things differently: canvas, stage, screen, output region; layer, track, clip, media object; timeline, sequence, cue list. This book uses the words most widely understood and names the alternatives where they matter, because the ideas are the same on all of them.

A note on safety

Media servers live in racks near power, under rigs and beside LED walls that other people hang. Nothing here qualifies you to rig a wall, to work at height or to do electrical work. It teaches you to recognise the hazards, work within your training, and stop work that is unsafe — and to remember that a bright wall pointed at an audience is itself worth thinking about.

Where this book sits

This book assumes LED Video Basics for what a wall is made of and Video Switching & Screen Management for how sources reach screens. It does not assume you have ever run a server on a show.

What pairs with this

• Show Control Fundamentals — the clock and the triggers that drive your playback
• LED Video Basics — the wall your canvas has to match

Where it leads

These are not steps in an order. Take whichever one fits.

• Media Servers Intermediate — deeper programming, larger canvases and harder shows
• Media Server Mastery — the full craft, at the scale where servers become the show
• Virtual Production Fundamentals — the LED volume, where a wall becomes both lighting and background

What a Media Server Is

A media server is a computer with one job taken very seriously: put the right pixels on the right screens at exactly the right moment, for hours, without missing a frame. Everything about it — the hardware, the software, the file formats — follows from that one requirement.

A media server is a specialised computer that stores show content and plays it to the screens, perfectly on cue.

The role of a media server

A media server is a powerful, specialised computer built to store video content and play it back to displays — LED walls, projectors, and screens — reliably and precisely on cue. At a concert, the towering visuals behind the band; at a corporate event, the branded content and presenter graphics on the big screen; at a broadcast, played-in video elements — these come from media servers. It sits in the video system between the content (the prepared media files) and the displays, feeding them exactly the right pixels at exactly the right moment.

In the source-processing-destination model, the media server is a powerful source-and-processor: it holds the content (source) and processes it — scaling, mapping, sequencing — before sending it to the displays (destination). It bridges the creative world of content and the technical world of screens, which is why it is grouped under creative technology and why media server operators blend technical and creative skill.

In the signal chain it is both a source and a processor: it holds the content, decides what appears where, and sends finished pixels onward to walls, projectors and screens. Everything upstream of it is preparation and everything downstream is distribution.

It is also the place where the creative side of a show meets the technical side. The content came from designers thinking in stories and colours; the screens are panels, processors and cables. The server operator lives between those two worlds and has to speak both languages.

The three core jobs

Everything a media server does falls into three jobs. It stores content — a library of video clips, images, and graphics prepared for the show. It plays back that content — on command, on a timeline, or triggered by cues, reliably and in sync. And it maps the content to the screens — placing and shaping the media so it fits the specific arrangement of LED panels or projectors, which is rarely a simple rectangle. Storing, playing, and mapping are the heart of what a media server is for.

These jobs make the media server far more than a video player. A consumer media player just plays a file to one screen; a media server plays show-critical content, on precise cues, mapped across complex multi-screen canvases, with the reliability a live show demands. Understanding these three jobs frames everything else in the book: the content and canvas (what is stored and where it goes), mapping (fitting content to screens), and playback (running it on a show).

Store: hold a library of prepared media, organised so that the right clip can be found under pressure. Play: deliver it on a timeline or on a cue, reliably, in sync with everything else. Map: place it onto a screen arrangement that is rarely a simple rectangle.

Every feature on every platform serves one of those three. When a menu makes no sense, ask which job it belongs to, and it usually resolves.

Say them as one phrase — store, play and map — and use it as a filing system. A question about codecs is a store question. A question about timecode is a play question. A question about a wall's geometry is a map question, and knowing which one you are being asked is most of answering it.

Why not a laptop

A laptop playing a video file is doing something superficially similar and fundamentally different. It has no frame-accurate cueing, no genlock, no redundancy, no mapping, an operating system that will decide to update itself, and storage that cannot sustain a high-bitrate stream for two hours.

This matters because somebody will always suggest it, usually to save money, usually the week of the show. The answer is not snobbery: it is that a show-critical playback machine needs guarantees a general-purpose computer does not make.

Where servers turn up

Concert touring, corporate conference, theatre, houses of worship, broadcast, exhibitions and museums, theme parks, and film and television — where a server drives an LED volume behind actors. The vocabulary changes between them and the machine does not.

Each sector adds one constraint. Touring adds speed and repetition; corporate adds presenters and last-minute content; theatre adds cue stacks and a stage manager; film adds cameras, which see things people do not.

The three jobs, and where each one goes wrong

Almost every media server problem is one of these three failing.

On the job

A conference producer asks why the presentation laptop cannot drive the main screen directly. It can — until the operating system decides to check for updates during the keynote, the screen resolution resets between presenters, and nothing can be cued to the timecode the lighting desk is already following.

What goes wrong

Practice it

Look at any screens show you can get near.

The Machine Itself

It is worth knowing what is inside the box, because the limits of the machine are the limits of the show. Every stutter, every layer you cannot add and every output you cannot drive comes back to one of four things: processing, memory, storage or outputs.

What actually limits a server

Graphics processing decides how many layers, effects and pixels the machine can compose in a frame's time. Storage speed decides whether high-bitrate content can be read fast enough to keep up. Memory holds what is being worked on. Output hardware decides how many screens, at what resolution and refresh, can be driven at once.

When a machine stutters, one of those four has run out. Knowing which is the difference between solving it and buying something expensive that does not help.

Outputs and what they can carry

A server's outputs are ordinary video connections with extraordinary expectations: exact resolutions, exact refresh rates, no re-negotiation mid-show. Many servers also carry dedicated capture inputs and a genlock connection so that everything they output is timed to the rest of the system.

Count the outputs you need early: one per projector, one per LED processor input, plus what the preview and the backup need. Running out of outputs is a purchasing problem discovered on site far too often.

Storage, and where content actually lives

Show content lives on fast local storage, not on a network share, not on a portable drive hanging off the back of the machine, and not on the desktop of somebody's laptop. The transfer happens in advance; the playback comes from the drive the machine was built around.

Leave headroom. A drive that is nearly full behaves worse than an empty one, and a show that grows by a few large clips a day fills a drive faster than anybody expects.

Servers come in sizes

The same platform often runs on a range of machines: a small unit driving one or two outputs for a corporate breakout room, a mid-range machine for a conference or a club, and a large chassis with many outputs and capture cards for an arena or a volume.

The show file is usually portable between them; the performance is not. Programming on a small machine and running on a large one is normal; promising a small machine the workload of a large one is not.

Keeping the machine boring

• No automatic updates, ever, and certainly not during a show week.
• No other software running, no browsers, no messaging apps.
• Power from a protected supply, with the machine's own shutdown behaviour known.
• Fans and filters clean; a hot server throttles and a throttled server stutters.
• A written note of the machine's build: version, drivers, licences, plug-ins.

What limits a server, and the symptom of each

Diagnose which one you have run out of before changing anything.

How to do it

1. Confirm the platform version matches the one the show was programmed on.
2. Disable automatic updates and anything that starts by itself.
3. Check drive space and clear old shows onto an archive drive.
4. Copy the current content to local storage, not a network share.
5. Check every output against what it will actually feed.
6. Set up genlock if the system uses it.
7. Play the longest, heaviest clip end to end and watch for dropped frames.
8. Record the machine's build details with the show file.

What goes wrong

Practice it

On any machine you can use as a server.

Content & the Canvas

Two things decide whether a media server show works before anybody presses play: whether the content is in a format the machine can actually stream, and whether it was made for the shape of the screens it has to fill.

Great playback starts with the right content prepared for the right canvas.

Content and codecs

The content a media server plays is prepared in advance — video clips, animations, images, and graphics created by content designers to the show's specifications. A crucial technical point is format: media servers need content in codecs (compression formats) designed for smooth, reliable playback, which are often different from the codecs used for streaming or delivery. Content in the wrong codec may stutter, fail to play, or overload the server, so part of the job is ensuring content is in a server-friendly format at the right resolution. Getting clean, correctly formatted content onto the server is the foundation of reliable playback.

Managing the content library matters too: organising clips so the right media is found and triggered correctly, versioning content as it is updated before a show, and checking every piece plays properly. A media server show can involve a large library of content, and the discipline of organising, formatting, and checking it — much like warehouse prep for gear — prevents the playback failures that come from disorganised or bad media.

Delivery codecs — the ones used for streaming, download and web video — squeeze a file small by making every frame depend on the frames around it. That is efficient to transmit and expensive to decode, and it is exactly wrong for a machine that may have to start at any frame, instantly, on cue.

Playback codecs go the other way: each frame stands alone, files are large, and decoding is cheap. That is why show content arrives as a very big file and why the first question about any clip is what it was encoded as.

The canvas and resolution

The canvas is the total pixel space of all the screens the media server feeds, treated as one big surface. An LED wall built from many panels, or several projection surfaces, together form a canvas of a certain total resolution and shape — often very wide, very large, or an unusual non-rectangular arrangement. The media server works in this canvas: content is placed onto it and then sent out to the physical screens. Understanding that the screens form one large pixel canvas, often far bigger than standard video, is key to understanding mapping.

Because the canvas can be enormous and oddly shaped, content is usually created specifically for it — at the right total resolution and aspect, designed to fit the actual screen layout. This is why content and the canvas are tightly linked: a clip made for a normal 16:9 screen will not naturally fill a 40-foot-wide curved LED wall. The media server and the content designer work to the same canvas specification so the content fits the screens it will live on.

The canvas is the whole pixel space of the show, laid out as the screens actually sit. A wall five panels high and twenty wide, a pair of side screens and a projection surface are all one canvas with regions in it, and content is placed onto that canvas rather than onto any individual screen.

Build the canvas from the real panel map, not from an idea of it. The map comes from whoever configured the LED processing or the projection, and checking it against the physical wall is worth doing before content arrives.

Resolution, frame rate and bit depth

Content is made at a resolution, a frame rate and a bit depth, and all three should match what the show runs at. Content at the wrong frame rate will judder however powerful the machine is, because frames have to be invented or thrown away to fit.

Resolution should match the canvas region the clip will fill, not a standard broadcast size. A clip made at 1920 by 1080 stretched across a wall eight thousand pixels wide is soft, and no amount of scaling in the server will put detail back.

Alpha channels and layered content

An alpha channel carries transparency, so a logo, a lower third or a flying graphic can sit over a background layer without a black box around it. Not every codec supports alpha, which is one of the commonest reasons a clip looks wrong on the wall and right on the designer's machine.

Where alpha is needed, say so in the specification. Where it is not, do not ask for it: alpha costs file size and decode effort on every frame.

The content specification

The way content arrives correct is that somebody wrote down what correct meant: canvas size and the pixel dimensions of each region, frame rate, codec, bit depth, whether alpha is required, colour space, naming convention, and the deadline.

Send it before anybody starts animating. A specification agreed early costs an email; the same information delivered after the content is made costs a re-render, and re-renders always land on the day you have least time.

Managing the library

Name files so that sorting them alphabetically sorts them usefully, carry a version in the name, and keep exactly one folder that is current. Everything superseded moves to an archive folder in the same move that the new version arrives.

Then check every clip, individually, by playing it through — not by looking at a thumbnail. Content that is the wrong length, has a black frame at the head, or stops two seconds early is found here or found in front of an audience.

What a content specification has to say

Send this before anybody starts work. It is one email and it saves a re-render.

How to do it

1. Check the file names against the naming convention.
2. Check resolution, frame rate and codec on every file, not a sample.
3. Copy to local storage and play each clip end to end.
4. Watch for black frames, wrong lengths and hard cuts at the head or tail.
5. Check anything with alpha against a background, not against black.
6. Move superseded versions to the archive folder in the same pass.
7. Note anything wrong and tell the designer once, as a list.
8. Back up the current folder before rehearsal.

What goes wrong

Practice it

Take one clip and one screen arrangement you can measure.

Mapping to Screens

Mapping is the act of telling the server where the screens actually are. Content lives on a canvas; the canvas has to be cut into the pieces that each physical device expects, in the order and shape that device expects them.

Mapping is the media server's signature skill: making content fit any arrangement of screens.

What mapping is

Mapping is placing and shaping the content from the canvas onto the actual physical outputs and screens. Real shows rarely have one simple rectangular screen; they have LED walls of specific pixel dimensions, multiple screens in different positions, curved or irregular arrangements, and projectors covering surfaces. Mapping tells the server which part of the canvas goes to which output and screen, so the content lands correctly across the whole arrangement. It is the step that turns a flat content file into the right pixels on each physical panel.

This is the media server's defining capability and a big part of why it exists. Getting mapping right means content appears seamlessly and correctly across a complex screen layout; getting it wrong means content is offset, stretched, split incorrectly, or on the wrong screen. The operator configures the mapping to match the exact physical screen setup, which is why understanding the canvas, the outputs, and the physical screens together is essential.

Two questions: which part of the canvas does each output carry, and what does the device on the end of that output do with it? Answer both and the content lands where it should. Get either wrong and the picture is offset, doubled, stretched or missing.

Mapping is also where an oddly-shaped wall becomes manageable. Panels in an arc, a strip above a door, three separate columns: all of them are regions of one canvas, positioned so that content crosses them as the designer intended.

Outputs, processing, and projection

The media server sends its mapped content out through video outputs to the screens — to LED processing (which drives the LED panels) or to projectors. The number and resolution of outputs must match the screen setup, and the server's processing handles scaling and arranging content to fit. For LED walls, the server feeds the LED processing that maps pixels onto the physical panels (connecting to the LED Engineering world); for projection, additional techniques like edge blending (seamlessly overlapping multiple projectors) and warping (shaping the image to fit a surface) come into play.

You do not need to master advanced projection mapping at this level — that is a deeper specialty. What matters here is understanding the path: content on the canvas, mapped to outputs, sent to LED processing or projectors, appearing on the physical screens. Recognising how the media server connects to the display systems (LED processing, projectors) shows where media servers sit alongside LED and projection skills in the creative technology world.

Projection adds geometry. A projector rarely sits square to its surface, so the image is warped to fit, and where projectors overlap their edges are blended so the overlap does not read as a bright band.

Both are done in the server, in the projector, or in a dedicated processor, and it matters which: whoever owns the geometry owns the alignment, and two devices both trying to correct the same thing fight each other.

Outputs, resolutions and EDID

Every output runs at a resolution and a refresh rate that the receiving device has to accept. EDID is how a display tells a source what it can take, and a server that listens to a changing EDID mid-show is a server that changes resolution mid-show.

So outputs are pinned: the mode is set deliberately, EDID is managed or emulated, and nothing is left to negotiation. This is why video systems contain boxes whose entire purpose is to hold an EDID steady.

The LED chain

Between the server and the panels sits an LED processor, which takes a video signal and distributes it across the panels through data cables, according to a panel map somebody built. The server's output is a rectangle; the processor turns it into the wall's actual arrangement.

This means two maps must agree: the server's idea of the region, and the processor's idea of the panels. When a wall shows the right content in the wrong places, that disagreement is almost always the cause.

Soft-edge blending in practice

Blending works by fading the overlapping edges of two projectors so that their combined brightness is even. It needs the projectors aligned first, matched in brightness and colour, and the overlap wide enough to blend smoothly.

Black level is the giveaway: in the overlap, two projectors' black adds up and reads grey. Good blends manage it; no blend hides it entirely, which is why dark content is where blends are judged.

Projection mapping onto objects

Mapping onto a building, a set piece or a car is the same idea taken further: the surface is described in the server, the projector's position is calibrated against known points on the object, and content is rendered as if it were painted onto the surface.

The hard parts are physical, not creative: the projector must not move, the object must not move, and somebody must be able to re-calibrate quickly when one of them does. Mark positions, photograph alignments, and save calibrations with the show file.

Where a mapping problem usually lives

Work along the chain; the symptom tells you where to look.

How to do it

1. Get the panel map from whoever configured the processing.
2. Count panels physically and compare with the map.
3. Build the canvas region at exactly the wall's pixel size.
4. Pin the server output to the resolution the processor expects.
5. Send a test pattern with a visible grid and numbered areas.
6. Walk the wall and check for offsets, rotations and missing panels.
7. Play real content and check the edges and the joins.
8. Save the show file with the mapping in it, and note the processor settings.

What goes wrong

Practice it

With any screen, projector or wall you can use.

Timelines, Cues & Playback

There are two ways to run content: lay it out against time and let the clock drive it, or put it in a list and fire each item when the moment arrives. Most shows use both, and choosing wrongly is what makes an operator's evening difficult.

Content has to play at exactly the right moment. Timelines and cues make playback a precise instrument.

Timelines and cues

A media server does not just play content randomly — it plays it on a structure. A timeline lays out content in sequence over time, like an editing timeline, for content that should run in a set order. Cues are stored playback states or actions triggered on command — play this clip, transition to that one, hold this image — so an operator (or a show controller) can fire the right content at the right moment in the show. Building the content into a timeline or a set of cues in advance is how a media server show is prepared, much like building lighting cues.

This connects media servers to show control and the whole live show. The content cues are triggered in coordination with the rest of the production — lighting, audio, the performance — often called by a director or fired by a show controller so everything changes together. The media server operator prepares the content and cues beforehand and executes them precisely on the night, making the visuals land exactly with the music, the speaker, or the moment.

A timeline places content against a clock: at this second, this clip starts, this layer fades, this effect runs. It is exact and repeatable, which suits anything that must match music, video or another department frame for frame.

A cue list places content in order, each waiting for a trigger. It is flexible, which suits anything that follows a person: a presenter, a stage manager, an act that plays a song longer tonight than last night.

Triggering and synchronization

Playback is triggered in different ways: manually by the operator pressing go on each cue, automatically along a timeline, or remotely by a show controller or another system sending a trigger. On bigger shows, the media server is often integrated with show control so that a single cue fires content, lighting, and more together. Synchronisation matters — content must play in time with the show and, where multiple servers or screens are involved, in sync with each other — which is a key reason media servers are specialised systems rather than ordinary computers.

The operator's live role is to execute the prepared content reliably and respond to the flow of the show: firing cues on time, adjusting if the show runs long or changes, and keeping the visuals coordinated with everything else. This is the same blend of preparation plus live execution seen in lighting and switching — the work is built in advance so the live show is a matter of precise, calm triggering.

A server is usually not in charge. Timecode gives it a clock to follow. MIDI and OSC let another desk or controller fire its cues. DMX or Art-Net let a lighting console drive layers and clips directly, which is common on concerts where the lighting operator busks the visuals too.

Whatever the method, decide who owns the master clock and write it down. Most sync disasters are two devices each believing they are in charge.

Choosing between them

Ask one question: does this moment have to be exact, or does it have to follow a human being? A song with a lighting sequence and a video edit wants a timeline locked to timecode. A conference with eight speakers and a shifting running order wants a cue list.

Shows mix them constantly — a cue list of items, some of which are timelines internally. That is the normal shape of a corporate show or a concert with both playback songs and talk-overs.

Being driven by a lighting desk

When a lighting console controls the server over DMX, each layer's clip selection, intensity, position and effects appear as channels in the console's patch. The programmer treats video as another fixture.

This is efficient and needs discipline: once the desk owns those channels, changing content order on the server without telling the lighting programmer breaks their show. The clip list becomes a shared interface, like cue numbers.

Previewing before it goes out

Every serious platform has a preview: a way of seeing what a layer or a cue will do before the audience does. Use it for every change, and keep the programmer's screen showing preview rather than programme when the room is live.

Where a show is critical, a backup machine runs in parallel, following the same triggers, ready to be switched to. Test that switch during rehearsal rather than discovering its quirks during the keynote.

Rehearsing playback

Run the show, end to end, from the real triggers, with the real content, on the real machine. Partial rehearsals prove almost nothing: the failures that matter are the long ones — a machine that heats up, a drive that fills, a clip that only fails at its own end.

Watch the frame counter as well as the wall. A show that drops frames quietly is a show that will drop something visible eventually.

Timeline or cue list

Match the mechanism to what the moment actually depends on.

How to do it

1. Agree who generates timecode and what the show's clock is.
2. Confirm the server sees it and reads the same numbers as everybody else.
3. Lay the content roughly against the clock first.
4. Run it with the real audio and nudge each item until it lands.
5. Set what the server does when timecode stops.
6. Rehearse stopping the clock and taking manual control.
7. Write the manual fallback on the same sheet as the running order.
8. Save the show file and export it before doors.

What goes wrong

Practice it

On any server platform, real or demo.

Sync, Genlock and Latency

The moment a system has more than one output, or more than one machine, the question stops being what is on screen and becomes when it is on screen. Frames that do not line up tear, drift or arrive after the sound.

Why frames have to be locked

Two outputs running from separate clocks drift, however slightly. Across a join in a wall that shows as tearing — one half of the image a frame ahead of the other — and on camera it shows as a moving band.

Genlock (also called frame lock or house sync) gives every device a common reference so that all of them draw their frames at the same instant. On any show with several outputs, several servers, cameras or an LED volume, it is not optional.

What genlock does not fix

Genlock aligns frame timing. It does not align content: two servers can be perfectly locked and still be playing different points in the same clip. That is a transport problem, solved by timecode or by the platform's own synchronisation between machines.

Nor does it remove latency. A locked system still takes time to get a picture from the server to the wall, and that time is what makes video arrive after audio.

Latency, measured rather than guessed

Every device in the chain adds delay: the server's own output, the processor, scalers, extenders, the panel driver. Individually small, together they can be several frames, which is visible when picture must match sound or a live camera.

Measure it rather than assuming it. Send a known reference through the chain, compare it against the source, and note the result on the system drawing so that audio can delay to match it.

Keeping picture with sound

Because video is nearly always slower than audio, sound is usually delayed to match the screens rather than the other way round. The number has to come from somebody who measured, and it has to be re-measured when the chain changes.

For a talking head on a screen, a few frames of error is visible and distracting. For music with abstract visuals, it matters far less — but somebody should still know the number.

Multiple servers

Large shows run several servers: one per surface, or a main and a backup, or several sharing a single enormous canvas. They must share genlock, share a clock, and usually share a synchronisation mechanism belonging to the platform.

Test the join. Play a clip that crosses the boundary between machines and look at the seam with fast-moving content, because slow content hides exactly the errors you are looking for.

Telling the sync problems apart

They look similar and have different cures.

On the job

A wall made of two server outputs looks perfect all afternoon on a slow ambient clip. The first fast edit of the show tears down the middle of the join, because nobody genlocked the machine and nobody tested with content that moves.

What goes wrong

Practice it

On any multi-output system you can reach.

Playing to Camera

A camera does not see what you see. It samples the world in slices, at its own rate, through a shutter, and a screen that looks perfect in the room can band, flicker, strobe or shimmer in the footage. On any job with a camera pointed at a screen, this is the part that costs days if nobody understood it.

Why screens misbehave on camera

An LED wall does not light up all at once and stay lit. It refreshes, and within each refresh it scans, lighting parts of the panel in sequence, far faster than an eye can follow. A camera's shutter opens for a slice of each frame and catches whatever the wall happened to be doing during that slice.

When the wall's refresh and the camera's frame rate and shutter do not agree, the result is banding — dark bars rolling through the screen in the footage — or flicker, or a partially lit panel.

Refresh, scan rate and shutter

Three numbers matter: the wall's refresh rate, its scan rate, and the camera's frame rate and shutter. High-refresh panels and processors exist precisely so that cameras can be used, and they are set up for it by whoever configures the processing.

The practical route is to agree the camera's frame rate and shutter first, then have the wall configured to suit, then check on the actual camera. Never on a phone, and never by eye.

Moiré and pixel pitch

Moiré is the shimmering interference pattern a camera produces when the wall's pixel grid and the camera's sensor grid are close in scale. It appears and disappears with distance, angle and focus, which is why a shot can be clean in rehearsal and shimmering on the day.

It is solved physically far more often than electronically: move the camera, change the lens, change the distance, throw the wall slightly out of focus, or use panels whose pitch suits the shot. The server cannot fix it.

Film frame rates and 24 frame playback

Film and much of drama television run at 24 frames a second, and a wall that must appear in shot has to run in a way that agrees with that rate. Content is made at the camera's rate, the playback runs at it, and the whole chain — server, processing, panels — is locked to the camera.

This is why playback for film is its own discipline. The wall is no longer scenery that happens to be lit; it is a light source and an image inside the frame, and everything about it is judged through the lens rather than from the seats.

Brightness, colour and what the camera exposes for

A wall bright enough to read in a room may be far too bright for a camera exposed for the actors in front of it, and its colour may not match the lighting on them. Screen brightness becomes an exposure decision made with the camera department, not a preference set by whoever built the wall.

Expect to be asked for a specific brightness, a specific colour temperature and sometimes a specific gamma. Write down what you set, because the next day somebody will ask you to reproduce it exactly.

Working with the camera department

Agree frame rate, shutter and the wall's refresh configuration before anything is built. Then test: put the real camera on the real wall with the real content and look at the monitor, not at the wall.

Keep a note of every setting that worked — camera rate, shutter, wall refresh and brightness — because that note is what makes the second day fast and the pick-up shoot possible.

Camera artefacts, and where the cure lives

Almost none of these are fixed in the media server.

How to do it

1. Agree the camera's frame rate and shutter with the camera department.
2. Have the wall's refresh and scan configured for that rate.
3. Genlock the whole chain to the same reference as the cameras.
4. Make and encode content at the camera's frame rate.
5. Put the real camera on the wall and look at the monitor.
6. Adjust wall brightness and colour with the camera exposed for the subject.
7. Test movement, angles and distances for moiré before the shot is locked.
8. Write down every setting that worked, and keep it with the show file.

What goes wrong

Practice it

With any screen and any camera, including a good one you borrow.

Live Inputs, Generative Content and Previs

Not everything a server plays is a file on its drive. Cameras, presenter laptops, streams and content generated in real time all pass through it — and long before any of that, the whole show is built on a machine in an office with no rig attached to it at all.

Live inputs and capture

Servers take live video in through capture cards: cameras for image magnification, a presenter's laptop, a lectern computer, a stream from elsewhere. Once captured, a live input behaves like any other layer and can be placed, scaled, mapped and mixed.

The risks are the ones every live source brings: resolution and refresh that change when a presenter plugs in a different laptop, EDID negotiation, and a source that goes black at the worst moment. Test with the actual machines that will be plugged in, not with a similar one.

IMAG through a server

IMAG — image magnification — is the live camera feed of a person on stage, and it is the most forgiving content to place and the least forgiving to delay. The audience can see the person and the screen at once, so latency shows immediately.

Where the server is in the IMAG path, keep that path as short as possible, measure its latency, and be prepared to argue for a direct route if the creative benefit of routing it through the server does not justify the delay.

Generative and real-time content

Some content is not rendered in advance at all: it is generated on the machine while the show runs, responding to audio, to control data or to a camera. It gives infinite variation, reacts live, and costs processing that would otherwise be spare.

It also changes what "checked" means. A rendered clip plays the same every time; a generative layer can behave differently under different inputs, so it must be rehearsed under the conditions of the show, not in isolation.

Previsualisation and offline programming

Most of a media server show is programmed before the screens exist, in a previs environment: a model of the stage, the screens and the content, on a laptop. The show arrives on site mostly built and is then corrected against reality.

Previs is only as good as the model. Panel counts, surface shapes and projector positions taken from a drawing must be checked against the real thing on the first day, and the differences applied before rehearsal.

Redundancy and backup machines

A show with one server has one point of failure. A backup machine runs the same file, follows the same triggers, and can be switched to — either by hand at a switcher or automatically by the platform's own failover.

Redundancy is only real if the switch has been tested with the show running. Test it in rehearsal, time it, and know what the audience sees while it happens.

Sources that are not files

Each brings its own failure mode.

On the job

A keynote goes to a presenter's own laptop, which has been asleep and wakes up at a different resolution. The server, told to expect a fixed mode, keeps showing the last frame instead of a black screen — because somebody set that behaviour deliberately in rehearsal.

What goes wrong

Practice it

With a server, a capture input and any laptop.

Running a Media Server Show

On the day, the work is not clever. It is checking: every clip, every output, every trigger, every time — and then sitting quietly, watching a frame counter, ready for the one thing that goes wrong.

Reliability is everything when content is the centrepiece. Preparation makes the live show calm.

Preparation and reliability

Because content is often the visual centrepiece of a show, a media server failure is highly visible, so reliability is paramount. Preparation is the key: get all content onto the server in the correct format and resolution, organise and check that every clip plays, build and verify the timeline and cues, configure the mapping to the actual screens, and rehearse the whole playback before the show. A media server show that is thoroughly prepared and rehearsed runs smoothly; one thrown together fails publicly. For critical shows, professionals also use a backup server that mirrors the main one, ready to take over if it fails.

This preparation mirrors the disciplines every AV job asks of you — the content library is prepped like warehouse gear, the cues are built like lighting cues, the mapping is set to the physical system, and everything is tested before the audience arrives. The media server operator who prepares meticulously is the one trusted with the big shows, because the visuals simply work.

The pre-flight before doors is a fixed routine, done the same way every show: content present and current, every clip played, every output live, triggers proved, backup ready, file saved and exported, drive space checked, machine running cool.

It takes twenty minutes and it is the whole difference between a calm evening and a visible failure. Write the routine down and work through it on paper, because under pressure memory skips exactly the step that matters.

Troubleshooting and the operator's value

When problems arise, the systematic troubleshooting method applies: content that will not play is usually a codec or file problem (back to formatting); content on the wrong screen or misaligned is a mapping issue; playback that stutters points to content format or an overloaded server; no output points to a connection or output configuration problem. Checking content, mapping, outputs, and connections methodically isolates most issues — and good preparation means most are caught before the show, not during it.

The media server operator blends technical skill (formats, mapping, outputs, the system) with creative awareness (how the content should look and land) and show discipline (cueing reliably with the crew). As screens grow ever more central to live events, this is one of the most in-demand and rewarding roles in AV. This book is the foundation; mastering specific media server platforms and advanced mapping builds the specialty on top of it.

When something goes wrong, work in the same order every time: is the machine playing, is the output live, is the trigger arriving, is the device downstream receiving. That order finds most faults in under a minute.

Cover before you diagnose. Get something acceptable on the screen — a holding image, a black, the backup machine — and then work out what happened. The audience judges what is on the wall, not the cause.

Practical sign-off

Media server skill is built on real systems. The learner loads correctly formatted content, configures mapping to a screen setup, builds simple cues, rehearses, and runs playback. A mentor signs off when the learner can prepare and run reliable playback on a small show.

• Loaded and checked correctly formatted content
• Configured mapping onto a screen/LED setup
• Built a timeline or cues and rehearsed playback
• Ran playback reliably and troubleshot a content/mapping issue

During the show

Watch the wall, the preview and the frame counter. Follow the running order rather than the clock, and keep the next item ready. On a cue-driven show, acknowledge cue calls exactly as a lighting operator would.

Do not change anything that is not broken. A show is not the time to tidy the layer stack, rename clips or clear the media cache, however untidy it looks.

Audio from a media server

Clips carry sound, and somebody has to decide what happens to it. A server can output embedded audio with its video, send it separately to the audio department, or have it stripped entirely so that sound comes from a separate playback machine the audio engineer controls.

Decide which of the three before the show, and write it down. Where the server does carry audio, the picture is usually a few frames behind the sound, so the audio department needs the measured latency to delay against — and where a separate machine plays the sound, both machines must follow the same clock or they will drift apart within a song.

The failures that actually happen

• A clip in the wrong codec, discovered during the show it was added for.
• A drive that filled overnight because renders kept arriving.
• An output that renegotiated when a device downstream was power-cycled.
• A trigger that stopped because somebody unplugged a network cable.
• The wrong version of a clip, because two versions were in the same folder.
• A machine that got hot in a closed rack and started dropping frames.

Content changes during rehearsal

New versions will arrive during rehearsal, often minutes before they are needed. Have a route for them: a folder they land in, a check you always run, a naming rule that makes the new one obviously newer, and a note of what changed.

Never let a new file go straight into the show without playing it through. The re-render that fixed the colour is also the one that arrived at the wrong frame rate.

What an operator is actually paid for

Not for pressing play. For the fact that the content is right, the mapping is right, the triggers work, the backup is warm, the file is saved, and nothing on the wall surprises anybody.

It is a quiet job done well. The measure of it is that the audience thinks about the content and never about the machine.

The pre-flight, in order

Twenty minutes, the same way, every show.

How to do it

1. Get something acceptable on screen first — hold, black, or switch to backup.
2. Check the server: is it playing, and is the frame counter moving?
3. Check the output: is the server sending on that output?
4. Check the trigger: is timecode or control still arriving?
5. Check downstream: processor, extender, panel power.
6. Fix the cause, not the symptom, once the show is covered.
7. Note what happened and what you changed.
8. Tell whoever owns the rest of the chain before they find out themselves.

What goes wrong

Practice it

Write your own pre-flight.

The People Around the Server

A media server sits between two groups who often do not speak the same language: the people who made the content and the people who own the screens. A large part of the job is translation, and most failures in this work are conversations that did not happen.

Content designers

Designers think in stories, colours and motion; the server thinks in pixel dimensions, codecs and frame rates. Your job is to give them a specification early, in their terms, and then to receive their work without treating it as an imposition.

Be specific and be early. "Four thousand by twelve hundred, twenty-five frames, this codec, alpha where it overlays" is a kindness. Silence followed by rejection on the day is not.

The video crew and the LED technicians

Somebody else owns the processing, the panels, the cabling and the projectors. They need from you: what resolution you will send, on which outputs, at what frame rate, and when you need it live. You need from them: the panel map, the processor's expectations and the real state of the wall.

Go and look at the wall with them once. Ten minutes standing in front of it prevents a day of mapping arguments conducted by message.

Lighting, audio and show control

Lighting may be triggering you or being triggered by you. Audio needs to know your latency. Show control needs your cue list to be stable. All three need to know who owns the master clock.

Agree these in the production meeting, not on the day, and write down what was agreed. Nothing in this job goes wrong more often than two departments each assuming the other is in charge of the clock.

The producer and the client

They will ask for changes late, because that is the nature of the work. What helps is honesty about cost in time: "that is a re-render, about two hours, and I need it by six to test it" is a useful sentence; "I'll try" is not.

Keep a visible list of outstanding content and its status. A producer who can see what is missing stops asking, and starts chasing the people who owe it.

Rehearsals and notes

Take notes in one place, in show order, with a status against each. After each run, work through them in that order rather than in the order they arrived, and mark what is done.

Re-check everything you change. The single most common media server failure on a show night is a file that was replaced after the last full run and never played through.

What to agree with whom, and when

Every line here is a failure that did not happen.

On the job

A conference video wall goes wrong for a week because the content agency is rendering to a 16:9 frame while the wall is 5:1. One email with a canvas specification, sent at the start, would have cost nothing; the re-render costs the agency a weekend and the producer their patience.

What goes wrong

Practice it

On your next screens job, before anything is built.

Load-out, Archiving and Where This Leads

A show that is archived properly can come back next year in an afternoon. One that is not has to be rebuilt from whatever survives on somebody's laptop, which is usually the content and none of the reasons behind it.

What to archive

The show file, the content in the version that actually ran, the mapping and calibration data, the machine's build notes, the panel maps and processor settings, the triggers and timecode offsets, and a short written account of anything unusual.

Archive the content that ran, not the folder that accumulated. One current set, named and dated, is worth more than forty gigabytes of history nobody can navigate.

Load-out without losing anything

Copy before you strike. The moment the machine comes out of the rack, somebody will want it for another job and the drive will be wiped. Get the archive onto two drives, verified, before the server moves.

Then strike properly: label cables, note anything faulty, return borrowed capture cards and licences, and leave the rack as the next person should find it.

Reviving a show later

The things that break a revival are versions: a platform that has moved on, a plug-in licence that expired, a codec that is no longer installed, and content whose source project nobody kept.

Write the version numbers down at archive time. When the show comes back, matching the versions first and only then opening the file saves a day of confusion about why things look different.

Where this work leads

Media server work opens onto screens production — owning the whole video picture of a show — and onto programming, where you build shows for designers at scale, and into virtual production, where the wall is the lighting and the background for a camera.

It also sits next to show control, projection design, content production and system engineering. The common thread is that all of them are paid for reliability under pressure, which is what this job teaches.

Getting better at it

• Rebuild a show you ran, offline, from the archive, and see what is missing.
• Encode the same clip in five codecs and watch what each one costs.
• Build a canvas for a wall you have only seen in a photograph, then check it.
• Learn one platform properly rather than three badly.
• Ask the LED technicians to show you the processor; it is where half the surprises live.
• Keep your own template show file, pre-flight list and content specification.

The archive, item by item

Everything here is cheap now and expensive to reconstruct later.

How to do it

1. Save the final show file and name it with the show and the date.
2. Export the file and copy the content that ran to an archive drive.
3. Add mapping, calibration, panel maps and processor settings.
4. Write the version notes: platform, plug-ins, licences, drivers.
5. Write half a page about anything unusual, and what you would do differently.
6. Verify the copy by opening it from the archive drive.
7. Make a second copy in a different place.
8. Only then let the machine be wiped.

What goes wrong

Practice it

Take the last show you worked on.

Glossary

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal