Technical requirements
LiveDirector specifications and network requirements. The figures correspond to the actual encoder and transport configuration, not to estimates. They are here so you can validate your installation before an event.
MINIMUM REQUIREMENTS
Access point on 5 GHz, 802.11ac or later, dedicated.
Client isolation disabled on the access point.
8 Mbps per camera of local network capacity.
4.63 Mbps of upload per simultaneous broadcast destination.
Server device running iPadOS 17, iOS 17, or macOS 12.3.
Camera phones running iOS 15 or later; Android in development.
01System specifications
Fixed parameters of the encoder, the transport, and the output. None are user configurable; the contribution bitrate is the only variable one, and the adaptive controller adjusts it automatically.
| Parameter | Value |
|---|---|
| Capture and program resolution | 1920 × 1080 |
| Frame rate | 30 fps |
| Contribution codec (camera to server) | HEVC / H.265, hardware encoding |
| Fallback codec | H.264, if the camera doesn't support HEVC. Agreed on connection |
| Contribution bitrate | 8 Mbps nominal; adaptive ladder 10 / 8 / 6 / 4 / 2.5 Mbps |
| Contribution audio | AAC-LC, 48 kHz, stereo, 128 kbps |
| Local network transport | TCP, tuned for minimum latency |
| Discovery | mDNS / Bonjour, `_livedirector._tcp` service |
| Server port | Assigned by the system and announced over mDNS. No fixed port to open |
| Pairing authentication | 4-digit PIN, optional |
| Output codec (broadcast) | H.264 High Profile, 4.5 Mbps |
| Maximum keyframe interval | 2 s |
| Output audio | AAC, 128 kbps |
| Output protocol | RTMP and RTMPS, one independent connection per destination |
| Capture to multiview latency | 150 to 200 ms |
| Camera cut latency | 1 frame, 33 ms |
Latency until the viewer sees the broadcast is determined by the destination platform, between 2 and 30 seconds depending on its live configuration. It does not depend on LiveDirector.
02Access point and local network
The cameras and the server device communicate over TCP within the same subnet. Discovery uses mDNS. These are the access point parameters that determine whether the system operates.
Requirements
- ✓
5 GHz band. The 2.4 GHz band supports two cameras at most, given available channel width and typical occupancy levels.
- ✓
802.11ac (WiFi 5) or later. With 6 or more cameras, 802.11ax (WiFi 6) shares the air better among many clients transmitting at once.
- ✓
Client isolation disabled. The setting appears as AP isolation, client isolation, or station isolation depending on the manufacturer. When enabled, it blocks traffic between clients of the same access point and prevents pairing.
- ✓
mDNS forwarding permitted. Automatic discovery uses multicast on `224.0.0.251:5353`. If the network filters it, pairing requires entering the IP address and port manually.
- ✓
Cameras and server on the same subnet. mDNS discovery does not traverse VLANs or routed segments without a configured reflector.
- ✓
80 MHz channel width on a channel that does not overlap with neighbouring networks.
Incompatible configurations
- ✕
Guest networks. They enable client isolation by default on most equipment.
- ✕
Captive portals. Periodic reauthentication drops the cameras' connection partway through the event.
- ✕
Band steering over a single SSID. The access point can reassign a camera to 2.4 GHz without notification, with a consequent bitrate drop. Publish the 5 GHz band as a separate SSID.
- ✕
Repeaters and mesh nodes with clients distributed across them. Each hop between nodes doubles airtime consumption. All devices must associate with the same access point.
- ✕
Networks shared with event attendees. Airtime is a resource shared among all associated clients.
Recommendation: an access point dedicated exclusively to the cameras and the server. It needs no internet uplink: mixing, compositing, and recording all operate without a connection. The connection is only involved when broadcasting.
03Local network bandwidth
Each camera maintains a continuous stream to the server at 8 Mbps of video plus 128 kbps of audio. The traffic is sustained rather than bursty, and all cameras transmit simultaneously. The adaptive controller lowers the bitrate along the 10 / 8 / 6 / 4 / 2.5 Mbps ladder when the network congests or when the device's temperature requires it.
| Remote cameras | Aggregate traffic | Access point |
|---|---|---|
| 2 | 16.3 Mbps | 802.11ac, 5 GHz |
| 4 | 32.5 Mbps | Dedicated 802.11ac, 5 GHz |
| 6 | 48.8 Mbps | Dedicated 802.11ac on a clean channel, or 802.11ax |
| 8 | 65.0 Mbps | Dedicated 802.11ax, server on Ethernet |
This traffic stays on the local network and consumes no bandwidth from your internet connection. Thermal management acts before the operating system throttles performance: as temperature rises the camera drops to 24 fps and caps at 6 Mbps, then 4 Mbps if it keeps climbing. Each camera's card reports the current bitrate and the reason for the reduction.
04Internet upload bandwidth
Each broadcast destination opens an independent RTMP connection with its own H.264 encoder at 4.5 Mbps plus 128 kbps of audio, which is 4.63 Mbps per destination. Upload consumption scales linearly with the number of simultaneous destinations.
| Simultaneous destinations | Required upload | Recommended upload | Plan |
|---|---|---|---|
| 1 | 4.63 Mbps | 8 Mbps | Any |
| 2 | 9.26 Mbps | 15 Mbps | PRO |
| 3 | 13.89 Mbps | 20 Mbps | PRO MAX |
| 5 | 23.15 Mbps | 35 Mbps | PRO MAX |
- ·
The figure that matters is upload speed. Residential plans are typically asymmetric, with upload well below download.
- ·
Measure upload at the event location and at the event time. Available capacity varies with the provider network's occupancy.
- ·
The recommended column applies a 50 % margin over the requirement. Without margin, any variation in available capacity produces encoder queueing and frame drops.
- ·
If available upload does not cover the requirement, reduce the number of simultaneous destinations.
The free tier requires no internet connection. Mixing, compositing, and local recording operate entirely on the local network.
05Ethernet connection for the server device
An access point's airtime is a shared resource: inbound camera traffic and outbound broadcast traffic compete for the same medium if the server is associated over WiFi. Connecting the server over Ethernet removes that contention and separates the uplink from the contribution link.
Ethernet required
- ✓
5 or more remote cameras. Aggregate traffic exceeds 40 Mbps sustained.
- ✓
2 or more simultaneous destinations. Aggregate upload exceeds 9 Mbps.
- ✓
Access points whose configuration you do not control.
- ✓
Non-repeatable events.
Implementation
- ·
USB-C to Gigabit Ethernet adapter. No specific model or additional driver required.
- ·
On iPad and iPhone, use an adapter with a power input (USB-C Power Delivery) to power the device and maintain the network connection at the same time.
- ·
On a Mac with a built-in Ethernet port, connect directly. Otherwise, the same USB-C adapter.
- ·
iOS, iPadOS, and macOS prioritise the Ethernet interface over WiFi automatically. No configuration required. Leave WiFi enabled: the cameras continue to use it.
- ·
Cameras accept Ethernet too, and each one moved to a cable frees around 8 Mbps of airtime for the rest. iPads and USB-C iPhones use the same adapter; Lightning iPhones need the USB 3 Camera Adapter plus a network adapter. It pays off on fixed cameras that sit near a network drop; on tripod-mounted cameras spread around the venue, rarely.
If the session involves local recording only and no broadcast, an Ethernet connection provides no advantage: there is no outbound traffic competing for the medium.
06Server device
The server continuously decodes every inbound stream, composites the program at 30 fps, and encodes the output. Continuous decoding is what allows a camera cut to take one frame without waiting for keyframes. The operating system requirement is iPadOS 17, iOS 17, or macOS 12.3. The number of simultaneous cameras depends on the chip's decoding and graphics capacity.
| Device | OS | Remote cameras |
|---|---|---|
| iPad 6th generation, A10 | iPadOS 17 | 4 |
| iPad with A12 to A14 | iPadOS 17+ | 4 to 6 |
| iPad with A15 or later | iPadOS 17+ | 6 |
| iPad with M chip | iPadOS 17+ | 8 |
| Mac with Apple Silicon | macOS 12.3+ | 8 |
| iPhone XS or later | iOS 17+ | 4 |
- ·
Landscape orientation on iPad. The console is dimensioned on the 9.7-inch iPad screen, so it fits from that size up.
- ·
On iPhone the interface is the compact mixer, in portrait orientation.
- ·
The server device's built-in camera can be used as an additional source, on top of the remote ones.
- ·
Intel Macs qualify from 2015, which is as far back as macOS 12.3 reaches. How many cameras they sustain varies a lot by generation: hardware HEVC decoding is complete from 2017 onward and partial before that. If you plan to direct from an Intel Mac, run the section 10 test with every camera you intend to use.
- ·
Models earlier than the 6th generation iPad do not reach iPadOS 17 and cannot install the application.
07Camera devices
The Camera application captures at 1920 × 1080 and 30 fps, encodes in HEVC in hardware, and sends it to the server over the local network. It is free and consumes no subscription seats. Its OS requirement is lower than the studio's, because capturing and encoding a single feed asks far less than decoding several and compositing them: iOS 15 reaches the iPhone 6s and iPadOS 15 the iPad Air 2.
| Platform | OS | Status |
|---|---|---|
| iPhone | iOS 15+ | Available |
| iPad | iPadOS 15+ | Available |
| Android | Android 11+ | In development |
- ·
Power. Continuous capture and encoding consume between 15 % and 25 % of battery per hour depending on the model. For sessions longer than one hour, use external power.
- ·
Heat dissipation. The application reduces frame rate and bitrate as temperature rises, before the operating system applies its own throttling. Remove insulating cases and avoid direct sunlight.
- ·
Mounting. Clamp mount on a tripod. The application does not compensate for camera movement.
- ·
Mixed devices supported. Each camera agrees its own codec and bitrate separately on connection, so different models and platforms can be combined in the same session.
08Intercom (PRO MAX plan)
Voice channel between the director and the camera operators, push-to-talk: nothing is encoded or sent unless someone holds the button. The director talks to every camera or to a single one; a camera operator's voice is heard by everyone but them. The app enables the feature through the intercom capability of the license.
Requirements
- ✓
Audio interface with at least two inputs on the server device. iOS keeps a single active input route, so the talkback microphone is patched into a channel of the interface — the last one by convention, configurable. It never enters the program bus.
- ✓
Headphones on every camera phone. Without a headphone route the intercom won't start: the phone's speaker sits inches from the scene and the director's voice would reach the program through any nearby microphone. The route is monitored continuously and the intercom stops when it's lost.
- ✓
Listening and talking are separate permissions. Headphones without a microphone still receive instructions; they only lose the reply.
Bandwidth
- ·
AAC-LC voice at 48 kHz, mono, 32 kbps per speaker, relayed by the mixer without transcoding.
- ·
With the gate closed, network cost is zero; with every camera talking at once, under 1% of the contribution budget in section 03.
A camera without headphones — or without the feature — connects and contributes as usual: it loses the intercom, nothing else.
09Storage
The program recording is written to the server device's local storage, in an MP4 container at 1920 × 1080 and 30 fps. Approximate consumption is 2 to 4 GB per hour, depending on the level of detail and motion in the image. Verify available space before extended sessions: interruption due to lack of space is not recoverable.
On the free tier the recording is segmented at 20 minutes per file and carries a watermark. Paid plans remove both restrictions.
10Pre-event verification
Validation procedure using the final installation and at the final location.
- ·
Configure the access point and associate all the cameras you plan to use.
- ·
Connect the server over Ethernet if the session includes broadcasting, and confirm the application detects the interface.
- ·
Measure upload speed at the location and compare it against the table in section 04.
- ·
Run a five-minute test broadcast to a private or unlisted stream, with the intended number of destinations.
- ·
Review each camera's readings: bitrate, fps, latency, and temperature. A reduction during the test indicates insufficient margin.
- ·
Confirm the camera devices stay powered and do not enter sleep.