Bài học ngôn ngữ hợp ngữ FFmpeg

• Bài học ngôn ngữ hợp ngữ FFmpeg là tài liệu học tập mã nguồn mở được thiết kế để giúp hiểu sâu cách máy tính vận hành bên trong
• Kho lưu trữ này cung cấp các ví dụ thực tế về ngôn ngữ hợp ngữ được sử dụng trong FFmpeg cùng các bài tập thực hành trọng tâm
• Con trỏ trong ngôn ngữ C và kiến thức toán học ở mức trung học phổ thông là điều kiện tiên quyết để học
• Qua đó, người học có thể rèn luyện năng lực đóng góp trực tiếp cho dự án mã nguồn mở FFmpeg
• Hỗ trợ đặt câu hỏi và thảo luận được cung cấp qua kênh Discord

---

Giới thiệu về bài học ngôn ngữ hợp ngữ FFmpeg

• FFmpeg School of Assembly Language là bài học mã nguồn mở được tạo ra để bạn bắt đầu một hành trình thú vị, đầy thử thách và xứng đáng nhất trong lập trình
• Thông qua bài học này, bạn có thể học bằng mã nguồn thực tế cách ngôn ngữ hợp ngữ được viết trong FFmpeg, đồng thời hiểu một cách có hệ thống những gì đang diễn ra bên trong máy tính

Kiến thức yêu cầu

• Cần hiểu ngôn ngữ C, đặc biệt là khái niệm con trỏ
  • Nếu chưa biết C, trước tiên bạn cần học cuốn sách "The C Programming Language"
• Cần có kiến thức toán học ở mức trung học phổ thông (đại lượng vô hướng và vectơ, phép cộng, phép nhân, v.v.)

Cấu trúc bài học và cách sử dụng

• Kho lưu trữ GitHub này bao gồm các bài học theo từng bước và các bài tập tương ứng với từng bài học (các bài tập vẫn chưa được tải lên)
• Sau khi hoàn thành toàn bộ khóa học, bạn sẽ có năng lực thực chiến để trực tiếp đóng góp cho dự án FFmpeg

Hỗ trợ cộng đồng

• Bạn có thể tham gia hỏi đáp và thảo luận qua máy chủ Discord (https://discord.com/invite/Ks5MhUhqfB)

Bản dịch đa ngôn ngữ

• Bài học cũng được cung cấp bằng tiếng Pháp và tiếng Tây Ban Nha, giúp các nhà phát triển ở nhiều ngôn ngữ khác nhau dễ tiếp cận hơn

[GN⁺]

Ý kiến trên Hacker News

• Chỉ cần tưởng tượng quy mô của FFMPEG thôi cũng đã thấy đáng kinh ngạc; ngay cả một cải thiện hiệu năng rất nhỏ cũng có thể tiết kiệm hàng nghìn, hàng chục nghìn giờ tính toán, đúng là một dự án thực sự hữu ích
  • Tôi thấy sự ám ảnh của đội FFMPEG với hiệu năng thật đáng nể; giá mà mọi dự án đều có thái độ như vậy thì tốt biết bao
  • Tuy vậy, tôi vẫn ước có một API đúng nghĩa theo nghĩa truyền thống hơn (không phải kiểu mệnh lệnh mà là thư viện thực sự), vì việc hiểu được dòng lệnh mang tính như một ngôn ngữ riêng như hiện nay không hề dễ
• Đã có thảo luận trước đó vào 2025-02-22, với 222 bình luận xem tại đây
• Tôi tò mò không biết trên thực tế người ta tìm ra các hotspot do assembly không tối ưu mà compiler tạo ra như thế nào, và cũng muốn biết việc tự viết trực tiếp một biểu diễn trung gian như LLVM IR thay vì assembly theo từng kiến trúc có ý nghĩa hay không
  • Nhiều vấn đề mọi người nghĩ tới lại không giống các vấn đề thực tế; trên thực tế không hẳn là “assembly không tối ưu” mà là mức có thể kỳ vọng từ compiler C, các yếu tố chính gồm: có bản cài đặt C vòng lặp thông thường và các bản asm/SIMD bổ sung theo từng phần cứng, nhưng đặc tính SIMD khác nhau giữa các nền tảng nên khó khái quát hóa; khác biệt phiên bản compiler có thể khiến không phải mọi người dùng đều tận dụng được bản cài đặt tốt nhất; mô hình bộ nhớ của C và việc dùng char * cản trở tối ưu hóa; intrinsic và auto-vectorization đôi khi còn xung đột với nhau; trong Intel C, intrinsic đôi lúc còn khiến assembly dễ đọc hơn vì Microsoft tạo ra các tên hàm quá phức tạp
  • Thông thường người ta phân tích các hotspot benchmark ở mức ISA bằng các công cụ như vtune hoặc uprof; tôi không rõ công cụ cho ARM; việc con người tự viết một biểu diễn trung gian như LLVM IR trên thực tế không có nhiều ý nghĩa; trong đa số trường hợp, người ta chỉ trực tiếp viết assembly cho các vấn đề đặc thù của kiến trúc; compiler C/C++ nói chung tạo mã tối ưu khá tốt, nhưng với mã đã vectorize thì phải thay đổi cả thuật toán, việc dùng intrinsic trở nên khó tránh khỏi, và khi đó mã vừa kém tính di động vừa trông giống assembly; thêm vào đó còn có overhead từ mã compiler sinh ra, nên thường viết thẳng assembly và để con người tự lo các việc như phân bổ thanh ghi hay thứ tự lệnh sẽ tốt hơn; rốt cuộc assembly viết tay có tốt hơn mã compiler tạo ra hay không thì chỉ có đo đạc mới biết, benchmark là bắt buộc
  • Tự viết LLVM IR không có nhiều ý nghĩa; nếu mục tiêu là mã vector thì trước hết nên thử các chỉ thị vector hóa (pragmas), nếu không được thì dùng intrinsic hoặc các ngôn ngữ như ISPC sẽ hiệu quả hơn; không có lợi ích gì khi viết IR; ngay cả khi muốn tự xử lý vấn đề phân bổ thanh ghi hay chọn lệnh của compiler thì viết bằng IR rồi cuối cùng compiler vẫn biến nó lại thành mã theo cách riêng của nó; kết quả là IR chỉ thêm một tầng không ổn định và khó dùng hơn mà thôi; nếu muốn tạo assembly viết tay tốt nhất thì cứ viết thẳng assembly là đúng hơn
• Hơi tiếc là tài liệu không bắt đầu từ một phần giới thiệu đơn giản có thể thực hành ví dụ bằng một assembler thực tế như NASM
• Tôi đã kỳ vọng có những hiểu biết hay bí quyết đúc kết từ vô số kinh nghiệm của dự án, nhưng chưa thực sự cảm nhận được sự gắn kết trực tiếp với ffmpeg; ít nhất khi chỉ xem vài chương thì nó giống nội dung nhập môn assembly nói chung hơn
• Tôi nghĩ sẽ hay nếu tài liệu bài giảng toán học cần thiết cho FFmpeg Assembly Lessons cũng được đưa vào kho GitHub, vì nếu mọi tài liệu ở cùng một chỗ thì sẽ dễ bắt đầu hơn
  • Tôi không phải tác giả, nhưng nếu độc giả chỉ có kiến thức nền tảng về lập trình C và muốn thực sự đóng góp cho video codec, thì có rất nhiều kiến thức nền cần phải đi qua trước khi tới được những nội dung như thuật toán Cooley-Tukey, mà đó mới chỉ là phần cơ bản
• Tôi tò mò không biết các đoạn mã assembly này làm thế nào để đảm bảo tính di động trên nhiều CPU khác nhau
  • Theo tôi, phần xử lý chạy bằng C thông thường cũng đóng vai trò baseline, còn với các kiến trúc chính thì sẽ có các phiên bản assembly viết tay riêng
  • Thực tế thì chỉ nhắm tới x86-64
• Tôi thấy đọc rất thú vị, và cảm giác các tutorial đặc thù theo miền như vậy tốt hơn nhiều
• Có vẻ đã lạm dụng khá nhiều macro preprocessor của nasm, nên chắc sẽ rất khó chuyển sang assembler khác
  • Tôi lại thấy thắc mắc là tại sao phải chuyển sang assembler khác làm gì
  • Tôi tò mò không biết cụ thể là ở đoạn nào, vì trong mã dùng cho bài học thực ra gần như không có nhiều mã lắm