เปิดตัว FFmpeg 8.0

 (ffmpeg.org)
2 คะแนน โดย GN⁺ 2025-08-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • FFmpeg 8.0 "Huffman" เพิ่ม โค้ดेकที่ทำงานบนการประมวลผลด้วย Vulkan พร้อมการถอดรหัสและเข้ารหัสแบบเร่งด้วยฮาร์ดแวร์ รวมถึง ฟอร์แมตไฟล์และฟิลเตอร์รุ่นใหม่หลายรายการ
  • มีการ ปรับโครงสร้างพื้นฐานให้ทันสมัย แบบยกเครื่อง และยังเสริมความแข็งแกร่งให้กับ กระบวนการมีส่วนร่วมและคุณภาพโค้ด
  • มีความก้าวหน้าในส่วนโค้ดेकเสียงและวิดีโอสำคัญ เช่น การทำให้ตัวถอดรหัส VVC มีเสถียรภาพมากขึ้น, ตัวถอดรหัส xHE-AAC และ การรองรับ MV-HEVC กับ LC-EVC
  • ยังคงทำหน้าที่เป็นศูนย์กลางของ ความก้าวหน้าด้านเทคโนโลยีมัลติมีเดียโอเพนซอร์ส พร้อมเดินหน้าปรับปรุงความสามารถและความปลอดภัยอย่างต่อเนื่อง

แนะนำ FFmpeg

  • FFmpeg คือ ชุดเครื่องมือประมวลผลมัลติมีเดียอเนกประสงค์แบบครบวงจร ที่เป็นโซลูชันยืดหยุ่นและทรงพลังสำหรับการ บันทึก แปลง และสตรีม เสียงกับวิดีโอ
  • สามารถประมวลผลวิดีโอและเสียงได้ด้วยคำสั่งง่าย ๆ เช่น ffmpeg -i input.mp4 output.avi

23 สิงหาคม 2025 เปิดตัว FFmpeg 8.0 "Huffman"

  • มีการเปิดตัว FFmpeg 8.0 "Huffman" แล้ว หลังผ่านการเลื่อนมาหลายครั้งและกระบวนการปรับโครงสร้างพื้นฐานให้ทันสมัย ทำให้ครั้งนี้เป็นรีลีสที่มีขนาดใหญ่ที่สุดเท่าที่เคยมีมา
  • ฟีเจอร์ใหม่ประกอบด้วยการเพิ่ม ตัวถอดรหัสเนทีฟ เช่น APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728, การเสริมการรองรับ IBC, ACT, Palette Mode ของ ตัวถอดรหัส VVC และ โค้ดेक อย่าง FFv1 (เข้ารหัส·ถอดรหัส), ProRes RAW (ถอดรหัสเท่านั้น) ที่ทำงานบนการประมวลผลด้วย Vulkan
  • มีการเพิ่มการถอดรหัส แบบเร่งด้วยฮาร์ดแวร์ บน Vulkan (เช่น VP9, VVC, H264/5) และการเข้ารหัส (AV1, H264/5) ตลอดจน ฟอร์แมต ใหม่หลากหลายรายการ (MCC, G.728, Whip, APV) และ ฟิลเตอร์ (colordetect, pad_cuda, scale_d3d11, Whisper เป็นต้น)
  • มีการเพิ่ม ชุดตัวถอดรหัสและตัวเข้ารหัส ใหม่ที่ใช้ compute shader และทำงานบน Vulkan 1.3 โดยไม่ต้องใช้ฮาร์ดแวร์เร่งความเร็วเฉพาะทางแยกต่างหาก และทำงานได้เช่นเดียวกับ hwaccel API เมื่อใช้ตัวเข้ารหัสจะต้องระบุตัวเข้ารหัสใหม่ ปัจจุบันรองรับเฉพาะ FFv1 (เข้ารหัส·ถอดรหัส) และ ProRes RAW (ถอดรหัส) ส่วน ProRes (สองทาง) และ VC-2 (สองทาง) กำลังอยู่ระหว่างเตรียมพร้อม
  • โครงสร้างนี้สามารถนำไปใช้ได้เฉพาะกับ โค้ดेकที่ออกแบบมาเพื่อการถอดรหัสแบบขนานให้เหมาะสมที่สุด และคาดว่าจะช่วยยกระดับ ประสิทธิภาพอย่างมาก รวมถึงเปิดทางสู่ การตัดต่อวิดีโอแบบไม่เชิงเส้นและการบันทึกแบบไม่สูญเสียข้อมูล ในอนาคต
  • โครงสร้างพื้นฐานของโปรเจกต์ก็ได้รับการอัปเดตครั้งใหญ่เช่นกัน มีการเปลี่ยนเซิร์ฟเวอร์เมลลิงลิสต์ทั้งหมด และตอนนี้รองรับ การทำงานร่วมกันพัฒนาโค้ดบน Forgejo ที่ code.ffmpeg.org
  • แนะนำให้ผู้ใช้อัปเกรดเป็นเวอร์ชันล่าสุด

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

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

 
GN⁺ 2025-08-23
ความคิดเห็นบน Hacker News

  • ขอขอบคุณนักพัฒนาและผู้มีส่วนร่วมของ FFmpeg

    • ทุกครั้งที่ต้องทำงานอัตโนมัติด้านเสียง/วิดีโอ ก็มักจะใช้ FFmpeg เสมอ และเครื่องมือวิดีโอออนไลน์ส่วนใหญ่ก็มักใช้เครื่องมือนี้เป็นเอนจินหลักหรือเป็นตัวห่อหุ้ม UI
    • วันนี้เพิ่งรู้ด้วยว่ามีโปรเจกต์ FFmpeg.Wasm (https://github.com/ffmpegwasm/ffmpeg.wasm)
    • แชร์ประสบการณ์เมื่อเดือนมกราคม 2024 ที่ดึงเฟรมจากแอนิเมชันปี 1993 ออกมาทีละช่วง 15 นาที จากนั้นอัปสเกลด้วย Real-ESRGAN-ncnn-vulkan (https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan) แล้วนำเฟรมผลลัพธ์กลับมาประกอบใหม่เป็น 4K
    • คิดเล่น ๆ ว่าถ้าเพิ่ม UI ให้ workflow นี้ ก็คงกลายเป็นเครื่องมือแบบ Topaz AI ที่กำลังนิยมกันทุกวันนี้ได้
    • มีการแชร์ภาพตัวอย่างที่อัปสเกลแล้วด้วย (ภาพตัวอย่าง)
    • ต่อให้ไม่ได้ใช้ ffmpeg โดยตรง ก็ยังมักใช้เครื่องมือที่ฝังมันไว้ข้างในอยู่บ่อย ๆ
      • ไม่นานมานี้ได้อัปสเกลแอนิเมะคุณภาพต่ำที่ริปมาจาก DVD เก่าผ่าน k4yt3x/video2x ซึ่งติดตั้งง่ายและมี libffmpeg ฝังมาให้
      • ตอนเข้ารหัสก็สามารถใช้พารามิเตอร์เดียวกับ FFmpeg ได้
      • เพื่อเลือกพารามิเตอร์ที่เหมาะที่สุด จึงใช้ ffmpeg เข้ารหัสฉากสั้น ๆ ด้วยชุดพารามิเตอร์หลายแบบ แล้วใช้ ffmpeg ดึงภาพนิ่งออกมาเปรียบเทียบอีกที

  • ดีใจที่ FFmpeg ได้นำตัวเข้ารหัสและถอดรหัสวิดีโอแบบ compute shader มาใช้

    • โคเดกที่ฮาร์ดแวร์รองรับอย่างแพร่หลายมีแค่ประมาณ H.264, H.265 และ AV1 ดังนั้นถ้าโคเดกอื่นสามารถใช้การเร่งความเร็วระดับแพลตฟอร์มได้ด้วยก็คงดีมาก (ถึงประสิทธิภาพจะด้อยลงบ้างก็ยังมีความหมาย)
    • ตัวเข้ารหัส ProRes ตัวใหม่ดูมีประโยชน์กับโปรเจกต์ที่กำลังทำอยู่
    • เข้าใจคำอธิบายที่ว่าการรองรับโคเดกทั่วไปที่ใช้กันแพร่หลายทำได้ยาก เพราะไม่เหมาะกับการถอดรหัสแบบขนาน
    • ต้องใช้หลายหมื่นเธรด แต่เพราะมี dependency ของข้อมูลระหว่างเฟรมและระหว่างไทล์ การทำให้ขนานกันจึงไม่ง่าย
    • ตัวเข้ารหัสน่าจะยืดหยุ่นกว่าตัวถอดรหัสอยู่บ้าง แต่การเข้ารหัสอะไรอย่าง VP9 (https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) ด้วย compute shader ก็ดูน่าจะเป็นงานที่ท้าทาย

    • แชร์ข่าวดีอีกครั้งว่ามีการทำตัวเข้ารหัส/ถอดรหัสวิดีโอด้วย compute shader

      • ในอดีตมีแต่ hardware interface แบบ in-silicon ที่เป็นมาตรฐาน เลยเคยถามว่า encoder/decoder ที่ใช้ Vulkan จะมีความเป็นสากลไหม แล้วก็โดนขำใส่
      • มันเจ๋งมากที่การพัฒนาแบบนี้สามารถใช้ได้กับฮาร์ดแวร์รุ่นเก่าด้วย และหวังว่าจะเปิดทางให้โคเดกใหม่ ๆ รวมถึงแนวทางยกระดับคุณภาพโดยรวมได้

    • ไม่ได้ตามความคืบหน้าล่าสุดของตัวถอดรหัสมานานกว่าสิบปีแล้ว แต่โดยสัญชาตญาณคิดว่าการเร่งด้วย GPU น่าจะช่วยมากในงาน post-processing ช่วงที่แปลงเป็นข้อมูลพิกเซล

      • ช่วงแตกข้อมูลเริ่มต้นอาจทำบน CPU แล้วค่อยส่งข้อมูลที่แตกแล้วไปยัง GPU เพื่อทำการแปลงขั้นสุดท้ายต่อ (เช่น ใช้ motion vector, iDCT ฯลฯ)
      • ถ้าเฟรมที่เสร็จสมบูรณ์อยู่ในรูป GPU texture อยู่แล้ว overhead ตอนแสดงผลก็น่าจะต่ำ
      • เลยสงสัยว่าสัญชาตญาณนี้ถูกต้องแค่ไหน

    • รู้สึกทึ่งกับความสามารถของเมนเทนเนอร์ FFmpeg ทุกครั้ง งานยากระดับนี้แต่ทำให้ใช้ฟรีได้ถือว่าสุดยอดมาก

    • release note นี้น่าสนใจมาก

      • ช่วงไม่กี่สัปดาห์ที่ผ่านมาได้ทำ ProRes decoder ด้วย WebGPU compute shader ซึ่งทำงานได้เร็วพอสมควร (คาดว่า Apple คงใช้ hardware acceleration ของตัวเอง)
      • เส้นทางนี้น่าจะเข้ากันได้ดีกับโคเดก APV ใหม่ของ Android ด้วย
      • สเปกของ ProRes bitstream ถูกส่งให้ SMPTE แล้ว แต่ข้อมูลเกี่ยวกับ ProRes RAW หาได้ยากมาก
      • รู้สึกว่าน่าสนใจมากที่เริ่มมี implementation แบบซอฟต์แวร์และแบบ compute ปรากฏขึ้นมา น่าจะเป็นไปได้ว่านักพัฒนา ffmpeg ทำ reverse engineering กันมา
      • ดูโค้ดคร่าว ๆ แล้วก็ไม่เห็นว่าจะต่างจาก ProRes ปกติมากนัก
      • เอกสารสเปก ProRes

  • ทุกครั้งที่ใช้ FFmpeg ก็อดทึ่งไม่ได้ (แม้ว่าจะต้องกลับไปเปิดคู่มือใหม่หรือขอให้ LLM ช่วยบ้างก็ตาม แม้แต่ตอนใช้ GUI ที่สร้างคำสั่งจากตัวเลือกแบบภาพก็ยังรู้สึกแบบนั้น)

    • ตอนนี้มันเหมือนกลายเป็น multi-tool ด้าน transcoding ที่ขาดไม่ได้ไปแล้ว
    • คิดว่าการนำ processing บน Vulkan 1.3 มาใช้นั้นเป็นการตัดสินใจที่ดี
    • เมื่อวานก็เพิ่งเห็นว่า Asahi Linux on Mac รองรับมาตรฐานเดียวกันด้วย

    • ทิ้งมุกไว้ว่าอาร์กิวเมนต์ของ FFmpeg นี่แหละคือ “prompt engineering ต้นฉบับ”

    • LLM กับเครื่องมือ command line ที่ซับซ้อนอย่าง FFmpeg และ ImageMagick เป็นการจับคู่ที่ยอดเยี่ยมมาก

      • รู้สึกเหมือนเป็น UI/UX แห่งอนาคตที่สมบูรณ์แบบ แค่บรรยายสิ่งที่ต้องการเป็นภาษาธรรมชาติ ก็ทำให้เกิดขึ้นได้ทันที
      • ลองนึกภาพสถานการณ์ที่สามารถครอปภาพทุกภาพในโฟลเดอร์ให้เป็นขนาดที่กำหนด ปรับ saturation บันทึกเป็น TIFF แล้วประกอบเป็นลูปวิดีโอพร้อมเข้ารหัสสำหรับเว็บได้ในครั้งเดียว

    • LLMs ทำงานเป็นอินเทอร์เฟซให้ FFmpeg ได้ยอดเยี่ยมมาก

      • มีเครื่องมือมากมายที่ช่วยให้ใช้งานด้วยภาษาธรรมชาติได้ และเจ้าตัวก็แชร์สคริปต์ของตัวเองด้วย (https://github.com/jjcm/llmpeg)

  • แชร์ความจริงปนขำว่าเวลาใช้ ffmpeg ไป 50% หมดกับการสร้างคำสั่ง CLI ซับซ้อน ๆ และอีก 50% หมดกับการสู้เรื่อง shell escape

    • โดยเฉพาะตอนใส่ข้อความลงบนวิดีโอ การ escape ข้อความนั้นยากมากเป็นพิเศษ
    • สงสัยว่ามีใครเจอวิธีที่สมบูรณ์แบบในการเรียก ffmpeg จาก Python พร้อมอาร์กิวเมนต์จำนวนมาก (เช่น filter ต่าง ๆ) หรือยัง (r-strings? heredocs? ฯลฯ)

  • สงสัยว่ามี GUI frontend ดี ๆ ที่จัดการฟีเจอร์หลากหลายของ FFmpeg ได้ง่ายหรือไม่

    • บางครั้งก็แค่ต้องการ remux หรือแค่อยากรวม video/audio stream ที่ใช้โคเดกเดียวกันเท่านั้น

    • เน้นว่าการรวมวิดีโอดูเหมือนง่าย แต่จริง ๆ มีตัวแปรและปัญหาเยอะกว่าที่คิด

      • มีตัวแปรอย่าง timebase, start offset, การครอปเฟรม, ความต่างของ FPS, B-frame, open GOP ฯลฯ ที่อาจทำให้เกิดปัญหาในสภาพแวดล้อมการเล่นบางแบบ
      • ฝั่งเสียงก็มีตัวแปรอีกหลายอย่าง เช่น ความต่างของ sample rate
      • มีการพูดถึงโปรแกรม Lossless-Cut ว่าฟีเจอร์ตรวจสอบความเข้ากันได้มีประโยชน์มาก
      • แต่การแปลงวิดีโอเป็น MPEG-TS ก่อนแล้วค่อยรวมกันนั้นช่วยเลี่ยงปัญหาได้หลายอย่าง และประมวลผลบน ramdisk ได้อย่างรวดเร็ว
      • มีการแชร์ตัวอย่างลำดับคำสั่ง ffmpeg ที่ใช้ได้ด้วย

    • Handbrake ทำหน้าที่นี้ได้ดีมาก

      • ในแง่ฟีเจอร์ก็เพียงพอ แม้จะดูเก่าไปนิดแต่ก็ยังใช้งานได้มีประโยชน์เสมอ

    • ถ้าเป็นผู้ใช้ Mac ขอแนะนำ ffWorks (https://www.ffworks.net/index.html)

      • เข้าถึงฟีเจอร์ส่วนใหญ่ได้ง่าย และรองรับการประมวลผลแบบ batch กับการตั้ง preset ด้วย
      • ผู้พัฒนาให้การสนับสนุนอย่างกระตือรือร้นมาก จึงเป็นหนึ่งในแอปที่ชอบที่สุด และยังรู้สึกว่าคุ้มค่าจนบริจาคให้ด้วย
      • Handbrake กับ Losslesscut ก็ยอดเยี่ยม แต่ดูเหมือนบนแพลตฟอร์มอื่นจะยังไม่มีแอปไหนสู้ความสมบูรณ์ของ ffWorks ได้

    • สำหรับตัวเอง คิดว่า frontend ที่ดีที่สุดคือ ChatGPT

      • ถ้าอธิบายงานที่ต้องการด้วยภาษาธรรมชาติ มันจะสร้างคำสั่ง ffmpeg ที่แม่นยำได้มาก

    • แนะนำให้ลองดูโปรแกรม Lossless-cut

  • แชร์ลิงก์สำหรับดูการเปลี่ยนแปลงของ FFmpeg (Changelog) (https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)

  • พูดสั้น ๆ ว่าเป็นข่าวที่น่าสนใจ

    • สงสัยว่าวิดีโอนี้เป็นการเสียดสีหรือเอาจริงกันแน่

  • เสนอความเห็นส่วนตัวว่า ffmpeg อาจเป็นไลบรารีที่ถูกใช้งานมากเป็นอันดับ 4 รองจาก ssl, zlib, sqlite (โดยตั้งอยู่บนสมมติฐานว่าวิดีโอมีอยู่ทุกที่จริง ๆ ในปี 2025)

    • มองว่าเห็นด้วยได้ยาก เพราะงานประมวลผลวิดีโอมักจำเป็นบนเซิร์ฟเวอร์ที่รับสื่อเป็นหลัก

      • กล่าวถึงว่ามือถือส่วนใหญ่ไม่ได้ประมวลผลวิดีโอด้วย ffmpeg

    • curl อาจอยู่อันดับสูงกว่า และ “SSL” เองก็มีหลาย implementation ทำให้ตัวเลขกระจายออกไป

    • เสนอ log metric ของ fastly ในโครงสร้างพื้นฐาน NixOS (https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md) เป็นแหล่งข้อมูล

    • คิดว่ายังมีไลบรารีอย่าง Qt, libpng, libusb ฯลฯ ที่ถูกใช้งานมากกว่า ffmpeg อยู่พอสมควร

    • สถิติแพ็กเกจของ Arch Linux (https://pkgstats.archlinux.de/packages) ก็น่าลองดูเช่นกัน

  • คิดว่า implementation แบบ Vulkan compute shader นั้นเจ๋งเป็นพิเศษใน FFv1 และ ProRes RAW

    • เพราะมันข้าม fixed-function hardware decoder ไปทั้งหมด เลยสงสัยว่าผลกระทบต่อ memory bandwidth เป็นอย่างไร
    • context-adaptive arithmetic coding ของ FFv1 ดูจะมีลักษณะต่อเนื่องโดยเนื้อแท้จนไม่น่าจะเร่งความเร็วได้ แต่ก็ยังแปลกใจที่ได้ประสิทธิภาพเพิ่มขึ้นมาก
    • สงสัยว่าเป็นการขนานหลายสัญลักษณ์พร้อมกัน หรือขนานในระดับ slice กันแน่ เพราะโดยทั่วไปมีเหตุผลที่การเร่ง arithmetic coding ด้วย GPU ทำได้ยาก เลยอยากรู้ว่าทีม ffmpeg แลกเปลี่ยนอะไรไปบ้าง
    • ถ้ามีใครเคยทำ profiling implementation นี้ ก็อยากฟังเรื่องสัดส่วนการใช้ทรัพยากรในขั้น entropy decoding และการเลือกด้าน bandwidth

  • ffmpeg เป็นรากฐานของเครื่องมือจำนวนมหาศาล

    • คนทั่วไปมักไม่ค่อยรู้ว่า ffmpeg มีส่วนช่วยอุตสาหกรรมสื่อมากแค่ไหน
    • มันเป็นเครื่องมือที่หยิบมาใช้ทุกครั้งเมื่อจำเป็นต้องทำงานอัตโนมัติด้านเสียง/วิดีโอ