Technical

AV control protocols: VISCA, OSC, NDI^® PTZ, ONVIF and the rest

Transport describes how the video travels, control describes how the machines are commanded. This reference page covers the second question: the protocols that drive PTZ, tally, routers and software. For transport, see the NDI®, SRT, RTSP, RTMP guide.

Two families of protocols

The Controlling a live production article describes AV control in four layers: the surface the operator touches, the middleware that orchestrates, then the protocols. This page covers the two lower layers, the ones that actually talk to the machines.

The dividing line is simple. Generic protocols are vendor-independent: OSC, MIDI, HTTP/REST, WebSocket, TCP/UDP, Art-Net. They serve to orchestrate and to link software. AV-specific protocols control precise functions of a device: VISCA for PTZ, NDI® for PTZ and tally carried in the stream, ONVIF for IP cameras, TSL UMD for tally, NMOS for ST 2110, Ember+ for broadcast audio, GPI/GPO for robust triggers.

Quick reference

Protocol	Key point	Main use
VISCA	"The PTZ standard"	Drive pan, tilt, zoom, presets and image settings of a PTZ camera, over serial or VISCA over IP
NDI® PTZ / tally	"Control inside the stream"	PTZ, tally and metadata carried within an existing NDI® infrastructure
OSC	"Flexible messages for show control"	Trigger cues and drive parameters between software (QLab, TouchOSC, Resolume)
Network API	"HTTP, WebSocket, TCP"	Drive live software (OBS, vMix, mimoLive) from an automation tool or a script
ONVIF	"The IP camera / VMS world"	Discover, configure and control IP cameras, mostly in video surveillance
TSL UMD	"Tally and source names"	Report tally and labels to multiviewers and under-monitor displays
NMOS	"Control in ST 2110"	Discovery, connection and events between senders and receivers in an ST 2110 environment
GPI / GPO	"The dry contact"	Simple, robust triggers, tally, redundancy, backup

Generic protocols

Open Sound Control, the flexibility of show control

OSC

OSC is a message protocol designed for real-time control in audio, video, lighting and interactive installations. A message uses a path-style address, for example /camera/1/preset/3, with typed arguments; the specification also provides time-tagged bundles to group several messages. It is widely used in QLab, TouchOSC, Millumin and Resolume, as well as in many consoles and creative tools.

Strengths

+Simple, readable, quick to map
+Very flexible: cues, parameters, touch interfaces, bridges between software
+UDP or TCP transport depending on the application
+Widely adopted in show control and interactive installations

Limits

-No universal vocabulary: each application defines its own addresses
-An address only means something in the application that defines it, so mappings must be documented
-Over UDP, fast but with no delivery guarantee
-State feedback depends on the application: to be checked case by case

Recommended use

Linking several pieces of software, triggering cues, driving a custom touch interface. For critical commands, prefer TCP when the application allows it and check whether state feedback exists.

The backbone of modern live software

Network API (HTTP, WebSocket, TCP)

Most live production software exposes a network API that lets an automation tool or a script change a scene, start a recording, retrieve a state or drive an overlay. OBS is automated via WebSocket, vMix exposes an HTTP API and a TCP API, mimoLive relies on its built-in web server and its HTTP API. It is through these interfaces that tools like Bitfocus Companion or Node-RED orchestrate a software control room.

Strengths

+Powerful and bidirectional: command and state feedback
+Easy to integrate into an automation tool, a script or a dashboard
+Standard and well documented on the software side
+Often allows subscribing to events (tally, recording state)

Limits

-Opens network access into the heart of the control room: security to be handled seriously
-Ports, authentication methods and functions vary by software and version
-No universal discovery: each piece of software has its own logic
-No direct exposure to the internet: a dedicated VLAN or VPN is required

Recommended use

Driving live software from a surface or an automation tool. Ports, authentication methods and available functions should always be checked in each software's documentation and in the version actually used.

Two other generic protocols come up often, more specialised: MIDI, simple and widespread for audio, controllers and macros, but less descriptive than OSC; and Art-Net, which carries DMX over Ethernet for lighting (see below).

AV-specific protocols

The PTZ control classic

VISCA

VISCA is a camera control protocol developed by Sony, historically over RS-232 / RS-422, then extended to VISCA over IP. It drives pan, tilt, zoom, presets, focus, iris, white balance, exposure, menu and power. In Sony's implementation, VISCA over IP relies on IPv4, UDP and port 52381. It is often the most direct protocol to drive a PTZ from a joystick, an automation tool, live software or a hardware controller. Some modern PTZ cameras, such as BirdDog solutions, can be driven over VISCA over IP as well as NDI® PTZ depending on the model.

Strengths

+Very widespread and effective for PTZ
+Compatible with many manufacturers
+Works over IP or serial depending on the model
+Often the most direct path for presets and real-time control

Limits

-Vendor variants: "VISCA over IP" does not guarantee the same ports, commands or feedback
-Behaviours and acknowledgements (ACK) that differ from one brand to another
-Firmware-dependent: an update can change behaviour
-To be tested precisely during integration: port, UDP/TCP, commands, presets, speed

Recommended use

Production PTZ control, especially when you want direct, responsive control. When integrating, always check port, transport, supported commands and ACK feedback for the camera and firmware actually used.

Control carried inside the stream

NDI® PTZ and tally

NDI® is first a system for transporting video, audio and metadata over IP. But it carries a bidirectional metadata layer used in particular for PTZ, tally and KVM. In an environment that is already NDI®, control can therefore travel in the same stream: an NDI® PTZ camera is driven from compatible software, and tally is reported back to the equipment. Even in multicast, a unicast channel can still be used for these bidirectional metadata.

Strengths

+Very convenient if the video is already NDI®
+Automatic source discovery
+PTZ and tally integrated into the stream, less separate control cabling
+Suited to software control rooms, corporate studios and education

Limits

-It is not a universal control bus: it all depends on real equipment support
-Requires a managed network: multicast/unicast, mDNS or Discovery Server, VLAN, bandwidth
-Wi-Fi to be avoided for critical workflows
-Less direct than VISCA when you need fine, deterministic PTZ control

Recommended use

PTZ and tally control within an infrastructure that is already NDI®. For the protocol basics and network sizing, see the Understanding NDI® guide.

More surveillance / VMS than broadcast

ONVIF

ONVIF comes mostly from the world of IP cameras, video surveillance and VMS. It is used to discover, configure and control IP cameras: streaming, profiles, events and PTZ depending on the supported profiles. Profile S targets IP video systems and lets a client configure and control the streaming of a compatible device; Profile T goes further with H.264 / H.265, image parameters, events, metadata and control functions such as client-side PTZ.

Strengths

+Open, interoperable standard between IP cameras and VMS
+Standardised discovery and configuration
+Useful in hybrid AV and security environments
+Client-side PTZ depending on the supported profiles

Limits

-Surveillance-oriented, less tailored to broadcast production
-Function support depends on the profile and the manufacturer
-For a production PTZ, often less direct than VISCA or NDI® PTZ
-Behaviour to be validated per device

Recommended use

Discovering and controlling IP cameras, especially in surveillance or hybrid environments. For a live production PTZ, VISCA or NDI® PTZ often remain more predictable.

Other protocols in pro environments

Protocol	Main use	Key point
TSL UMD	Tally, labels, multiviewers, under-monitor displays	Widely used to carry tally and source names; v5 is oriented toward Ethernet and multiviewers
NMOS IS-04/05/07	Discovery, connection and events in ST 2110	IS-04 discovers network resources, IS-05 handles sender/receiver connections, IS-07 events and tally
Ember+	Audio and broadcast control: consoles, matrices, pro equipment	Open protocol historically driven by Lawo to expose controllable parameters
Art-Net / sACN	Lighting, DMX over Ethernet	Carry DMX512 over an Ethernet network; widely used in lighting and events
GPI / GPO	Simple triggers, tally, redundancy	Dry contact, closure, relay: old but very robust and deterministic
RS-232 / RS-422	Cameras, projectors, matrices, legacy equipment	Reliable and deterministic, but point-to-point and less flexible than IP

How to choose

Need	Orientation
Production PTZ camera	VISCA over IP, or NDI® PTZ if the camera is NDI®
IP or VMS camera	ONVIF
Multi-software show control	OSC, with a show control tool
Drive live software	The software's network API (HTTP, WebSocket, TCP)
Tally and multiviewer	TSL UMD, the switcher API, or NDI® tally depending on context
ST 2110 environment	NMOS IS-04/05/07, optionally Ember+
Lighting and events	DMX, Art-Net, sACN
Critical backup	GPI/GPO, RS-422, dedicated hardware panel

These orientations describe families of solutions, not a single combination: the right choice depends on the equipment in place, the network and how demanding the operating conditions are.

In short

The essentials

There is no universal control bus. In practice, you combine a generic protocol to orchestrate (often OSC or a network API) and AV-specific protocols for the precise functions (VISCA or NDI® PTZ for cameras, TSL UMD for tally, NMOS in ST 2110).

But the decisive criterion is not the number of functions: a control protocol is only truly usable live if it lets you know, directly or indirectly, the state of the controlled equipment.

In this series