Disguise System Network Configuration Guide
Within the Disguise Ecosystem, live shows can increase in complexity and require large amounts of integration with third-party systems. The information below outlines workflows and best practices developed by our dedicated show support teams and freelancer community.
Creating a robust, efficient, and secure network infrastructure is a critical aspect of designing a show system. Disguise Video System designers often need to integrate with a wide variety of devices and technologies. A well-planned network ensures flexibility, precise control, and smooth collaboration across different teams and equipment.
When designing a system, careful consideration should be given to traffic management and access permissions. For example, guest stage engineers might not need access to NDA-protected content on the content network, while lighting engineers may require access to camera streams or internet connectivity. Balancing these requirements is key to ensuring a secure and streamlined operation.
Given that Disguise machines, as part of a video infrastructure, typically utilise large network traffic, especially with protocols like ST2110 or Consistent Media Transfers, it is important to accommodate their significant data demands.
Fast, stable, and secure connections are the cornerstone of effective network design.
What Can Go Wrong in shows?
-
Physical Failures: Network cables are susceptible to physical damage (e.g., tripping hazards, accidental unplugging, or wear and tear). Redundant cabling ensures continuity if a primary cable fails.
-
Seamless Failover: With properly configured redundancy (e.g., using LACP or failover policies), the transition between primary and secondary cables can occur without interruption, ensuring event continuity.
Utilizing both VLANing and teaming, along with switch stacking, can help mitigate risks and enhance network resilience in the event of issues.
Below, we outline some of the major network types and their use cases within a live show environment.
Key Networks in a Show System
In the tables below, there is a brief description of a range of common network devices you will most likely encounter in a larger Disguise system.
This information provides an outline of each use case and bandwidth considerations.
1. d3Net
Aspect | Details |
---|---|
Purpose | Facilitates communication between Disguise machines and editors. |
Traffic | Low, but speed is crucial (1Gb/10Gb networking recommended). |
Requirements | Dedicated network to ensure quick and reliable machine-to-machine communication. |
2. KVM Net
Aspect | Details |
---|---|
Purpose | Supports KVM (keyboard, video, mouse) systems with high PoE requirements. |
Traffic | High; can saturate a network switch backbone. |
Usage | Often shared across departments or used locally in large installations. |
3. Media Net
Aspect | Details |
---|---|
Purpose | Handles large video file transfers (200–300GB or more). |
Traffic | Extremely high; 25Gb/100Gb networking or trunked 10Gb uplinks are ideal. |
Requirements | Critical for time-sensitive file transfers, often shared with third-party designers. |
4. Automation Net (PSN)
Aspect | Details |
---|---|
Purpose | Used for communication with automation systems. |
Traffic | Low, but reliability is essential. |
Usage | Typically shared with automation teams for precise control. |
5. NDI Net
Aspect | Details |
---|---|
Purpose | Manages multicast streams like NDI (Network Device Interface). |
Traffic | Very high; a few 4K streams can saturate a 1Gb uplink. |
Requirements | Requires a high-capacity network to support demanding video streams. |
6. Internet
Aspect | Details |
---|---|
Purpose | Provides internet access for editors, utility equipment, and guests. |
Traffic | Variable, depending on usage. |
Access Control | Often restricted for Disguise machines to maintain security. |
7. sACN/Artnet
Aspect | Details |
---|---|
Purpose | Shares data with lighting systems. |
Traffic | Moderate to high; up to 64 universes (100Mb traffic). |
Characteristics | Traffic can be spammy; requires careful management. |
8. OSC/Control
Aspect | Details |
---|---|
Purpose | Facilitates control interfaces for lighting, stage management, iPads, and other devices. |
Traffic | Low (TCP/UDP messages). |
Requirements | Needs visibility across all connected networks. |
9. OmniCal
Aspect | Details |
---|---|
Purpose | Supports the Omnical calibration system. |
Traffic | Moderate but complex; best kept on a separate network. |
Usage | Requires precise communication for accurate calibration. |
10. PTZ Camera Control
Aspect | Details |
---|---|
Purpose | Manages pan-tilt-zoom camera systems. |
Traffic | Similar to other control networks. |
Usage | Can often share resources with OSC or control networks. |
11. MGMT (Management)
Aspect | Details |
---|---|
Purpose | Provides access to network switches and third-party devices. |
Traffic | Low; primarily used for configuration and monitoring. |
Requirements | Best kept secure and separate to avoid interference. |
12. RenderStream
Aspect | Details |
---|---|
Purpose | Used for Disguise communication and streaming with rendering engines. |
Traffic | High bandwidth for uncompressed streams; lower with reduced bit depth and frame rates. |
Requirements | 25Gb/100Gb fibre recommended for uncompressed streams, typically using Disguise Fabric. |
d3Net Backbone
d3Net is a core component of Disguise’s infrastructure, serving as the backbone for networked communication within a Disguise session. It plays a crucial role in synchronising multiple Disguise servers, ensuring frame-accurate playback across a connected system.
d3Net enables:
- Remote communication between Disguise media servers. (Launch, Quit, Reboot etc.)
- Remote display management.
- Timeline and playback synchronisation.
- Failover and redundancy.
- Resource Transport to keep the project state in-sync between editors, actors, understudies and directors.
- Content synchronisation within Disguise.
- Renderstream workload control (Launch, Stop etc.)
- Multi-editor workflows.
d3Net must be configured to enable all Disguise servers and editors to access the same d3Net network. We suggest keeping the d3Net isolated from other networks to ensure seamless communication between all machines and to prevent any surrounding network issues from affecting Disguise operation. This also means that after a re-image, network settings can be recreated quickly, and as a result, network issues are simpler to debug and support.
Read more about d3Net on the d3Net Overview page.