Match the format
Every camera must output the switcher's format, for example 1080p50. A camera set to 1080p25 or 1080i will show black or flicker on many switchers.
Live streaming and video
Live streaming, from camera to viewer
Live streaming is a chain: cameras, a switcher, an encoder, a platform and every viewer's player, and each link adds delay or risk. As a hobby I stream and record with Blackmagic ATEM switchers and PTZ (pan, tilt and zoom) and cinema cameras. This page covers video formats, switchers, cameras, cables and distance, lip sync, OBS (Open Broadcaster Software), the protocols that carry streams, multi site shows and the network underneath, and ends with a fault finder.
Stream chain
From camera to viewer, one link at a time
A live stream is a chain. Cameras feed a switcher, the switcher feeds an encoder, the encoder sends one stream to a platform such as YouTube, and the platform delivers copies to every viewer. Sound joins the picture at the switcher. Knowing the chain tells me where delay builds up and where a fault can sit.
Swipe sideways to see the whole diagram.
Orange is camera video, teal is sound from the mixer, purple is the programme stream on its way to the platform and cyan is what viewers receive. Most of the delay a viewer notices sits at the right hand end, in the platform and the player buffer, not in the cameras.
The chain, stage by stage
| Stage | What it does | What can go wrong |
|---|---|---|
| Cameras | Capture the picture and send it over HDMI (High Definition Multimedia Interface), SDI (Serial Digital Interface) or the network. | A format the switcher cannot take, overheating, a flat battery. |
| Switcher | Chooses which camera is live, adds graphics and keys, and mixes in sound. | A wrong input format, a source that will not lock. |
| Encoder | Compresses the programme with H.264, HEVC (High Efficiency Video Coding) or AV1 (AOMedia Video 1) and sends it out. | Too little upload bandwidth, an overloaded computer. |
| Platform | Takes the stream in, makes lower quality copies for slow viewers and sends them out. | A wrong stream key, settings the platform rejects. |
| Players | Buffer, decode and play the stream on each viewer's device. | Buffering when a viewer's connection is slow. |
Every stage has to keep up in real time. A recording can be fixed later. A live stream cannot, so I design each link with spare capacity and a fallback.
Video basics
Resolution, frame rate and bitrate
A video stream is a series of frames, compressed so it fits down an internet connection. Three numbers decide most of the result: the resolution, the frame rate and the bitrate. The codec decides how much quality each bit buys. Step through to see what YouTube recommends and what that means for the upload.
Swipe sideways to see the whole diagram.
YouTube recommends these H.264 bitrates for each resolution and frame rate. H.264, also called AVC (Advanced Video Coding), plays on almost everything, so it is my default.
HEVC and AV1 (AOMedia Video 1) reach the same quality at roughly 30% less bitrate. They need an encoder and a platform that accept them.
I plan the upload at about one and a half times the stream bitrate (typical), so 1080p60 at 17 Mbit/s needs a line that sustains about 26 Mbit/s up.
Sound is small next to video: AAC (Advanced Audio Coding) at 128 kbit/s for stereo is YouTube's recommendation.
The settings I start from
| Setting | What I use | Why |
|---|---|---|
| Frame rate | 25 or 50 fps (frames per second) in the UK; 30 or 60 where the audience and cameras expect it | UK mains is 50 Hz, so 25 and 50 avoid flicker from lighting. Every camera, the switcher and the stream must match. |
| Resolution | 1080p for most streams; 4K only when the switcher, the upload and the audience can all take it | A sharp 1080p stream at a healthy bitrate beats a starved 4K one. |
| Scan | Progressive (the p in 1080p) | Interlaced video (1080i) shows combing on phones and computers. |
| Rate control | CBR (constant bitrate) | Platforms expect a steady stream and size their buffers for it. |
| Keyframe interval | 2 seconds | YouTube recommends 2 seconds and no more than 4, so players can join and switch quality quickly. |
| Codec | H.264 by default; HEVC or AV1 when every part of the chain supports it | Newer codecs save bitrate but cost more processing. |
| Audio | AAC, 128 kbit/s stereo on the stream; 48 kHz through the production | YouTube lists 44.1 kHz for stereo. 48 kHz, the usual rate for video kit, also works in practice. I keep one rate from the mixer onwards. |
Bitrates and stream settings from YouTube's live encoder guidance, checked in October 2026. Other platforms publish similar figures.
Switchers
The switcher, the heart of the show
A vision switcher chooses which source is on air, adds graphics and mixes in sound. Blackmagic's ATEM switchers do this in a small box, with a streaming encoder and a recorder built into many models. Choose a mode to see how the switcher handles it.
Swipe sideways to see the whole diagram.
Cut. I set the next shot on the preview bus, check it on the multiview, then cut. The preview shot swaps onto programme in one frame, and the old programme shot moves to preview.
Mix. A mix, or dissolve, blends the two shots over a set time, typically about a second. I keep transitions simple and consistent; the audience should notice the speaker, not the effects.
Key. Keyers layer one source over another: a logo, a lower third with a name, or slides beside the presenter in a box. Upstream keyers sit in the shot; downstream keyers sit on top of everything.
Multiview. One monitor shows every input, the preview and the programme, with a red border on what is live. On an ATEM switcher this is the screen I watch all show long.
Swipe sideways to see the whole diagram.
The programme starts with one source, here the presenter on camera 2.
An upstream keyer places the slides in a box beside the presenter, using a DVE (digital video effect). It belongs to the shot, so it leaves when I cut away.
A downstream keyer puts the logo on top of everything. It stays put whatever I cut to.
A second downstream keyer adds a name strap. I take it on when the speaker starts and off after about eight seconds.
Fade to black takes the whole programme, keys included, to black at the start and end of the show.
The ATEM range, in short
| ATEM family | Inputs | What sets it apart |
|---|---|---|
| ATEM Mini and Mini Pro | 4 HDMI | The Pro streams over Ethernet with RTMP (Real Time Messaging Protocol) or SRT (Secure Reliable Transport), and records the programme to a USB (Universal Serial Bus) drive. |
| ATEM Mini Pro ISO | 4 HDMI | Also records each input as its own file, called ISO (isolated) recording, and saves a DaVinci Resolve project for editing later. |
| ATEM Mini Extreme and Extreme ISO | 8 HDMI | More keyers, a SuperSource for several boxes on screen and two USB outputs. The ISO models record every input, and the newer ISO G2 adds XLR microphone inputs. |
| ATEM SDI models and Television Studio HD8 | 4 to 8 SDI | SDI inputs for long runs, talkback, and tally and camera control sent to Blackmagic cameras over the programme return. |
| ATEM Constellation | Many SDI | Large broadcast switchers with several M/E (mix effects) rows for big multi camera shows. |
Input counts and features from Blackmagic Design's published specifications, October 2026. I use ATEM switchers from both the HDMI and the SDI families.
The same ideas apply to any vision switcher, hardware or software: preview and programme, transitions, keys and a multiview. Software switching in OBS is covered further down.
Cameras
Cameras that cut together cleanly
In my own time I stream and record with PTZ and cinema cameras. Each type has a job: PTZ cameras for fixed angles under remote control, cinema cameras where the picture has to look its best. What matters most is that every camera matches the switcher's format and looks the same when I cut between them.
Swipe sideways to see the whole diagram.
Orange is camera video into the switcher. Purple, on the dashed line, is the programme return to the camera, which carries tally (red) so the presenter and operator know when that camera is live. Teal is pan, tilt and zoom control from the joystick to each PTZ camera over the network.
Choosing cameras
| Camera type | Where it fits | What I watch for |
|---|---|---|
| PTZ (pan, tilt and zoom) | Fixed positions such as the back of a hall or a meeting room, run by one person from a joystick, with stored presets. | Control over VISCA (Video System Control Architecture) on serial or IP (Internet Protocol), or NDI (Network Device Interface); slow, smooth moves on air. |
| Cinema camera | The main presenter or performer shot, where picture quality matters most. | Heat on long shows, power, and a clean HDMI or SDI output without on screen menus. |
| Camcorder | Roaming shots and long events, with a long zoom and an all day battery. | Autofocus behaviour and the output format menu. |
| Mirrorless or DSLR (digital single lens reflex) | Low cost extra angles with good lenses. | Clean HDMI output, recording time limits, overheating and fragile micro HDMI ports. |
| Webcam or phone | Remote guests and quick extra views. | Variable frame rate and auto exposure that drifts. |
Habits that make cameras cut together
Lock exposure and colour
I set white balance, shutter and iris by hand, so shots match when I cut between cameras. Shutter at twice the frame rate, 1/50 for 25 fps, avoids flicker under UK lighting.
Use the return feed
On SDI switchers the programme return gives each camera operator tally and talkback, and lets me match cameras from the switcher with camera control.
Presets save the show
On PTZ cameras I store a preset for every shot I plan: lectern, panel, audience, wide. A preset recall moves the camera in a second, ideally while it is off air.
Cables and distance
HDMI, SDI and fibre, and how far each goes
The cable between a camera and the switcher decides how far apart they can be. HDMI suits a desk, SDI suits a hall, and fibre or the network suit a building or a campus. Choose a link type to see its reach, then try a run of your own.
Swipe sideways to see the whole diagram.
HDMI is made for a few metres between a box and a screen. Passive cables carry 1080p for roughly 5 to 10 m; 4K needs shorter or active optical cables. The connector has no lock, so I tie it off at both ends.
SDI uses 75 ohm coax with locking BNC (Bayonet Neill Concelman) connectors, built for broadcast runs. Belden's calculated figures are about 78 m for 3G on its 1694A cable and 93 m for 12G on its 4794R. Barco recommends staying under 50 m and 30 m on some cables.
Fibre converters turn SDI into light and back, in both directions on one unit. Single mode fibre with the right SFP (small form factor pluggable) optic carries SDI for kilometres, and fibre cannot pick up hum or interference.
Network video such as NDI or SRT goes as far as the network does. One copper Ethernet run is limited to 100 m, but switches, fibre and the internet extend it, at the cost of compression and some delay.
Try it: which cable for this run?
Pick the camera output and the distance from the camera to the switcher. The tool suggests the cable or converter I would use. Distances are indicative and depend on the cable and equipment.
- Cable
- 75 ohm coax, 3G rated or better
- Connectors
- BNC, locking
- Fallback
- a spare run, or fibre converters
Run SDI on good 75 ohm coax. At 40 m a 1080p SDI signal is well inside the reach of RG6 type cable. I use cable rated for 3G or better, locking BNC connectors and no adapters along the way.
Reach at a glance
| Link | Typical reach | Notes |
|---|---|---|
| HDMI, passive | About 5 to 10 m at 1080p; less at 4K | Cheap and common. No lock, and the plug is easily pulled out. |
| HDMI, active optical | About 10 to 30 m | Light inside, so it is directional: the source end must be at the source. |
| HDMI over HDBaseT | Up to 100 m on Cat6A | A transmitter and receiver over one Ethernet cable; covered on the audio visual (AV) over IP page. |
| 3G-SDI on RG6 coax | About 80 to 100 m | For 1080p50 and 1080p60. Reclocking distribution amplifiers extend it. |
| 12G-SDI on 12G coax | About 30 to 90 m | For 4K. The cable and the BNC connectors must be rated for 12G. |
| SDI over fibre | Kilometres | Converters at each end with SFP optics; single mode for long runs. |
| NDI on the network | 100 m per copper run; any distance across switches | Uses the network, so it needs bandwidth and good switching. |
Cable figures from Belden's calculated reach charts and Barco's guidance, checked October 2026; real reach depends on installation.
Fibre and copper basics, connectors and testing are on the fibre optics and copper cabling pages.
Audio
Sound for the stream, in sync with the picture
Viewers forgive a soft picture long before they forgive bad sound. Two things matter most: a mix made for the stream, and sound that lines up with the picture. Video takes longer through cameras and converters than sound takes from the mixer, so the switcher has to hold the sound back. Step through a lip sync check.
Swipe sideways to see the whole diagram.
A clap on stage leaves at time zero as sound and picture. It reaches the switcher by two routes.
The camera, its processing and any converter add about two frames, 80 ms at 25 fps (typical).
Sound from the mixer arrives almost at once, 75 ms ahead of the picture. EBU (European Broadcasting Union) R37 asks for sound no more than 40 ms early or 60 ms late.
I delay the sound input on the switcher by two frames. ATEM Mini switchers can delay their analogue inputs by up to 8 frames.
I check with a clap or a sync test clip on the stream itself, because the encoder and platform can shift it again.
Getting sound to the stream
A clean feed from the mixer
I take a dedicated stereo mix for the stream from the mixer, not the room mix. The room needs less of the voices that are already loud in the hall; the stream needs all of them.
Embed or input
Sound joins the picture at the switcher, through its analogue or XLR inputs, or embedded in an HDMI or SDI signal from the mixer's own outputs or a converter.
Levels and loudness
I peak around minus 6 dBFS (decibels relative to full scale) on the switcher meters and never clip. Platforms turn loud streams down; the post production page covers loudness.
Remote guests
A remote guest must hear everyone except themselves, a mix minus, or they hear their own voice back with a delay. I build that on the mixer.
My live sound setup and the mixer side are on the live sound page.
OBS
Software switching with OBS Studio
OBS (Open Broadcaster Software) Studio is free software that does a switcher's job on a computer. It builds scenes from sources such as cameras, capture cards, NDI (Network Device Interface) feeds, images and browser pages, then streams and records the result. Choose a scene to see how its sources stack.
Swipe sideways to see the whole diagram.
Starting soon. A holding slide with a countdown and music, live before the start so the stream is proven and viewers can gather.
Main camera. The presenter from an NDI camera, a lower third for the name, the logo and the mixer's sound. Sources are layered: the top of the list is drawn on top.
Two shot. Two cameras side by side for a conversation, over a branded background.
Slides. The presenter's laptop through a capture card, with the presenter in a small box. Slides need a sharp, steady picture, so I keep the bitrate up.
Be right back. A holding slide for breaks, so the stream never shows an empty stage or a crew conversation.
The OBS settings I start from
| OBS setting | Where it is | What I set |
|---|---|---|
| Encoder | Settings, Output | A hardware encoder such as NVENC (NVIDIA's encoder) when the computer has one; x264 software encoding only on a strong processor. |
| Rate control and bitrate | Settings, Output | CBR at the platform's recommended bitrate for the resolution, for example 12 to 17 Mbit/s for 1080p60 H.264. |
| Keyframe interval | Settings, Output | 2 seconds. |
| Base and output resolution | Settings, Video | 1920 by 1080 for both, so OBS does not scale. |
| Frame rate | Settings, Video | The same as the cameras: 25 or 50 in the UK. |
| Audio sample rate | Settings, Audio | 48 kHz, the same as the mixer, to avoid drift. |
| Recording | Settings, Output, Recording | A local recording at a higher bitrate in a crash safe container such as MKV (Matroska video), remuxed to MP4 afterwards. |
NDI sources come into OBS through the DistroAV plugin, formerly called OBS NDI, which needs the NDI runtime installed. vMix and Wirecast are commercial alternatives with built in NDI, instant replay and remote guest calls.
Protocols
RTMP, SRT, NDI and the hop each one suits
Different protocols carry the stream on different hops. RTMP (Real Time Messaging Protocol) carries the finished programme to a platform. SRT carries a camera or a remote site across the internet, NDI moves video around a local network, and HLS (HTTP Live Streaming) takes it from the platform to viewers. Step through how SRT survives a lossy internet link.
Swipe sideways to see the whole diagram.
SRT sends the stream over UDP (User Datagram Protocol), numbering every packet. It can encrypt with AES (Advanced Encryption Standard) at 128, 192 or 256 bits.
The internet drops a packet. Plain UDP would simply lose it, and the picture would break up.
The receiver sees the gap in the numbers and sends a NAK (negative acknowledgement) asking for that packet again. This is ARQ (automatic repeat request).
The sender resends the packet, and it arrives while the receiver is still holding earlier packets in its latency buffer. The output stays clean.
If the latency setting is shorter than a resend takes, the packet arrives too late. I set it to several round trip times; devices commonly default to about 120 ms.
Which protocol for which hop
| Protocol | Typical use | Delay (typical) | Notes |
|---|---|---|---|
| RTMP and RTMPS | Encoder to platform, such as YouTube or Facebook | A few seconds end to end, set mostly by the platform | Runs over TCP (Transmission Control Protocol). RTMPS is RTMP with TLS (Transport Layer Security) encryption, and is what YouTube recommends. |
| SRT | Site to site contribution over the internet | About 120 ms to a few seconds, set by the latency value | Open source, from Haivision. Recovers lost packets, encrypts, and works in caller, listener or rendezvous mode. |
| NDI | Cameras and computers on the same network | About a frame or two on a good network | Full bandwidth NDI needs about 125 to 150 Mbit/s for 1080p60; NDI HX3 about 50 to 62 Mbit/s. |
| WebRTC (Web Real Time Communication) | Remote guests and very low delay viewing | Under a second | Built into browsers. Harder to scale to large audiences. |
| HLS | Platform to viewer | About 6 to 30 seconds; 2 to 5 with low latency HLS | Video sent as short files over HTTP (Hypertext Transfer Protocol), so it scales through content delivery networks. |
NDI figures from the NDI documentation and Epiphan; delays are indicative and depend on settings and networks.
Multi site
One show from several locations
Some events happen in more than one place: a second stage, a satellite office or speakers at home. The pictures from each location travel to one main venue, which mixes them into a single programme and sends the show back to every site.
Swipe sideways to see the whole diagram.
Purple is contribution from each remote site into the main venue, cyan dashed is the programme return so each site can see and hear the show, and orange is a remote guest on a browser call. Only one programme leaves for the platform, so viewers see one show.
What makes a multi site show work
One place mixes
Every site sends its pictures to one main venue, which makes the programme. Two switchers both streaming to the platform is two shows, not one.
Return feeds and talkback
Each remote site gets the programme back, so presenters can hear questions, and a talkback line so the director can cue them.
SRT or a bridge
I carry remote sites with SRT, from an encoder or a switcher that supports it, or with NDI Bridge between networks. Blackmagic's ATEM Streaming Bridge turns a stream from an ATEM Mini Pro back into SDI and HDMI at the far end.
Mix minus for every remote
A remote presenter hears the whole show except their own voice. Without that they hear themselves late and lose their place.
Bonded connections
Where a venue has no reliable line, cellular bonding units combine several mobile connections into one, at the cost of more delay.
Rehearse the links
I test every remote link at the same time of day as the show, because shared internet connections behave differently in the evening.
Network
The network under the stream
A modern production is also a network. NDI cameras, the switcher's control, the encoder and the upload all share switches and links, and a stream only stays smooth if those links have room. Choose a camera format to see the load on one uplink, then check a venue's upload.
Swipe sideways to see the whole diagram.
Full bandwidth NDI. At about 150 Mbit/s for each 1080p60 camera (indicative), six cameras put about 900 Mbit/s on a 1 Gbit/s uplink. That leaves no room for anything else, and a burst drops frames.
NDI HX3. HX3 compresses with H.264 or HEVC to about 50 to 62 Mbit/s for 1080p60, so the same six cameras use about 370 Mbit/s. I check every device on the production supports HX3.
Only send what is needed. A camera only sends a stream to receivers that ask for it, and NDI can use multicast so several receivers share one stream. With IGMP (Internet Group Management Protocol) snooping, the switch sends each stream only where it is wanted.
Try it: is the upload big enough?
Pick the stream format and how many platforms the encoder sends to directly, then enter the upload speed measured at the venue. The tool uses YouTube's recommended bitrates and plans one and a half times the stream rate as headroom (typical).
- Stream bitrate
- 17.1 Mbit/s per platform
- Total sent
- 17.1 Mbit/s
- Upload to plan for
- about 26 Mbit/s
- Line use
- 86% of the measured upload
Tight. One 1080p60 H.264 stream at 17 Mbit/s plus audio needs about 26 Mbit/s with headroom, and the line gives 20. I would drop to 1080p30 at about 14 Mbit/s, use a wired second line, or send one stream to a restreaming service that copies it to each platform.
Network rules I keep for streams
Wired, always
The encoder, the switcher and every NDI device go on cable. Wi-Fi is for the audience, never for the stream.
A production VLAN
Production traffic gets its own VLAN (virtual local area network), away from guest and office traffic, with its own addresses and no surprise firewalls.
Multicast done properly
If NDI uses multicast, the switches need IGMP snooping and a querier, or every stream floods every port. The AV over IP page walks through it.
Prioritise the stream
On a shared connection, QoS (quality of service) marks the outgoing stream so office traffic cannot starve it. Marking and queuing are on the QoS page.
Measure the real upload
I test the upload at the venue, at the time of the event, for several minutes. A speed test burst flatters a busy line.
A second way out
A second line, a bonded cellular unit or a phone tether ready to take over, plus a backup stream key the platform can fail over to.
Streams that cross a building network, with NDI, Dante and multicast, are on my AV over IP page.
Recording
Record everything, and plan for failure
A live stream happens once, but the recording lasts. I record the programme and every camera, and I plan what happens when each part of the chain fails, because one of them eventually will.
Record the programme
The switcher or OBS records the programme locally at a higher bitrate than the stream. If the stream fails, the event still exists.
Record every camera
ISO recording keeps each camera as its own file with matching timecode. ATEM ISO models also write a DaVinci Resolve project, so the edit can recut the show.
Record the sound separately
A multitrack recording from the mixer lets me remix the sound afterwards. A two track backup goes to a second device.
Two copies before leaving
Before I pack down, the media is copied to a second drive. The post production page covers what happens next.
Planning for things to fail
| Failure | What I prepare |
|---|---|
| Encoder or computer crash | A second encoder, or the switcher's own streaming engine as a backup, with a backup stream key. |
| Internet drop | A second line or bonded cellular, and a platform setting that keeps the event open for a few minutes. |
| Camera failure | A wide safety shot that never moves, so there is always something to cut to. |
| Sound failure | A backup microphone at the lectern and a second feed into the switcher. |
| Power cut | A small UPS (uninterruptible power supply) on the switcher, encoder and network switch. |
The ISO recordings become an editable timeline afterwards, as on my post production page.
Troubleshooting
Finding a fault along the chain
Most streaming faults sit in one of five places: the source, the cable, the switcher, the encoder and its network, or the platform. Choose a symptom to see where it usually sits and what I check first.
Swipe sideways to see the whole diagram.
One camera shows black on the switcher. Almost always a format mismatch: the camera sends 1080p25, 1080i or 4K while the switcher runs 1080p50. I set the camera's output to the switcher's format, or use an input with a standards converter.
Slides show but a video goes black. The laptop is protecting content with HDCP (High bandwidth Digital Content Protection), which capture and streaming kit is not allowed to show. I play the clip from a local file in a plain player, or put the video into the switcher directly.
The picture flickers or rolls. The camera shutter is fighting the 50 Hz mains lighting. I set the shutter to 1/50 or 1/100, or adjust it until the bands stop, and keep every camera the same.
Sparkles and dropouts on an SDI feed. The run is too long for the format or the cable, or a BNC connector or barrel is poor. I test with a short known good cable, check the reach for 3G or 12G, and add a reclocking amplifier or fibre for long runs.
Sound is out of step with the picture. Video is delayed by cameras and converters while sound arrives at once. I measure with a clap or a sync clip and delay the sound input on the switcher by the matching number of frames, then check on the stream itself.
A remote guest hears their own voice. They are being sent the full programme sound. I send them a mix minus: everything except their own voice.
The stream drops frames. Dropped frames in OBS mean the network cannot keep up; skipped frames mean the computer cannot encode in time. I test the sustained upload, lower the bitrate or the resolution, use a hardware encoder and keep the encoder on a cable.
An SRT link glitches every few seconds. Resent packets arrive after the latency buffer has played out. I look at the round trip time and loss in the SRT statistics and raise the latency to several round trips, or find a cleaner connection.
Viewers buffer while the stream health is good. Viewers' connections cannot take the full bitrate, the keyframe interval is too long, or the platform is not offering lower qualities. I keep keyframes at 2 seconds, use a sensible bitrate and check the platform makes lower quality copies.
Where I look
| Question | Where I look | What it tells me |
|---|---|---|
| Is every source in the right format? | The switcher's software, such as ATEM Software Control, and the multiview | Which inputs are locked, and their format |
| Is the network or the computer the problem? | OBS, View, Stats | Frames dropped by the network versus frames skipped by the encoder |
| Is the stream arriving cleanly? | The platform's stream health page, such as YouTube Live Control Room | Bitrate received, keyframe interval and warnings |
| Is the internet link clean? | SRT statistics on the encoder and decoder | Round trip time, lost and resent packets, and buffer use |
| What does the line really give? | iperf3 -c server -R -t 60 or a sustained upload test | Upload over a full minute, not a short burst |
| Is sound in sync? | A clap on camera, or a sync test clip played through the chain | How many frames to delay the sound |
I change one thing at a time and test again on the stream itself, from a phone on mobile data, not just on the production monitors. My general method is on the troubleshooting page.
Engagement
How I plan a live stream, from first call to the last upload
A stream looks simple to viewers and is anything but for the crew. I follow the same path for every stream, small or large. I agree who is watching and why, set clear targets and visit the venue. Then I plan the cameras and the network on paper, rehearse the whole chain, run the show calmly and finish with the recordings.
Swipe sideways to see the whole diagram.
I start with who will watch and how: a public stream, a private link or only a recording for later. I agree the platforms, the running order, music and image rights, consent to film the audience, and what the organiser can spend on cameras, crew and connectivity.
I turn the brief into requirements: the format and bitrate, how much delay is acceptable, what must be recorded, and what happens if the internet fails. Accessibility counts too, with captions for viewers who need them. Each target has an owner who agrees it.
I visit the venue at the same time of day as the event. I measure the upload over several minutes, walk every cable run, find power for each camera position, check sight lines, and agree a wired network port or VLAN with the venue's IT team.
On paper I draw the camera plan and shot list, the signal flow from every source to the stream, and a cable schedule with lengths and types. I set the stream format and keys, and write down what happens when each part fails.
I build early and test everything: each camera and microphone, graphics, a private test stream watched on a phone on mobile data, lip sync, and every remote link. Presenters rehearse their entrances, slides and handovers so nothing surprises them live.
During the show the director calls shots, and someone watches the stream itself, its health page and the viewer chat. I keep an incident log, so problems are fixed calmly and remembered, and the backup line and encoder stay ready to take over.
After the show the media is copied twice before anything is deleted, the edited version goes to the organiser, and we review what went well and what did not. Between events I update firmware and software, test it, and replace worn cables.
Functional requirements
What it must do.
- Stream the programme to the agreed platforms, publicly or privately, from the planned start until the end.
- Switch between every planned camera, the slides and the graphics, with names on screen for each speaker.
- Carry a clean stereo sound mix, in sync with the picture, with every speaker clearly audible.
- Bring in remote presenters or sites, with a return feed and talkback for each.
- Record the programme, and every camera where an edit is planned, at a higher quality than the stream.
- Keep a holding slide ready for the start, the breaks and any failure.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Picture
- 1080p at 25 or 50 fps, at the platform's recommended bitrate (typical).
- Delay
- Viewers see the stream within the platform's normal or low latency setting, agreed in advance.
- Lip sync
- Sound within the EBU R37 window: no more than 40 ms early or 60 ms late.
- Upload
- A measured, sustained upload of at least one and a half times the total stream bitrate (typical).
- Resilience
- No single failure stops the stream for more than a minute (typical), with a backup line and encoder.
- Recording
- Two copies of every recording before the crew leaves the venue.
- Accessibility
- Captions available on the stream or added to the recording afterwards.
- Security
- Stream keys kept private, remote links encrypted, and production devices off the guest network.
Numbers are typical starting points. Each event agrees its own with the organiser and the venue.
Who I talk to
- The event organiser, who owns the audience, the budget and the running order
- Presenters and performers, with their slides, videos and music
- The venue manager and technician, for power, rigging and house sound
- The venue's IT team, for the internet line, network ports and firewall rules
- Remote sites and guests, with their own connections and equipment
How I find out
- A site visit at the time of day the event will run
- A sustained upload test over several minutes on the actual line
- Measuring every cable run from camera positions to the control table
- A test call to each remote site or guest
- A look at the house sound system and where to take a feed from it
Discovery tools
| Tool or source | What it tells me |
|---|---|
| iperf3, or the platform's own test stream | What the line really sustains, not a short burst |
| A measuring wheel or laser measure | Cable lengths for each camera position |
| An unlisted test event on the platform | The whole chain, end to end, before the day |
| ATEM Software Control or OBS stats | Formats, sound levels and dropped frames |
| A phone on mobile data | What viewers will actually see and hear |
| Venue drawings and the power plan | Where power, network points and rigging points are |
On show day there is little time, so I work along the chain from the source to the viewer and fix the first broken link.
My approach
- Scope. What is wrong, for whom and since when: one camera, the sound, the whole stream or only some viewers?
- Protect the show. Cut to a working camera or the holding slide first, so viewers see something sensible while I fix the fault.
- Locate. Follow the chain: source, cable, switcher, encoder and network, platform. Each stage has a monitor or a meter to check.
- Compare. Swap with a known good camera, cable or input. If the fault moves, it was the part I swapped.
- Fix and prove. Change one thing, then check on the stream itself, from a phone on mobile data, not only in the control room.
- Record. Write it in the incident log, so the cause is fixed properly before the next event.
Common faults
- A camera set to a different format from the switcher, showing black
- Videos from a laptop blocked by HDCP
- Dropped frames from an upload that looked fine in a short speed test
- Sound early against the picture by a couple of frames
- A remote guest hearing their own voice without a mix minus
- An SDI run longer than its format allows, with sparkles and dropouts
Layer by layer
| Layer | What I check |
|---|---|
| 1 · Physical | Cables, connectors, SDI reach, HDMI locks, fibre optics and power at each position. |
| 2 · Data link | Switch ports, VLANs for production, and PoE (Power over Ethernet) for PTZ cameras. |
| 3 · Network | Addressing, multicast and IGMP for NDI, and the route out to the platform. |
| 4 · Transport | TCP for RTMP, UDP with resends for SRT, and the retransmit counters on each. |
| 5 to 7 · Application | Encoder settings, stream keys, the platform's health page and the players. |
My general method, with worked faults, is on the troubleshooting page.
A stream is supported by roles that each own part of the chain. On small shows one person holds several of them.
Roles
A director calling shots, a vision mixer, camera operators, a sound engineer and a stream producer watching the output and the chat.
Comms
Talkback for the crew, with a clear way to call a problem without stopping the show.
Monitoring
The multiview, the sound meters, the platform's health page and the stream on a phone, all watched throughout.
Runbooks
Short cards for the common failures: a camera lost, the internet down, sound out of sync, a guest not connecting.
Incident log
Every problem written down with the time, so the edit and the review can deal with it.
Handover
The organiser gets the recordings, the stream link and the analytics once the show ends.
Streaming kit, software and platforms change often, so I keep them current between events.
- Firmware. Switcher and camera firmware updated between events, never on the day, and tested before the next show.
- Software. OBS, plugins and NDI tools updated together, because a plugin can break with a new OBS release.
- Platforms. Platform settings and recommendations change, so I check the current guidance before each event.
- Cables. Cables tested and worn ones replaced, with every cable labelled with its length and type.
- Media. Recordings archived in two places, and old media cleared only when the organiser has signed off.
- Lessons. What went wrong at the last event fed into the checklists and runbooks for the next.
Projects
Where I use it
I stream and record video in my own time. My network work gives them a solid base, because a modern production is a network as much as a set of cameras. These cards show the kit I use, the training I have done and the projects behind it.
Multi camera streams with ATEM switchers
In my own time I stream and record with Blackmagic ATEM switchers: the ATEM Mini series for HDMI sources, and a larger ATEM with SDI inputs for longer cable runs.
PTZ and cinema cameras
My cameras are PTZ cameras for fixed angles under remote control, and cinema cameras for the main shots. Making them match when I cut between them is most of the work.
Sound from my own mixer
I mix sound on an Allen & Heath Qu series mixer. The mixer side, from microphones to the stream feed, is on the live sound page.
AV fundamentals and AV over IP
I have completed Kramer's AV Fundamentals, AV over IP Installer and AV over IP Sales Associate courses, which cover carrying audio and video across networks.
Real time media on a network
My lab carries voice calls between three sites over an MPLS (Multiprotocol Label Switching) core, with a voice VLAN on every phone port. Live video needs the same care: bandwidth, separation and priority. See the topology.
Voice over IP across a group
LAN (local area network), WAN (wide area network), VoIP (voice over IP), virtualisation and security across the group, including the warehouse and cold chain systems at the food depots.
Backed by Kramer's AV Fundamentals and AV over IP courses, and CCVP (Cisco Certified Voice Professional) for real time media on networks. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.