PTZ Camera System Design: Video, Control, and Power

The three-path model: every PTZ is three systems

PTZ means pan, tilt, zoom, the three motions the camera makes on command instead of an operator on the handle. For that to work, three separate things have to be true at once: a command has to reach the camera, the picture has to leave it, and the motors and sensor have to be powered. Those are three independent paths, and a design that tracks only the video quietly forgets the two paths that strand a camera on show day.

Over IP the three paths can share one physical cable, which is exactly why they get missed. One RJ45 looks like one connection. It is still doing three jobs, and each job has its own limit, its own document, and its own way to fail. Separate them on paper first, then decide how they share cable.

The three paths at a glance

Each path uses a different carrier, lands in a different document, and fails in a different way. Get all three on the drawing before you spec a single cable.

The whole reason a port-aware tool helps here is that these three paths overlap on the same devices. In WireFlow each PTZ carries its real ports, video out, a control connection, and a power input, so one diagram can show all three layers and derive the cable schedule, power report, and IP schedule from the same source instead of three drawings that drift apart.

NDI or SDI for the video path?

This is the decision that shapes the rest of the system, because it decides whether the video path is its own dedicated run or shares the network with everything else.

• SDI is a dedicated coax per camera, one direction, built for long runs and deterministic behavior. It does not touch a network, so nothing else can congest it, but it carries only video, so control and power still need their own paths.
• NDI puts the video on the IP network alongside your data, control, and often power. One cable per camera can carry all three, which is its whole appeal, but the picture now depends on the network being sized and configured correctly.
• HDMI shows up on smaller or consumer PTZ cameras. It is fine for a short run to a nearby switcher, but it needs an extender or a converter for any real distance, and that converter has to make the gear list.

Choose SDI when you want a run you do not have to trust a network to protect, or when the switcher and router are already SDI. Choose NDI when you want one cable per camera position and you control the network it rides on. Plenty of rooms mix both and convert at the edges, which is fine as long as every format transition is drawn and every converter is on the list.

Control topology: daisy-chain vs star

The control path gets wired one of two ways, and the choice usually follows the video decision.

• Serial daisy-chain (VISCA over serial): the controller feeds camera 1, camera 1 passes through to camera 2, and so on down the chain. Each camera is set to a unique address on the chain. Fewer cables, but a break or a duplicate address takes out everything downstream of the fault.
• IP star (VISCA over IP): every camera sits on the network and the controller addresses each one by IP. Cameras are independent, so a single fault drops one camera, not the chain. When the video is NDI, this is the same star the video and power already ride.

Either way, the control path is real and belongs on the diagram next to the video and power. Draw the controller as a device, draw its connection to each camera, and record the address, a serial position on a chain or an IP on the network. That record is what stops two cameras answering to the same command.

When one cable carries power, video, and control

Take an NDI camera powered by PoE, and one RJ45 to the switch now carries power in, video out, and control both ways. Physically it is a single cable. Logically it is still three paths, and the diagram has to keep showing three even though there is one wire.

This is what changes about the drawing: the switch becomes the one point that has to satisfy all three paths at once. It has to deliver the PoE that camera pulls, carry the NDI video with bandwidth to spare, and route the control traffic, ideally on a planned VLAN so the video does not fight the rest of the network. One under-sized switch strands the entire camera position, not just one path. Plan the network and the power together: see VLAN planning for AV systems for the traffic side and PoE budget planning for the power side.

How to document a multi-PTZ system, step by step

The method is the same left-to-right signal flow as any diagram (see how to create an AV signal-flow diagram for the base technique), with the control and power layers added deliberately instead of assumed.

1. List every camera and its position. For each, note the video format it outputs, the control method (serial address or IP), and how it is powered (PoE or local).
2. Lay cameras as sources on the left, the controller and network switch in the middle, and the switcher, recorder, and stream on the right.
3. Draw the video path from each camera to the switcher or router, port to port, in that camera's actual format, and mark any format conversion with the converter that handles it.
4. Draw the control path from the controller to each camera, serial chain or IP star, and assign every camera a unique address as you go.
5. Draw the power path. Mark which cameras are PoE and which are local, and add each PoE camera's draw to the switch budget.
6. Where a camera is NDI over PoE, note that one cable carries all three paths, but keep the three connections visible so each derived document still sees its own.
7. Walk each path end to end: every camera has power, a picture that lands on a real switcher input, and a control address nothing else shares.

For a full worked build that carries these cameras through switching, audio, record, and stream, walk the multicamera livestream signal flow example, and check connecting devices and ports for the port-to-port mechanics in the builder.

Common PTZ mistakes and how to catch them

• Duplicate control addresses. Two cameras at the same serial address or IP, and the controller drives both or neither. Assign addresses on paper first, then verify each one is used exactly once.
• PoE budget exceeded. Every camera fits a port, but the switch's shared PoE pool runs dry, and cameras drop out under motion when draw peaks. Size the switch against total draw with headroom, not just the per-port class.
• Mixed formats never converted. An HDMI camera aimed at an SDI input, or an NDI camera with no path onto an SDI router, needs a converter, and that converter is real gear that has to appear on the list.
• The control path never drawn. Video and power get documented, control gets assumed, and the joystick that does nothing on show day was never on the diagram in the first place.
• The network treated as free. NDI video, IP control, and PoE all landing on a switch that was sized for none of them. Over IP, the switch is the system, so plan its VLAN, bandwidth, and PoE budget as one job.

Frequently asked questions

Do PTZ cameras need a separate cable for control?

Not always. Over IP, one network cable can carry video, control, and power together (NDI plus VISCA over IP plus PoE). Over SDI or HDMI, the video runs on its own coax or HDMI cable and control runs separately, on a serial chain or a second network connection. Either way the control path exists and gets documented, whether or not it has its own cable.

What is VISCA and do I need it?

VISCA is the control protocol most PTZ cameras and controllers speak, giving a joystick commands for pan, tilt, zoom, and presets. It runs two ways: over serial, as a wired chain of addressed cameras, or over IP, with each camera addressed on the network. A PTZ needs some control protocol to be useful, and VISCA is the common one. Check each camera's manual for its exact addressing and pinout.

SDI or NDI for a PTZ system?

SDI when you want a dedicated, deterministic run per camera and a network you do not have to trust. NDI when you want one cable per camera carrying power, video, and control and you control the network it rides on. Many rooms mix both and convert at the edges. The deciding numbers, cable length and bandwidth, live in the camera and switch datasheets, not in a rule of thumb.

How many PTZ cameras can one PoE switch power?

However many its total PoE budget covers, not however many ports it has. A PTZ pulls more while panning and tilting than sitting still, so size against peak draw with headroom and confirm the switch's shared pool, not just the per-port class. Working through a PoE budget before load-in is the way to avoid cameras dropping under motion.

Can I control PTZ cameras over the same network as the video?

Yes, and over IP that is the normal setup: NDI video, VISCA over IP control, and PoE power can share one cable to one switch. The catch is that the switch now has to satisfy all three at once, so plan the VLAN, bandwidth, and PoE budget together rather than treating the network as free capacity.

Build this diagram in WireFlow

Port-aware devices, validated connections, and exports your crew can read on site. Free plan includes three editable diagrams, no credit card.

Start a free diagram · Explore the sample show first