Fino a pochi anni fa, controllare camere Sony significava abitare mondi separati. I PTZ parlavano VISCA su seriale. Le camere broadcast avevano RCP collegati alla CCU con il loro cavo dedicato. Le camere cinema si gestivano a bordo, con al massimo un pannello remoto. Oggi quei mondi si stanno fondendo, e il collante è la rete.
In questo articolo mettiamo in fila i linguaggi di controllo che Sony usa nei vari ambienti di produzione. Vediamo dove si parlano tra loro e cosa significa per chi progetta un impianto.
ProAV e PTZ: VISCA over IP, CGI e FreeD
Il punto di partenza per molti integratori sono i PTZ delle serie SRG e BRC. Il loro linguaggio principale è VISCA over IP, che però non è semplicemente il VISCA seriale messo dentro un pacchetto UDP. Il protocollo Sony aggiunge un header di 8 byte con tipo di payload (comando, inquiry, controllo), lunghezza e un numero di sequenza, e viaggia sulla porta UDP 52381.
Proprio il numero di sequenza è la causa più frequente dei problemi di integrazione. Dopo un riavvio del controller, la camera può ignorare i comandi finché la sequenza non viene resettata, e non tutti i software di terze parti gestiscono bene questo passaggio. C’è poi un tema di compatibilità: molti produttori dichiarano il supporto a “VISCA over IP”, ma usano TCP o VISCA senza header. La stessa sigla non garantisce che due apparati si parlino davvero. Anche la configurazione degli indirizzi segue un meccanismo Sony, basato su broadcast UDP sulla porta 52380, che è quello usato dai tool di setup e dai controller.
Accanto al VISCA c’è l’interfaccia CGI su HTTP, con autenticazione digest. È meno adatta al movimento in tempo reale, ma perfetta per l’integrazione con sistemi di controllo, perché consente di leggere lo stato completo della camera oltre a inviare comandi. In pratica, VISCA serve per muovere e CGI per configurare e interrogare.
Sul lato hardware, il riferimento è l’RM-IP500, che può gestire fino a 100 camere Sony BRC o SRG via IP e supporta fino a cinque pannelli sulla stessa rete.
Cinema Line: SDK, app e la camera ponte
Le camere Cinema Line compatte, come FX6, FX3 e FX30, si controllano principalmente con il Camera Remote SDK di Sony, che lavora via USB o via rete, e con le app ufficiali. È il terreno di chi sviluppa software su misura.
L’FR7 merita un discorso a parte, perché è la vera camera ponte dell’ecosistema. Da un lato parla VISCA over IP come un PTZ, e quindi entra in qualsiasi impianto ProAV. Dall’altro può essere controllata collegando via cavo LAN un RCP come l’RCP-3500/3501, un MSU come l’MSU-3500 o un adattatore di rete come il CNA-2. In pratica, una camera cinema su testa PTZ che in regia si pittura come una camera da studio.
Tracking e metadati: FreeD e OpenTrackIO non sono controllo
Prima di proseguire conviene mettere da parte due protocolli che spesso finiscono nello stesso elenco degli altri, ma che fanno un mestiere diverso. VISCA, CGI e S700 servono a comandare la camera: muovi, chiudi il diaframma, cambia il gain. FreeD e OpenTrackIO vanno nella direzione opposta: escono dalla camera e portano metadati a un altro sistema, tipicamente il motore grafico. Nessuno dei due muove una camera, e in un impianto vanno progettati come un flusso dati a sé, spesso con requisiti di sincronismo e di rete propri.
FreeD è lo standard di fatto della virtual production. La camera invia su UDP i dati di pan, tilt, zoom e fuoco, che il motore grafico usa per muovere la camera virtuale in modo coerente con quella reale. È supportato dai PTZ Sony più recenti e dall’FR7, e in genere richiede una calibrazione dell’ottica per essere davvero utilizzabile.
OpenTrackIO è il passo successivo, ed è arrivato sull’FR7 con il firmware 4.0, disponibile da febbraio 2026. È uno standard aperto per il tracking camera in virtual production, sviluppato dal gruppo SMPTE RIS OSVP, e permette la sincronizzazione e l’uscita in tempo reale di dati di tracking, informazioni sull’ottica, dati di ripresa e posizione 6DoF rispetto all’origine della scena CG. Il punto pratico è come ci si arriva: il protocollo si collega a Unreal Engine con un singolo cavo Ethernet, senza bisogno di plug-in di terze parti.
I quattro vantaggi che Sony mette in evidenza dicono bene cosa cambia sul set: si lavora senza tracker esterni, senza calibrazione dell’ottica, con sincronizzazione del timecode e con calibrazione spaziale in un solo passaggio. Chi ha montato un sistema di tracking tradizionale sa quanto pesino quelle quattro voci in termini di tempo di allestimento e di personale specializzato.
Un dettaglio utile per chi deve far convivere i due mondi: nel firmware 4.00 dell’FR7 i valori di posizione (offset sugli assi X, Y e Z) e di orientamento (angoli di pan, tilt e roll) sono uniformati tra OpenTrackIO e FreeD, e la stessa versione amplia le funzionalità di uscita dei dati di tracking FreeD. In pratica si può passare da un protocollo all’altro senza rifare le convenzioni di sistema.
Nota operativa: pianificate questo flusso insieme al reparto grafica, non solo con il reparto camere. Banda, latenza, timecode e posizione del motore grafico nella topologia di rete vanno decisi prima, perché il tracking tollera molto meno del controllo.
CineAlta: BURANO e VENICE 2 entrano nella multi-camera live
Sulla BURANO il controllo da RCP è supportato a partire dal firmware 1.1. Il nome della funzione è eloquente: S700 Protocol over Ethernet, che permette il controllo remoto della BURANO tramite un RCP. È il protocollo delle camere broadcast Sony che arriva, su rete, su una camera cinema. Con la versione 2.0 sono arrivati il controllo del filtro ND variabile dall’RCP e il controllo del tally da dispositivi esterni collegati via LAN cablata. Sul fronte app, la versione 1.1 supporta Monitor & Control 2.0, con monitoraggio multi-camera su iPad fino a quattro camere, strumenti di esposizione e controllo del fuoco.
La VENICE 2 nasce invece con il controllo remoto su cavo, e la sua integrazione nel mondo IP passa dal CNA-2. Dal firmware V5.0, con CNA-2 V1.30 o successivo, la VENICE 2 guadagna la conversione LAN tramite CNA-2 e può essere integrata nei sistemi di rete delle camere.
C’è un aspetto da tenere presente quando si porta una camera cinema in un flusso broadcast: sotto RCP non si comporta come una HDC. Sulla BURANO, in modalità Cine EI si possono gestire solo iris, bianco (tranne ATW), ND, tally e call, e con ottiche PL l’iris si può solo leggere, mentre con le E-mount si può anche controllare. Chi arriva dal broadcast deve saperlo prima della diretta, non durante. Sony ha raccolto tutti questi dettagli nella CineAlta Remote Control Guide, che copre VENICE, VENICE 2 e BURANO e che consigliamo di tenere a portata di mano.
Broadcast: il pannello diventa un nodo di rete
Nel mondo delle system camera HDC il cambiamento è meno visibile ma altrettanto profondo. L’RCP-3500 si può collegare con un cavo LAN oltre che con il tradizionale CCA-5, e il sistema può essere costruito su una connessione 1000Base-T con supporto PoE. Il pannello smette di essere un terminale punto-punto e diventa un nodo di rete, assegnabile e riassegnabile.
CNA-2: l’hub e il traduttore
Se c’è un oggetto che riassume la strategia Sony, è il CNA-2. Sulla carta è un adattatore di rete per il controllo camera. In realtà fa quattro mestieri.
Traduttore di protocollo. Il CNA-2 traduce il protocollo proprietario Sony 700PTP da e verso il Simple Protocol, per lavorare con dispositivi di terze parti, e permette anche di tradurre il 700PTP da e verso il cavo CCA. È la porta d’ingresso per sistemi di automazione, tally e pannelli custom.
API per integratori. Con la licenza HZC-GWCN2, la Web API permette di gestire impostazioni di formato, painting delle camere, assegnazione degli RCP e anteprime in un ambiente di produzione distribuito.
Pannelli nel browser. Con la licenza WEB-RCP si controllano fino a 12 camere direttamente dal browser di un PC o tablet, senza applicazioni dedicate. Il WEB-MSU porta nel browser gestione di sistema, configurazione dei parametri e gestione dei file, con collaborazione simultanea di più utenti.
Hub di sistema. Nell’architettura GMCS le camere sono raggruppate in domini logici, assegnabili a un singolo studio o a un OB van, con monitoraggio centralizzato e controllo remoto su più domini. Attenzione alle versioni: GMCS richiede il firmware 1.1 o successivo del CNA-2 e può richiedere un aggiornamento anche lato camera.
Completano il quadro l’affidabilità da impianto broadcast, con due porte LAN per la ridondanza, alimentazione PoE, alert, monitoraggio della fibra e controllo degli errori.
Focus CNA-2: sette funzioni e cosa risolvono davvero
Le schede tecniche elencano le funzioni. Qui proviamo a tradurle in quello che cambia sul lavoro di tutti i giorni.
Il CNA-2 come dispositivo master MCS. Usando il CNA-2 come master del sistema di rete delle camere si gestisce l’MCS senza ricorrere a una MSU. È la funzione che abbassa la soglia d’ingresso al mondo networked: uno studio da quattro o sei camere, o un OB van medio, può avere gestione centralizzata, assegnazione dei pannelli e file di setup senza mettere a budget una MSU e senza trovarle spazio in regia. Gli RCP restano quelli, la configurazione si fa dal menu web.
GMCS Domain Manager: più domini e un manager ridondato. Oltre alla modalità MCS tradizionale c’è la modalità GMCS, che abilita gestione multi-dominio e ridondanza del manager. Il primo aspetto serve a chi ha più ambienti: studio A, studio B e OB van diventano domini logici distinti, ognuno autonomo, ma visibili e controllabili da un unico punto quando serve condividere camere tra produzioni. Il secondo aspetto è quello che interessa al responsabile tecnico: il manager non è più un singolo punto di guasto, perché un secondo CNA-2 può subentrare. In un impianto fisso che lavora sette giorni su sette, è la differenza tra un guasto e un fermo trasmissione.
Conversione da CCA a LAN: il parco esistente entra in rete. Collegando il CNA-2 alla rete via LAN e la CCU o l’RCP al CNA-2 con cavo CCA, quei dispositivi entrano nel sistema di rete senza essere collegati direttamente alla LAN. È la funzione che rende possibile una migrazione per gradi. Non serve sostituire tutti i pannelli il primo giorno: si porta in rete l’infrastruttura, si aggiungono le camere nuove, e il materiale esistente continua a lavorare accanto a loro. Per chi deve giustificare un investimento, è l’argomento più forte di tutto il sistema.
Conversione del trasporto: due CNA-2 per reti ad alta latenza. Con due unità CNA-2 si può lavorare in ambienti di rete caratterizzati da latenze elevate. In pratica è la coppia di apparati che rende praticabile il controllo camera su un collegamento geografico, dove il traffico di controllo nativo soffrirebbe. È il prerequisito tecnico di qualsiasi scenario in cui l’operatore di shading non è nello stesso edificio delle camere.
Conversione di protocollo tra MCS e GMCS. Il CNA-2 converte tra il sistema tradizionale e quello di nuova generazione. Serve nel momento più delicato, cioè quando si convive: una parte dell’impianto è già passata a GMCS, un’altra è ancora MCS, e devono lavorare insieme nello stesso evento. Permette di pianificare l’aggiornamento in più stagioni invece che in un unico fermo macchina.
Dashboard di monitoraggio. Lo stato del sistema è monitorato in continuo dal menu web del CNA-2, che consente di rilevare anomalie e segnali premonitori di malfunzionamento. È la funzione meno spettacolare e forse la più utile: una fibra che inizia a degradare o un contatore di errori che cresce si vedono prima della diretta, non durante. Per un service o un rental è anche un argomento commerciale, perché permette di documentare lo stato dell’impianto al cliente e di programmare la manutenzione invece di subirla.
Produzione live distribuita. Collegando tramite CNA-2 sistemi che si trovano in località diverse si realizza una produzione live distribuita. È il punto in cui tutte le funzioni precedenti si sommano: domini in sedi diverse, conversione di trasporto sul collegamento geografico, monitoraggio centralizzato. Il modello operativo che ne esce è quello che molti broadcaster stanno già adottando, con le camere e pochi tecnici sul posto e il controllo qualità immagine nella sede centrale.
Cosa verificare prima di preventivare. Le licenze necessarie per Web API, Web RCP e Web MSU, le versioni firmware minime di CNA-2 e camere (GMCS richiede la 1.1 o successiva), il budget PoE dello switch, la VLAN di controllo e, per gli scenari distribuiti, la latenza e la banda reali del collegamento tra le sedi.
Quando anche il segnale diventa IP
Nel broadcast full IP, il controllo camera convive con gli standard aperti. L’HDCE-TX50 trasmette i segnali dalla testa camera via rete IP, secondo la famiglia SMPTE ST 2110, alla CCU situata in un centro di produzione remoto. Il vantaggio per chi gestisce gli impianti è che, mentre in SDI una camera è legata alla sua CCU dalla fibra, qui camere, CCU e altri apparati si riconfigurano via IP senza ricablare.
Sul fronte delle camere native IP, l’HDC-P50A, con la licenza opzionale HZC-SFP5A, esce direttamente in ST 2110, è compatibile con AMWA NMOS e supporta il tally IP. Qui il controllo si divide in due livelli. NMOS gestisce in modo standard discovery e connessioni dei flussi, mentre il painting e il controllo della camera restano nel linguaggio Sony.
Mettiamo tutto insieme in un evento live. Due PTZ per i totali, un FR7 sul palco, una BURANO a spalla per il look cinematografico, una VENICE 2 come camera principale e una HDC in regia. Su una VLAN dedicata al controllo, l’RM-IP500 muove i PTZ e l’FR7 in VISCA over IP. Gli RCP-3500 pitturano FR7, BURANO e HDC in S700 e la VENICE 2 attraverso il CNA-2. Un tecnico in remoto lavora con il Web RCP dal tablet, mentre il sistema di tally e l’automazione dialogano con il CNA-2 tramite Simple Protocol. Companion, infine, orchestra macro e scene, parlando VISCA e CGI con i PTZ e la Web API con il CNA-2.
Cinque camere di tre famiglie diverse e un unico linguaggio di painting. Pochi anni fa questo impianto avrebbe richiesto cablaggi dedicati e operatori specializzati per ciascun mondo.
Consigli pratici per la rete
Qualche regola che vale in tutti gli scenari:
- Tenete il controllo su una VLAN dedicata, separata dai flussi video (NDI, SRT, ST 2110). Ricordate però che i meccanismi di discovery basati su broadcast non attraversano le VLAN.
- Preferite indirizzi statici per camere, pannelli e CNA-2. In diretta, un lease DHCP scaduto è un problema che nessuno vuole diagnosticare.
- Documentate le versioni firmware. Molte funzioni citate qui dipendono da versioni minime, sia delle camere sia del CNA-2.
- Verificate i PoE budget degli switch quando alimentate RCP e CNA-2 dalla rete.
In sintesi
| Linguaggio | Ambiente | Trasporto | Apertura verso terze parti |
|---|---|---|---|
| VISCA over IP | PTZ, FR7 | UDP 52381 | Documentato |
| CGI | PTZ | HTTP | Documentato |
| Camera Remote SDK | Cinema Line, Alpha | USB, rete | SDK pubblico |
| S700 su Ethernet | HDC, FR7, BURANO, VENICE 2 via CNA-2 | LAN | Proprietario |
| Simple Protocol e Web API | Tramite CNA-2 | LAN, HTTPS | Per integratori, su licenza |
| NMOS | Broadcast ST 2110 | HTTP | Standard aperto |
E, separatamente, i protocolli che non comandano la camera ma ne trasportano i metadati:
| Protocollo | Ambiente | Trasporto | Apertura verso terze parti |
|---|---|---|---|
| FreeD | PTZ recenti, FR7 | UDP | Standard di fatto |
| OpenTrackIO | FR7 dal firmware 4.0 | Ethernet, verso Unreal | Standard aperto SMPTE RIS OSVP |
Sony sta portando tutto il controllo camera su IP con due anime. Una è aperta e documentata, pensata per integratori e sviluppatori. L’altra è proprietaria e ottimizzata per il broadcast. Il CNA-2 è il punto in cui si incontrano, e l’FR7 è la camera che le parla entrambe. Per chi progetta impianti, la domanda non è più quale sistema scegliere, ma come far dialogare tutti i mondi sulla stessa rete.
