Răspuns scurt: alegeți protocolul pe care partea de recepție îl poate accepta efectiv. SRT este o opțiune de contribuție când ambele capete îl acceptă și calea a fost configurată; RTMP rămâne o predare uzuală de la encoder la platformă sau server de ingestie. Redarea și livrarea către spectatori rămân sarcini separate, configurate în aval.
Începeți cu receptorul, apoi alegeți predarea
| Punct de decizie | Cale SRT | Cale RTMP |
|---|---|---|
| Receptor | Un receptor de contribuție compatibil SRT, pe care îl controlați sau care v-a fost atribuit | Un endpoint de ingestie RTMP sau un URL de platformă furnizat pentru publicare |
| Transport | Sesiune SRT bazată pe UDP; modul live include controale de temporizare și retransmisie | Sesiune RTMP bazată pe TCP către endpointul configurat |
| Întrebare de rețea | Pot ajunge cele două părți una la alta și se potrivesc setările lor de mod, latență și parolă? | Poate encoderul ajunge la gazdă și corespund URL-ul/cheia contractului endpointului? |
| Întrebare despre codec | Validați separat containerul și codec-urile acceptate de receptor | Validați separat profilul audio/video acceptat de țintă |
| Următoarea sarcină utilă | Contribuție într-un flux operațional sau de producție | Publicare către un serviciu de ingestie sau RTMP Server configurat |
Trei decizii frecvente
- Platforma oferă numai un URL și o cheie de stream: publicați RTMP folosind acel contract.
- Echipa dvs. controlează un receptor SRT: folosiți SRT când modul, host:port, latența și orice Stream ID/parolă au fost convenite la ambele capete.
- Contribuția SRT se termină la o platformă RTMP/RTMPS: validați separat contribuția SRT și predarea de publicare către platformă.
Modul live SRT este proiectat în jurul unei ferestre de latență configurate și al feedbackului receptorului; o fereastră mai mare poate permite mai mult timp pentru recuperare, dar rămâne o alegere de implementare, nu promisiunea unei imagini mai bune. Compatibilitatea RTMP depinde la fel de mult de endpoint. O platformă care solicită un URL RTMP sau RTMPS decide predarea finală chiar dacă segmentul de contribuție din altă parte folosește SRT.
Ce se schimbă operațional
| Înainte de prima conexiune | Înregistrați |
|---|---|
| SRT | Modul caller/listener/rendezvous; host:port; latență; Stream ID sau parolă când sunt folosite; containerul și codec-urile video/audio. |
| RTMP | URL-ul complet de ingestie, aplicația/calea și cheia; profilul declarat de receptor, adesea H.264/AAC unde endpointul îl solicită; și verificarea sa de sănătate a streamului. |
Păstrați credențialele în afara capturilor de ecran, jurnalelor de chat și înregistrărilor de test.
Criptarea SRT și RTMPS rezolvă întrebări diferite despre securitatea transportului: SRT poate fi configurat cu criptare, în timp ce RTMPS este RTMP transportat prin TLS. O destinație RTMPS nu descrie opțiunile de ingestie ale unui RTMP Server separat.
Testați o cale de contribuție
Folosiți aceeași sursă pregătită pentru oricare filă: fixați formatul programului, notați setările codec-ului video și audio și oferiți publicatorului acces la endpointul de test selectat. Porniți o sesiune de protocol, confirmați starea publicatorului, inspectați previzualizarea, apoi verificați ieșirea din aval dacă fluxul folosește una.
DEMONSTRAȚII DE PROTOCOL
Alegeți un protocol pentru test
Fiecare demonstrație este lansată manual și păstrează propria perioadă temporară. Folosiți setări de sursă echivalente când comparați fluxuri; această pagină nu rulează un benchmark controlat de latență.
Demo SRT live
Încercați o conexiune SRT live
Creați o conexiune temporară pentru o oră. Trimiteți fluxul la adresa publicatorului în modul Caller, lăsând Stream ID-ul gol. Urmăriți-l în Multiview mai jos sau conectați receptorul la adresa receptorului în modul Caller.
Rezultatul confirmă că sursa selectată a ajuns la acea cale temporară și la previzualizarea sa. Este o verificare de configurare, nu un benchmark comparativ, deci nu clasifică latența, calitatea sau fiabilitatea. Repetați o configurație modificată ca test nou și păstrați jurnalele receptorului sau datele de conexiune vizibile operatorului.
Unde se încadrează Callaba
RTMP Server de la Callaba poate oferi publicatorilor și receptorilor reguli de acces separate și poate afișa activitatea vizibilă operatorului. Un RTMP Server Guest poate fi în schimb deschis fără reguli de acces predefinite. SRT Server-ul său este resursa de contribuție corespunzătoare pentru un flux SRT compatibil. Observarea în browser și redarea către spectatori folosesc module configurate separat; un URL de publicare RTMP nu este un URL redabil în browser.
Pașii următori
- Pentru un listener RTMP configurat, consultați RTMP Server și controalele sale de acces/ciclu de viață.
- Pentru un receptor de contribuție SRT, consultați SRT Server.
- Pentru o punte explicită, folosiți calea documentată gateway de contribuție RTMP numai după ce confirmați ambele endpointuri.
