Cos'è lo streaming SRT? Differenze tra SRT e RTMP spiegate
SRT è un protocollo di trasporto video pensato per resistere alle reti inaffidabili. Ecco come recupera i pacchetti persi, a cosa serve l'impostazione della latenza, come si confronta con RTMP e perché la maggior parte delle piattaforme chiede ancora RTMP.
In questa pagina
SRT (Secure Reliable Transport) è un protocollo open source per lo streaming di video in diretta su reti imprevedibili come l'internet pubblica. Funziona su UDP, richiede di nuovo i pacchetti che vanno persi, ti lascia scegliere quanto ritardo concedere in cambio di affidabilità e può crittografare il flusso. I broadcaster lo usano per spostare flussi di alta qualità tra sedi diverse.
Non sostituisce RTMP ovunque, ma risolve molto bene problemi specifici. Ecco come funziona e quando vale la pena usarlo.
Punti chiave
- SRT usa UDP e recupera i pacchetti persi entro una finestra di latenza che imposti tu.
- È adatto a collegamenti a lunga distanza o con perdite, come sedi remote e flussi di contribuzione.
- La maggior parte delle piattaforme per creator documenta ancora l'ingest RTMP o RTMPS.
- La crittografia AES con una passphrase condivisa protegge i flussi SRT durante il transito.
Da dove nasce SRT e quale problema risolve
SRT è stato sviluppato dall'azienda video Haivision e rilasciato come open source nel 2017. Oggi è supportato da un'ampia gamma di encoder, decoder, media server e software, tra cui OBS e FFmpeg.
Il problema che affronta è facile da descrivere: l'internet pubblica perde e riordina i pacchetti, soprattutto sulle lunghe distanze, su Wi-Fi congestionati o su connessioni cellulari. I collegamenti broadcast tradizionali evitavano il problema con circuiti dedicati o capacità satellitare. SRT punta invece a offrire un'affidabilità da broadcast su normali connessioni internet.
Lo fa senza preoccuparsi troppo di cosa c'è dentro il flusso. SRT è un trasporto, non un formato video, e di solito trasporta un MPEG transport stream con video H.264 o HEVC e audio AAC. Questa flessibilità ha aiutato i flussi di lavoro professionali ad adottarlo rapidamente.
Come funzionano il recupero dei pacchetti e il buffer di latenza
RTMP si appoggia a TCP, che ritrasmette i dati persi ma rallenta l'intera connessione ogni volta che rileva una perdita. Sui collegamenti a lunga distanza con perdite, questo si traduce in blocchi e buffering.
SRT usa UDP e gestisce da sé il recupero. Il ricevitore trattiene i pacchetti in un breve buffer. Quando nota un buco nella sequenza, chiede al mittente di reinviare solo il pacchetto mancante. Se il sostituto arriva prima che quel momento del video esca dal buffer, a valle nessuno se ne accorge.
La dimensione del buffer è l'impostazione di latenza. Valori più alti tollerano reti peggiori a costo di più ritardo; valori più bassi mantengono il ritardo contenuto ma scartano i pacchetti che arrivano troppo tardi. Un punto di partenza comune è qualche volta il tempo di andata e ritorno tra mittente e ricevitore, da aumentare per i collegamenti instabili. Gli strumenti esprimono la latenza in unità diverse, quindi controlla la documentazione.
Crittografia, stream ID e modalità di connessione
SRT include funzioni che RTMP da solo non offre:
- Crittografia. AES con una passphrase condivisa da entrambi i lati, con chiavi a 128, 192 o 256 bit. RTMP ha bisogno della variante separata RTMPS per essere crittografato.
- Stream ID. Un identificatore facoltativo che permette a una sola porta del ricevitore di accettare più flussi e instradare correttamente ciascuno, un po' come una chiave di streaming.
- Modalità di connessione. Un lato resta in ascolto su una porta e l'altro lo chiama. Una terza modalità, rendezvous, fa connettere entrambi i lati contemporaneamente, e può aiutare quando tutti e due sono dietro un firewall.
Dato che SRT usa UDP, la porta UDP di chi è in ascolto deve essere aperta in tutti i firewall lungo il percorso, a differenza delle connessioni TCP in uscita di RTMP. Per il lato RTMP, leggi come funziona RTMP e RTMP e RTMPS a confronto.
SRT e RTMP: dove vince ciascuno
Nessuno dei due protocolli è semplicemente migliore; sono bravi in compiti diversi.
- SRT vince nella contribuzione. Inviare un flusso da una sede remota, da una troupe esterna o da un collegamento cellulare verso un hub di produzione è il caso in cui il recupero dei pacchetti ripaga, così come le catene broadcast che alimentano sistemi di playout, decoder e media server.
- SRT gestisce meglio la distanza. Sui collegamenti intercontinentali con perdite e jitter, un buffer di latenza ben regolato di solito dà risultati più stabili di RTMP basato su TCP.
- RTMP vince sulla compatibilità. Quasi tutti gli encoder, i servizi e le piattaforme lo supportano, e la configurazione è solo un URL più una chiave.
- RTMP è più semplice da mettere in opera. Nessuna porta UDP, nessuna regolazione della latenza e nessuna passphrase da coordinare.
Una regola pratica: usa SRT tra sistemi controllati da te o da un partner, e RTMP o RTMPS per l'ultimo passaggio verso le piattaforme pubbliche.
Perché YouTube, Twitch e la maggior parte delle piattaforme chiedono ancora RTMP
Se SRT è così resistente, perché le principali piattaforme per creator continuano a documentare l'ingest RTMP e RTMPS?
Primo, la compatibilità: le piattaforme vogliono che ogni streamer possa collegarsi, dalle app per telefono ai vecchi encoder hardware, e RTMP è il protocollo che parlano tutti. Secondo, la maggior parte dei creator trasmette da casa verso un server di ingest vicino, dove TCP funziona abbastanza bene. Terzo, le piattaforme hanno costruito in anni autenticazione, gestione delle chiavi e monitoraggio attorno a RTMP.
Il quadro sta cambiando. Alcune piattaforme e molti servizi video professionali accettano SRT o altri protocolli di ingest più recenti. Al momento in cui scriviamo, però, una piattaforma social o di gaming mainstream di solito ti fornirà un URL RTMP o RTMPS. La guida allo streaming RTMP personalizzato spiega come funzionano queste destinazioni.
Inviare RTMP e SRT dalla stessa diretta nel cloud
Molte configurazioni hanno bisogno di entrambi i protocolli contemporaneamente: RTMP per le piattaforme pubbliche e SRT per uno studio, un server di playout o il ricevitore di un partner. Da un encoder di casa, questo significa due uscite e il doppio dell'upload.
StreamHouse lo gestisce nel cloud. Aggiungi alla stessa diretta YouTube, Twitch o Kick via RTMP o RTMPS, più un'uscita SRT personalizzata puntata sul tuo ricevitore. Una sola trasmissione le raggiunge tutte, e le destinazioni aggiuntive non occupano slot di streaming in più.
Per la programmazione preregistrata, carica i tuoi video, che vengono preparati in anticipo con un unico profilo di codifica coerente, poi crea una playlist e avviala o programmala. La diretta va in loop 24/7, si riconnette automaticamente dopo gli intoppi di rete e continua a girare con il computer spento.
Domande frequenti
SRT è meglio di RTMP per lo streaming?
Per percorsi di rete lunghi o inaffidabili, di solito sì, perché SRT recupera i pacchetti persi senza bloccare l'intera connessione. Le piattaforme mainstream però offrono spesso solo RTMP o RTMPS, quindi la scelta giusta dipende da dove va il tuo flusso.
SRT ha una latenza più bassa di RTMP?
Può averla. Il ritardo di trasporto di SRT corrisponde più o meno al buffer di latenza che imposti, che su reti buone può essere ridotto. Ma il ritardo totale per gli spettatori dipende anche dall'elaborazione e dalla riproduzione della piattaforma, quindi cambiare protocollo non sembrerà sempre più veloce.
OBS può trasmettere tramite SRT?
Sì. Inserisci un indirizzo srt:// come server personalizzato in OBS, includendo nell'URL parametri come modalità, latenza e passphrase. Il server o servizio che riceve deve supportare SRT ed essere configurato per accettare la connessione.
SRT è crittografato per impostazione predefinita?
Solo se imposti una passphrase. Con la stessa passphrase su entrambi i lati, SRT crittografa il flusso con AES e chiavi a 128, 192 o 256 bit. Senza passphrase viaggia in chiaro, quindi impostane una per i flussi che attraversano l'internet pubblica.
