proposal for carriage of Visca Protocol over NDI

This page contains a technical proposal which is not currently a published or formal standard. If you have comments or feedback on the content of this proposal PLEASE contact us with your contribution.


The NDI IP Video protocol SDK incorporates a set of highly standardised PTZ camera control messages which are widely implemented.  However, many cameras feature a considerably wider array of controls than that currently offered by NDI within the standard NDI PTZ Protocol.  To extend this capability and allow for complete remote control of sophisticated broadcast cameras over an NDI connection, this proposal adds a standardised wrapper to carry Visca control data over NDI by way of a recommended practice technical note.


Basic Premise:

The focus is based on the need for remote control of camera shading functionality over NDI connections, and over NDI over WAN extended connections for remote sports camera backhaul and other workflows.


- The Sony Visca protocol offers extensive support for all aspects of camera control in a standardised and well understood protocol.


In this proposal, the Visca data is sent using dedicated metadata messages already defined in the NDI Protocol, the same type used for PTZ control of cameras, and NDI specific tally information.  It uses the real time (non frame based) NDI Metadata stream, with Visca Control data enclosed.  Raw Visca  message data is encoded in hexadecimal text format before being wrapped in the XML tag.


Sent Messages are wrapped in the outer XML tag VISCA_MSG. Each message contains a seq attribute, which increments for each message, and must be included in asynchronous status in order to provide context of returned async status.


For  messages, where a 'reply' is required - the return data is sent asynchronously on the reverse NDI metadata channel, along with sufficient information to give the async data its context, using the XML tag VISCA_REPLY. In this mechanism, all operations must be asynchronous and control systems must be designed with this in mind.


Where a command is sent expecting a reply - the control system should typically wait for the reply before proceeding with additional commands.


NDIlib_metadata_frame_t meta_data

meta_data.p_data =

<VISCA_MSG seq="21">...........</VISCA_MSG>

<VISCA_REPLY seq="21">...........</VISCA_REPLY>


Example : CAM_BackLight Compensation ON Visca Command


<VISCA_CMD seq="22">8101043302FF</VISCA_CMD>



This protocol is designed to co-reside alongside the existing NDI PTZ Protocol. Where messages for both protocols are received, devices should respond to both.


This protocol can be used in either direction on NDI connections, but will most typically be used as return commands from an NDI Reciever talking to an NDI Source which can be directly or indirectly controlled with Visca commands.


NB: The VISCA_CMD includes the first byte which includes the camera ID, but given the dynamic nature of NDI, and since this messaging is indirect to the end Visca device it is anticipated that the NDI Device processing the VISCA_CMD may alter the camera ID to target a camera configured within the receiving system when emitting the real Visca command.  NDI-VISCA is discrete to a single NDI Stream - and as such could be considered a single channel system.   Systems which override the camera ID when sending Visca should take care to also override the return message from the camera in order that the system sending the NDI-VISCA command gets a response with the same camera ID as it was sent with.


If you have any questions, or you would like to engage Sienna for NDI Consultancy or Custom Development, please contact info @ sienna.tv