คำตอบสั้น: เลือกโปรโตคอลที่ฝั่งรับสามารถยอมรับได้จริง SRT เป็นตัวเลือกสำหรับคอนทริบิวชันเมื่อทั้งสองฝั่งรองรับและตั้งค่าเส้นทางแล้ว; RTMP ยังเป็นการส่งต่อที่พบบ่อยจากเอนโค้ดเดอร์ไปแพลตฟอร์มหรือเซิร์ฟเวอร์อินเจสต์ การเล่นและการส่งถึงผู้ชมยังเป็นงานปลายทางที่ต้องตั้งค่าแยกกัน
เริ่มที่ตัวรับ แล้วเลือกวิธีส่งต่อ
| จุดตัดสินใจ | เส้นทาง SRT | เส้นทาง RTMP |
|---|---|---|
| ตัวรับ | ตัวรับคอนทริบิวชันที่รองรับ SRT ซึ่งคุณควบคุมหรือได้รับการกำหนดให้ใช้ | ปลายทางอินเจสต์ RTMP หรือ URL ของแพลตฟอร์มที่ให้มาเพื่อเผยแพร่ |
| ทรานสปอร์ต | เซสชัน SRT บน UDP; live mode มีการควบคุมเวลาและการส่งซ้ำ | เซสชัน RTMP บน TCP ไปยังปลายทางที่ตั้งค่าไว้ |
| คำถามเรื่องเครือข่าย | เพียร์ทั้งสองเข้าถึงกันได้หรือไม่ และโหมด ความหน่วง กับ passphrase ตรงกันหรือไม่ | เอนโค้ดเดอร์เข้าถึงโฮสต์ได้หรือไม่ และ URL/คีย์ตรงกับข้อตกลงปลายทางหรือไม่ |
| คำถามเรื่องโคเดก | ตรวจคอนเทนเนอร์และโคเดกที่ตัวรับยอมรับแยกต่างหาก | ตรวจโปรไฟล์เสียง/วิดีโอที่ปลายทางยอมรับแยกต่างหาก |
| งานถัดไปที่เหมาะสม | คอนทริบิวชันเข้าสู่เวิร์กโฟลว์ปฏิบัติการหรือผลิตรายการ | เผยแพร่ไปยังบริการอินเจสต์หรือ RTMP Server ที่ตั้งค่าไว้ |
การตัดสินใจที่พบบ่อยสามแบบ
- แพลตฟอร์มให้เพียง URL และ stream key: เผยแพร่ RTMP ตามข้อตกลงนั้น
- ทีมของคุณควบคุมตัวรับ SRT: ใช้ SRT เมื่อทั้งสองฝั่งตกลงโหมด host:port ความหน่วง และ Stream ID/passphrase (ถ้ามี) แล้ว
- คอนทริบิวชัน SRT สิ้นสุดที่แพลตฟอร์ม RTMP/RTMPS: ตรวจคอนทริบิวชัน SRT และการส่งต่อเพื่อเผยแพร่ไปแพลตฟอร์มแยกกัน
SRT live mode ออกแบบโดยมีหน้าต่างความหน่วงที่ตั้งค่าได้และข้อมูลย้อนกลับจากตัวรับ หน้าต่างที่ใหญ่ขึ้นอาจเพิ่มเวลาสำหรับการกู้คืน แต่ยังเป็นทางเลือกของการติดตั้ง ไม่ใช่คำรับประกันว่าภาพจะดีขึ้น ความเข้ากันได้ของ RTMP ก็ขึ้นอยู่กับปลายทางเช่นกัน แพลตฟอร์มที่ต้องการ URL RTMP หรือ RTMPS เป็นผู้กำหนดการส่งต่อสุดท้าย แม้ช่วงคอนทริบิวชันที่อื่นจะใช้ SRT
สิ่งที่เปลี่ยนในทางปฏิบัติ
| ก่อนเชื่อมต่อครั้งแรก | สิ่งที่ต้องบันทึก |
|---|---|
| SRT | โหมด caller/listener/rendezvous; host:port; ความหน่วง; Stream ID หรือ passphrase เมื่อใช้; คอนเทนเนอร์และโคเดกวิดีโอ/เสียง |
| RTMP | URL อินเจสต์เต็มรูปแบบ application/path และ key; โปรไฟล์ที่ตัวรับกำหนด ซึ่งมักเป็น H.264/AAC เมื่อปลายทางต้องการ; และการตรวจสุขภาพสตรีม |
อย่าให้ข้อมูลรับรองปรากฏในภาพหน้าจอ บันทึกแชต หรือวิดีโอทดสอบ
การเข้ารหัส SRT และ RTMPS ตอบคำถามความปลอดภัยของทรานสปอร์ตคนละแบบ: SRT ตั้งค่าการเข้ารหัสได้ ส่วน RTMPS คือ RTMP ที่ส่งผ่าน TLS ปลายทาง RTMPS ไม่ได้บอกตัวเลือกอินเจสต์ของ RTMP Server คนละตัว
ทดสอบเส้นทางคอนทริบิวชันหนึ่งเส้นทาง
ใช้แหล่งสัญญาณที่เตรียมไว้เดียวกันกับทั้งสองแท็บ: ล็อกฟอร์แมตรายการ จดการตั้งค่าโคเดกวิดีโอและเสียง และให้ผู้เผยแพร่เข้าถึงปลายทางทดสอบที่เลือก เริ่มเซสชันด้วยโปรโตคอลหนึ่งแบบ ยืนยันสถานะผู้เผยแพร่ ตรวจพรีวิว แล้วตรวจเอาต์พุตปลายทางหากเวิร์กโฟลว์ใช้
เดโมโปรโตคอล
เลือกหนึ่งโปรโตคอลเพื่อทดสอบ
แต่ละเดโมเริ่มด้วยตนเองและมีระยะเวลาชั่วคราวของตนเอง ใช้การตั้งค่าแหล่งสัญญาณที่ตรงกันเมื่อเปรียบเทียบเวิร์กโฟลว์ หน้านี้ไม่ได้ทำการทดสอบเวลาแฝงแบบควบคุม
เดโม SRT สด
ลองการเชื่อมต่อ SRT สด
สร้างการเชื่อมต่อชั่วคราวเป็นเวลาหนึ่งชั่วโมง ส่งฟีดของคุณไปยังที่อยู่ publisher ในโหมด Caller, โดยปล่อย Stream ID ว่างไว้ ดูได้ใน Multiview ด้านล่าง หรือเชื่อมต่อ receiver ของคุณไปยังที่อยู่ receiver ในโหมด Caller.
ผลที่ได้ยืนยันว่าแหล่งสัญญาณที่เลือกไปถึงเส้นทางชั่วคราวนั้นและแสดงพรีวิวได้ เป็นการตรวจการตั้งค่า ไม่ใช่เกณฑ์เปรียบเทียบ จึงไม่ได้จัดอันดับความหน่วง คุณภาพ หรือความเชื่อถือได้ หากเปลี่ยนการตั้งค่า ให้ทดสอบใหม่เป็นการทดสอบแยก และเก็บบันทึกจากตัวรับหรือข้อมูลการเชื่อมต่อที่ผู้ปฏิบัติงานมองเห็น
Callaba อยู่ตรงไหน
RTMP Server ของ Callaba ช่วยให้ผู้เผยแพร่และตัวรับมีสิทธิ์เข้าถึงแยกกัน และแสดงกิจกรรมที่ผู้ปฏิบัติงานมองเห็นได้ ส่วน Guest RTMP Server เปิดใช้ได้โดยไม่ต้องกำหนดกฎการเข้าถึงล่วงหน้า SRT Server คือทรัพยากรคอนทริบิวชันคู่กันสำหรับเวิร์กโฟลว์ SRT ที่เข้ากันได้ การดูผ่านเบราว์เซอร์และการเล่นสำหรับผู้ชมใช้โมดูลที่ตั้งค่าแยก; URL สำหรับเผยแพร่ RTMP ไม่ใช่ URL ที่เบราว์เซอร์เล่นได้
ขั้นตอนถัดไป
- สำหรับตัวรับฟัง RTMP ที่ตั้งค่าไว้ โปรดดู RTMP Server และการควบคุมสิทธิ์/วงจรชีวิต
- สำหรับตัวรับคอนทริบิวชัน SRT โปรดดู SRT Server
- สำหรับบริดจ์ที่ระบุชัด ให้ใช้เส้นทาง RTMP contribution gateway ที่มีเอกสารกำกับ เฉพาะหลังยืนยันทั้งสองปลายทางแล้ว
