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

 (git.ffmpeg.org)
3 คะแนน โดย GN⁺ 2025-06-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • FFmpeg avformat/whip มี WHIP muxer เพิ่มเข้ามา ทำให้สามารถจัดการ สตรีมมิงที่มีความหน่วงต่ำกว่า 1 วินาที บนพื้นฐาน WebRTC ได้ภายใน FFmpeg
  • การเปลี่ยนแปลงอ้างอิง WHIP Version 3 และมีการปรับทั้งชื่อ muxer กับการติดตั้งใช้งาน รวมถึงบริบทล็อกของ SSL·DTLS·RTC และข้อความผิดพลาดด้วย
  • magic number ภายใน implementation ถูกแทนที่ด้วย มาโครและฟังก์ชัน และมีการปรับปรุงการจัดการ DTLS curve list, SRTP profile, ICE STUN magic number และ RTP payload type
  • ในเส้นทางสื่อ เปลี่ยนจากการใช้ขนาดเฟรมคงที่มาใช้ rtc->audio_par->frame_size และใช้ h264_mp4toannexb สำหรับการแปลง Annex B ของอินพุต MP4/ISOM
  • การตั้งค่าบิลด์ถูกเปลี่ยนให้ whip เปิดใช้ เฉพาะเมื่อเปิดใช้ DTLS เท่านั้น และปัจจุบันจำกัดการรองรับไว้ที่ OpenSSL

เพิ่ม WHIP muxer และเชื่อมกับระบบบิลด์

  • เพิ่ม WHIP muxer ใน avformat/whip เพื่อรองรับสตรีมมิงที่มีความหน่วงต่ำกว่า 1 วินาที
  • implementation อ้างอิง WHIP Version 3
  • เพิ่มไฟล์ implementation ใหม่ libavformat/whip.c
  • เอกสารและคอนฟิกการบิลด์ก็ถูกเปลี่ยนแปลงด้วย

ปรับปรุงการจัดการ DTLS·ICE·RTP

  • WHIP muxer ได้รับการปรับปรุง implementation พร้อมกับการเปลี่ยนชื่อ และปรับปรุงข้อความผิดพลาดกับบริบทล็อกของ SSL·DTLS·RTC
  • magic number ถูกแทนที่ด้วย มาโคร และตรรกะบางส่วนถูกแยกออกเป็นฟังก์ชัน
    • ปรับระดับล็อกให้ชัดเจนยิ่งขึ้นด้วย
  • เส้นทาง DTLS มีการเปลี่ยนแปลงหลายจุดที่เกี่ยวกับความเข้ากันได้และประสิทธิภาพ
    • อัปเดต DTLS curve list
    • ปรับปรุงชื่อ SRTP profile สำหรับ FFmpeg และ OpenSSL
    • ปรับแต่ง DTLS handshake และการจัดการ ICE เพื่อเพิ่มประสิทธิภาพ
    • ใช้ handshake timeout เดียวและ server role เพื่อป้องกัน ARQ
  • การจัดการ ICE ถูกจัดระเบียบไปในทิศทางที่รวม request/response และ DTLS handshake ไว้ในฟังก์ชันเดียว
    • ปรับปรุง ICE STUN magic number
  • RTP payload type ถูกอัปเดตตามนิยามของ Chrome

การจัดการสื่อและข้อจำกัดของ OpenSSL

  • ฝั่งเสียงเปลี่ยนจากขนาดเฟรมคงที่มาใช้ rtc->audio_par->frame_size
  • ใช้ h264_mp4toannexb เพื่อแปลงอินพุต MP4/ISOM เป็น Annex B
  • แก้ไขปัญหา OPUS timestamp และการตั้งค่า marker หลังใช้ BSF ไปพร้อมกัน
  • implementation ของ TLS และ DTLS ถูกรวมเข้ากับโครงสร้างร่วมกัน
    • ใช้ BIO callback, read, write, print_ssl_error, openssl_init_ca_key_cert, init_bio_method ร่วมกัน
    • ใช้โครงสร้างข้อมูลเดียวกัน
  • แก้ไขข้อผิดพลาดการบิลด์ของ OpenSSL และปรับให้ทำงานร่วมกับ Pion ได้
  • configure ถูกเปลี่ยนให้เปิด whip เฉพาะเมื่อเปิดใช้ dtls
    • ปัจจุบันรองรับเฉพาะ OpenSSL

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

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

 
GN⁺ 2025-06-05
ความคิดเห็นใน Hacker News

  • ตื่นเต้นกับ การออกอากาศผ่าน WebRTC มาก ได้สรุปเหตุผลไว้ใน README ของ Broadcast Box และ PR ของ OBS แล้ว
    ตอนนี้ GStreamer, OBS และ FFmpeg รองรับ WHIP กันหมดแล้ว ก็เท่ากับว่าได้โปรโตคอลการออกอากาศวิดีโอแบบสากลที่ใช้ได้บนทุกแพลตฟอร์ม ทั้งมือถือ เว็บ อุปกรณ์ฝังตัว และซอฟต์แวร์กระจายเสียง
    ทำงานฝั่งโอเพนซอร์สและการออกอากาศด้วย WebRTC มาหลายปี มองว่านี่เป็นหมุดหมายสำคัญ
    [0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
    [1] https://github.com/obsproject/obs-studio/pull/7926

    • ในมุมของคนที่ทำงานด้านการถ่ายทอดอีเวนต์ การเปลี่ยนแปลงนี้ทำให้ OBS อาจกลายเป็นทางเลือกที่ใช้งานได้จริงแทนซอฟต์แวร์มืออาชีพอย่าง vMix โดยเฉพาะการรองรับ P2P และความสามารถในการถ่ายทอดหลายซีนที่ดูมีคุณค่ามาก
    • สงสัยว่ามีวิดีโอเพลเยอร์ที่เล่น สตรีม WebRTC ได้หรือไม่ ตอนที่เช็กล่าสุด VLC และเครื่องมือยอดนิยมอื่น ๆ ยังไม่รองรับ

  • ไม่ใช่ส่วนของ SCTP ที่จริงคือการทำ WebRTC-HTTP Ingestion Protocol หรือ WHIP ซึ่งเป็นโปรโตคอล HTTP แบบหน่วงต่ำสำหรับเชื่อมต่อเข้ากับเกตเวย์ที่สื่อสารกับเพียร์ผ่านโปรโตคอลบน SCTP ของ WebRTC
    https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
    หวังว่าสักวันจะย้ายจาก SCTP ไปเป็นโปรโตคอล P2P ที่อิง QUIC หรือ WebTransport ได้ QUIC จัดการสิ่งที่ SCTP เคยทำบน UDP ได้ดี โดยไม่เพิ่มความซับซ้อนและความต่างของการติดตั้งใช้งานมากนัก
    ตัวเลือกหนึ่งคือ Media-over-QUIC (MoQ) แต่เบราว์เซอร์ยังไม่มี P2P QUIC และความคืบหน้าฝั่งนั้นก็แทบหยุดนิ่งมาหลายปีแล้ว
    https://quic.video/ https://datatracker.ietf.org/group/moq/about/

    • สงสัยว่าควรเปิดเผยและใช้งานส่วนของ SCTP อย่างไรดี ใน ร่าง IETF ของ WHIP ดูเหมือนจะไม่มีการพูดถึงหรือเสนอแนวทางไว้
      ผู้ให้บริการ WHIP ส่วนใหญ่รองรับ DataChannel ด้วย แต่ยังไม่ได้เป็นมาตรฐาน

  • สงสัยว่านี่หมายความว่าอะไร หมายถึงเว็บไซต์จะเชื่อมต่อกับ อินสแตนซ์ FFmpeg โดยตรงเพื่อรับสตรีมเสียงหรือวิดีโอได้ใช่ไหม?
    คำอธิบายจากฝั่ง Phoronix ละเอียดกว่าเล็กน้อย: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

    • ดูเหมือนว่าจะหมายถึงโปรแกรมที่ใช้ไลบรารีของ FFmpeg โดยเฉพาะ libavformat จะสามารถรับสตรีม WebRTC ได้

  • แบบนี้น่าจะทำ สตรีมแบบโฮสต์เอง หรือ CDN สำหรับสตรีมมิงได้ง่ายขึ้นมาก
    FFmpeg เป็นซอฟต์แวร์สื่อแบบสแตนด์อโลนและ plug-and-play ที่น่าทึ่งมากถ้ารู้วิธีใช้

    • ตื่นเต้นมาก โดยเฉพาะถ้ามี Simulcast ด้วย ก็น่าจะทำให้คนทั่วไปใช้งานได้แบบถูกและง่ายมาก
      สร้าง https://github.com/Glimesh/broadcast-box ขึ้นมาเพราะอยากให้การโฮสต์เองและ WebRTC ทำได้ง่ายกว่านี้มาก
    • LLM เก่งเรื่องการใช้งาน FFmpeg มาก แทบจะถามงานเกี่ยวกับวิดีโออะไรก็ได้ แล้วมันจะสร้างคำสั่ง ffmpeg แบบบรรทัดเดียวที่เหมาะให้
    • จริงมาก และการ์ตูนนี้ก็ผุดขึ้นมาในหัวเสมอ: https://xkcd.com/2347/

  • Gajim ซึ่งเป็นไคลเอนต์ XMPP รอสิ่งนี้มานานมาก ฟีเจอร์โทรเสียง/วิดีโอแทบถูกปล่อยทิ้งไว้ และก็เฝ้ารออย่างอดทนว่า FFmpeg จะช่วยให้เพิ่มกลับมาได้ง่ายขึ้น

    • สงสัยว่ายังมีคนใช้ Gajim และ XMPP อยู่หรือไม่ คิดถึงสมัยก่อนที่ใช้แอปแชตต่าง ๆ ผ่าน pidgin
      ตอนนี้กลายเป็นสวนปิดหรือบริการแยกตามแอปกันหมดแล้ว

  • พอเห็นกราฟิก Anubis แบบไม่คาดคิดแล้วรู้สึกยินดี เคยเห็นมาก่อนกับ ffmpeg และ gnu เป็นต้น

    • ฉันก็ชอบเหมือนกัน แต่รอบนี้มันไม่ยอมให้เข้า

  • หวังว่านี่จะไม่ทำให้การมี ffmpeg อยู่ในระบบเสี่ยงขึ้นอีก ช่องโหว่ความปลอดภัยของ WebRTC เป็นสาเหตุของการเจาะระบบหลายครั้ง และเป็นหนึ่งในฟีเจอร์แรก ๆ ที่ปิดหลังติดตั้งเบราว์เซอร์

    • สงสัยว่าหมายถึงช่องโหว่แบบไหน
      การติดตั้งใช้งานนี้เล็กมาก และมั่นใจ 100% ว่ากำลังมอบสิ่งที่ดีที่สุดเท่าที่ทำได้ให้ผู้ใช้
    • ffmpeg เป็น โค้ดประสิทธิภาพสูง ที่เขียนด้วย C เพื่อจัดการโค้เดกประหลาด ๆ และฟอร์แมตไบนารีอยู่แล้ว ดังนั้นคงไม่จำเป็นต้องกังวลเฉพาะเรื่อง WebRTC
    • ถ้าไม่ต้องการหรือไม่จำเป็น สงสัยว่าสามารถตัดออกจากการคอมไพล์ด้วยอาร์กิวเมนต์อย่าง --without-whip ได้หรือไม่ นั่นน่าจะเหมาะที่สุด
    • ffmpeg ก็มีประเด็นด้านความปลอดภัยมาโดยตลอดอยู่แล้ว [1] ดังนั้นเวลาจัดการอินพุตจากผู้ใช้ แนวปฏิบัติที่ดีคือแยกกักไว้ให้ดีอยู่แล้ว
      วิธีที่ดีคือสร้าง Docker image ที่มีแค่ ffmpeg และ dependency ของมัน แล้วรัน docker run สำหรับแต่ละงานแปลงไฟล์ ถ้าต้องสร้างภาพขนาดย่อของรูปหรือเอกสารด้วย ก็ใส่ ClamAV, OpenOffice และ ImageMagick เข้าไปด้วยได้
      โดยส่วนตัวมองว่าเซิร์ฟเวอร์ที่ประมวลผลไฟล์จากผู้ใช้ ไม่ใช่แค่รับมาแล้วเสิร์ฟกลับ ควรอยู่ใน VLAN ที่ล็อกเข้มแยกออกมาต่างหาก หรือถ้าอยู่บน AWS ก็อยู่ใน Security Group ที่แยกต่างหาก
      นี่ไม่ใช่การโจมตีแบบไม่รู้อะไรต่อโปรเจกต์ที่ถูกกล่าวถึง ความปลอดภัยเป็นเรื่องยาก และยิ่งยากขึ้นอีกเมื่อทำงานกับฟอร์แมตไบนารีที่สั่งสมมายาวนานและบางครั้งก็ถูก reverse engineer มาอย่างน่าสงสัย การยอมรับเรื่องนี้ก่อนจะโดนแบบ 4chan ถือว่าฉลาดกว่า
      [1] https://ffmpeg.org/security.html

  • ดีมากจริง ๆ กำลังทำระบบควบคุมระยะไกลผ่านเว็บอยู่ ถ้าสามารถใช้สิ่งนี้ทำให้ ffmpeg gdigrab กลายเป็นสตรีม WebRTC แล้วให้ไคลเอนต์รับไปใช้ได้โดยตรงโดยไม่ต้องมี งานอ้อมผ่าน ExpressJS ที่ทำอยู่ตอนนี้ ก็น่าจะยอดเยี่ยมมาก

  • น่าสนใจที่บน iOS Safari โดนระบบตรวจจับบอตบล็อกตลอด ทั้งบน WiFi บริษัทและเครือข่ายมือถือ
    อยากให้ Anubis ปล่อยผ่านสักที

    • สงสัยว่ามันขึ้นหน้า "access denied" หรือว่าลูป challenge ไม่รู้จบ
    • สงสัยว่าใช้งาน เครือข่าย dual-stack อยู่หรือเปล่า

  • Anubis ไม่ยอมปล่อยผ่าน ;(