Risposta breve: scegli il protocollo che il lato ricevente può effettivamente accettare. SRT è un'opzione di contribuzione quando entrambi gli estremi lo supportano e il percorso è stato configurato; RTMP resta un comune passaggio da encoder a piattaforma o server di ingest. La riproduzione e la distribuzione agli spettatori restano compiti downstream configurati separatamente.
Inizia dal ricevitore, poi scegli il passaggio
| Punto decisionale | Percorso SRT | Percorso RTMP |
|---|---|---|
| Ricevitore | Un ricevitore di contribuzione compatibile con SRT che controlli o che ti è stato assegnato | Un endpoint di ingest RTMP o URL della piattaforma fornito per la pubblicazione |
| Trasporto | Sessione SRT basata su UDP; la modalità live include controlli di temporizzazione e ritrasmissione | Sessione RTMP basata su TCP verso l'endpoint configurato |
| Questione di rete | I due peer possono raggiungersi e le impostazioni di modalità, latenza e passphrase coincidono? | L'encoder può raggiungere l'host e URL/chiave corrispondono al contratto dell'endpoint? |
| Questione codec | Convalida separatamente container e codec accettati dal ricevitore | Convalida separatamente il profilo audio/video accettato dalla destinazione |
| Prossimo compito utile | Contribuzione verso un flusso operativo o di produzione | Pubblicazione a un servizio di ingest o RTMP Server configurato |
Tre decisioni comuni
- La piattaforma fornisce solo un URL e una chiave di flusso: pubblica RTMP usando quel contratto.
- Il tuo team controlla un ricevitore SRT: usa SRT quando modalità, host:porta, latenza ed eventuali Stream ID/passphrase sono stati concordati a entrambi gli estremi.
- La contribuzione SRT termina su una piattaforma RTMP/RTMPS: convalida separatamente la contribuzione SRT e il passaggio di pubblicazione alla piattaforma.
La modalità live SRT è progettata attorno a una finestra di latenza configurata e al feedback del ricevitore; una finestra più ampia può consentire più tempo per il recupero, ma resta una scelta di distribuzione, non una promessa di immagine migliore. Anche la compatibilità RTMP dipende dall'endpoint. Una piattaforma che richiede un URL RTMP o RTMPS decide il passaggio finale anche se il tratto di contribuzione altrove usa SRT.
Cosa cambia operativamente
| Prima della prima connessione | Registra |
|---|---|
| SRT | Modalità caller/listener/rendezvous; host:porta; latenza; Stream ID o passphrase quando utilizzati; container e codec video/audio. |
| RTMP | URL di ingest completo, applicazione/percorso e chiave; il profilo dichiarato dal ricevitore, spesso H.264/AAC dove richiesto dall'endpoint; e il relativo controllo dello stato del flusso. |
Tieni le credenziali fuori da screenshot, log chat e registrazioni di test.
La crittografia SRT e RTMPS risolvono questioni di sicurezza del trasporto diverse: SRT può essere configurato con crittografia, mentre RTMPS è RTMP trasportato su TLS. Una destinazione RTMPS non descrive le opzioni di ingest di un RTMP Server separato.
Testa un percorso di contribuzione
Usa la stessa sorgente preparata per entrambe le schede: blocca il formato di programma, annota le impostazioni di codec video e audio e fornisci al publisher l'accesso all'endpoint di test selezionato. Avvia una sessione con un protocollo, conferma lo stato del publisher, ispeziona l'anteprima, quindi verifica l'output downstream se il flusso ne usa uno.
DEMO DEI PROTOCOLLI
Scegli un protocollo da testare
Ogni demo viene avviata manualmente e conserva il proprio lease temporaneo. Usa impostazioni sorgente corrispondenti quando confronti i flussi; questa pagina non esegue un benchmark di latenza controllato.
Demo SRT live
Prova una connessione SRT live
Crea una connessione temporanea per un'ora. Invia il feed all'indirizzo publisher in modalità Caller, lasciando vuoto lo Stream ID. Guardalo in Multiview qui sotto oppure collega il receiver all'indirizzo receiver in modalità Caller.
Il risultato conferma che la sorgente selezionata ha raggiunto quel percorso temporaneo e la sua anteprima. È un controllo di configurazione, non un benchmark comparativo, quindi non classifica latenza, qualità o affidabilità. Ripeti una configurazione modificata come nuovo test e conserva i log del ricevitore o i dati di connessione visibili all'operatore.
Dove si colloca Callaba
RTMP Server di Callaba può fornire a publisher e receiver regole di accesso separate e mostrare attività visibili all'operatore. Un RTMP Server Guest può invece essere aperto senza regole di accesso predefinite. Il suo SRT Server è la risorsa di contribuzione corrispondente per un flusso SRT compatibile. L'osservazione nel browser e la riproduzione per gli spettatori usano moduli configurati separatamente; un URL di pubblicazione RTMP non è un URL riproducibile nel browser.
Passaggi successivi
- Per un listener RTMP configurato, consulta RTMP Server e i relativi controlli di accesso/ciclo di vita.
- Per un ricevitore di contribuzione SRT, consulta SRT Server.
- Per un bridge esplicito, usa il percorso documentato del gateway di contribuzione RTMP solo dopo aver confermato entrambi gli endpoint.
