Live View - Technical Implementation

Live View uses WebRTC, Low-Latency HLS (LL-HLS) and image previews. The camera supplies the footage, the TetherBox prepares it for browser playback, and the viewer selects the quality and transport. For the controls, see Live View.

 Camera Streams and Quality

Cameras usually provide a high-resolution primary stream, a smaller secondary stream and snapshots. Their resolutions, frame rates and bitrates depend on the camera configuration.

• Auto selects primary or secondary video according to the displayed tile size and zoom. It compares the required picture size with the camera's secondary resolution, rather than using a fixed tile-size threshold. Hysteresis prevents repeated changes near the boundary.
• Primary (HQ) requests the primary stream.
• Secondary (LQ) requests the secondary stream.
• Preview requests images instead of video.

Quality and video transport are separate choices. Where video is supported, the camera menu offers WebRTC and LL-HLS. Preview hides the video transport choices. A fullscreen tile inherits its transport preference.

Selecting a viewing quality does not change the camera's recording settings. A lower-quality live stream can therefore be viewed while the primary stream continues recording.

 WebRTC

WebRTC is standard on TetherBoxes and regional clouds; there is no per-unit enable switch. Local video initially selects WebRTC. Internet video initially selects LL-HLS unless the viewer has saved a WebRTC preference for that tile.

The browser negotiates a session through WHEP, an HTTP signalling protocol. MediaMTX on the TetherBox then sends encrypted media to the browser. Compatible video is copied from the camera stream. Where audio conversion is needed, an on-demand FFmpeg publisher converts it to Opus. An audio track is available only if the source supplies usable audio.

On the local network, the browser connects directly to the TetherBox. Over the Internet, signalling uses the authenticated TetherX application and media travels through the regional TURN relay on port 443. UDP provides a faster connection where permitted; TLS over TCP provides the fallback. Media remains encrypted with either route. The relay reaches the TetherBox through its existing VPN connection. No inbound Internet port forwarding to the TetherBox is required.

If WebRTC negotiation or playback fails, the video player falls back to LL-HLS. Browser codec support, camera output and network reachability still determine whether an individual stream can play.

 LL-HLS

LL-HLS delivers video through HTTPS playlists and media fragments. MediaMTX's low-latency output uses fragmented MP4, with configured one-second segments and 200ms parts. The actual segment timing also depends on camera keyframes.

The player uses hls.js where supported and native HLS on supported Safari devices. For Internet viewing, hls.js requests completed one-second segments with a two-second live-edge target and a three-second resynchronisation limit. This avoids making a separate authenticated round trip for every 200ms part on a distant cloud route. Confirmed local routes retain part loading and the existing buffering policy. Native Safari HLS controls its own buffering.

These are playback targets, not guarantees of total camera-to-screen delay. The player keeps its network retry budget and increases the target slightly after a stall. Camera keyframes, network conditions and decoding still affect the result.

Older stream sources can use the existing HLS delivery path. Choosing LL-HLS does not force every camera to produce the same container or codec.

 Preview and Fallbacks

Preview polls images at approximately one frame per second, adapting requests to loading time. Each image is independently decodable, so a missed update does not break subsequent frames. Preview provides less fluid motion and can be useful for large walls or constrained connections.

The player can fall back through the available video streams to images. Availability follows the source and browser capabilities; monitor-only cameras and iPhones are not universally restricted to Preview.

 Connection and Access Control

TetherX checks whether the TetherBox is reachable locally and chooses an appropriate local, external or cloud route. See Local Streaming for connection indicators and troubleshooting, and Connecting your TetherBox to the Internet for firewall requirements.

Cloud signalling checks the viewer's authentication, camera access, remote-view permission, schedule and IP restrictions. Cookie-authenticated signalling also requires CSRF protection. Session updates and cleanup are bound to the viewer, camera, stream and session.

The TetherBox checks authentication and camera schedules for local signalling too. Signed session URLs bind updates and cleanup to the credential, camera and stream. Cookie-authenticated local signalling also checks the request origin. These checks remain in place when cameras share one MediaMTX process.

TURN credentials are temporary and expire within one hour, or sooner if the account expires. They grant relay access; they do not independently grant camera access. Existing media sessions are not instantly revoked by a permission change.

 Startup, Latency and Timestamps

Startup time includes signalling, ICE connectivity, any on-demand publisher startup and waiting for a decodable camera keyframe. It is separate from latency during established playback.

For WebRTC, the pill's milliseconds measure RTT, the network round-trip time reported by the browser's WebRTC connectivity checks. The tooltip explains the measurement. It includes the selected relay route where one is used, and excludes camera capture and decoding delay. It is not total camera-to-screen delay. If no RTT measurement is available, the pill shows WebRTC.

The WebRTC timestamp identifies when the displayed frame was received by the browser. It is measured separately from RTT, and is omitted when the browser does not supply frame receive metadata. A stale timestamp indicates that decoded frames have stopped advancing, even if the network connection still answers connectivity checks.

HLS timing uses the available live-edge information. Preview timing follows the image response. Values from different transports therefore describe different measurements and should not be treated as equivalent network latency.

Related Articles

• Live View - Quality, scaling and camera controls
• Local Streaming - Direct access and troubleshooting
• Connecting your TetherBox to the Internet - Network and firewall requirements
• Automatic Configuration - Camera stream configuration
• TetherBox Recording Capacity - Bandwidth and storage estimates