FFmpeg ผสานการรองรับสตรีมมิงหน่วงต่ำมากผ่าน WebRTC (WHIP)

 (git.ffmpeg.org)
3 คะแนน โดย GN⁺ 2025-06-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเพิ่ม WHIP (WebRTC-HTTP Ingestion Protocol) muxer เข้าใน FFmpeg อย่างเป็นทางการ ทำให้รองรับ สตรีมมิงหน่วงต่ำมากต่ำกว่า 1 วินาที ได้โดยตรง
  • คอมมิตนี้ปรับโครงสร้างและการตั้งชื่อของ WHIP muxer ใหม่ พร้อมปรับปรุง ข้อความแสดงข้อผิดพลาดและล็อกของ SSL/DTLS/RTC
  • มีการอัปเดตพารามิเตอร์โปรโตคอลสำคัญ เช่น DTLS curve/profile, RTP payload, ICE STUN ให้สอดคล้องกับข้อกำหนดของ Chrome และแยก magic number ออกเป็นแมโครและฟังก์ชัน
  • กระบวนการ DTLS handshake และการจัดการ ICE ถูกรวมและปรับแต่งให้อยู่ในฟังก์ชันเดียว ส่งผลให้ ประสิทธิภาพและเสถียรภาพ ดีขึ้นอย่างมาก
  • แก้บั๊กด้าน audio และ video transcoding (เช่น h264_mp4toannexb, OPUS timestamp, การตั้งค่า marker ฯลฯ) ทำให้เข้ากันได้ดียิ่งขึ้นกับสภาพแวดล้อม WebRTC มาตรฐาน
  • มีการระบุ dependency ของ OpenSSL ให้ชัดเจนขึ้น โดยจะ build WHIP เฉพาะเมื่อรองรับ DTLS เท่านั้น
  • ทำให้การสร้างสภาพแวดล้อม การออกอากาศและสตรีมแบบเรียลไทม์บน WebRTC ทำได้ง่ายขึ้นด้วย FFmpeg เพียงอย่างเดียว และสามารถใช้ประโยชน์จากคุณสมบัติหน่วงต่ำมากเมื่อเทียบกับโปรโตคอลแบบ legacy อย่าง RTMP ได้

avformat/whip: เพิ่มการรองรับ FFmpeg WHIP muxer

สรุปการเปลี่ยนแปลงหลัก

  • เพิ่ม muxer อย่างเป็นทางการบนพื้นฐาน WHIP Version 3 พร้อมปรับระเบียบชื่อเรียกและโครงสร้างภายใน
  • บริบทของล็อกและข้อความแสดงข้อผิดพลาด ของ SSL, DTLS และ RTC ชัดเจนขึ้นมาก
  • แยก magic number ที่เคยฮาร์ดโค้ดไว้ออกเป็นแมโครและฟังก์ชันเฉพาะ เพื่อให้ดูแลรักษาได้ง่ายขึ้น
  • ปรับ รายการ DTLS curve, ชื่อ SRTP profile ฯลฯ ให้ตรงกับมาตรฐานของ FFmpeg และ OpenSSL
  • อัปเดต ICE STUN magic number และ RTP payload type ให้สอดคล้องกับมาตรฐานของเบราว์เซอร์ Chrome
  • แก้ปัญหา media processing เช่น ขนาดเฟรมเสียง, การแปลง H.264 MP4→AnnexB, OPUS timestamp ฯลฯ
  • รวมลอจิก DTLS handshake และการจัดการ ICE ไว้ใน ฟังก์ชันเดียว เพื่อให้ง่ายต่อการดูแล
  • ทำให้เงื่อนไขการรองรับ DTLS บน OpenSSL ชัดเจนขึ้น ส่งผลให้ ข้อผิดพลาดในการ build และความเข้ากันได้ ดีขึ้น
  • รวมโครงสร้างภายในของ TLS/DTLS เช่น SRTP, BIO callback, การเริ่มต้น CA key/ใบรับรอง ฯลฯ
  • มีการแก้ไขและเพิ่มไฟล์ใหม่รวม 13 ไฟล์ เช่น การเพิ่มไฟล์ whip.c

ที่มาและความหมาย

  • WHIP เป็นโปรโตคอลมาตรฐานแบบ HTTP สำหรับการส่งสตรีมบน WebRTC และเป็นองค์ประกอบสำคัญของการไลฟ์สดแบบหน่วงต่ำมาก
  • ก่อนหน้านี้ การเข้ารหัสและส่งออก WebRTC บน FFmpeg ต้องอาศัยเครื่องมือแยกต่างหากหรือการทำรีเลย์ที่ซับซ้อน แต่การ merge ครั้งนี้ทำให้ สามารถส่งออกผ่าน WHIP ด้วยคำสั่ง FFmpeg เพียงคำสั่งเดียว
  • นี่เป็นจุดเปลี่ยนทางเทคนิคที่ช่วยให้เชื่อมต่อกับ ระบบนิเวศ WebRTC สมัยใหม่ได้โดยตรง ในหลากหลายงาน เช่น การถ่ายทอดสดแบบเรียลไทม์ ไลฟ์คอมเมิร์ซ และวิดีโอคอนเฟอเรนซ์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-05
ความคิดเห็นจาก Hacker News
  • กำลังรู้สึกตื่นเต้นมากกับการสตรีมผ่าน WebRTC โดยอธิบายเหตุผลที่ผมสรุปไว้ใน README ของ Broadcast Box และ PR ของ OBS ลิงก์ ตอนนี้ทั้ง GStreamer, OBS และ FFmpeg รองรับ WHIP แล้ว จึงเหมือนเราไปถึงจุดของโปรโตคอลกระจายภาพวิดีโอแบบทั่วไปที่ใช้ได้กับทุกแพลตฟอร์ม และด้วยประสบการณ์หลายปีในการทำงานด้านโอเพนซอร์ส + การกระจายภาพผ่าน WebRTC ผมมองว่านี่เป็นหมุดหมายสำคัญมาก
    • ผมเคยเล่นเกม dosbox ระยะไกลบนมือถือผ่าน VNC แต่ตอนนี้อยากทำเว็บแอป input handler เองแล้วเอาเทคโนโลยีนี้+OBS มาผสมกัน เป็นแรงบันดาลใจสำหรับความท้าทายใหม่ที่จะเผลอใช้เวลาไปได้ไม่สิ้นสุด
    • ถามว่ามีแผนจะเพิ่มความสามารถ multipath/failover-bonding ในหน่วยสตรีมมิงมือถือที่เชื่อมต่อ 5G modem หลายตัวหรือไม่ (เช่น ดัดแปลง SRT เพื่อส่ง H.265 ผ่านหลายลิงก์)
    • หลังจากได้ใช้งานจริงโดยตรงบนหลายแพลตฟอร์ม เช่น ซอฟต์แวร์กระจายภาพยอดนิยม, มือถือ, เว็บ, อุปกรณ์ฝังตัว ก็รู้สึกทึ่งกับ broadcast-box และการมีส่วนร่วมในการพัฒนา
    • แสดงความยินดีที่ไลบรารี webrtc ของตัวเองถูกนำไปใช้อย่างมีประโยชน์ในหลายโปรเจกต์และส่งผลต่อสเปกตรัมทางเทคโนโลยีที่กว้างขวาง
  • แจ้งว่ามีการทำ WebRTC-HTTP Ingestion Protocol (WHIP) implementation—ไม่ใช่การจัดการ SCTP โดยตรง แต่เป็นเอกสาร WHIP IETF ที่ทำหน้าที่เกตเวย์กับ peers ที่ใช้ WebRTC ผ่าน HTTP (ดู ลิงก์) พร้อมบอกความหวังว่าสักวันหนึ่งจะย้ายจาก SCTP ไปเป็นโปรโตคอล p2p บน QUIC หรือ WebTransport แทน แสดงความสนใจใน Media-over-Quic(MoQ) แต่ก็แชร์ว่าการรองรับจากเบราว์เซอร์และพัฒนาการยังช้ามาหลายปีแล้ว ลิงก์ที่เกี่ยวข้องคือ quic.video และ MoQ IETF introduction
    • มีคำถามว่าอยากใช้งาน/เปิดเผยส่วนของ SCTP ในรูปแบบไหน เพราะในร่างมาตรฐาน WHIP ของ IETF ไม่มีการกล่าวถึงหรือข้อเสนอที่เกี่ยวข้อง จึงค่อนข้างคลุมเครือ โดยผู้ให้บริการ 'WHIP Provider' ส่วนใหญ่รองรับ DataChannel แต่ยังไม่เป็นมาตรฐาน
  • ถามว่าสามารถเชื่อม FFmpeg กับเว็บไซต์โดยตรงเพื่อรับสตรีมเสียง/วิดีโอได้เลยหรือไม่ รายละเอียดเพิ่มเติมดูได้ที่หน้า Phoronix (ลิงก์)
    • สรุปว่าโปรแกรมที่ใช้ไลบรารีของ FFmpeg (โดยเฉพาะ libavformat) จะสามารถรับและใช้งาน WebRTC stream ได้โดยตรง
  • คาดว่าการเปลี่ยนแปลงครั้งนี้จะทำให้การสร้างสตรีมแบบ self-hosting/CDN สำหรับสตรีมมิงง่ายขึ้นมาก พร้อมเน้นความเป็นอิสระและความสามารถแบบ plug-and-play ของ ffmpeg
    • เมื่อรวมกับ Simulcast ก็คาดว่าต้นทุนและอุปสรรคในการเริ่มต้นจะลดลงอย่างมาก และหนึ่งในเหตุผลที่สร้าง broadcast-box ก็เพื่อทำให้การเริ่มต้นกับ self-hosting+WebRTC ง่ายขึ้น
    • ด้วยการใช้ LLM ยังสามารถดึงคำสั่งแบบ one-liner สำหรับงานวิดีโอทุกอย่างที่เกี่ยวกับ ffmpeg ได้ด้วย ชื่นชมประสบการณ์การใช้ AI อย่างมาก
    • มักนึกถึงการ์ตูน xkcd 2347 อยู่เสมอ เพราะมันแสดงให้เห็นความสารพัดประโยชน์ของ ffmpeg ได้ชัดเจนในภาพเดียว
  • รู้สึกประทับใจกับประสบการณ์ที่ได้พบกราฟิก Anubis แบบไม่คาดคิดใน ffmpeg และ gnu เป็นต้น
  • กังวลว่าการเพิ่มฟีเจอร์ WHIP จะทำให้การคง ffmpeg ไว้ในระบบมีความเสี่ยงมากขึ้นหรือไม่ เพราะรู้สึกว่าช่องโหว่ด้านความปลอดภัยของ WebRTC เป็นสาเหตุของการเจาะระบบจริงอยู่บ่อยครั้ง และในอดีตก็เคยปิดการทำงานเสมอหลังติดตั้งเบราว์เซอร์
    • มีคนถามว่าช่องโหว่ด้านความปลอดภัยอะไรบ้าง พร้อมระบุว่าการ implementation ครั้งนี้มีขนาดเล็กมาก และแสดงความมั่นใจอย่างแรงกล้าว่าจะมอบผลลัพธ์ที่ดีที่สุดให้ผู้ใช้
    • มีคนถามว่าสามารถเลือกตัดออกจากการ build ไปเลยได้ไหมหากไม่ต้องการ เช่น --without-whip ซึ่งถ้าทำได้ก็น่าจะดีที่สุด
    • เนื่องจาก ffmpeg มีประวัติเรื่องปัญหาความปลอดภัยอยู่มาก แนวทางที่ดีที่สุดเมื่อจัดการกับอินพุตจากผู้ใช้คือใช้งานในสภาพแวดล้อมแยกเสมอ เช่น ใช้ Docker image ที่มีเฉพาะ ffmpeg และ dependency แล้วสตาร์ตใหม่ทุกครั้งต่อหนึ่งงาน หรือถ้าต้องประมวลผล thumbnail หรือเอกสารก็แนะนำให้เพิ่ม ClamAV, OpenOffice, ImageMagick เป็นต้น และถ้าเป็นเซิร์ฟเวอร์ที่ต้องจัดการไฟล์ที่ผู้ใช้สร้างขึ้น ก็ควรแยกให้อยู่ใน VLAN ที่แยกมากที่สุด หรือถ้าเป็น AWS ก็ให้ทำงานอยู่ภายใน security group เท่านั้น แนวคิดนี้ไม่ได้มีเจตนาวิพากษ์แต่ละโปรเจกต์ แต่ต้องการย้ำถึงความยากโดยเนื้อแท้ของ binary format และความสำคัญของมาตรการเชิงป้องกันล่วงหน้า ดูกรณีของ 4chan ได้ด้วย และหน้า security ของ ffmpeg อยู่ ที่นี่
  • ถามว่ากิจกรรมตรวจสอบความปลอดภัยของ ffmpeg เป็นอย่างไรบ้าง โดยแชร์ความรู้สึกว่าบนเว็บไซต์ทางการดูค่อนข้างเป็นการตอบสนองหลังเกิดเหตุ
  • ถามว่าตอนนี้สามารถใช้ ffmpeg บันทึกสตรีมเสียงจากการประชุมวิดีโอ Jitsi ได้หรือยัง
  • ถามว่ามีใครเคยเปิดใช้การรองรับ whip สำเร็จในการ build จากซอร์สของ FFmpeg หรือไม่ เพราะหาออปชัน ./configure ที่ถูกต้องได้ยาก
    • มีคำแนะนำว่าออปชันที่ต้องใช้คือ --enable-muxer=whip และ --enable-openssl
  • กำลังเฝ้ารอวันที่ฟีเจอร์นี้จะถูกนำมาใช้ใน Jellyfin อย่างใจจดใจจ่อ
    • มีคำถามตอบกลับว่าฟีเจอร์นี้จะช่วย Jellyfin ในเชิงการใช้งานอย่างไร