FFmpeg giới thiệu đa luồng cho CLI qua đợt "tái cấu trúc phức tạp nhất" trong nhiều thập kỷ

Hỗ trợ đa luồng cho FFmpeg CLI

• Tính năng hỗ trợ đa luồng cho giao diện dòng lệnh (CLI) của FFmpeg đã được hợp nhất vào Git của FFmpeg.
• Đây là thay đổi được thực hiện trước khi FFmpeg 7.0 phát hành vào đầu năm sau, và là một cải tiến lớn đối với dự án mã nguồn mở quan trọng được sử dụng rộng rãi cho việc chuyển mã video.
• Trong bối cảnh bộ xử lý đa lõi đã trở nên phổ biến, cải tiến này là cực kỳ hữu ích.

Công việc tái cấu trúc phức tạp

• Trong thông báo kỹ thuật gần đây, các nhà phát triển FFmpeg mô tả công việc đa luồng này là "một trong những đợt tái cấu trúc phức tạp nhất từng được thực hiện trên FFmpeg CLI trong nhiều thập kỷ".
• Các nhà phát triển kêu gọi người dùng thử nghiệm và báo cáo các vấn đề được phát hiện lên FFmpeg Trac.

Những thay đổi kỹ thuật đã được triển khai

• Bản vá đã được hợp nhất bao gồm việc bổ sung hạ tầng lập lịch chuyển mã có nhận thức về luồng, chuyển quá trình mã hóa sang một luồng riêng, cùng nhiều thay đổi mức thấp khác.
• Việc chuyển FFmpeg sang kiến trúc luồng có nghĩa là mỗi thành phần (demuxer, decoder, filter, encoder, muxer) vốn đã chạy trên các luồng riêng biệt, nay có thể thực sự chạy song song.

Ý kiến của GN⁺

• Hỗ trợ đa luồng của FFmpeg là một bước tiến quan trọng có thể cải thiện đáng kể hiệu quả của các tác vụ chuyển mã video.
• Công việc tái cấu trúc phức tạp này đã đặt ra nhiều thách thức cho các nhà phát triển, cho thấy FFmpeg đang liên tục thích nghi và phát triển theo môi trường điện toán hiện đại.
• Sẽ rất thú vị khi quan sát thay đổi này ảnh hưởng thế nào đến hiệu năng thực tế đối với cả người dùng lẫn nhà phát triển.

[GN⁺]

Ý kiến trên Hacker News

• Lý thuyết về tối ưu hóa đa luồng/xử lý

  • Trước đây, việc đọc, xử lý và kết xuất một hình ảnh mất khá nhiều thời gian, nhưng nhờ sự phát triển của công nghệ phần cứng và phần mềm, giờ đã nhanh hơn rất nhiều.
  • Trước kia, để nhiều worker xử lý một khung hình là hiệu quả, nhưng hiện nay một worker đơn lẻ có thể xử lý khung hình hiệu quả hơn so với việc huy động nhiều worker.
  • Các hệ thống hiện đại có môi trường hoàn toàn khác với thời điểm FFmpeg mới được tạo ra, nên cần suy nghĩ lại về cách định nghĩa, lập lịch, phân phối, theo dõi khối lượng công việc và sau đó ghép lại thành kết quả cuối cùng.
  • Khen ngợi đội ngũ FFmpeg vì đã chấp nhận thử thách này. FFmpeg là đỉnh cao của hạ tầng mã nguồn mở và là thành phần thiết yếu để xây dựng nền văn minh.

• Bản ghi bài nói chuyện tại sự kiện VDD@Dublin

  • Đã tìm bản ghi của bài nói chuyện nhưng không dễ thấy trên trang của tác giả hay ở đây.
  • Cập nhật: Đã tìm thấy trên YouTube!

• Suy nghĩ về việc cải thiện hiệu năng đa lõi

  • Các encoder hiện nay dùng nhiều luồng để xử lý cùng một khung hình đồng thời. Cách phổ biến là chia khung hình thành nhiều vùng và để mỗi luồng xử lý một vùng nhất định.
  • Một phương án khác được đề xuất là xử lý độc lập các đoạn keyframe. Cách này có thể song song hóa codec theo cách tổng quát và hiệu quả, đồng thời tránh việc giảm hiệu quả nén do chia khung hình thành vùng cũng như overhead giao tiếp giữa các luồng.
  • Vấn đề của phương pháp này là phải nạp vào bộ nhớ số khung hình tương ứng với chu kỳ N*keyframe, và có thêm overhead bộ nhớ cần thiết để mã hóa N khung hình.
  • Tuy vậy, trong nhiều trường hợp những nhược điểm này có lẽ không quá nghiêm trọng. Phần lớn trường hợp đều chấp nhận dùng nhiều RAM và xuất ra với khoảng cách keyframe cố định.
  • Có thể kết hợp xử lý song song trong nội bộ khung hình với xử lý song song theo các đoạn keyframe để đạt mức song song hóa cao mà vẫn giảm thiểu suy giảm chất lượng.

• Thách thức của việc rebase liên tục

  • Việc liên tục rebase các thay đổi đổ vào mỗi ngày là một thử thách đáng kể.
  • Giờ đây vì đã được tích hợp vào FFmpeg, công việc về sau sẽ dễ hơn nhiều.
  • Đây là một thắng lợi lớn và sẽ đóng góp đáng kể vào việc tăng tốc.

• Kỳ vọng cải thiện thời gian khởi động stream của bộ đệm hiển thị ảo trong FFmpeg

  • Dự án LLMStack dùng FFmpeg để stream video trình duyệt.
  • Hiện tại có độ trễ dễ nhận thấy khi khởi động pipeline mỗi lần gọi từng công cụ.
  • Những cải tiến của FFmpeg chắc chắn sẽ giúp ích cho công việc tối ưu hóa này.

• Quảng bá khóa học về FFmpeg C API

  • Quảng bá một khóa học dạy FFmpeg C API trên Udemy.

• Thắc mắc về codebase FFmpeg

  • Không quá quen với codebase của FFmpeg, nhưng tò mò không biết họ có thể tiến hành thay đổi dần dần như thế nào mà không cần một commit khổng lồ.
  • Theo bài trình bày thì có 700 commit; không rõ đó là trên một nhánh riêng hay được sáp nhập dần vào dự án.

• Góc nhìn của nhà vận hành dịch vụ đám mây

  • Nếu đang vận hành một dịch vụ đám mây như Netflix, bạn có lẽ đã chạy hàng nghìn tiến trình FFmpeg trên mỗi máy, nên về bản chất đây đã là công việc đa lõi rồi.

• Chia sẻ trải nghiệm xử lý filter theo luồng của VapourSynth

  • Đã tận hưởng việc xử lý filter theo luồng trong VapourSynth gần 10 năm nay.
  • Cải tiến lần này của FFmpeg cũng rất tuyệt, nhưng sẽ không tạo ra thay đổi lớn nào với quy trình tiền xử lý bằng VapourSynth + mã hóa bằng av1an dành cho encode video 'chất lượng'.

• Câu hỏi về hỗ trợ đa lõi của FFmpeg

  • Tò mò liệu FFmpeg giờ đã có thể sử dụng đa lõi với tất cả các codec đi kèm hay chưa.
  • Đang dùng FFmpeg để mã hóa MP3 bằng LAME cho một dịch vụ lưu trữ âm thanh, nên sẽ rất tốt nếu có thể cải thiện thời gian mã hóa các tệp dài.