Stack Django + DRF + Celery + Postgres + Redis. Encoder GPU (Nvidia) con Restreamer come motore di transcoding. MediaMTX come output RTMP/HLS. H.264/HEVC input, adaptive bitrate a tre livelli (high/mid/low). Monitoring Prometheus + Grafana. Multi-client, multi-encoder, multi-camera: il cliente ha il suo spazio, l'operatore vede tutto l'inventario.
01Casi d'uso tipici
Non è una piattaforma "per fare video in generale". È pensata per scenari concreti in cui servono flussi RTSP che arrivano in un posto e devono uscire altrove, su player che RTSP non lo parlano.
- Videosorveglianza distribuita su più siti — filiali, magazzini, cantieri. Le videocamere restano dove sono; il feed viene concentrato, transcodificato e reso disponibile a guardiania centrale o app web/mobile, senza aprire porte di rete o configurare VPN per ogni sede.
- Live streaming di eventi — conferenze, fiere, concerti. Camere IP on-site, regia RTSP, pubblicazione HLS verso il sito dell'evento, con pochi secondi di latenza e bitrate che scala in base alla rete del visitatore.
- Feed pubblici verso portali — webcam spiagge, parcheggi, meteo, webcam di località turistiche. Il portale embedda l'HLS, noi gestiamo ingest, uptime, transcoding e bandwidth.
- Monitoring industriale — linee di produzione, impianti remoti, controlli qualità. Feed sempre disponibile nel gestionale aziendale, con storicizzazione opzionale e alerting quando una camera va offline.
02Architettura tecnica
Il flusso è lineare e volutamente disaccoppiato in tre stadi. Ogni stadio fa una cosa sola, bene.
Ingest RTSP: l'encoder apre una connessione TCP/UDP verso la camera, autentica, tiene aperta la sessione e gestisce i reconnect. Le credenziali RTSP (user/password della camera) sono cifrate nel database — mai in chiaro nei log.
Transcoding GPU: Restreamer gira sull'encoder e pilota ffmpeg con hardware acceleration Nvidia (NVENC/NVDEC). Il transcoding produce le tre versioni adaptive bitrate in parallelo, sulla stessa GPU, senza passare dalla CPU. Questo è il motivo per cui un singolo RTX 4070 tiene decine di camere simultanee dove un transcoding software ne gestirebbe cinque o sei.
Output RTMP/HLS: MediaMTX riceve le tre varianti transcodificate e le pubblica come HLS (per i player web) o RTMP (per CDN, OBS, broadcast). Il player HLS sceglie da solo la variante giusta in base alla banda disponibile.
La console di amministrazione (Django + DRF sul backend, frontend React) orchestra tutto: crea i client, assegna gli encoder, configura le camere, avvia e ferma i feed. Le operazioni lunghe (start transcoding, test connessione RTSP, rotazione credenziali) passano da Celery con Redis come broker, così l'API resta reattiva anche sotto carico.
03Transcoding e adaptive bitrate
Perché transcodificare invece di passare il flusso RTSP così com'è? Due motivi. Primo: i player web non parlano RTSP — parlano HLS o WebRTC. Serve comunque una conversione di protocollo, tanto vale farla bene. Secondo: la camera produce un flusso, a una qualità. Ma chi guarda può essere in ufficio su fibra, in ferrovia su 4G ballerino, oppure all'estero. Serve adaptive bitrate.
Il three-tier che usiamo di default:
| Livello | Risoluzione | Bitrate video | Uso tipico |
|---|---|---|---|
| High | 1920×1080 | 3.500–5.000 kbps | Desktop fibra, guardiania centrale |
| Mid | 1280×720 | 1.200–2.000 kbps | Laptop, reti aziendali condivise |
| Low | 854×480 | 400–800 kbps | Mobile 4G, connessioni saturate |
Sul codec: H.264 resta il default — compatibile con qualsiasi browser, player, CDN. HEVC (H.265) lo usiamo solo quando il parco player è controllato (app native, guardiania dedicata) e quando il risparmio di banda del 30-40% fa la differenza — tipicamente su installazioni con molte camere UHD o upstream limitato.
GPU vs CPU: non è una preferenza ideologica, è matematica. Una GPU Nvidia gestisce il transcoding simultaneo di decine di flussi con latenza sotto il secondo e consumo energetico prevedibile. Lo stesso carico in software richiederebbe un server multi-socket con costi elettrici e hardware fuori scala. Il costo di una RTX 4070 si ripaga in pochi mesi se il volume è serio.
04Multi-tenant e gestione
La struttura dati è a tre livelli: cliente → encoder → videocamere. Il cliente è il tenant logico (un'azienda, un comune, un evento). L'encoder è la macchina fisica GPU che fa il lavoro, assegnata a uno o più clienti secondo capienza. Le videocamere sono configurate per cliente, ognuna col suo RTSP, le sue credenziali, i suoi parametri di output.
Dal punto di vista dei permessi: l'utente cliente vede e gestisce solo i feed del proprio tenant — le camere degli altri clienti non esistono nemmeno a livello di API. L'operatore PSA ha visibilità sull'intero inventario, può ribilanciare camere tra encoder, risolvere problemi, aggiungere capacità quando serve. La separazione è enforced a livello di queryset Django, non solo a UI.
Autenticazione via Keycloak con 2FA obbligatoria per chiunque abbia accesso alla console di amministrazione — nessuna eccezione, perché un feed video compromesso è un problema di privacy serio.
05Monitoraggio e alerting
Senza monitoring una piattaforma di streaming è cieca — e una camera offline per un giorno che nessuno ha notato è un danno reputazionale che brucia contratti.
Prometheus raccoglie metriche per ogni encoder (GPU load, memoria GPU, temperatura, bitrate in ingresso, bitrate in uscita per ogni variante, numero di client connessi, errori ffmpeg) e per ogni camera (stato RTSP, packet loss, frame rate effettivo, timestamp ultimo frame ricevuto). Grafana espone dashboard per l'operatore e dashboard semplificate per il cliente sulla sua porzione di inventario.
Gli alert vanno su Slack (canali critical/warning/info separati) ed email quando: un encoder va offline, una camera non risponde per più di N minuti, la GPU satura, il bitrate in uscita crolla sotto soglia. Gli stati online/offline/error sono visibili in tempo reale sulla console — chi è di turno non deve cercarli nei log.
06Requisiti infrastrutturali
Dal lato nostro: encoder con GPU Nvidia di classe RTX 4070 o superiore, 32+ GB RAM, SSD NVMe, rete 1 Gbps simmetrica minimo — meglio 10 Gbps quando si parla di decine di flussi 1080p in uscita verso più destinazioni. Gli encoder possono vivere in datacenter (tipicamente il nostro pool condiviso) o on-premise dal cliente quando ha già connettività buona e vuole tenere il traffico video dentro la propria rete.
Dal lato cliente: le videocamere devono essere raggiungibili dall'encoder via RTSP. Se sono sotto NAT, si risolve con VPN site-to-site o con reverse tunnel. Per la banda upstream serve fare due conti onesti: una camera 1080p a 4 Mbps in ingresso produce altri ~6 Mbps complessivi in uscita (le tre varianti adaptive). Moltiplicato per il numero di camere, è il numero che va detto al provider.
Latenza tipica dalla camera al player web: 4-8 secondi con HLS standard. Scende a 2-3 secondi con LL-HLS quando serve. Sotto il secondo si entra nel dominio WebRTC, che supportiamo ma è un'altra configurazione — la facciamo quando l'uso lo giustifica (controllo remoto, interazione live).
07Sicurezza
Un flusso video può essere materiale sensibile (interni di filiali, aree private, persone identificabili). Non è trattato come contenuto pubblico di default.
- Autenticazione sugli stream — gli URL HLS/RTMP possono richiedere token firmati con scadenza, oppure IP whitelisting per client istituzionali.
- Cifratura credenziali RTSP — user/password delle camere cifrati a riposo nel database, decifrati solo in memoria al momento della connessione, mai loggati.
- 2FA admin console — obbligatoria, TOTP o FIDO2. Le sessioni hanno scadenza e audit trail.
- TLS end-to-end sul traffico API, console, e HLS pubblico. Niente HTTP in chiaro.
- Audit log — chi ha aperto quale stream, quando, da che IP. Serve per capire cos'è successo quando qualcosa va storto.
08Come si inizia
Il punto di partenza è un sopralluogo tecnico: quali camere, quali modelli, come sono cablate, che rete c'è dietro, dove vive chi deve guardare. Mezz'ora di call e di solito il 90% delle domande trova risposta — se emergono gap (camere troppo vecchie, rete insufficiente, scenari complessi) li mettiamo sul tavolo subito, non a progetto avviato.
Dopo il sopralluogo facciamo una stima di risorse GPU e un dimensionamento dell'upstream. Poi un pilot con 1-2 feed in condizioni reali, per validare latenza, qualità, comportamento sotto carico. Se il pilot regge, si passa al rollout graduale — mai un big bang con trenta camere in un giorno.
Il modello è SaaS: canone mensile per cliente che copre encoder, banda, monitoring, gestione. Non vendiamo licenze, vendiamo il servizio che funziona.