PPCDN EP05: ทำความเข้าใจ Simulcast และการสตรีมความหน่วงต่ำ
เจาะลึกตอนที่ 5 ของหลักสูตร PPCDN อธิบายการทำงานของ Simulcast ในการสร้างสตรีมหลายความละเอียดจากต้นทาง และข้อแตกต่างจากเซิร์ฟเวอร์ทรานสโคด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Simulcast คือการสร้างเอนโคดดิ้งอิสระหลายชุดพร้อมกันจากฝั่งผู้ส่ง
- ช่วยลดภาระเซิร์ฟเวอร์โดยไม่ต้องถอดรหัสและเข้ารหัสใหม่ฝั่งเครือข่าย
- แตกต่างจากการทรานสโคดบนเซิร์ฟเวอร์ซึ่งใช้ประมวลผลหนักและเพิ่มความหน่วง
- โปรเจกต์นี้เลือกใช้ H264/HEVC และ Simulcast ตามความเข้ากันได้ของเบราว์เซอร์
บทความนี้เป็นเนื้อหาใน Episode 5 ของหลักสูตร 20 ตอน PPCDN Low-Latency Live Streaming Course ซึ่งมุ่งเน้นการสร้าง CDN สำหรับสตรีมมิ่งความหน่วงต่ำด้วยตนเอง โดยในบทความนี้จะเชื่อมโยงช่องว่างระหว่าง EP02 ที่ระบุว่าไม่มีการทรานสโคดฝั่งเครือข่าย และ EP04 ที่พูดถึงตรรกะการลดคุณภาพแบบ ABR โดยอธิบายว่าเลเยอร์ต่างๆ ถูกสร้างขึ้นอย่างไรที่ฝั่งผู้ส่ง และเซิร์ฟเวอร์สลับคุณภาพอย่างไรโดยไม่ต้องแปลงพิกเซล
หลายคนอาจเข้าใจผิดว่า Simulcast คือการนำสตรีมเดียวมาตัดย่อยบนเซิร์ฟเวอร์ แต่ความจริงแล้วฝั่งผู้ส่ง (Sender) จะผลิตเอนโคดดิ้งที่ถอดรหัสได้อิสระหลายชุดพร้อมกัน เช่น อินพุต 1080p ที่มี 3 เลเยอร์ Simulcast จะสร้างสตรีม 1080p, 720p และ 360p แยกออกจากกันเป็นคนละ RTP สตรีม โดยอาจใช้เอนโคดเดอร์หลายอินสแตนซ์หรือไปป์ไลน์ที่รองรับหลายเอาต์พุต ซึ่งไม่ได้บังคับว่าต้องรันเอนโคดเดอร์แยกเด็ดขาดเสมอไป
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การเข้าใจกลไกของ Simulcast เป็นหัวใจสำคัญในการออกแบบระบบสตรีมมิ่งยุคใหม่ที่ต้องการบาลานซ์ทรัพยากรระหว่างฝั่งผู้ส่ง (Publisher) และฝั่งโครงสร้างพื้นฐาน (Server) การย้ายภาระการแปลงไฟล์ไปที่ต้นทางช่วยลดคอขวดที่เซิร์ฟเวอร์ส่วนกลางได้อย่างมหาศาล เหมาะสำหรับระบบสตรีมมิ่งสดที่ต้องการความหน่วงต่ำแบบเรียลไทม์
หากเปรียบเทียบกับวิธีดั้งเดิมอย่าง Server-side transcoding เซิร์ฟเวอร์จะต้องถอดรหัสสตรีมขาเข้าเป็นภาพดิบก่อน แล้วค่อยเข้ารหัสใหม่ตามจำนวนเลเยอร์เป้าหมาย ซึ่งกระบวนการนี้กินทรัพยากรซีพียูสูงมากและเพิ่มความหน่วงโดยธรรมชาติ แต่ Simulcast ย้ายงานนั้นไปไว้ที่ผู้เผยแพร่ เซิร์ฟเวอร์จึงทำหน้าที่เพียงส่งต่อข้อมูลไบต์ (Byte forwarding) โดยไม่ต้องถอดหรือเข้ารหัสซ้ำ
"the transcoding work didn't vanish; it moved to the publisher's encoder, trading publisher encode cycles for server transcode cycles."
Greg Tham
สำหรับคำถามที่ว่าทำไมไม่เลือกใช้ Scalable Video Coding (SVC) ที่มีประสิทธิภาพด้านบิตเรตสูงกว่า โปรเจกต์นี้เลือกใช้ H264/HEVC และ Simulcast ตามข้อจำกัดของเบราว์เซอร์เป้าหมายและความเข้ากันได้ของอุปกรณ์ปัจจุบัน ซึ่งเป็นการตัดสินใจแลกเปลี่ยนทางผลิตภัณฑ์ของ PPCDN ไม่ได้แปลว่ามาตรฐาน H264/HEVC ปิดกั้น SVC แต่อย่างใด
ในตอนต่อไปของหลักสูตรจะเปลี่ยนโฟกัสจากการเข้ารหัสไปสู่การป้องกันความปลอดภัย เช่น การลงนามเผยแพร่และเล่นวิดีโอ กลไกโทเค็น และการป้องกันการดึงลิงก์ (Anti-hotlinking)
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น