การใช้ FFmpeg ของ Meta: เบื้องหลังการประมวลผลสื่อขนาดมหาศาล

• Meta รัน FFmpeg หลายหมื่นล้านครั้งต่อวัน และสามารถเปลี่ยนผ่านจากเวอร์ชันฟอร์กภายในองค์กรไปสู่ upstream FFmpeg ได้ทั้งหมดสำเร็จ
• เพื่อปิดช่องว่างของความสามารถระหว่างฟอร์กภายในกับเวอร์ชันโอเพนซอร์ส Meta ได้ร่วมมือกับ FFlabs และ VideoLAN เพื่อนำความสามารถ การเข้ารหัสแบบขนานหลายเลน และเมตริกวัดคุณภาพแบบเรียลไทม์ขึ้นไปพัฒนาใน upstream
• รองรับ การอัปโหลดวิดีโอกว่า 1 พันล้านรายการต่อวัน และทำการเข้ารหัสหลายความละเอียดและหลายโคเดกสำหรับการเล่นแบบ DASH ด้วยคำสั่ง FFmpeg บรรทัดเดียว
• โครงสร้างการทำเธรดที่มีประสิทธิภาพ ซึ่งถูกพัฒนาใน FFmpeg เวอร์ชัน 6.0~8.0 อิงจากแนวทางการออกแบบของ Meta และช่วยเพิ่มประสิทธิภาพการเข้ารหัสให้กับผู้ใช้ทุกคน
• ผสานรวม MSVP (Meta Scalable Video Processor) ซึ่งเป็น ASIC ที่ Meta ออกแบบเอง ผ่าน standard hardware API ของ FFmpeg เพื่อให้ซอฟต์แวร์และฮาร์ดแวร์ไปป์ไลน์มีความสอดคล้องกัน
• เสริมทั้งประสบการณ์วิดีโอรูปแบบใหม่และความเสถียรของแพลตฟอร์ม Meta ไปพร้อมกัน ผ่าน การลงทุนอย่างต่อเนื่อง กับ FFmpeg ที่พัฒนามานานกว่า 25 ปี

---

บทบาทของ FFmpeg และความท้าทายของ Meta

• FFmpeg เป็น เครื่องมือประมวลผลสื่อมาตรฐานของอุตสาหกรรม ที่รองรับโคเดกเสียงและวิดีโอ รวมถึงคอนเทนเนอร์ฟอร์แมตที่หลากหลาย และสามารถแก้ไขหรือแปลงสื่อผ่านฟิลเตอร์เชนที่ซับซ้อนได้
• Meta รันไบนารี ffmpeg (CLI หลัก) และ ffprobe (ยูทิลิตีสำหรับตรวจสอบคุณสมบัติของไฟล์สื่อ) หลายหมื่นล้านครั้งต่อวัน และยังมีความต้องการเพิ่มเติมที่เกินกว่าการประมวลผลไฟล์ทีละไฟล์
• ตลอดช่วงเวลายาวนาน Meta พึ่งพาฟอร์กภายในองค์กรและพัฒนาความสามารถที่ upstream ยังไม่มีในเวลานั้นเอง เช่น การเข้ารหัสหลายเลนบนพื้นฐานของเธรด และการคำนวณเมตริกคุณภาพแบบเรียลไทม์

การแยกทางของฟอร์กภายในและความจำเป็นในการกลับไปใช้ upstream

• เมื่อเวลาผ่านไป ฟอร์กภายในเริ่ม แยกออกจาก upstream FFmpeg อย่างมาก ทำให้ช่องว่างของชุดความสามารถขยายตัวขึ้นเรื่อย ๆ
• ขณะเดียวกัน FFmpeg เวอร์ชันใหม่ก็เพิ่มการรองรับโคเดกและฟอร์แมตไฟล์ใหม่ ๆ พร้อมทั้ง ปรับปรุงเสถียรภาพ ทำให้จำเป็นต้องรองรับเวอร์ชันโอเพนซอร์สล่าสุดควบคู่กันไป เพื่อรับมือกับคอนเทนต์วิดีโอหลากหลายที่ผู้ใช้อัปโหลดเข้ามาโดยไม่สะดุด
• เมื่อการรีเบสการเปลี่ยนแปลงภายในทำให้ ป้องกัน regression ได้ยากขึ้น Meta จึงร่วมมือกับนักพัฒนา FFmpeg, FFlabs และ VideoLAN เพื่อเปลี่ยนไปสู่แนวทางที่เลิกใช้ฟอร์กภายในทั้งหมด และใช้เฉพาะเวอร์ชัน upstream

การสร้างทรานส์โค้ดดิ้งหลายเลนอย่างมีประสิทธิภาพ (VOD และไลฟ์สตรีมมิง)

• เมื่อผู้ใช้อัปโหลดวิดีโอ ระบบจะสร้างชุดการเข้ารหัสหลายแบบสำหรับการเล่น DASH (Dynamic Adaptive Streaming over HTTP) โดยมีการเข้ารหัสที่ต่างกันทั้งด้านความละเอียด โคเดก เฟรมเรต และระดับคุณภาพ
  • ตัวเล่นวิดีโอในแอปสามารถ สลับการเข้ารหัสแบบเรียลไทม์ ตามสัญญาณอย่างสภาพเครือข่ายได้
• วิธีที่ง่ายที่สุดคือประมวลผลแต่ละเลนแยกกันด้วยคำสั่ง FFmpeg คนละบรรทัดตามลำดับ แต่แม้จะรันขนานกัน แต่ละโปรเซสก็ยังทำ งานซ้ำซ้อน เช่น การถอดรหัสซ้ำ และโอเวอร์เฮดจากการเริ่มโปรเซส ทำให้ไม่มีประสิทธิภาพ
• หากใช้คำสั่ง FFmpeg บรรทัดเดียวเพื่อถอดรหัสเฟรมเพียงครั้งเดียว แล้วส่งต่อไปยังตัวเข้ารหัสของแต่ละเอาต์พุต ก็จะ ตัดการถอดรหัสซ้ำ และลดโอเวอร์เฮดจากการเริ่มโปรเซสได้
  • เนื่องจากต้องรองรับการอัปโหลดวิดีโอ มากกว่า 1 พันล้านรายการต่อวัน การลดงานคำนวณต่อโปรเซสจึงแปลเป็นการเพิ่มประสิทธิภาพอย่างมีนัยสำคัญในภาพรวม
• ฟอร์กภายในของ Meta ยังเพิ่มการปรับแต่งสำหรับ การเข้ารหัสวิดีโอแบบขนาน: FFmpeg แบบเดิมเมื่อใช้หลายตัวเข้ารหัสจะทำงานแบบอนุกรมเป็นรายเฟรม แต่แนวทางนี้ทำให้ทุกอินสแตนซ์ของตัวเข้ารหัสทำงานแบบขนาน เพื่อให้ได้ระดับ parallelism ที่สูงกว่า
• จากผลงานของนักพัฒนา FFmpeg รวมถึง FFlabs และ VideoLAN ทำให้ตั้งแต่ FFmpeg 6.0 เริ่มมีการทำเธรดที่มีประสิทธิภาพมากขึ้น และ สมบูรณ์ใน 8.0
  • ได้รับอิทธิพลโดยตรงจากการออกแบบในฟอร์กภายในของ Meta และถูกบันทึกว่าเป็น การรีแฟกเตอร์ FFmpeg ที่ซับซ้อนที่สุดในรอบหลายทศวรรษ
  • ผู้ใช้ FFmpeg ทุกคนจึงได้รับประโยชน์จากการเข้ารหัสที่มีประสิทธิภาพมากขึ้น

เมตริกคุณภาพแบบเรียลไทม์ (ไลฟ์สตรีมมิง)

• เมตริกคุณภาพเชิงภาพใช้สำหรับ แสดงคุณภาพที่รับรู้ได้ของสื่อออกมาเป็นตัวเลข เพื่อวัดปริมาณการสูญเสียคุณภาพจากการบีบอัด
  • เมตริกแบบ reference: เปรียบเทียบระหว่างต้นฉบับที่เข้ารหัสกับวิดีโอที่มีความเพี้ยน
  • เมตริกแบบ no-reference: ประเมินคุณภาพโดยไม่ต้องมีต้นฉบับ
• FFmpeg สามารถคำนวณเมตริกคุณภาพ เช่น PSNR, SSIM และ VMAF โดยใช้ไฟล์เข้ารหัสที่มีอยู่สองชุดผ่านคำสั่งแยกหลังการเข้ารหัสเสร็จแล้ว แต่ใน ไลฟ์สตรีมมิงจำเป็นต้องคำนวณแบบเรียลไทม์
• ด้วยการ แทรกตัวถอดรหัสวิดีโอ ไว้หลังตัวเข้ารหัสวิดีโอของแต่ละเอาต์พุตเลน เพื่อให้ได้บิตแมปของเฟรมหลังผ่านการบีบอัด แล้วนำไปเทียบกับเฟรมก่อนการบีบอัด จึงสามารถคำนวณเมตริกคุณภาพของแต่ละเลนการเข้ารหัสแบบเรียลไทม์ได้ภายในคำสั่ง FFmpeg บรรทัดเดียว
• ตั้งแต่ FFmpeg 7.0 เป็นต้นไป ด้วยผลงานจากนักพัฒนา FFlabs และ VideoLAN ฟีเจอร์การถอดรหัสแบบ "in-loop" ถูกเปิดใช้งาน ทำให้ไม่จำเป็นต้องพึ่งพาฟอร์กภายในสำหรับความสามารถนี้อีกต่อไปโดยสิ้นเชิง

เกณฑ์ในการส่งโค้ดขึ้น upstream และแพตช์ที่ใช้ภายในเท่านั้น

• ความสามารถอย่างเมตริกคุณภาพแบบเรียลไทม์และการทำเธรดอย่างมีประสิทธิภาพ ช่วยเพิ่มประสิทธิภาพให้กับไปป์ไลน์ที่อิง FFmpeg หลากหลายแบบทั้งภายในและภายนอก Meta จึง ส่งกลับไปยัง upstream
• ในทางกลับกัน แพตช์ที่เฉพาะเจาะจงกับโครงสร้างพื้นฐานของ Meta มากเกินไปและยากต่อการทำให้เป็นทั่วไป จะยังคงเก็บไว้ใช้ภายใน
• FFmpeg รองรับ การถอดรหัส การเข้ารหัส และการกรองแบบเร่งด้วยฮาร์ดแวร์ ผ่าน standard API สำหรับ NVIDIA NVDEC/NVENC, AMD UVD, Intel QSV และอื่น ๆ
• MSVP (Meta Scalable Video Processor) ซึ่งเป็น ASIC สำหรับทรานส์โค้ดวิดีโอที่ Meta พัฒนาขึ้นเอง ก็ถูกเพิ่มการรองรับผ่าน standard API เดียวกัน ทำให้สามารถใช้เครื่องมือร่วมกันได้บนแพลตฟอร์มฮาร์ดแวร์ที่หลากหลาย
  • MSVP ถูกใช้งานเฉพาะในโครงสร้างพื้นฐานภายในของ Meta ทำให้นักพัฒนา FFmpeg ภายนอกไม่สามารถเข้าถึงฮาร์ดแวร์เพื่อทดสอบและตรวจสอบได้ จึงยังคงเป็นแพตช์ภายใน
  • เมื่อต้องรีเบสไปยัง FFmpeg เวอร์ชันล่าสุด Meta ใช้ การตรวจสอบอย่างครอบคลุม เพื่อรับประกันความทนทานและความถูกต้อง

การลงทุนอย่างต่อเนื่องกับ FFmpeg

• ด้วยความสามารถด้านการเข้ารหัสหลายเลนและเมตริกคุณภาพแบบเรียลไทม์ Meta จึง เลิกใช้ฟอร์กภายในอย่างสมบูรณ์ ในทุกไปป์ไลน์ของ VOD และไลฟ์สตรีมมิง
• standard hardware API ของ FFmpeg ช่วยให้สามารถรองรับทั้ง ASIC MSVP และไปป์ไลน์แบบซอฟต์แวร์ได้ โดยมีแรงเสียดทานน้อยที่สุด
• Meta มีแผน ลงทุนต่อเนื่อง กับ FFmpeg ที่ถูกพัฒนาอย่างแข็งขันมานานกว่า 25 ปี ผ่านความร่วมมือกับนักพัฒนาโอเพนซอร์ส เพื่อสร้างประโยชน์ให้กับ Meta ทั้งอุตสาหกรรม และผู้ใช้

[GN⁺]

ความคิดเห็นบน Hacker News

• เมื่อ internal fork เริ่ม ล้าสมัย มากขึ้นเรื่อย ๆ เราจึงร่วมมือกับนักพัฒนา FFmpeg เพื่อนำฟีเจอร์ที่ต้องการไปรวมไว้ใน FFmpeg อย่างเป็นทางการ
  ผลคือสามารถเลิกใช้เวอร์ชันภายในได้ทั้งหมด และรันด้วยเวอร์ชัน upstream เพียงอย่างเดียว
  บางคนอาจบอกว่า “น่าจะมีส่วนร่วมได้มากกว่านี้ไม่ใช่หรือ” แต่แก่นของโอเพนซอร์สคือ ทุกคนได้รับประโยชน์ร่วมกัน

  • คิดว่าคงปฏิเสธไม่ได้ว่า Meta มีส่วนช่วย ต่อชุมชน
    เราได้รับประโยชน์จากโครงการมากมายอย่าง React, React Native เป็นต้นอยู่แล้ว
  • แต่ถ้าฟีเจอร์เหล่านี้เกิดจากความต้องการของ บริษัทยักษ์ใหญ่มหาศาล ผู้ใช้ส่วนใหญ่ก็คงไม่ได้รู้สึกถึงประโยชน์นั้น
    สุดท้ายโครงสร้างแบบนี้ก็ดูจะเอื้อฝ่ายที่มีอำนาจมากกว่าเท่านั้น
  • แน่นอนว่าเป็นการเปลี่ยนแปลงในทางที่ดี แต่เบื้องหลังก็มีช่วงเวลาที่ให้ความสำคัญกับผลประโยชน์ภายในก่อน
    ถึงอย่างนั้น การที่ Meta เปิดเผยสิ่งต่าง ๆ สู่ระบบนิเวศโอเพนซอร์สจำนวนมาก ก็เป็นจุดที่ทำให้บริษัทแตกต่างจากรายอื่นในอุตสาหกรรม
  • อย่าลืมว่าบริษัทบิ๊กเทคทุกแห่งคงอยู่ไม่ได้เลยหากไม่มี รากฐานโอเพนซอร์ส
  • การมีส่วนร่วมกับโอเพนซอร์สนั้นเป็นเรื่องดี แต่ไม่ชอบ น้ำเสียง ของบทความบล็อกนี้
    คำพูดทำนองว่า “ตอนนี้ถึงได้รวมเข้ากับ upstream” ให้ความรู้สึกเหมือนพยายามกลบเกลื่อนสิ่งที่เคยทำได้ไม่ดีในอดีต
    การเอาถ้อยคำแบบการตลาดมาปนในบล็อกเทคนิคเป็นอะไรที่ในมุมผู้อ่านแล้วน่ารำคาญ

• หวังว่า Fabrice Bellard จะได้รับ ผลตอบแทนที่เหมาะสม ตอนเกษียณ
  บริษัทจำนวนมหาศาลทำเงินได้จากซอฟต์แวร์ของเขา

• เป็นเรื่องดีที่ FFmpeg เวอร์ชันใหม่รองรับ codec และ format ได้หลากหลายขึ้น แต่
  ถ้าเป็นสเกลที่ Meta รันวันละหลายพันล้านครั้ง ก็อดสงสัยไม่ได้ว่าพวกเขา มีส่วนร่วมอย่างต่อเนื่อง กับการปรับปรุงเหล่านี้หรือไม่

  • [ความคิดเห็นถูกลบ]

• การรันวันละหลายหมื่นล้านครั้งนี่เป็น สเกลมหาศาลจริง ๆ
  ผมแค่รันงานประกอบวิดีโออัตโนมัติวันละไม่กี่พันครั้งก็เริ่มรู้สึกถึง overhead แล้ว
  ฟีเจอร์ single-decode multi-output ช่วยลดเวลาในการประมวลผลลงได้ 40%

  • ถ้าสเกลขนาดนี้ ปริมาณการใช้ RAM ก็น่าจะเกินจินตนาการ
    โชคดีที่ราคาหน่วยความจำช่วงหลังลดลง ทำให้ ความคุ้มค่าต่อค่าใช้จ่าย ของการปรับปรุงโอเพนซอร์สดียิ่งขึ้น

• แนวทางเพิ่ม parallelism ด้วยการรัน encoder instance แบบขนานก็ดูสมเหตุสมผล
  แต่ผมอยากเห็นฟีเจอร์ time-axis parallelization
  ถ้าแบ่งวิดีโอขาเข้าตาม keyframe แล้วเข้ารหัสแบบขนาน ก็น่าจะเพิ่มความเร็วได้โดยไม่ลดคุณภาพ

  • แต่จะ คาดเดา ตำแหน่ง keyframe ล่วงหน้าได้หรือ?
    ปกติ encoder มักจัดวางแบบไดนามิกเพื่อประสิทธิภาพ จึงอาจแบ่งล่วงหน้าได้ยาก
  • สงสัยว่า motion analysis ที่ encoder ทำระหว่างวิเคราะห์เฟรม P/B จะคำนวณครั้งเดียวแล้วนำกลับมาใช้กับการเข้ารหัสหลายแบบได้หรือไม่

• ขอบคุณทีม Meta ที่มีส่วนช่วยกับ ffmpeg และ ffprobe
  ต่อไปก็อยากให้พิจารณาสนับสนุนทางการเงินด้าน คุณภาพโค้ด เอกสาร และงานชุมชน ด้วย

• ประโยคที่ว่า “internal fork เริ่มเก่าและล้าหลังขึ้นเรื่อย ๆ” นี่ โดนใจมาก
  สำหรับข้อมูลเพิ่มเติม FFmpeg 8 ตอนนี้จัดการ color mapping ระหว่าง HDR และ SDR ได้สมบูรณ์แล้ว

  • เมื่อก่อนผมเคยปวดหัวกับปัญหาการคัดลอก metadata อัตโนมัติ แต่ตอนนี้แก้ได้แล้ว ดีใจมาก
  • ดีใจที่ได้ยินข่าวอีกครั้งหลังห่างหายไปนาน และพัฒนาการก็น่าประทับใจ

• ข่าวที่ Sovereign Tech Fund ของเยอรมนีบริจาคให้ FFmpeg น่าสนใจดี

  • STF ของเยอรมนีบริจาคราว 150,000 ดอลลาร์ แต่แค่ต้นทุนวิศวกร Meta 1 ปี ก็น่าจะมากกว่านั้นเกินเท่าตัวแล้ว
    Meta น่าจะมีทีมเฉพาะด้าน media encoding และอาจมีส่วนร่วมคิดเป็นมูลค่า มากกว่า 1 ล้านดอลลาร์ต่อปี
  • แต่บัญชีทางการของ FFmpeg ก็เคยบอกว่า “ขอบคุณการสนับสนุนจาก Meta แต่ ยังไม่ใช่ระดับที่ยั่งยืน”
    ดูทวีตที่เกี่ยวข้อง
  • อยากรู้ว่า Meta บริจาคจริง ๆ ไปเท่าไร
    ฝั่ง STF ของเยอรมนีบอกว่าสนับสนุน €157,580 ในปี 2024/2025
  • Meta ทำเงินได้หลายพันล้านดอลลาร์ แต่กลับ บริจาคน้อยกว่ากองทุนของรัฐ ก็ดูประชดประชันอยู่เหมือนกัน
  • [ความคิดเห็นถูกลบ]

• โชคดีที่เซิร์ฟเวอร์ FFmpeg เหล่านี้ประมวลผลแต่ คอนเทนต์เบา ๆ เลยยังพอรับไหว
  ถ้าเป็นวิดีโอหนัก ๆ คง overload ไปแล้ว

• โพสต์ HN เดียวกันนี้ ถูกโพสต์ไปแล้วเมื่อ 6 วันก่อน
  ไม่เข้าใจว่าทำไมแค่แปะลิงก์นี้ถึงโดน downvote

  • เท่าที่ผมเข้าใจ ถ้าไม่ใช่ผู้ใช้คนเดิมโพสต์ซ้ำเอง การรีโพสต์ ก็ถือว่าโอเค
  • [ความคิดเห็นถูกลบ]