संक्षिप्त उत्तर: वही प्रोटोकॉल चुनें जिसे रिसीविंग पक्ष वास्तव में स्वीकार कर सकता है। दोनों सिरों पर समर्थन और कॉन्फ़िगरेशन होने पर SRT योगदान का विकल्प है; RTMP एन्कोडर से प्लेटफ़ॉर्म या इनजेस्ट सर्वर तक हैंडऑफ़ का सामान्य विकल्प बना हुआ है। Viewer playback और delivery अलग से कॉन्फ़िगर होने वाले downstream काम हैं।
पहले रिसीवर से शुरू करें, फिर हैंडऑफ़ चुनें
| निर्णय बिंदु | SRT पथ | RTMP पथ |
|---|---|---|
| रिसीवर | आपके नियंत्रण में या आपको दिया गया SRT-सक्षम contribution receiver | publishing के लिए दिया गया RTMP ingest endpoint या platform URL |
| ट्रांसपोर्ट | UDP-आधारित SRT session; live mode में timing और retransmission controls होते हैं | कॉन्फ़िगर endpoint तक TCP-आधारित RTMP session |
| नेटवर्क प्रश्न | क्या दोनों peers एक-दूसरे तक पहुँच सकते हैं और उनका mode, latency व passphrase मेल खाते हैं? | क्या encoder host तक पहुँचता है और URL/key endpoint contract से मेल खाता है? |
| Codec प्रश्न | रिसीवर के स्वीकार्य container और codecs अलग से सत्यापित करें | target के स्वीकार्य audio/video profile अलग से सत्यापित करें |
| उपयोगी अगला काम | operations या production workflow में contribution | ingest service या configured RTMP Server पर publishing |
तीन सामान्य निर्णय
- Platform केवल URL और stream key देता है: उसी contract के अनुसार RTMP publish करें।
- आपकी टीम SRT receiver नियंत्रित करती है: दोनों सिरों पर mode, host:port, latency और Stream ID/passphrase तय होने पर SRT उपयोग करें।
- SRT contribution RTMP/RTMPS platform पर समाप्त होता है: SRT contribution और platform publish handoff अलग-अलग सत्यापित करें।
SRT live mode कॉन्फ़िगर latency window और receiver feedback पर बना है; बड़ी window recovery के लिए अधिक समय दे सकती है, पर बेहतर चित्र का वादा नहीं है। RTMP compatibility भी endpoint-विशिष्ट है। कोई platform RTMP या RTMPS URL मांगता है तो अंतिम handoff वही तय करता है, भले contribution leg कहीं और SRT हो।
ऑपरेशनल रूप से क्या बदलता है
| पहले connection से पहले | रिकॉर्ड करें |
|---|---|
| SRT | Caller/listener/rendezvous mode; host:port; latency; इस्तेमाल होने पर Stream ID या passphrase; container और video/audio codecs। |
| RTMP | पूरा ingest URL, application/path और key; receiver द्वारा घोषित profile, जहाँ endpoint मांगे वहाँ अक्सर H.264/AAC; और उसकी stream-health check। |
Credentials को screenshots, chat logs और test recordings से दूर रखें।
SRT encryption और RTMPS अलग transport-security प्रश्न हल करते हैं: SRT encryption के साथ कॉन्फ़िगर हो सकता है, जबकि RTMPS TLS पर चलने वाला RTMP है। RTMPS destination किसी अलग RTMP Server के ingest options नहीं बताता।
एक contribution path जांचें
किसी भी tab के लिए वही तैयार source उपयोग करें: programme format लॉक करें, video और audio codec settings नोट करें और publisher को चुने हुए test endpoint का access दें। एक protocol session शुरू करें, publisher state की पुष्टि करें, preview देखें, फिर यदि workflow में हो तो downstream output जांचें।
प्रोटोकॉल डेमो
जाँचने के लिए एक प्रोटोकॉल चुनें
हर डेमो आपको स्वयं शुरू करना होता है और उसके लिए अलग अस्थायी सत्र मिलता है। काम करने के तरीकों की तुलना करते समय स्रोत की सेटिंग एक जैसी रखें; यह पृष्ठ नियंत्रित परिस्थितियों में विलंब की तुलनात्मक माप नहीं करता।
लाइव SRT डेमो
लाइव SRT कनेक्शन आज़माएँ
एक घंटे के लिए अस्थायी कनेक्शन बनाएँ। अपना फ़ीड कॉलर मोड में पब्लिशर पते पर भेजें, स्ट्रीम ID खाली रखते हुए। उसे नीचे Multiview में देखें या अपना रिसीवर कॉलर मोड में रिसीवर पते से कनेक्ट करें।
नतीजा केवल यह पुष्टि करता है कि चुना source उस temporary path और उसके preview तक पहुँचा। यह setup check है, तुलनात्मक benchmark नहीं; इसलिए latency, quality या reliability की रैंकिंग नहीं करता। बदली हुई configuration को नए test के रूप में दोहराएँ और receiver logs या operator को दिखने वाला connection data रखें।
Callaba कहाँ उपयोगी है
Callaba का RTMP Server publishers और receivers को अलग access rules दे सकता है और operator को दिखने वाली activity देता है। Guest RTMP Server में पहले से defined access rules के बिना endpoint खुला रखा जा सकता है। इसका SRT Server संगत SRT workflow के लिए संबंधित contribution resource है। Browser observation और viewer playback अलग modules में कॉन्फ़िगर होते हैं; RTMP publish URL ब्राउज़र में चलने वाला URL नहीं है।
अगले चरण
- कॉन्फ़िगर RTMP listener के लिए RTMP Server और उसके access/lifecycle controls देखें।
- SRT contribution receiver के लिए SRT Server देखें।
- स्पष्ट bridge के लिए endpoints की पुष्टि के बाद ही documented RTMP contribution gateway path उपयोग करें।
