Connessioni alle telecamere: chi apre un flusso RTSP¶

Analisi del 29/10/2026 sul codice (mdm_installation linee main e stage, mdm_frigate_wrapper, mdm_web_panel branch dev), sulla configurazione Frigate di riferimento della guida di installazione, sul traffico letto in pfSense il 27/10, sulla call dell'8 aprile 2026, sulla configurazione di OME in mdm_mid_server (server_data/ovenmediaengine/Server.xml), sulla risposta di Mohammad del 29/10 (proposta DVR concordata con Marco) e sulla documentazione pubblica di Frigate e go2rtc. Prime misure sulla telecamera di laboratorio il 29/10 (vedi sotto); le telecamere e gli impianti dei clienti non sono ancora stati misurati (ticket MDM-037).

Il problema¶

Le telecamere IP accettano poche sessioni RTSP contemporanee, di solito 2–6 a seconda di marca, modello e flusso (principale o secondario). La gestione delle sessioni pesa sulla CPU della telecamera, non sul codificatore video. Oltre il limite la telecamera rifiuta la connessione nuova, oppure chiude una già aperta, perde fotogrammi o si riavvia. Se perde la connessione il detector, l'impianto smette di rilevare finché il detector non si ricollega. In un sistema di allarme questo è il rischio più grave.

Setup attuale¶

Box con Frigate¶

Frigate gira in rete host (docker-compose.yml), quindi il suo go2rtc ascolta sulla porta 8554 del box. Le telecamere possono essere configurate in due modi, e oggi convivono entrambi:

	Hub go2rtc	Diretto
Come	la telecamera sta in `go2rtc.streams`; Frigate legge `rtsp://…@localhost:8554/<telecamera>`	Frigate legge l'URL della telecamera in `ffmpeg.inputs`
Chi lo crea	wrapper Frigate, `add_camera` (`mdm_frigate_wrapper/src/services/frigate_config/service.py`), chiamata `/frigate/add` del pannello	dialogo Add Camera della pagina Frigate del pannello (`config.controller.dart`), configurazione di riferimento della guida, configurazione di default della linea `stage`
Connessioni verso la telecamera	1 per flusso, condivisa da Frigate, centrale e chiunque legga dalla 8554	1 di Frigate, più una per ogni altro lettore
La centrale può leggere dal box	sì, sulla 8554	no: deve andare sulla telecamera (554)

Situazione reale (censimento delle telecamere del 29/10, 24 box Frigate, 235 telecamere): - solo 4 box su 24 hanno go2rtc configurato (49 telecamere, 3 box per tutte e 1 per una parte); negli altri 20 box Frigate legge direttamente dalla telecamera o dal DVR, e non esiste nessuno stream go2rtc; - nei box con go2rtc quasi tutti gli stream hanno 1 lettore (Frigate stesso); solo 6 ne hanno 2; - in 11 impianti Frigate legge già da un probabile DVR/NVR (12 apparati, 86 telecamere): in quei casi le sessioni verso le telecamere sono del DVR, non del box.

Correzione del 29/10: in precedenza questa pagina deduceva dal traffico in pfSense (circa 120 connessioni dalla centrale verso la porta 8554 dei box, 27/10) che la maggioranza degli impianti usasse l'hub go2rtc. Il censimento lo smentisce: quel traffico non si spiega con gli stream go2rtc esistenti e va ricontrollato in pfSense (destinazioni e orari; MDM-037).

Il pannello rispetta la scelta quando si modifica l'URL (se esistono stream go2rtc cambia quelli, firgate_config.entity.dart). Quando si aggiunge una telecamera dal dialogo, però, crea sempre un ingresso diretto, anche su un box che usa l'hub.

Box con GANZ¶

Qui "GANZ" è l'apparato di analisi (interfaccia AI SOURCES, porta 8443), non il software di registrazione per Windows GANZ CORTROL.

Il container Frigate parte solo con il profilo frigate: sui box GANZ non c'è go2rtc. Il GANZ apre la propria connessione verso ogni telecamera (Video Source, protocollo TCP).

Il GANZ di laboratorio (192.168.200.164, "AI Box") non ripubblica i flussi: sono aperte solo le porte 80 e 8443, mentre 554 e 8554 sono chiuse (29/10). Ogni altro lettore (centrale, live MDM) va quindi direttamente sulla telecamera. Secondo la scheda tecnica GANZ AI Box V2.0, giugno 2023 l'AI Box V2.0 ha un'uscita RTSP annotata solo in modalità 8 canali (non in quella a 16): da verificare con Michele in che modalità lavorano i GANZ installati (M-12). Anche se disponibile, sarebbe il video con le annotazioni dell'analisi, non il flusso originale.

Correzione del 29/10: una prima versione di questa pagina attribuiva al GANZ l'indirizzo RTSP /unicast/c<n>/s<m>/live e un limite di 4 sessioni. Erano invece della telecamera di laboratorio 192.168.200.166, canale 1 del GANZ (prove).

Live del sistema nuovo (OME), uguale per Frigate e GANZ¶

Il box legge l'URL scritto a mano in webrtc_streams e a ogni avvio di un live (live_stream_service.py, stage; stessa sequenza di trasporto in web_rtc_handler.py, main):

ffprobe in UDP con timeout di circa 1–3 s (rtsp_transport_util.py);
se fallisce, ffprobe in TCP;
solo nella linea stage/3.9, fino al 30/10: ffprobe per l'audio (_ensure_audio_stream). Tolto: ora audio_supported viene dall'avvio di ffmpeg stesso (modifica locale, non ancora committata);
ffmpeg che resta aperto e manda il flusso a OME.

Più spettatori dello stesso live riusano lo stesso ffmpeg (active_connections). Lo snapshot non apre connessioni: passa dalle API di Frigate o del GANZ (/api/snapshot/jpeg/).

webrtc_streams è volutamente separato dalla configurazione del detector: il flusso del live si sceglie per ogni telecamera, indipendentemente da quello che usa il rilevamento (Mohammad, 29/10). È il punto in cui si decide da dove legge il live.

Dal box al browser: il box copia, OME transcodifica¶

Box: ffmpeg non ricodifica il video (-map 0:v:0 -c:v copy, in main e stage). Converte solo l'audio in AAC, che è leggero (main e, dal 30/10, stage: -map 0:a? -c:a aac -b:a 128k -ar 48000; prima la stage lo mappava solo se il probe trovava l'audio). Il flusso esce dal sito alla risoluzione e al bitrate della sorgente: dal GANZ di laboratorio, per esempio, 2560×1440.
OME: ogni flusso ricevuto viene transcodificato in H.264 720×460, 15 fps, 2 Mbit/s, con audio AAC e Opus. Il passaggio diretto senza ricodifica (bypass_video) è commentato. Non c'è accelerazione hardware (HWAccels disattivato). È così nel Server.xml di main e di refactor/v1; da confermare che sia la configurazione realmente caricata sui server.
Conseguenze:
il costo della transcodifica è sul server di OME, non sul box: una decodifica e una codifica per ogni telecamera in live, che con la griglia diventano molte insieme;
la banda in uscita dal sito è quella del flusso originale;
il browser riceve sempre H.264, quindi anche una sorgente H.265 si vede, a costo di CPU sul server.

Più operatori sulla stessa telecamera (qAlarm e pannello MDM)¶

Verificato su qAlarm2_fe (OvenPlayerWrapper.tsx, cameraApi.ts), qAlarm2_be (routes/mdm/camera.py, repo_impl/mdm_installation.py), mdm_mid_server (main e refactor/v1) e mdm_installation (stage).

Ogni operatore che apre il video chiama create_stream → midserver /live_stream/create → MQTT al box.
Il box cerca la telecamera in active_connections: se c'è già un ffmpeg attivo restituisce lo stesso token, senza nuovi probe né nuove connessioni. Altrimenti esegue la sequenza descritta sopra.
Il browser si collega a OME in WebRTC (wss://…/app/<token>). È OME che distribuisce il flusso: N operatori corrispondono a 1 connessione verso la telecamera e 1 flusso in uscita dal box, più N connessioni WebRTC su OME.
Alla chiusura il frontend chiama stop_stream. Il midserver chiede a OME quanti spettatori WebRTC ci sono ancora: se più di zero non ferma il flusso (a meno di force_stop).

Attenzioni: - Flusso che resta aperto (da verificare): quando esce l'ultimo spettatore, OME potrebbe contarlo ancora per qualche istante. In quel caso lo stop viene ignorato e il box non ha alcun timeout di inattività: ffmpeg resterebbe aperto, con una connessione verso la telecamera e il traffico in uscita dalla linea del cliente, fino al prossimo stop o al riavvio. - Principale e secondario non esistono nel live: il frontend distingue main e sub (griglia e focus), ma il backend non manda il profilo e il box ha un solo URL per telecamera in webrtc_streams. Griglia e focus mostrano lo stesso flusso. - Griglia (video wall): un operatore che apre la griglia avvia un ffmpeg per ogni telecamera visibile. La banda in uscita dal sito cresce con il numero di telecamere, non con il numero di operatori. - Nome del parametro: il backend qAlarm manda force, mentre il midserver legge force_stop. Oggi non ha effetti, perché il frontend non forza mai lo stop.

Riepilogo delle connessioni per telecamera¶

Lettore	Frigate con hub go2rtc	Frigate diretto	GANZ
Detector	1 (go2rtc)	1	1
Centrale (sistema vecchio)	0 in più (8554)	1 per lettura (554)	1 per lettura (554)
Live OME con URL della telecamera	+1, più 1–3 brevi all'avvio	+1, più 1–3 brevi	+1, più 1–3 brevi
Live OME con URL `localhost:8554/<telecamera>`	0 in più	non disponibile	non disponibile
Live OME con URL del DVR (proposta)	0 in più (il DVR registra già)	0 in più	0 in più

Altri dati dal censimento¶

Flusso del rilevamento: circa metà delle telecamere usa il flusso principale per rilevamento e registrazione insieme (un solo ingresso con ruoli detect e record). Frigate decodifica il flusso ad alta risoluzione e lo riduce, quindi consuma più CPU sul box. Dove la telecamera o il DVR hanno il flusso secondario, il rilevamento su quello è più leggero.
7 telecamere attive con 0 fotogrammi al secondo al momento del censimento: su quelle il rilevamento non funziona. Da verificare impianto per impianto.
Marche probabili: Hikvision o compatibili 81, formati generici /profileN 61 e /media/videoN 33, Uniview 18, Dahua 13, altri formati generici 20, non riconosciute 9.

Problemi trovati¶

Il live OME aggiunge connessioni. Gli operatori di oggi guardano attraverso go2rtc o il GANZ; il live del sistema nuovo, configurato con l'URL della telecamera (come sul box di prova MDMTESTGANZ1), apre una connessione persistente in più e fino a tre brevi a ogni avvio.
Le connessioni brevi possono occupare il posto più a lungo del previsto (escluso sulla telecamera di laboratorio in TCP, da verificare su altri modelli). Se ffprobe va in timeout viene terminato senza chiudere la sessione RTSP (TEARDOWN). La telecamera di laboratorio libera il posto appena si chiude la connessione TCP; altre telecamere tengono la sessione finché non scade, spesso circa 60 s.
Prima UDP, poi TCP. Il live prova prima UDP. Sui collegamenti RTSP intermedi è preferibile TCP: con UDP la perdita di un pacchetto rovina il gruppo di immagini successivo (artefatti a blocchi) e, sui flussi del detector, porta a falsi allarmi o all'arresto del decoder. Il GANZ usa già TCP.
Due modi di configurare Frigate. Il dialogo Add Camera del pannello crea ingressi diretti anche sui box con hub: quella telecamera perde il restream per la centrale e per il live. Il wrapper invece, in add_camera, legge go2rtc.rtsp.username/password senza controllare che esistano: sulla configurazione di default stage, che non ha la sezione go2rtc, la chiamata fallirebbe (da verificare).
Box GANZ senza restream. Il GANZ non ripubblica i flussi, quindi ogni lettore in più (centrale, live MDM, probe) consuma un posto della telecamera, già occupata dal GANZ stesso. La telecamera di laboratorio accetta 4 lettori: avvii ripetuti del live o più lettori insieme la saturano facilmente.
Ogni salvataggio della configurazione Frigate interrompe il restream. Con l'hub go2rtc dentro Frigate, il riavvio dopo "Update Config" ferma per qualche secondo anche le letture della centrale e il live, non solo il rilevamento. È il limite principale di questo modello.
Configurazione automatica degli stream. Se in futuro webrtc_streams venisse compilato in automatico con l'URL della telecamera, i problemi 1–3 riguarderebbero tutte le telecamere.
Transcodifica tutta sul server e flusso pieno dal sito. OME ricodifica ogni live in software. La banda del cliente porta il flusso originale anche quando l'operatore guarda una miniatura della griglia.

Proposta del team: il DVR come sorgente del live¶

Risposta di Mohammad del 29/10/2026, concordata con Marco.

Box Frigate: go2rtc, già dentro Frigate, condivide una sola connessione verso la telecamera.
Box GANZ: il GANZ non ha un media server RTSP, quindi go2rtc di Frigate non aiuta. Il GANZ di laboratorio non ha nessuna porta RTSP aperta. Il limite di 4 sessioni citato nella risposta viene dalla nostra prova, che era sulla telecamera e non sul GANZ: la conclusione non cambia.
Proposta: usare il DVR, presente negli impianti, come sorgente dei flussi del live, attraverso la configurazione separata webrtc_streams.
Perché non un media server in più sul box: un componente da mantenere e risorse in più su macchine piccole.
Codec: in passato alcune installazioni hanno richiesto la transcodifica. Prima di introdurre go2rtc a sé va verificato che possa ripubblicare senza ricodificare, restando compatibile con Frigate, GANZ e OME. Se serve transcodificare, il costo va messo nel conto.

Valutazione. - Il punto più forte della proposta: il live dal DVR non tocca mai le sessioni della telecamera usate dal rilevamento. Se il DVR si ferma o è saturo, si perde il video, non l'allarme. - Zero componenti in più sul box, e il DVR di solito offre anche un flusso secondario, che riduce la banda dal sito. - Codec: nel nostro schema il browser riceve il video da OME, che ricodifica già tutto (sezione sopra). Un go2rtc a sé farebbe solo da ripetitore RTSP, senza ricodificare. Il codec della sorgente conta quindi per i lettori sul box (Frigate, GANZ, ffmpeg in copia verso SRT) e per la CPU del server OME, non per il browser. - Da verificare prima di sceglierlo: - che il DVR ci sia davvero in ogni impianto; - quante sessioni RTSP accetta in uscita (anche i DVR hanno un limite); - se ha il flusso secondario; - formato degli URL e codec per marca e modello; - stabilità nel tempo.

Il censimento di oggi non registra il DVR.

Soluzione ideale¶

Il live non tocca mai le sessioni della telecamera usate dal rilevamento, qualunque sia il numero di operatori, e pesa il meno possibile su box, banda del cliente e server.

Decisione (29/10/2026): non c'è urgenza, quindi si fa la soluzione completa prima della produzione del live di qAlarm, senza rimedi provvisori come un limite ai live per impianto.

                   ┌──▶ detector (Frigate o GANZ)           sessioni della telecamera: solo rilevamento e DVR
telecamera ────────┤
                   └──▶ DVR (registra già) ──flusso secondario──▶ ffmpeg del box (copia) ──SRT──▶ OME ──WebRTC──▶ N operatori

Sorgente del live in webrtc_streams, in quest'ordine:
DVR, preferibilmente sul flusso secondario (proposta del team), dove c'è e regge il numero di live;
altrimenti, sui box Frigate, go2rtc di Frigate (localhost:8554/<telecamera>), senza componenti nuovi;
mai l'URL diretto della telecamera.

go2rtc in un container a sé resta un'opzione di riserva solo per gli impianti senza DVR adatto. 2. Live pulito sul box: TCP, un solo controllo iniziale, audio facoltativo senza probe, timeout di inattività (MDM-039). 3. OME senza ricodifica quando non serve: passaggio diretto per le sorgenti H.264 a risoluzione già adatta (flusso secondario), transcodifica solo per H.265 o risoluzioni alte. Il costo per telecamera in live va misurato. 4. Stream del live compilati dal box: una volta nota la sorgente di ogni impianto (DVR o go2rtc), webrtc_streams si compila in automatico, con nome uguale alla telecamera. 5. Pannello e wrapper coerenti sui box Frigate: aggiungere una telecamera la mette anche in go2rtc.

Cosa dobbiamo fare¶

#	Passo	Perché	Ticket
1	Prove in laboratorio: rilevamento del GANZ con la telecamera satura (4 lettori); stop dell'ultimo spettatore; sessioni lasciate dai probe su una telecamera vera; DVR di laboratorio: sessioni in uscita, flusso secondario, codec, URL	decidono la sorgente per ogni tipo di impianto	MDM-037
2	Censimento dei DVR: presenza, marca e modello, limite di sessioni, flusso secondario, codec per ogni impianto	la proposta vale solo dove il DVR c'è e regge	MDM-037
3	Sorgente del live configurabile e compilata dal box (DVR o go2rtc di Frigate, mai la telecamera); pannello e wrapper coerenti su go2rtc	applicare la scelta a tutto il parco senza configurazione a mano	MDM-038
4	Live pulito sul box: TCP, un probe, audio facoltativo, timeout di inattività	meno connessioni, niente flussi orfani	MDM-039
5	OME: passaggio diretto per le sorgenti H.264 adatte; misurare la CPU di una transcodifica; verificare la configurazione caricata sui server	il costo della transcodifica cresce con ogni telecamera in live	MDM-039

Il passo 1 va fatto per primo. Prima della produzione servono i passi 1–5. go2rtc in un container a sé si valuta solo per gli impianti dove il passo 2 mostra che il DVR non va bene.

Prove sulla telecamera di laboratorio (29/10/2026)¶

Fatte da una postazione dell'ufficio verso la telecamera di laboratorio 192.168.200.166 (canale 1 del GANZ 192.168.200.164), con ffprobe/ffmpeg in TCP, senza decodifica e senza salvare immagini.

Prova	Risultato
Porte della telecamera	554 (RTSP), 80, 443, 8443 aperte; 8554 chiusa
Porte del GANZ (`.164`)	80 e 8443 ("AI Box") aperte; 554 e 8554 chiuse: nessuna uscita RTSP
Percorso `c1/s0`	H.264 2560×1440, 15 fps, audio G.711 (`pcm_mulaw`)
Percorso `c1/s1`	identico a `s0`: il flusso secondario non c'è o non è configurato
Percorsi `c2`, `c3`, `c11`	rispondono con lo stesso flusso: la telecamera ignora il numero di canale
6 lettori contemporanei su `c1`	4 riusciti, il 5° e il 6° rifiutati
4 lettori su `c1` + 1 su `c2` + 1 su `c1/s1`	i 4 riusciti, gli altri rifiutati (`500` su `SETUP`)
2 lettori su c1 + 2 su c2 + 1 su c3	4 riusciti, il 5° rifiutato: 4 sessioni per la telecamera, qualunque percorso
4 lettori chiusi di colpo, poi 4 nuovi	i 4 nuovi riescono dopo circa 3 s: i posti si liberano alla chiusura della connessione

Limiti delle prove: non è noto se durante la prova il GANZ fosse collegato alla telecamera (se lo era, il limite reale è 5); non è stato verificato se il rilevamento del GANZ perde la telecamera quando è satura; la prova in UDP non è stata fatta.

Come misurarlo¶

Sul box, prima, durante e subito dopo un live (sola lettura):

# connessioni RTSP aperte dal box verso le telecamere (porta 554)
ss -tn state established '( dport = :554 )' | tail -n +2 | awk '{print $4}' | sort | uniq -c
# lettori del restream go2rtc (solo box Frigate)
ss -tn state established '( sport = :8554 )' | tail -n +2 | wc -l

Molte telecamere mostrano anche i client collegati nella propria interfaccia web. Prova da fare solo su telecamere di laboratorio: rilevamento attivo, poi più avvii e arresti del live in pochi secondi; controllare se il detector perde la telecamera (stato offline nel pannello, errori nei log di Frigate o in Video Source del GANZ) e quanto restano occupate le sessioni.