User's Manual

vMix User Guide
184 / 208
In the example above Input 2 is active and Input 1 is currently running as Overlay 2.
TCP API
The vMix TCP API provides the same functionality as the HTTP WEB API but with lower processing
overhead making it suitable for use in embedded devices that have limited XML parsing capabilities.
It also provides the ability to subscribe to a TALLY event that will automatically send TALLY updates to the
client.
Preface
The vMix TCP API is designed to be a simple protocol that can be expanded in the future without breaking
compatibility with existing clients.
Therefore it employs a simple text command/response architecture, similar to other standard protocols such
as SMTP.
As a result, fixed length binary structures have been avoided.
The <> symbols in this specification refer to mandatory commands/responses while [] are always optional.
Connection
TCP connection on fixed port 8099
Formatting
All messages are UTF8 encoded and \r\n terminated unless specified otherwise.
This is compatible with ASCII only devices for the vast majority of commands with the exception of those
that might retrieve incompatible characters such as in Titles.
Responses
Responses are space delimited \r\n terminated strings with optional binary data in the following format:
<command> <status/length> [response]\r\n
[data]
Examples:
MYCOMMAND OK This is the response to MYCOMMAND\r\n
MYCOMMAND ER This is an error message in response to MYCOMMAND\r\n
MYCOMMAND 28\r\n
This is optional binary data
MYCOMMAND 28 This is a message in addition to the binary data\r\n
This is optional binary data
Notes:
a. Optional binary data is the exact length specified in <status/length> including additional terminating
characters such as \r\n
which are always appended to the end of multiline text such as from XMLTEXT.
b. Single line responses such as ER should always be expected and handled, even for commands that
usually return binary data.
c. OK (Success), ER (Error) and length are the only three statuses to expect.
Events
Events are responses that can be sent at any time to the client in response to state changes.
All clients should be written to handle any response at any time, as these may be received in the middle of
sending a command but before
receiving that particular commands response. Therefore it is recommended clients operate
"asynchronously" without waiting for a particular command response.