คำตอบสั้น: ใช้ RTMP เมื่อเอนโค้ดเดอร์ได้รับคำสั่งให้เผยแพร่ไปยังปลายทางอินเจสต์ ใช้ WebRTC เมื่อปฏิสัมพันธ์ของผู้ชมและเส้นทางเรียลไทม์มีเหตุผลรองรับ และใช้ HLS เมื่อเลือกการส่งผู้ชมผ่าน HTTP บริการถ่ายทอดสดหนึ่งงานมักใช้มากกว่าหนึ่งโปรโตคอล เพราะชื่อโปรโตคอลอธิบายขอบเขตคนละส่วน
เลือกจากผู้ชมย้อนกลับไปยังแหล่งสัญญาณ
| คำถาม | WebRTC | HLS | RTMP |
|---|---|---|---|
| ตัวรับหลัก | เพียร์เบราว์เซอร์/แอปพลิเคชันแบบโต้ตอบ หรือบริการสื่อ | ตัวเล่นและเส้นทางส่งที่รองรับ HTTP | เซิร์ฟเวอร์อินเจสต์หรือปลายทางของแพลตฟอร์ม |
| รูปแบบทรานสปอร์ต/การส่ง | เซสชันสื่อเรียลไทม์ที่เจรจาสำหรับเพียร์ | เพลย์ลิสต์พร้อมเซกเมนต์สื่อที่ดึงผ่าน HTTP | เซสชันเผยแพร่แบบต่อเนื่องบน TCP |
| บทบาทในเบราว์เซอร์ | ออกแบบมาสำหรับ API สื่อเรียลไทม์ของเบราว์เซอร์ | ส่งผ่านเส้นทางตัวเล่น; การรองรับขึ้นกับแพลตฟอร์ม | ไม่ใช่การเล่นโดยกำเนิดในเบราว์เซอร์สมัยใหม่ |
| การตรวจโคเดก | ยืนยันการรองรับของเบราว์เซอร์ บริการ และการเจรจา | ยืนยันความเข้ากันได้ของตัวเล่น แพ็กเกจ และ rendition | ยืนยันความเข้ากันได้ของเอนโค้ดเดอร์และปลายทางอินเจสต์ |
| การตรวจเครือข่าย | เงื่อนไข signalling, ICE/STUN/TURN และไฟร์วอลล์ | พฤติกรรมของ origin, cache/CDN และคำขอจากตัวเล่น | การเข้าถึงโฮสต์และพอร์ตอินเจสต์ที่กำหนด |
| เหมาะเมื่อ | ปฏิสัมพันธ์เป็นส่วนหนึ่งของข้อกำหนดผลิตภัณฑ์ | การส่งถึงผู้ชมเป็นงานหลัก | เอนโค้ดเดอร์ต้องส่งฟีดให้ตัวรับอินเจสต์ |
สิ่งที่ควรทดสอบก่อน
| ทางเลือกเวิร์กโฟลว์ | ปลายทางที่ทดสอบ | การตรวจรับครั้งแรก |
|---|---|---|
| คอนทริบิวชันหรือผู้ชมแบบโต้ตอบ: WebRTC | ปลายทาง WebRTC สำหรับผู้ชมหรือเซสชันที่ตั้งค่าไว้ | signalling และการเชื่อมต่อ ICE/TURN จากนั้นจึงเสียง/วิดีโอของรายการ |
| การเล่นในเบราว์เซอร์สำหรับผู้ชมจำนวนมาก: HLS | https://example.invalid/live/master.m3u8 | การดึง manifest และ rendition ในตัวเล่นที่ตั้งใจใช้ |
| อินเจสต์เอนโค้ดเดอร์/แพลตฟอร์ม: RTMP | rtmp://example.invalid/app พร้อมคีย์ที่กำหนด | สถานะผู้เผยแพร่ แล้วจึงเอาต์พุต HLS หรือ WebRTC ที่เลือกไว้โดยชัดเจน |
นี่เป็นรูปแบบปลายทาง ไม่ใช่ที่อยู่ที่ Callaba จัดเตรียมไว้ สำหรับรูปแบบการส่งพื้นฐาน โปรดดู W3C WebRTC, IETF HLS และ ข้อกำหนด RTMP
ตัดสินใจเร็ว: เลือกโปรโตคอลตามงาน
สำหรับคอนทริบิวชันแบบโต้ตอบหรือการร่วมรายการของผู้ชม ให้ทดสอบ signalling และ ICE/TURN ของ WebRTC ก่อนเลือก สำหรับการเล่นในเบราว์เซอร์วงกว้าง ให้ทดสอบ manifest HLS และตัวเล่น สำหรับอินเจสต์จากเอนโค้ดเดอร์สู่แพลตฟอร์ม ให้ทดสอบ RTMP ไปยังปลายทางที่กำหนด แล้วเลือกและทดสอบเอาต์พุต HLS หรือ WebRTC ปลายทาง
หากคำถามคือ “ผู้ชมรับรายการในเบราว์เซอร์อย่างไร” ให้เริ่มจาก WebRTC หรือ HLS รวมถึงข้อกำหนดตัวเล่น การเข้าถึง และการส่ง หากคำถามคือ “เอนโค้ดเดอร์นี้เผยแพร่ไปยังแพลตฟอร์มอย่างไร” ให้เริ่มจากข้อตกลงอินเจสต์ RTMP ของแพลตฟอร์ม RTMP ป้อนสู่ขั้น HLS หรือ WebRTC ภายหลังได้ แต่ไม่ได้สร้างขั้นนั้นขึ้นมาเอง
การเปรียบเทียบที่มักทำให้สับสน
WebRTC กับ HLS
นี่คือการตัดสินใจเรื่องการส่ง WebRTC ต้องมีเส้นทางเซสชันเรียลไทม์ ส่วน HLS ต้องมีการส่งเพลย์ลิสต์/เซกเมนต์และตัวเล่นที่เข้ากันได้ ให้ทดสอบปลายทางผู้ชมจริงและรูปแบบสิทธิ์เข้าถึง แทนการตรวจเพียงฟีดต้นทาง
RTMP กับ WebRTC
มักอยู่กันคนละปลายของเวิร์กโฟลว์: RTMP เป็นอินเจสต์จากเอนโค้ดเดอร์ ส่วน WebRTC เป็นการส่งแบบโต้ตอบ บริดจ์คือฟังก์ชันของมีเดียเซิร์ฟเวอร์หรือบริการที่ตั้งค่าไว้ ซึ่งมีโคเดก signalling และการปฏิบัติการของตนเอง ไม่ใช่คุณสมบัติของ URL ใด URL หนึ่ง
HLS กับ RTMP
HLS แพ็กเกจสื่อเพื่อส่งผ่าน HTTP; RTMP เผยแพร่สื่อไปยังตัวรับอินเจสต์ ผู้ชมที่เปิด URL RTMP ไม่ได้ ต้องใช้เส้นทางเอาต์พุต HLS หรือ WebRTC ที่เลือกไว้ ไม่ใช่เปลี่ยนเบราว์เซอร์
เวิร์กโฟลว์แบบผสม
เอนโค้ดเดอร์รายการสามารถเผยแพร่ RTMP ไปยังทรัพยากรอินเจสต์ที่ควบคุมได้ ผู้ปฏิบัติงานยืนยันกิจกรรมจากแหล่งสัญญาณ แล้วตั้งค่าเอาต์พุตแยกสำหรับส่งถึงผู้ชม—HLS สำหรับเวิร์กโฟลว์ตัวเล่น HTTP หรือ WebRTC สำหรับเส้นทางปฏิสัมพันธ์ ยืนยันแต่ละขอบเขตตามลำดับ: เอนโค้ดเดอร์สู่อินเจสต์ การประมวลผล/การสร้างเอาต์พุต แล้วจึง URL ที่ผู้ชมใช้จริง
รายการตรวจโปรโตคอลก่อนผลิต
- จดโคเดกของแหล่งสัญญาณ อัตราเฟรม เสียง และข้อจำกัดของตัวรับปลายทาง
- มอบหมายผู้รับผิดชอบข้อมูลรับรองการเผยแพร่ signalling/การเข้าถึง และการทดสอบตัวเล่น
- ใช้ผู้ชมสำหรับซ้อมแบบส่วนตัว และทดสอบการกู้คืนหลังหยุดแหล่งสัญญาณ
- ผูกคำกล่าวเรื่องการเล่นตรงในเบราว์เซอร์ไว้กับเอาต์พุตที่ตั้งค่าแล้วเสมอ ไม่ใช่ URL ของแหล่ง RTMP
เลือกขั้นตอนถัดไป
สำหรับอินเจสต์จากเอนโค้ดเดอร์และสิทธิ์ของผู้เผยแพร่/ตัวรับ โปรดดู RTMP Server URL เผยแพร่ RTMP อาจใช้ application และชื่อสตรีมเดียวกับ URL ของตัวรับ แต่ผู้เผยแพร่และตัวรับยังมีบทบาทต่างกัน สำหรับเอาต์พุตเบราว์เซอร์ เริ่มที่ คู่มือ Web Player; สำหรับเจตนาการแพ็กเกจ ดู RTMP เป็น HLS หากเวิร์กโฟลว์เป็นคอนทริบิวชัน SRT แทนการเผยแพร่ RTMP SRT Server คือหน้าที่เหมาะสม
