Phát hành FFmpeg 8.0

 (ffmpeg.org)
2 điểm bởi GN⁺ 2025-08-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • FFmpeg 8.0 "Huffman" bổ sung codec dựa trên tính toán Vulkan cùng giải mã/mã hóa tăng tốc phần cứng và nhiều định dạng tệp, bộ lọc mới
  • Hạ tầng đã được hiện đại hóa toàn diện, đồng thời quy trình đóng góp và chất lượng mã nguồn cũng được tăng cường
  • Các mảng codec âm thanh và video chủ chốt cũng đã tiến bộ, bao gồm ổn định hóa bộ giải mã VVC, bộ giải mã xHE-AAC, hỗ trợ MV-HEVC và LC-EVC
  • Dự án tiếp tục giữ vai trò trung tâm trong sự phát triển của công nghệ đa phương tiện mã nguồn mở, đồng thời liên tục cải thiện tính năng và tăng cường bảo mật

Giới thiệu FFmpeg

  • FFmpeg là bộ công cụ xử lý đa phương tiện đa dụng hoàn chỉnh, cung cấp giải pháp linh hoạt và mạnh mẽ để ghi, chuyển đổi, truyền phát âm thanh và video
  • Chỉ với một lệnh đơn giản như ffmpeg -i input.mp4 output.avi, người dùng có thể xử lý video và âm thanh

Ngày 23 tháng 8 năm 2025, phát hành FFmpeg 8.0 "Huffman"

  • FFmpeg 8.0 "Huffman" đã được công bố. Sau nhiều lần trì hoãn và quá trình hiện đại hóa hạ tầng, đây là bản phát hành có quy mô lớn nhất từ trước đến nay
  • Các tính năng mới bao gồm bổ sung bộ giải mã native như APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728, tăng cường hỗ trợ IBC, ACT, Palette Mode cho bộ giải mã VVC, cùng các codec như FFv1 (mã hóa/giải mã), ProRes RAW (chỉ giải mã) dựa trên tính toán Vulkan
  • Đã bổ sung giải mã tăng tốc phần cứng dựa trên Vulkan (ví dụ: VP9, VVC, H264/5) và mã hóa (AV1, H264/5), cùng nhiều định dạng mới (MCC, G.728, Whip, APV) và bộ lọc (colordetect, pad_cuda, scale_d3d11, Whisper, v.v.)
  • Một dòng bộ giải mã và bộ mã hóa mới dựa trên compute shader, chạy trên Vulkan 1.3, đã được bổ sung. Cấu trúc này không yêu cầu bộ tăng tốc phần cứng chuyên dụng riêng và hoạt động giống hệt hwaccel API. Khi dùng bộ mã hóa, cần chỉ định bộ mã hóa mới; hiện chỉ hỗ trợ FFv1 (mã hóa/giải mã) và ProRes RAW (giải mã). ProRes (hai chiều) và VC-2 (hai chiều) đang được chuẩn bị
  • Cấu trúc này chỉ có thể áp dụng cho các codec được tối ưu cho giải mã song song, và trong tương lai được kỳ vọng mang lại cải thiện hiệu năng lớn hơn cùng các cách sử dụng mới như biên tập video phi tuyến và ghi hình lossless
  • Hạ tầng của dự án cũng đã được cập nhật đáng kể. Máy chủ mailing list đã được thay thế hoàn toàn, và hiện hỗ trợ cộng tác mã nguồn dựa trên Forgejo tại code.ffmpeg.org
  • Người dùng được khuyến nghị nâng cấp lên phiên bản mới nhất

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-08-23
Ý kiến trên Hacker News

  • Gửi lời cảm ơn tới các nhà phát triển và cộng tác viên của FFmpeg

    • Mỗi khi cần tự động hóa audio/video thì luôn dùng FFmpeg, và phần lớn các công cụ video trực tuyến cũng dùng công cụ này làm engine cốt lõi hoặc như một lớp UI bọc ngoài
    • Hôm nay cũng mới biết có dự án FFmpeg.Wasm (https://github.com/ffmpegwasm/ffmpeg.wasm)
    • Chia sẻ trải nghiệm vào tháng 1/2024 khi trích xuất frame từ một phim hoạt hình năm 1993 theo từng đoạn 15 phút, rồi dùng Real-ESRGAN-ncnn-vulkan (https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan) để upscale và ghép lại các frame kết quả thành 4K
    • Nghĩ rằng nếu thêm UI vào quy trình này thì có thể đã trở thành một công cụ kiểu như Topaz AI đang phổ biến hiện nay
    • Cũng chia sẻ ảnh mẫu đã được upscale (ảnh mẫu)
    • Ngay cả khi không trực tiếp dùng ffmpeg thì vẫn thường xuyên dùng các công cụ có nhúng nó
      • Gần đây đã upscale một bộ anime chất lượng thấp được rip từ DVD cũ thông qua k4yt3x/video2x, cài đặt dễ và có libffmpeg tích hợp sẵn
      • Khi encode có thể dùng cùng các tham số như FFmpeg
      • Để chọn tham số tối ưu, đã encode một cảnh ngắn bằng ffmpeg với nhiều bộ tham số khác nhau, rồi lại dùng ffmpeg trích xuất ảnh tĩnh để so sánh

  • Vui khi FFmpeg đã đưa vào encoder và decoder video dựa trên compute shader

    • Các codec được phần cứng hỗ trợ rộng rãi chủ yếu là H.264, H.265, AV1, nên sẽ rất tốt nếu các codec khác cũng có thể tận dụng tăng tốc nền tảng, dù hiệu quả có thể thấp hơn một chút
    • Encoder ProRes mới có vẻ hữu ích cho dự án đang làm
    • Hiểu lời giải thích rằng các codec phổ biến, được dùng rộng rãi không phù hợp lắm cho giải mã song song nên khó hỗ trợ
    • Phải dùng đến hàng chục nghìn luồng, nhưng do phụ thuộc dữ liệu giữa các frame và giữa các tile nên việc song song hóa không hề dễ
    • Encoder có vẻ linh hoạt hơn decoder đôi chút, nhưng việc encode thứ như VP9 (https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) bằng compute shader vẫn có vẻ là một bài toán đầy thách thức

    • Một lần nữa chia sẻ niềm vui về việc encoder/decoder video được triển khai bằng compute shader

      • Trước đây chỉ có các interface phần cứng in-silicon được chuẩn hóa, nên từng bị cười khi hỏi liệu encoder/decoder dựa trên Vulkan có mang tính phổ quát hay không
      • Thật tuyệt khi những cải tiến này cũng có trên phần cứng cũ, và hy vọng cách làm này sẽ mở ra con đường cho codec mới cũng như cải thiện chất lượng tổng thể

    • Dù hơn 10 năm rồi chưa theo dõi sát các xu hướng mới của decoder, nhưng trực giác cho rằng tăng tốc GPU sẽ đặc biệt hữu ích ở giai đoạn hậu xử lý khi dữ liệu được chuyển thành dữ liệu pixel

      • Giai đoạn giải nén ban đầu có thể chạy trên CPU, sau đó chuyển dữ liệu đã giải nén sang GPU để thực hiện bước biến đổi cuối cùng như áp dụng motion vector, iDCT, v.v.
      • Nếu frame hoàn chỉnh đã nằm sẵn trong texture GPU thì overhead hiển thị cũng sẽ thấp
      • Tò mò không biết trực giác đó đúng tới mức nào

    • Luôn kinh ngạc trước tài năng của các maintainer FFmpeg, thật đáng nể khi họ làm miễn phí những việc khó đến vậy

    • Ghi chú phát hành này rất thú vị

      • Gần đây đã làm một decoder ProRes bằng WebGPU compute shader trong vài tuần, và nó chạy đủ nhanh (có lẽ Apple sẽ dùng tăng tốc phần cứng riêng của họ)
      • Hướng tiếp cận này có vẻ cũng rất hợp với codec APV mới của Android
      • Đặc tả bitstream ProRes đã được nộp cho SMPTE, nhưng rất khó tìm thông tin về ProRes RAW
      • Cảm thấy rất thú vị khi xuất hiện các triển khai dựa trên software và compute, có lẽ các nhà phát triển ffmpeg đã reverse engineer nó
      • Xem sơ qua mã nguồn thì có vẻ không khác mấy so với ProRes thông thường
      • Tài liệu đặc tả ProRes

  • Mỗi lần dùng FFmpeg đều phải trầm trồ (dù vẫn cần tra lại manual hoặc nhờ LLM giúp, ngay cả khi dùng GUI tạo lệnh từ các tùy chọn trực quan)

    • Có vẻ giờ nó đã trở thành multitool chuyển mã thiết yếu
    • Việc đưa vào xử lý dựa trên Vulkan 1.3 là một quyết định tốt
    • Hôm qua cũng mới biết Asahi Linux trên Mac hỗ trợ cùng tiêu chuẩn này

    • Một cách nói dí dỏm rằng các tham số FFmpeg chính là “prompt engineering nguyên bản”

    • LLM và các công cụ dòng lệnh phức tạp như FFmpeg, ImageMagick là một sự kết hợp tuyệt vời

      • Chỉ cần mô tả bằng ngôn ngữ tự nhiên việc muốn làm là có thể thực hiện ngay, đến mức cảm thấy đó là UI/UX tương lai hoàn hảo
      • Hình dung một kịch bản xử lý một lần hết mọi thứ: crop toàn bộ ảnh trong thư mục về kích thước nhất định, chỉnh saturation, lưu thành TIFF, ghép thành vòng lặp video rồi encode cho web

    • LLMs hoạt động rất tốt như một interface cho FFmpeg

      • Có rất nhiều công cụ giúp dùng nó bằng ngôn ngữ tự nhiên, và cũng chia sẻ script của mình (https://github.com/jjcm/llmpeg)

  • Chia sẻ vui mà thật rằng 50% công sức bị lãng phí để tạo các lệnh CLI phức tạp bằng ffmpeg, còn 50% còn lại là để vật lộn với shell escaping

    • Đặc biệt là escaping văn bản khi chèn text lên video cực kỳ khó chịu
    • Tò mò không biết có ai đã tìm ra cách hoàn hảo để gọi ffmpeg từ Python với rất nhiều tham số như filter hay chưa (r-strings? heredocs? v.v.)

  • Tò mò không biết có frontend GUI nào tốt để xử lý dễ dàng các tính năng đa dạng của FFmpeg hay không

    • Đôi khi chỉ cần remux đơn giản, hoặc chỉ muốn ghép stream video/audio cùng codec với nhau

    • Việc ghép video nghe thì dễ nhưng thực tế có nhiều biến số và vấn đề hơn tưởng tượng

      • Có thể phát sinh lỗi ở một số môi trường phát do các biến như timebase, start offset, crop frame, khác biệt FPS, B-frame, open GOP, v.v.
      • Audio cũng có nhiều biến số như khác biệt sample rate
      • Có nhắc tới chương trình Lossless-Cut, trong đó tính năng kiểm tra tương thích rất hữu ích
      • Tuy vậy, chuyển video sang MPEG-TS rồi mới ghép lại là cách tốt để né được nhiều vấn đề, và có thể xử lý nhanh trên RAM disk
      • Cũng chia sẻ một chuỗi lệnh ffmpeg có thể dùng làm ví dụ

    • Handbrake làm việc đó khá tốt

      • Về mặt tính năng là đủ dùng, hơi cũ một chút nhưng vẫn hữu ích

    • Nếu là người dùng Mac thì khuyên dùng ffWorks (https://www.ffworks.net/index.html)

      • Có thể dễ dàng truy cập hầu hết tính năng, đồng thời hỗ trợ xử lý hàng loạt và thiết lập preset
      • Nhà phát triển hỗ trợ rất tích cực nên đây là một trong những ứng dụng yêu thích nhất, đến mức thấy đáng để donate
      • Handbrake và Losslesscut cũng rất tuyệt, nhưng có vẻ trên nền tảng khác chưa có ứng dụng nào cạnh tranh được mức độ hoàn thiện của ffWorks

    • Với bản thân thì frontend tốt nhất chính là ChatGPT

      • Chỉ cần mô tả bằng ngôn ngữ tự nhiên việc muốn làm là nó tạo ra lệnh ffmpeg cực kỳ chính xác

    • Khuyên nên xem thử chương trình Lossless-cut

  • Chia sẻ liên kết để xem changelog của FFmpeg (https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)

  • Một tin khá thú vị

    • Tò mò không biết video này là châm biếm hay nghiêm túc

  • Nêu ý kiến cá nhân rằng ffmpeg có lẽ là thư viện được dùng nhiều thứ 4 sau ssl, zlib và sqlite (với giả định video vào năm 2025 thực sự đã ở khắp mọi nơi)

    • Cho rằng khó đồng ý, vì xử lý video chủ yếu cần ở các server nhận media

      • Nhắc rằng phần lớn điện thoại không xử lý video bằng ffmpeg

    • curl có thể còn đứng cao hơn, còn “SSL” thì có nhiều implementation nên số liệu sẽ bị phân tán

    • Đề xuất log metric fastly của hạ tầng NixOS (https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md) làm nguồn dữ liệu

    • Nghĩ rằng còn khá nhiều thư viện được dùng nhiều hơn ffmpeg như Qt, libpng, libusb

    • Cũng đáng xem thống kê gói của Arch Linux (https://pkgstats.archlinux.de/packages)

  • Cho rằng phần triển khai compute shader trên Vulkan đặc biệt ấn tượng ở FFv1 và ProRes RAW

    • Vì nó hoàn toàn bỏ qua fixed-function hardware decoder nên tò mò tác động lên băng thông bộ nhớ sẽ ra sao
    • Mã hóa số học thích ứng theo ngữ cảnh của FFv1 về bản chất có tính tuần tự nên tưởng rằng khó mà tăng tốc được, vì vậy rất ngạc nhiên khi thấy đạt được mức cải thiện tốc độ lớn
    • Tò mò không biết họ song song hóa nhiều symbol cùng lúc hay song song theo từng slice, vì từ trước tới nay việc tăng tốc mã hóa số học trên GPU vốn khó, nên muốn biết nhóm ffmpeg đã chấp nhận những trade-off nào
    • Nếu có ai đã từng profiling phần triển khai đó thì rất muốn nghe về mức sử dụng ở giai đoạn entropy decoding và lựa chọn băng thông

  • ffmpeg là nền tảng của vô số công cụ

    • Công chúng thường không biết ffmpeg đã đóng góp nhiều đến mức nào cho ngành media
    • Mỗi khi cần tự động hóa audio/video thì đây luôn là công cụ được tìm đến