- Meta chạy FFmpeg hàng chục tỷ lần mỗi ngày và đã chuyển đổi hoàn toàn thành công sang FFmpeg upstream thay vì tiếp tục dùng bản fork nội bộ
- Để thu hẹp khoảng cách tính năng giữa bản fork nội bộ và phiên bản mã nguồn mở, Meta đã hợp tác với FFlabs và VideoLAN để đưa mã hóa song song multi-lane cùng tính năng đo chất lượng theo thời gian thực lên upstream
- Xử lý hơn 1 tỷ lượt tải video lên mỗi ngày, Meta thực hiện mã hóa đa độ phân giải và codec cho phát DASH chỉ bằng một dòng lệnh FFmpeg duy nhất
- Cấu trúc phân luồng hiệu quả được triển khai trong các phiên bản FFmpeg 6.0~8.0 dựa trên thiết kế của Meta, mang lại hiệu quả mã hóa cao hơn cho mọi người dùng
- Meta tích hợp MSVP (Meta Scalable Video Processor), ASIC do hãng tự thiết kế, thông qua API phần cứng tiêu chuẩn của FFmpeg để bảo đảm tính nhất quán giữa pipeline phần mềm và phần cứng
- Thông qua đầu tư liên tục vào FFmpeg, dự án đã được phát triển hơn 25 năm, Meta đồng thời củng cố các trải nghiệm video mới và độ ổn định trên nền tảng của mình
Vai trò của FFmpeg và thách thức của Meta
- FFmpeg là công cụ xử lý media tiêu chuẩn của ngành, hỗ trợ nhiều codec âm thanh/video và định dạng container khác nhau, đồng thời cho phép chỉnh sửa và chuyển đổi media qua các chuỗi filter phức tạp
- Meta chạy các binary ffmpeg (CLI chính) và ffprobe (tiện ích truy vấn thuộc tính tệp media) hàng chục tỷ lần mỗi ngày, với các yêu cầu vượt xa việc xử lý từng tệp riêng lẻ
- Trong thời gian dài, công ty phụ thuộc vào bản fork nội bộ để tự triển khai các tính năng khi đó chưa có trên upstream như mã hóa multi-lane dựa trên luồng và tính toán chỉ số chất lượng theo thời gian thực
Sự phân nhánh của bản fork nội bộ và nhu cầu quay lại upstream
- Bản fork nội bộ ngày càng tách biệt đáng kể với FFmpeg upstream, khiến khoảng cách về bộ tính năng tiếp tục nới rộng
- Đồng thời, các phiên bản FFmpeg mới bổ sung hỗ trợ codec và định dạng tệp mới cùng với cải thiện độ ổn định, nên Meta cũng cần song song hỗ trợ phiên bản mã nguồn mở mới nhất để tiếp nhận liên tục các nội dung video đa dạng do người dùng tải lên
- Khi rebase các thay đổi nội bộ, việc ngăn hồi quy trở nên ngày càng khó khăn, vì vậy Meta đã hợp tác với các nhà phát triển FFmpeg, FFlabs và VideoLAN để loại bỏ hoàn toàn bản fork nội bộ và chuyển sang chỉ dùng phiên bản upstream
Xây dựng transcoding multi-lane hiệu quả (VOD và livestream)
- Khi người dùng tải video lên, Meta tạo ra nhiều bộ mã hóa cho phát DASH (Dynamic Adaptive Streaming over HTTP), cung cấp các bản mã hóa khác nhau theo độ phân giải, codec, tốc độ khung hình và mức chất lượng
- Trình phát video trong ứng dụng có thể chuyển đổi theo thời gian thực giữa các bản mã hóa này dựa trên tín hiệu như tình trạng mạng
- Cách đơn giản nhất là xử lý từng lane bằng các dòng lệnh FFmpeg riêng theo tuần tự, nhưng ngay cả khi chạy song song thì mỗi tiến trình vẫn thực hiện công việc trùng lặp như giải mã lặp lại và chịu overhead khởi tạo tiến trình, nên kém hiệu quả
- Nếu chỉ dùng một dòng lệnh FFmpeg để giải mã khung hình một lần rồi chuyển chúng tới từng encoder đầu ra, có thể loại bỏ trùng lặp khi giải mã và giảm overhead khởi tạo tiến trình
- Meta xử lý hơn 1 tỷ lượt tải video lên mỗi ngày, nên việc tiết kiệm tính toán trên mỗi tiến trình tạo ra cải thiện hiệu quả rất lớn ở quy mô toàn hệ thống
- Bản fork nội bộ của Meta còn bổ sung tối ưu hóa mã hóa video song song: FFmpeg trước đây khi dùng nhiều encoder sẽ chạy tuần tự theo từng khung hình, còn Meta cho chạy song song mọi instance encoder để đạt mức độ song song cao hơn
- Nhờ đóng góp của các nhà phát triển FFmpeg (bao gồm FFlabs và VideoLAN), cơ chế phân luồng hiệu quả hơn bắt đầu được triển khai từ FFmpeg 6.0 và hoàn thiện ở 8.0
- Thiết kế này chịu ảnh hưởng trực tiếp từ bản fork nội bộ của Meta và được ghi nhận là đợt tái cấu trúc FFmpeg phức tạp nhất trong nhiều thập kỷ
- Nó mang lại lợi ích mã hóa hiệu quả hơn cho mọi người dùng FFmpeg
Chỉ số chất lượng theo thời gian thực (livestream)
- Các chỉ số chất lượng thị giác dùng để biểu diễn chất lượng hình ảnh cảm nhận bằng con số, nhằm định lượng mức suy giảm chất lượng do nén gây ra
- Chỉ số tham chiếu (reference): so sánh bản mã hóa gốc với bản mã hóa bị méo
- Chỉ số không tham chiếu (no-reference): đánh giá chất lượng mà không cần bản gốc
- FFmpeg có thể tính các chỉ số như PSNR, SSIM, VMAF sau khi mã hóa hoàn tất bằng một dòng lệnh riêng dùng hai bản mã hóa có sẵn, nhưng với livestream thì cần tính theo thời gian thực
- Bằng cách chèn bộ giải mã video phía sau encoder video của từng lane đầu ra, Meta lấy bitmap khung hình sau khi nén và so sánh với khung hình trước khi nén để tạo ra chỉ số chất lượng cho từng lane mã hóa theo thời gian thực ngay trong một dòng lệnh FFmpeg duy nhất
- Từ FFmpeg 7.0, nhờ đóng góp từ các nhà phát triển FFlabs và VideoLAN, tính năng giải mã "in-loop" được kích hoạt, qua đó chấm dứt hoàn toàn sự phụ thuộc vào bản fork nội bộ cho tính năng này
Tiêu chí đóng góp upstream và các bản vá chỉ dùng nội bộ
- Những tính năng như chỉ số chất lượng theo thời gian thực và phân luồng hiệu quả mang lại cải thiện hiệu suất cho nhiều pipeline dựa trên FFmpeg cả trong lẫn ngoài Meta, nên được đóng góp lên upstream
- Ngược lại, các bản vá quá đặc thù với hạ tầng của Meta và khó khái quát hóa thì chỉ được duy trì nội bộ
- FFmpeg hỗ trợ giải mã, mã hóa và lọc tăng tốc phần cứng thông qua API tiêu chuẩn cho NVIDIA NVDEC/NVENC, AMD UVD, Intel QSV và nhiều nền tảng khác
- MSVP (Meta Scalable Video Processor), ASIC chuyển mã video do Meta tự phát triển, cũng được bổ sung hỗ trợ thông qua cùng API tiêu chuẩn đó, cho phép dùng chung công cụ trên nhiều nền tảng phần cứng khác nhau
- Vì MSVP chỉ được dùng trong hạ tầng nội bộ của Meta nên các nhà phát triển FFmpeg bên ngoài không thể truy cập phần cứng để kiểm thử và xác minh, do đó phần hỗ trợ này được giữ lại dưới dạng bản vá nội bộ
- Khi rebase lên phiên bản FFmpeg mới nhất, Meta bảo đảm độ vững chắc và độ chính xác thông qua xác minh trên diện rộng
Đầu tư liên tục vào FFmpeg
- Nhờ các tính năng mã hóa multi-lane và chỉ số chất lượng theo thời gian thực, Meta đã loại bỏ hoàn toàn bản fork nội bộ trên mọi pipeline VOD và livestream
- API phần cứng tiêu chuẩn của FFmpeg cho phép Meta hỗ trợ song song ASIC MSVP và các pipeline dựa trên phần mềm với ma sát tối thiểu
- Meta có kế hoạch tiếp tục đầu tư vào FFmpeg, dự án đã được phát triển tích cực hơn 25 năm, thông qua quan hệ hợp tác với các nhà phát triển mã nguồn mở, mang lại lợi ích cho Meta, ngành công nghiệp và người dùng
1 bình luận
Ý kiến trên Hacker News
Khi nhánh fork nội bộ ngày càng trở nên lỗi thời, chúng tôi đã hợp tác với các nhà phát triển FFmpeg để tích hợp các tính năng cần thiết vào FFmpeg chính thức
Nhờ đó, giờ đây có thể loại bỏ hoàn toàn phiên bản nội bộ và chỉ vận hành bằng phiên bản upstream
Một số người nói rằng “đáng lẽ có thể đóng góp nhiều hơn”, nhưng bản chất của mã nguồn mở là mọi người cùng chia sẻ lợi ích
Chúng ta đã hưởng lợi từ vô số dự án như React, React Native
Cuối cùng, tôi thấy cấu trúc như vậy chỉ có lợi cho phía nắm quyền lực
Dù vậy, việc Meta công khai rất nhiều thứ cho hệ sinh thái mã nguồn mở vẫn là một yếu tố tạo khác biệt trong ngành
Cách diễn đạt kiểu “giờ mới tích hợp lên upstream” tạo cảm giác như đang cố bao biện cho những thiếu sót trước đây
Việc trộn câu chữ marketing vào blog kỹ thuật khá khó chịu từ góc nhìn người đọc
Mong rằng khi Fabrice Bellard nghỉ hưu, ông ấy sẽ được đền đáp xứng đáng
Rất nhiều công ty đã kiếm tiền nhờ phần mềm của ông
Việc phiên bản FFmpeg mới hỗ trợ nhiều codec và định dạng hơn là điều tốt,
nhưng với quy mô Meta chạy nó hàng chục tỷ lần mỗi ngày, tôi vẫn tò mò liệu họ có tham gia liên tục vào những cải tiến này hay không
Việc chạy tới hàng chục tỷ lần mỗi ngày thực sự là một quy mô khổng lồ
Tôi chỉ chạy tác vụ ghép video tự động vài nghìn lần mỗi ngày thôi mà đã cảm nhận được overhead
Nhờ tính năng
single-decode multi-output, thời gian xử lý đã giảm 40%May là giá bộ nhớ gần đây giảm, nên hiệu quả chi phí của các cải tiến mã nguồn mở còn cao hơn nữa
Cách tiếp cận chạy song song các instance encoder để tăng mức độ song song là hợp lý
Nhưng tôi muốn thấy tính năng song song hóa theo trục thời gian (time-axis parallelization)
Nếu chia video đầu vào theo các keyframe rồi encode song song, có thể tăng tốc mà không làm giảm chất lượng
Thường thì encoder đặt chúng một cách động để tối ưu hiệu quả, nên việc chia sẵn có thể sẽ khó
Cảm ơn đội ngũ Meta vì đã đóng góp cho
ffmpegvàffprobeMong rằng trong tương lai họ cũng sẽ cân nhắc hỗ trợ tài chính cho chất lượng mã nguồn, tài liệu và các sự kiện cộng đồng
Câu “nhánh fork nội bộ ngày càng cũ đi” thật sự rất đồng cảm được
Nhân tiện, trong FFmpeg 8, việc ánh xạ màu giữa HDR và SDR đã được xử lý hoàn hảo
Tin Đức có Sovereign Tech Fund quyên góp cho FFmpeg khá thú vị
Có lẽ Meta đang có cả một đội chuyên về media encoding và đóng góp với giá trị hơn 1 triệu USD mỗi năm
Xem tweet liên quan
STF của Đức được cho là đã hỗ trợ €157,580 trong giai đoạn 2024/2025
May là các máy chủ FFmpeg chỉ đang xử lý nội dung nhẹ nên còn trụ được
Nếu là video nặng thì có lẽ đã quá tải rồi
Cùng bài đăng HN này đã được đăng từ 6 ngày trước
Tôi không hiểu vì sao chỉ vì gắn link này mà lại bị downvote