FFmpeg giới thiệu pipeline chuyển mã đa luồng

 (ffmpeg.org)
2 điểm bởi GN⁺ 2023-11-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Chuyển mã đa luồng của FFmpeg CLI đã được công bố dưới dạng phiên bản “hoạt động đầy đủ” đầu tiên sau khoảng 2 năm phát triển và hơn 700 commit chuẩn bị
  • Do phạm vi thay đổi lớn, vẫn còn khả năng một số chức năng bị hỏng; trước khi merge thực tế, kiểm thử và review vẫn là nhiệm vụ then chốt
  • -fix_sub_duration_heartbeat khó tránh hành vi không xác định khi chạy bất đồng bộ, do giả định đồng bộ hóa giữa decoder và encoder·muxer
  • Overhead của threading nhìn chung nhỏ, nhưng trong các tác vụ có khối lượng xử lý trên mỗi packet rất ít, chi phí này có thể nổi bật hơn lợi ích hiệu năng
  • Nếu nút thắt cổ chai không tập trung vào một component đơn lẻ và mỗi component chưa ở trạng thái đã được đa luồng hóa sẵn, mức sử dụng CPU và thời gian xử lý thực tế trong môi trường đa lõi có thể được cải thiện đáng kể

Điểm chính của bản vá đa luồng cho FFmpeg CLI

  • Sau khoảng 2 năm làm việc và hơn 700 commit chuẩn bị, phiên bản “fully functional” đầu tiên của FFmpeg CLI đa luồng đã được công bố dưới dạng một patch set
  • Vì quy mô thay đổi lớn, vẫn có khả năng xảy ra lỗi chưa được phát hiện, nên cần kiểm thử và review dựa trên các trường hợp sử dụng thực tế
  • Trong trường hợp thông thường, overhead của threading là nhỏ, nhưng với workload có khối lượng xử lý trên mỗi packet rất thấp, overhead có thể trở nên đáng kể
  • Nếu quá trình chuyển mã không bị chi phối bởi một component đơn lẻ và các component chưa bị bão hòa bởi cơ chế đa luồng riêng của chúng, mức sử dụng CPU và thời gian chạy trên hệ thống đa lõi có thể được cải thiện

Ràng buộc vận hành và các vấn đề đã biết

  • Tùy chọn -fix_sub_duration_heartbeat trong kiến trúc hiện tại dựa trên giả định đồng bộ hóa giữa các component tách rời nhau
    • Luồng mục tiêu là đồng bộ hóa từ encoder·muxer đến decoder
    • Khi mỗi component chạy bất đồng bộ, hành vi về cơ bản trở nên không xác định
    • Ngay cả hiện tại, hành vi cũng khó dự đoán, nhưng nếu chạy với cùng tùy chọn thì kết quả giữa các lần chạy là xác định
    • Trong bản vá 16/24, tùy chọn này bị vô hiệu hóa và cần một cách xử lý tốt hơn

Cấu trúc của patch set gồm 24 bản vá

  • Patch set gồm tổng cộng 24 bản vá
    • 01-09/24 là các chỉnh sửa chuẩn bị và có thể được push trước phần còn lại của series
    • 10-17/24 chuyển encoding và filtering sang thread, đồng thời thực hiện các thay đổi chuẩn bị cần thiết
      • Threading ở giai đoạn này là threading “giả”, trong đó main thread chờ các thread khác hoàn tất, nên chưa phải là chạy song song thực sự
      • Vì overhead tạm thời có thể lớn hoặc một số corner case có thể bị hỏng, tốt hơn là chỉ push sau khi toàn bộ set đã sẵn sàng
    • 18/24 là bản vá đơn lẻ lớn nhất, bổ sung transcode scheduler, nhưng ở thời điểm đó nó vẫn chưa thực sự hoạt động
    • 19-24/24 chuyển từng component sang cách sử dụng scheduler
      • Chúng được tách ra để review, nhưng khi push cuối cùng thì nên gộp lại
  • Có thể xem tài liệu liên quan trong video bài trình bày VDD gần đây và nhánh ffmpeg_threading

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-11-07
Ý kiến Hacker News

  • Trên máy chủ ARM 4 lõi, nhanh hơn khoảng 2 lần, và có vẻ hầu như không có overhead do song song hóa
    ffmpeg_threading/ffmpeg là 7.771 giây, còn ffmpeg hiện tại là 13.841 giây; mức sử dụng CPU lần lượt là 218% và 114%

    • Ở đây không dùng tăng tốc phần cứng cho phía giải mã, và cũng đã bỏ đầu ra video
      Tôi tò mò nếu dùng tăng tốc phần cứng cho cả giải mã và mã hóa video trên card NVIDIA thì sẽ thế nào: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • Tôi muốn biết phần nào đang được đa luồng. Nén video vốn đã đa luồng rồi, còn giải nén video thì tôi không rõ
      Các phần việc khác có lẽ tương đối nhỏ xét về chi phí hiệu năng, nên dù cải thiện là đáng hoan nghênh, tôi đoán tác động thực tế sẽ khá hạn chế

  • Có lẽ nên liên kết tới https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... thay vì tweet
    Nội dung cốt lõi của tweet rốt cuộc cũng là liên kết này

    • Giờ thì cứ gọi là post thôi. Cũng không còn giới hạn 280 ký tự nữa, bài dài chỉ là mặc định bị thu gọn lại

  • Để hiểu nội dung này, tốt nhất nên xem bài trình bày của Anton tại VideoLAN Dev Days 2023: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • Bài trình bày rất hay, và tôi tò mò dynamic pipelines cùng “scripting (Lua?)” được nhắc ở phần “Future directions” đang nhắm tới điều gì
      Nó khiến tôi hình dung đến hướng xử lý animation thuộc tính mạnh mẽ hơn
    • Tôi đã thật sự gặp rất nhiều vấn đề liên quan đến Extras xuất hiện trên slide ở khoảng phút 33
    • Tôi rất muốn xem video này, nhưng chất lượng âm thanh quá tệ nên khó mà tập trung. Không hiểu sao đến giờ vẫn có thể làm hỏng nặng như vậy
    • Tôi không rõ phần nào là khó hiểu. Trong lĩnh vực transcoding video, đa luồng có được dùng với nghĩa khác không?

  • Tweet dẫn tới http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655..., và từ đó lại tham chiếu tới mã nguồn https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading

    • Tweet dẫn tới mailing list, là nguồn chính thức của bộ patch. Để đọc tiếp thì chọn “Next in Thread”

  • Tôi muốn biết liệu cái này có tự động được áp dụng hay không, hay là phải kết hợp rắc rối các tham số dòng lệnh

  • Tôi tò mò có phần mềm biên tập video nào dùng ffmpeg không
    Có lúc tôi từng nghĩ đến việc làm thứ gì đó để vẽ hình bằng SVG rồi dùng ffmpeg, hoặc gắn UI vào, hoặc chỉ thêm văn bản, nhưng chưa bắt đầu
    Avidemux hơi mang cảm giác như vậy, còn nội bộ ffmpeg thì khá thô, không có vẻ được dùng để GUI truy cập trực tiếp, nên một trình biên tập xây trên đó có lẽ sẽ chậm chạp, kỳ quặc và khó bảo trì
    Tuy vậy, có vẻ vẫn có thể làm một trình biên tập dạng mô-đun, tạo preview bằng trình giải thích lệnh hoặc trình xem pipeline
    ffmpeg rất mạnh, nhưng việc chỉ dùng qua dòng lệnh khiến nó trở thành rào cản với một số người dùng. Trước đây tôi từng viết một script Python nhận số lượng clip ngẫu nhiên rồi tạo mosaic bằng bộ lọc xstack, và việc đó không hề dễ

    • VapourSynth có thể là điểm trung gian phù hợp cho thứ bạn đang tìm. Thay vì ffmpeg CLI, bạn thao tác video bằng Python, và nhờ khả năng mở rộng, đôi khi nó còn mở rộng tốt hơn và mạnh hơn ffmpeg thuần
      https://vsdb.top/
      https://www.vapoursynth.com/
      Trong nhóm phần mềm ngách dựa trên ffmpeg, tôi đã thấy losslesscut: https://github.com/mifi/lossless-cut
      Staxrip cũng khá lớn: https://github.com/staxrip/staxrip
      Nhưng một trình biên tập “toàn diện” thì tôi không rõ
    • https://shotcut.org/ cũng dùng ffmpeg
    • Có KDENlive. Đây là phần mềm biên tập video tự do mã nguồn mở rất tuyệt

  • Tôi sẽ rất vui nếu các tác vụ transcoding nhỏ cho Plex nhanh hơn
    Tôi không có hỗ trợ transcoding phần cứng từ card đồ họa, nên khá kỳ vọng

  • Tôi đang tìm cách tăng tốc độ transcoding, và một hướng là tăng tốc GPU, hướng còn lại là tăng số luồng
    Chỉ là rất khó tìm được số luồng tối ưu

    • Sao không dùng tối ưu siêu tham số để tìm giá trị tối ưu? Các công cụ như Sherpa hay Scikit-optimize có thể quét không gian tìm kiếm như số luồng, kiểu đầu vào, loại CPU
    • Với hầu hết tác vụ, cứ đặt số luồng bằng số vCPU là được. Tức là lõi có hyperthreading thì tính là 2
      Tuy nhiên, nếu có thể thì tăng tốc GPU vẫn tốt hơn nhiều

  • Tôi tò mò về yêu cầu giấy phép khi triển khai ffmpeg ở quy mô lớn. Trong trường hợp nào thì phải trả phí?

    • “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
      Tức là miễn phí, nhưng nếu dùng một số mô-đun thì có thể phát sinh vấn đề khi trộn với mã nguồn độc quyền
    • Cách phổ biến để dùng ffmpeg trong phần mềm độc quyền là biên dịch tĩnh phiên bản ffmpeg đang dùng rồi liên kết vào tệp thực thi, hoặc để phần mềm độc quyền gọi nó như một tệp thực thi riêng biệt

  • Thật vui khi thấy FFmpeg tiếp tục được cải thiện. Hy vọng sớm có cả hỗ trợ Dolby AC4