FFmpeg เปิดตัวไปป์ไลน์ทรานส์โค้ดแบบมัลติเธรด

• การทรานส์โค้ดแบบมัลติเธรด ของ FFmpeg CLI ถูกเผยแพร่ในรูปแบบ “ใช้งานได้เต็มรูปแบบ” รุ่นแรก หลังใช้เวลาพัฒนาราว 2 ปีและมีคอมมิตเตรียมงานมากกว่า 700 รายการ
• เนื่องจากขอบเขตการเปลี่ยนแปลงมีขนาดใหญ่ จึงยังมีโอกาสที่บางฟีเจอร์จะเสียหาย และ การทดสอบกับการรีวิว ยังเป็นงานสำคัญก่อนการรวมจริง
• -fix_sub_duration_heartbeat หลีกเลี่ยงพฤติกรรมแบบ ไม่กำหนดแน่นอน ในการทำงานแบบอะซิงก์ได้ยาก เนื่องจากมีสมมติฐานเรื่องการซิงก์ระหว่างดีโคเดอร์กับเอนโค้ดเดอร์·มัคเซอร์
• โดยทั่วไปโอเวอร์เฮดจากเธรดมีขนาดเล็ก แต่ในงานที่มีปริมาณงานต่อแพ็กเก็ตน้อยมาก ต้นทุนอาจเด่นชัดกว่าประโยชน์ด้านประสิทธิภาพ
• หากคอขวดไม่ได้กระจุกอยู่ที่คอมโพเนนต์เดียว และแต่ละคอมโพเนนต์ยังไม่ได้อิ่มตัวจากการทำมัลติเธรดของตัวเองอยู่แล้ว สภาพแวดล้อมมัลติคอร์อาจช่วยเพิ่มการใช้ CPU และ เวลาประมวลผลจริง ได้อย่างมาก

---

ประเด็นสำคัญของแพตช์มัลติเธรดสำหรับ FFmpeg CLI

• หลังจาก พัฒนามาราว 2 ปี และมีคอมมิตเตรียมงานมากกว่า 700 รายการ เวอร์ชัน “fully functional” รุ่นแรกของ FFmpeg CLI แบบมัลติเธรดได้ถูกเผยแพร่เป็นชุดแพตช์
• เนื่องจากการเปลี่ยนแปลงมีขนาดใหญ่ จึงยังอาจมีความเสียหายที่ยังไม่ถูกค้นพบ ทำให้ต้องมี การทดสอบและการรีวิว บนกรณีใช้งานจริง
• ในกรณีทั่วไปโอเวอร์เฮดจากเธรดมีขนาดเล็ก แต่ในเวิร์กโหลดที่มี ปริมาณงานต่อแพ็กเก็ต ต่ำมาก โอเวอร์เฮดอาจมีนัยสำคัญ
• หากการทรานส์โค้ดไม่ได้ถูกครอบงำด้วยคอมโพเนนต์เดียว และแต่ละคอมโพเนนต์ยังไม่อิ่มตัวจากมัลติเธรดภายในของตัวเอง ระบบมัลติคอร์อาจช่วยปรับปรุงทั้งการใช้ CPU และเวลาในการรันได้

ข้อจำกัดในการทำงานและปัญหาที่ทราบแล้ว

• ตัวเลือก -fix_sub_duration_heartbeat ในโครงสร้างปัจจุบันตั้งอยู่บนสมมติฐานเรื่องการซิงก์ระหว่างคอมโพเนนต์ที่แยกจากกัน
  • โฟลว์เป้าหมายคือ การซิงก์จากเอนโค้ดเดอร์·มัคเซอร์ไปยังดีโคเดอร์
  • เมื่อแต่ละคอมโพเนนต์ทำงานแบบอะซิงก์ พฤติกรรมจะกลายเป็นไม่กำหนดแน่นอนโดยพื้นฐาน
  • แม้ปัจจุบันพฤติกรรมจะคาดเดาได้ยากอยู่แล้ว แต่หากรันด้วยตัวเลือกเดียวกัน ผลลัพธ์ระหว่างการรันยังคงเป็นแบบกำหนดแน่นอน
  • ในแพตช์ 16/24 ตัวเลือกนี้จะถูกปิดใช้งาน และจำเป็นต้องมีแนวทางจัดการที่ดีกว่า

โครงสร้างของชุดแพตช์ 24 รายการ

• ชุดแพตช์ประกอบด้วยทั้งหมด 24 รายการ
  • 01-09/24 เป็นการแก้ไขเตรียมความพร้อม และอาจถูกพุชก่อนซีรีส์ที่เหลือ
  • 10-17/24 ย้ายการเข้ารหัสและการกรองไปอยู่บนเธรด และทำการเปลี่ยนแปลงเตรียมความพร้อมที่จำเป็น
    • การทำเธรดในขั้นนี้เป็นเพียงเธรด “หลอก” ที่เธรดหลักรอให้เธรดอื่นทำงานเสร็จ จึงยังไม่ใช่การทำงานขนานจริง
    • เนื่องจากมีโอเวอร์เฮดชั่วคราวสูง หรืออาจทำให้บางกรณีมุมเสียหาย จึงเหมาะกว่าจะพุชหลังจากชุดทั้งหมดพร้อมแล้ว
  • 18/24 เป็นแพตช์เดี่ยวที่ใหญ่ที่สุด โดยเพิ่ม ตัวจัดตารางทรานส์โค้ด แต่ในจุดนั้นยังไม่ทำงานจริง
  • 19-24/24 แปลงคอมโพเนนต์แต่ละตัวให้มาใช้รูปแบบการทำงานผ่านตัวจัดตาราง
    • แม้จะแยกไว้เพื่อให้รีวิวได้ง่าย แต่ตอนพุชจริงควรถูกรวมเข้าด้วยกัน
• สามารถดูข้อมูลที่เกี่ยวข้องได้จากวิดีโองานนำเสนอ VDD ล่าสุดและสาขา ffmpeg_threading
  • VDD talk
  • ffmpeg_threading branch

[GN⁺]

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

• บนเซิร์ฟเวอร์ ARM แบบ 4 คอร์ เร็วขึ้นประมาณ 2 เท่า และดูเหมือนว่า overhead จากการทำ parallelization จะไม่มากนัก
  ffmpeg_threading/ffmpeg ใช้เวลา 7.771 วินาที ส่วน ffmpeg เดิมใช้ 13.841 วินาที และการใช้งาน CPU อยู่ที่ 218% กับ 114% ตามลำดับ

  • ในกรณีนี้ไม่ได้ใช้ hardware acceleration ฝั่ง decoding และตัด video output ออกไปด้วย
    อยากรู้ว่าถ้าใช้ hardware acceleration ทั้ง video decoding และ encoding บนการ์ด NVIDIA จะเป็นอย่างไร: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
  • สงสัยว่าส่วนไหนที่ถูกทำให้เป็น multithreading กันแน่ การบีบอัดวิดีโอเป็น multithread อยู่แล้ว ส่วนการคลายการบีบอัดวิดีโอนั้นไม่แน่ใจ
    งานอื่น ๆ น่าจะมีต้นทุนด้าน performance ค่อนข้างเล็ก ดังนั้นถึงจะยินดีกับการปรับปรุงนี้ แต่คาดว่าผลกระทบจริงน่าจะค่อนข้างจำกัด

• น่าจะลิงก์ไปที่ https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... แทนทวีตจะดีกว่า
  สาระสำคัญของทวีตก็อยู่ที่ลิงก์นี้อยู่ดี

  • ตอนนี้เรียกว่า post เฉย ๆ ก็ได้แล้ว ไม่มีข้อจำกัด 280 ตัวอักษรอีกต่อไป และโพสต์ยาวก็แค่ถูกพับไว้เป็นค่าเริ่มต้นเท่านั้น

• ถ้าจะเข้าใจเรื่องนี้ แนะนำให้ดูการนำเสนอของ Anton ที่ VideoLAN Dev Days 2023: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

  • การนำเสนอดี และสงสัยว่า dynamic pipelines กับ “scripting (Lua?)” ที่พูดถึงในส่วน “Future directions” นั้นหมายถึงอะไรกันแน่
    ทำให้นึกถึงแนวทางที่จะจัดการ property animation ได้ทรงพลังขึ้น
  • เคยเจอปัญหาเกี่ยวกับ Extras ที่อยู่บนสไลด์ช่วงประมาณนาทีที่ 33 ของวิดีโอบ่อยมาก
  • อยากดูการนำเสนอนี้จริง ๆ แต่ คุณภาพเสียง แย่มากจนมีสมาธิยาก ไม่รู้ว่าสมัยนี้ยังทำให้แย่ขนาดนี้ได้อย่างไร
  • ไม่เข้าใจว่าส่วนไหนที่เข้าใจยาก คำว่า multithread ในขอบเขตของ video transcoding ใช้ในความหมายอื่นหรือ?

• ทวีตลิงก์ไปที่ http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655... แล้วจากตรงนั้นก็อ้างถึงโค้ดอีกทีที่ https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading

  • ทวีตลิงก์ไปยัง mailing list ซึ่งเป็นแหล่งทางการของ patchset ถ้าจะอ่านต่อให้เลือก “Next in Thread”

• สงสัยว่านี่จะถูก นำไปใช้โดยอัตโนมัติ หรือว่าต้องผสม command-line parameters ให้ซับซ้อนเอง

• สงสัยว่ามี ซอฟต์แวร์ตัดต่อวิดีโอ ที่ใช้ ffmpeg หรือไม่
  ครั้งหนึ่งเคยคิดจะลองทำอะไรสักอย่างที่วาดรูปทรงด้วย SVG แล้วใช้ ffmpeg หรือใส่ UI หรือแค่เพิ่มข้อความ แต่ก็ไม่ได้เริ่มทำ
  Avidemux ให้ความรู้สึกคล้าย ๆ แบบนั้นอยู่บ้าง และข้างในของ ffmpeg ก็ค่อนข้างดิบ ไม่ได้ถูกออกแบบมาให้เข้าถึงจาก GUI ดังนั้น editor ที่ใช้เป็นฐานน่าจะอืด แปลก และดูแลรักษายาก
  แต่ editor แบบ modular ที่สร้าง preview ด้วยตัวอธิบายคำสั่งหรือ pipeline viewer น่าจะเป็นไปได้
  ffmpeg ทรงพลัง แต่การที่ใช้งานผ่าน command line เท่านั้นก็เป็นสิ่งที่กีดกันผู้ใช้บางส่วนอยู่ ก่อนหน้านี้เคยเขียนสคริปต์ Python ที่รับคลิปจำนวนสุ่มแล้วใช้ฟิลเตอร์ xstack ทำเป็น mosaic ซึ่งไม่ง่ายเลย

  • จุดกึ่งกลางที่ตามหาอาจเป็น VapourSynth ใช้ Python จัดการวิดีโอแทน ffmpeg CLI และด้วยส่วนขยายต่าง ๆ หลายครั้งจึงขยายต่อได้มากกว่าและทรงพลังกว่า ffmpeg ล้วน ๆ
    https://vsdb.top/
    https://www.vapoursynth.com/
    สำหรับซอฟต์แวร์ niche ที่อิง ffmpeg เคยเห็น losslesscut: https://github.com/mifi/lossless-cut
    Staxrip ก็ใหญ่เช่นกัน: https://github.com/staxrip/staxrip
    แต่ editor ที่ “ครบวงจร” นั้นไม่ค่อยแน่ใจ
  • https://shotcut.org/ ก็ใช้ ffmpeg
  • มี KDEnlive เป็นซอฟต์แวร์ตัดต่อวิดีโอแบบเสรีโอเพนซอร์สที่ยอดเยี่ยม

• ถ้างาน transcoding เล็ก ๆ ที่ทำสำหรับ Plex เร็วขึ้นก็คงดี
  การ์ดจอไม่รองรับ hardware transcoding เลยคาดหวังกับเรื่องนี้

• กำลังหาวิธีเพิ่มความเร็ว transcoding อยู่ วิธีหนึ่งคือ GPU acceleration อีกวิธีคือเพิ่มจำนวน thread
  แต่การหาจำนวน thread ที่เหมาะสมที่สุดนั้นยาก

  • ใช้ hyperparameter optimization เพื่อหาค่าที่เหมาะสมไม่ได้หรือ? เครื่องมืออย่าง Sherpa หรือ Scikit-optimize สามารถไล่สำรวจ search space เช่นจำนวน thread, ประเภท input, ประเภท CPU ได้
  • สำหรับงานส่วนใหญ่ ให้ตั้งจำนวน thread เท่ากับ จำนวน vCPU ก็พอ กล่าวคือให้นับคอร์ที่ทำ hyperthreading เป็น 2
    แต่ถ้าทำได้ GPU acceleration จะดีกว่ามาก

• สงสัยว่าในการ deploy ffmpeg ขนาดใหญ่ ข้อกำหนดด้านไลเซนส์ เป็นอย่างไร กรณีไหนต้องมีค่าใช้จ่าย?

  • “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.”
    http://ffmpeg.org/legal.html
    กล่าวคือใช้ฟรี แต่ถ้าใช้บางโมดูล อาจมีปัญหาเมื่อนำไปผสมกับโค้ด proprietary
  • วิธีทั่วไปในการใช้ ffmpeg ภายในซอฟต์แวร์ proprietary คือ static compile เวอร์ชัน ffmpeg ที่ใช้แล้วลิงก์เข้า executable หรือให้ซอฟต์แวร์ proprietary เรียกใช้เป็น executable แยกต่างหาก

• ดีใจที่เห็น FFmpeg ดีขึ้น หวังว่าจะได้เห็นการรองรับ Dolby AC4 เร็ว ๆ นี้