SRTLA vs SRT vs RTMP: quale protocollo è il migliore per lo streaming IRL?

Per lo streaming IRL, SRT di solito è più adatto di RTMP, e SRTLA è l'opzione migliore quando puoi inviare il flusso su più connessioni contemporaneamente. RTMP serve comunque, perché le piattaforme di streaming lo richiedono, ma va usato sull'ultimo tratto stabile tra un server e la piattaforma, non su una rete mobile.

Questa guida spiega come funzionano i tre protocolli, come si comportano sulle connessioni cellulari e come impostare correttamente la latenza SRT.

Che cos'è RTMP?

RTMP (Real-Time Messaging Protocol) è stato specificato da Adobe e pubblicato come specifica aperta nel 2009. È pensato per funzionare su un trasporto affidabile come TCP, che garantisce l'arrivo ordinato di tutti i messaggi (specifica RTMP). La bozza IETF per SRT definisce RTMP lo standard de facto per la contribuzione su internet pubblico, ed è per questo che praticamente ogni encoder, app e piattaforma lo supporta.

Il punto debole nasce dalla stessa progettazione. Poiché RTMP si basa su TCP, offre un'affidabilità accettabile solo su connessioni con un round-trip time basso, e il controllo di congestione di TCP gli impedisce di sfruttare tutta la banda di una connessione. È una scelta poco adatta a uno smartphone che passa da una cella all'altra.

Anche l'RTMP classico ha dei limiti sui codec: supporta solo due canali audio e un insieme ristretto di codec, senza HEVC, VP9 o AV1. La specifica Enhanced RTMP aggiunge questi codec, e YouTube ora elenca H.264, H.265 e AV1 per RTMP(S). Però devono supportarlo sia il tuo software sia la piattaforma. RTMPS è RTMP dentro una connessione SSL cifrata, e YouTube lo consiglia proprio per questo motivo.

Che cos'è SRT?

SRT (Secure Reliable Transport) è un protocollo open source sviluppato nel repository GitHub pubblico di Haivision e descritto in un Internet-Draft dell'IETF. Funziona su UDP e aggiunge l'affidabilità che a UDP da solo manca. Il metodo principale è l'ARQ (Automatic Repeat reQuest): quando il ricevitore si accorge che manca un pacchetto, chiede al mittente di inviarlo di nuovo. Il protocollo supporta anche la Forward Error Correction e un proprio bonding delle connessioni.

Tre proprietà contano per lo streaming IRL:

• Buffer di latenza: Il ricevitore trattiene ogni pacchetto per un tempo configurato prima di inoltrarlo. Questa finestra dà ai pacchetti persi il tempo di essere ritrasmessi e riproduce la temporizzazione originale del flusso. I pacchetti che arrivano troppo tardi possono essere scartati, così il ritardo resta costante invece di crescere.
• Crittografia: SRT supporta la crittografia AES con chiavi a 128, 192 o 256 bit.
• Indipendenza dal codec: SRT è agnostico rispetto al payload. Trasporta qualsiasi codec, risoluzione o frame rate, HEVC incluso.

Il compromesso è intrinseco. Il buffer aggiunge ritardo di proposito, quindi devi scegliere un valore di latenza adatto alla tua rete (ne parliamo meglio più sotto).

Che cos'è SRTLA?

SRTLA è un proxy di trasporto SRT con link aggregation. Nasce dal progetto BELABOX e trasporta il traffico SRT su più collegamenti di rete per avere più capacità e ridondanza. Il traffico viene bilanciato dinamicamente in base alle condizioni della rete, e l'uso previsto è il bonding di modem mobili per lo streaming in diretta.

SRTLA non sostituisce SRT. Si colloca tra mittente e ricevitore SRT: il tuo dispositivo invia il flusso SRT, per esempio, tramite due SIM oppure una SIM più il Wi-Fi, e un ricevitore che comprende SRTLA rimette insieme i pacchetti e li passa avanti come un normale flusso SRT. Ne derivano tre conseguenze pratiche:

• Ti serve un mittente compatibile con SRTLA. L'app iOS gratuita Moblin, per esempio, può usare contemporaneamente una connessione cellulare, una Wi-Fi e più connessioni Ethernet. Anche IRL Pro e i dispositivi BELABOX offrono il bonding SRTLA.
• Ti serve un ricevitore SRTLA. Una piattaforma di streaming o un semplice listener SRT non è in grado di farlo, quindi in mezzo deve esserci un server con ingresso SRTLA.
• Richiede una messa a punto. I pacchetti arrivano fuori ordine sui diversi collegamenti. Per questo il README richiede opzioni del ricevitore come lossmaxttl e una latenza adeguata.

RTMP vs SRT vs SRTLA a colpo d'occhio

Perché le piattaforme vogliono RTMP e perché in mezzo c'è un server

La documentazione per gli encoder delle grandi piattaforme ruota ancora attorno a RTMP. YouTube indica RTMP/RTMPS come protocollo per gli encoder (HLS è l'alternativa), e la documentazione per sviluppatori di Twitch descrive l'invio dello stream a Twitch tramite RTMP. Nella maggior parte dei casi, quindi, SRT e SRTLA non si possono puntare direttamente su una piattaforma.

Un server risolve il problema e aggiunge un secondo vantaggio. La catena è questa:

1. Il tuo telefono o encoder invia SRT o SRTLA (o RTMP) a un server.
2. Il tuo software di streaming, come OBS Studio, preleva lo stream da quel server.
3. OBS invia lo stream finito alla piattaforma tramite RTMP(S) su una connessione stabile.

Il tratto mobile debole usa il protocollo più tollerante, e la piattaforma riceve il protocollo che si aspetta su una connessione che non si sposta. Se il segnale mobile cade per un attimo, OBS continua a trasmettere alla piattaforma, quindi lo stream non si interrompe per i tuoi spettatori. Sia il tuo encoder sia OBS avviano la connessione verso il server, perciò non devi aprire porte sul router.

È quello che fa per te il nostro IRL Endpoint Server con OBS sul tuo PC. Accetta RTMP, SRT e SRTLA in ingresso. Se non hai un PC per lo streaming, l'IRL Broadcasting Server esegue OBS Studio nel cloud e accetta gli stessi tre ingressi. Per un quadro più ampio di una configurazione IRL, consulta la nostra guida allo streaming IRL.

Come impostare la latenza SRT

La latenza SRT non è il ritardo totale tra telecamera e spettatore. Nella documentazione di Haivision descrive solo il ritardo introdotto dall'invio sulla rete. Codifica, decodifica, OBS e piattaforma si aggiungono a questo. Ciò che l'impostazione definisce davvero è il tempo extra che il ricevitore aspetta per compensare i pacchetti in ritardo e le ritrasmissioni.

La knowledge base di OBS fornisce una regola empirica per l'opzione più importante:

• Il valore predefinito è 120 ms.
• Il valore dovrebbe essere almeno 2,5 volte il round-trip time tra encoder e server, in millisecondi.
• In un URL in stile FFmpeg, che OBS utilizza, l'unità è il microsecondo. Una latenza di 1 secondo si scrive latency=1000000.

Esempio: se un ping verso il tuo server mostra un round-trip time di 80 ms, la regola dà un minimo di 200 ms, quindi inseriresti srt://SERVER:PORT?latency=200000. Usa l'indirizzo e la porta esatti dal tuo portale clienti. In OBS, queste opzioni possono essere aggiunte all'URL SRT di una sorgente multimediale o di una destinazione stream personalizzata.

Per gli stream verso i nostri server consigliamo una latenza di 2 secondi. A seconda dell'app, la inserisci come 2000 (millisecondi) oppure 2000000 (microsecondi). Di solito esiste un campo dedicato. In caso contrario, aggiungila all'URL SRT, per esempio srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000. Un valore più basso è possibile, ma consigliamo 2 secondi di proposito a favore della stabilità.

Alcune cose da tenere a mente:

• Le unità cambiano. La libreria SRT e il README di SRTLA usano i millisecondi, mentre gli URL in stile FFmpeg usano i microsecondi. Controlla quale unità si aspetta la tua app prima di digitare un valore.
• Le due parti negoziano. Secondo la bozza SRT, la latenza di una connessione è il massimo tra i valori proposti da mittente e ricevitore. Abbassarla da un lato non serve se l'altro lato ne chiede di più.
• Le connessioni mobili e in bonding richiedono margine. La regola sopra è un minimo, non una raccomandazione. Una finestra più ampia dà più tempo a ritrasmissione e riordino, ma aumenta anche il ritardo. Il README di SRTLA, per esempio, usa latency=2000 (ms) insieme a lossmaxttl nella sua configurazione di esempio del ricevitore.
• Cambia una cosa alla volta e prova mentre ti muovi, non solo alla scrivania.

Posizione del server e latenza

Poiché la latenza SRT minima cresce con il round-trip time, la distanza conta. Un server più vicino a te ha un round-trip time più breve, quindi puoi usare una finestra di latenza più piccola oppure ottenere la stessa stabilità con meno ritardo. Lo stesso vale per l'ultimo tratto: Twitch, per esempio, consiglia gli endpoint di ingest in base al percorso di rete verso il tuo dispositivo.

Offriamo server nelle regioni USA, Europa, Asia e Sud America. Con l'IRL Endpoint Server puoi scegliere tra queste con il piano standard e cambiare in qualsiasi momento nel portale clienti, il che aiuta quando viaggi. Con il piano Dedicated configuriamo noi un endpoint per te, per impostazione predefinita nella posizione più vicina al tuo indirizzo di fatturazione.

Quale protocollo dovresti usare?

• Una connessione, app moderna: usa SRT e imposta la latenza in base al tuo round-trip time.
• Due o più connessioni: usa SRTLA, se la tua app lo supporta e il tuo server lo accetta.
• App o telecamera che supporta solo RTMP: usa RTMP. Funziona, ma tollera meno le reti deboli.
• HEVC: SRT è indipendente dal codec. Verifica che l'intera catena, dall'encoder a OBS fino alla piattaforma, lo supporti. Imposta l'intervallo dei keyframe nell'encoder su 2 secondi e, con HEVC sui dispositivi Apple, disattiva i B-frame se l'app lo permette.

FAQ

SRT è meglio di RTMP per lo streaming IRL?

Per il tratto mobile, di solito sì. SRT funziona su UDP e ritrasmette i pacchetti persi all'interno di una finestra di latenza configurabile, mentre RTMP si basa su TCP e resta affidabile solo su connessioni con un round-trip time basso. RTMP rimane la scelta comune per il collegamento da un server o da OBS alla piattaforma.

Qual è la differenza tra SRT e SRTLA?

SRT è il protocollo di trasporto per una singola connessione. SRTLA trasporta il traffico SRT su più collegamenti di rete contemporaneamente, per esempio due SIM, per aggiungere capacità e ridondanza. SRTLA richiede un'app compatibile con SRTLA e un ricevitore che lo comprenda.

Posso trasmettere in SRT direttamente su Twitch o YouTube?

La documentazione per gli encoder di entrambe le piattaforme si concentra su RTMP(S), con HLS come alternativa su YouTube. Se vuoi usare SRT o SRTLA sul tratto mobile, metti un server e OBS tra il tuo dispositivo e la piattaforma.

Quale latenza devo impostare per SRT?

Per gli stream verso i nostri server consigliamo 2 secondi, da inserire come 2000 (millisecondi) o 2000000 (microsecondi) a seconda dell'app. Un valore più basso è possibile, ma i 2 secondi sono una scelta consapevole a favore della stabilità. Come regola generale, la knowledge base di OBS indica almeno 2,5 volte il round-trip time verso il tuo server, con un valore predefinito di 120 ms. Le reti mobili e le connessioni in bonding di solito richiedono più margine, al prezzo di un ritardo maggiore.

L'IRL Endpoint Server supporta tutti e tre i protocolli?

Sì. L'IRL Endpoint Server e l'IRL Broadcasting Server accettano RTMP, SRT e SRTLA in ingresso.