RTMP-to-HLS คือการส่งต่องานจากอินเจสต์ฝั่งเอนโค้ดเดอร์ไปสู่การเล่นผ่าน HTTP รับและยืนยันสัญญาณ RTMP จากผู้ส่งก่อน จากนั้นจึงแพ็กเกจหรือแปลงรหัสสำหรับ HLS แล้วทดสอบเพลย์ลิสต์และปลายทางตัวเล่นที่ผู้ชมใช้งานจริง การเชื่อมต่อ RTMP เพียงอย่างเดียวไม่ใช่การเล่นในเบราว์เซอร์
เส้นทาง RTMP-to-HLS
อย่างน้อยที่สุด เส้นทางคือ แหล่งสัญญาณ → ตัวรับฟัง RTMP → การประมวลผลหรือแพ็กเกจสื่อ → เพลย์ลิสต์และเซกเมนต์ HLS → ตัวเล่น แต่ละช่วงอาจทำงานปกติ ขณะที่ช่วงถัดไปมีปัญหาได้ ด้วยเหตุนี้ผู้ปฏิบัติงานจึงควรแยกหลักฐานว่าอินเจสต์ทำงานออกจากหลักฐานว่าผู้ชมดูได้
ตัดสินใจว่าสามารถคัดลอกสื่อได้หรือไม่
อาจแพ็กเกจได้โดยไม่ต้องแปลงรหัสวิดีโอ ก็ต่อเมื่อโคเดกขาเข้า เสียง ไทม์สแตมป์ จังหวะคีย์เฟรม และข้อกำหนดของแพ็กเกจ เข้ากับเส้นทาง HLS ปลายทาง หากไม่เข้ากัน ให้แปลงรหัสอย่างตั้งใจและบันทึกชุดคุณภาพขาออก อย่าเรียกสิ่งนี้ว่าเส้นทางคัดลอกที่ใช้ได้ทุกกรณีโดยยังไม่ได้ตรวจผลลัพธ์ที่ตั้งค่าไว้
ตรวจสอบตามลำดับ
- ส่งแหล่ง RTMP ที่ทราบสถานะ แล้วตรวจว่าตัวรับฟังรายงานกิจกรรมและมีสื่อที่ใช้งานได้
- เปิด URL ของเพลย์ลิสต์ HLS ที่สร้างขึ้น และยืนยันว่าเพลย์ลิสต์อัปเดตขณะที่แหล่งยังถ่ายทอดอยู่
- ตรวจว่าเซกเมนต์ที่ระบุสามารถถูกดึงโดยสภาพแวดล้อมตัวเล่นที่ตั้งใจใช้
- ฟังเสียง ตรวจภาพ และวัดความหน่วงที่ผู้ชมได้รับจริงบนเส้นทางที่ติดตั้งใช้งาน
- หยุดและเริ่มผู้ส่งใหม่ แล้วตรวจว่าเพลย์ลิสต์และตัวเล่นกู้คืนตามที่แผนปฏิบัติการคาดไว้
คีย์เฟรม เซกเมนต์ และความหน่วง
HLS จัดกลุ่มสื่อเป็นเซกเมนต์ที่อ้างอิงจากเพลย์ลิสต์ ภาพรวม HLS ของ Apple และ RFC 8216 อธิบายรูปแบบการส่งแบบเพลย์ลิสต์และเซกเมนต์ ระยะเวลาของเซกเมนต์ คีย์เฟรมจากเอนโค้ดเดอร์ บัฟเฟอร์ของตัวเล่น พฤติกรรมของต้นทาง และการตั้งค่า CDN ล้วนเพิ่มเข้าไปในความหน่วงฝั่งผู้ชม การลดบัฟเฟอร์ตัวหนึ่งไม่ได้พิสูจน์ค่าความหน่วงของทั้งเส้นทาง จึงต้องวัดเส้นทางที่คุณจะใช้งานจริง
เมื่อ RTMP ปกติแต่ HLS ใช้ไม่ได้
| ผลที่พบ | สิ่งที่ควรตรวจต่อ |
|---|---|
| ผู้ส่งทำงาน แต่ไม่มีเพลย์ลิสต์ | ตรวจงาน RTMP-to-HLS และการตั้งค่าขาออก |
| เพลย์ลิสต์เปิดได้ แต่ตัวเล่นค้าง | ตรวจการส่งเซกเมนต์ ข้อผิดพลาดของตัวเล่น ความเข้ากันได้ของโคเดก และนโยบายการเข้าถึง |
| เริ่มเล่นช้า | วัดบัฟเฟอร์ของเอนโค้ดเดอร์ แพ็กเกจ เพลย์ลิสต์ ตัวเล่น และการส่ง ก่อนเปลี่ยนการตั้งค่า |
Callaba รับแหล่ง RTMP ที่ตั้งค่าไว้และส่งต่อให้เวิร์กโฟลว์ปลายทางที่เลือกได้ ตัวรับฟังไม่ใช่ตัวเล่นสาธารณะสำหรับเบราว์เซอร์โดยตัวมันเอง สำหรับการวิเคราะห์ฝั่งเบราว์เซอร์ โปรดดู ตัวเล่น RTMP และการเล่นในเบราว์เซอร์; สำหรับการตั้งค่าอินเจสต์ โปรดดู RTMP Server
การตั้งค่าที่เกี่ยวข้อง
ใช้ คู่มือผู้ปฏิบัติงาน RTMP Server เพื่อพิสูจน์ว่าอินเจสต์ทำงาน จากนั้นดู เอกสาร Web Player สำหรับโมดูลฝั่งผู้ชม เก็บ คู่มือโปรโตคอล RTMP ไว้ใช้ตอบคำถามเรื่องทรานสปอร์ตฝั่งแหล่งสัญญาณ
การวิเคราะห์ในเครื่อง: แพ็กเกจ HLS ด้วย FFmpeg
mkdir -p hls-out && ffmpeg -re -i input.mp4 -c:v libx264 -pix_fmt yuv420p -g 60 -c:a aac -f hls -hls_time 2 -hls_list_size 6 -hls_flags delete_segments hls-out/live.m3u8ผลที่คาดหวัง: live.m3u8 เปลี่ยนไปตามการทำงานของอินพุต และอ้างอิงเซกเมนต์สื่อล่าสุดใน hls-out ให้เสิร์ฟไดเรกทอรีนั้นผ่านเซิร์ฟเวอร์ HTTP เพื่อทดสอบกับเบราว์เซอร์ การเปิดพาธในระบบไฟล์ไม่ใช่การทดสอบ HLS origin ที่ 30 fps ค่า -g 60 ให้จังหวะคีย์เฟรมสองวินาทีซึ่งสอดคล้องกับระยะเวลาเซกเมนต์ในตัวอย่าง ปรับค่านี้ตามอัตราเฟรมจริง
Safari รองรับการเล่น HLS ระดับแพลตฟอร์ม ขณะที่เบราว์เซอร์อื่นจำนวนมากใช้ Media Source Extensions ผ่านไลบรารีตัวเล่น แทนที่จะถือว่า .m3u8 ทุกไฟล์เป็นแหล่งวิดีโอ HTML ที่เล่นได้โดยกำเนิด ให้ทดสอบคู่เบราว์เซอร์/ตัวเล่นที่ใช้จริง ขั้นตอน UI ที่ Callaba ระบุไว้คือ สร้าง Web Player จาก RTMP Server ที่เลือกหรืออินพุตอื่นที่รองรับ เปิด URL ของตัวเล่นที่ได้ แล้วตรวจการเข้าถึงและการเล่น; ดู เอกสาร Web Player
ขั้นตอนถัดไป
ใช้ คู่มือผู้ปฏิบัติงาน RTMP Server เพื่อพิสูจน์ว่าอินเจสต์ทำงาน จากนั้นดู เอกสาร Web Player สำหรับโมดูลฝั่งผู้ชม
