Mã hóa và giải mã video bằng Vulkan Computer Shaders trong FFmpeg

Mã hóa và giải mã video trên internet phần lớn là một vấn đề đã được giải quyết đối với người dùng hàng ngày. Hầu hết các thiết bị tiêu dùng hiện nay đều được trang bị chip tăng tốc phần cứng chuyên dụng mà các API như tiện ích mở rộng Vulkan® Video cung cấp quyền truy cập trực tiếp. Trong khi đó, các codec mới hơn ngày càng được miễn phí bản quyền với các thông số kỹ thuật mở — hoặc đơn giản là không còn bị hạn chế cấp phép — khiến mọi người đều có thể tiếp cận các tiêu chuẩn này.

Thật dễ dàng để quên việc giải mã 720p H.264 đòi hỏi khắt khe như thế nào trên CPU chỉ 18 năm trước. Thử thách đó đã thúc đẩy sự cạnh tranh và tối ưu hóa gay gắt giữa việc triển khai phần mềm, đẩy hiệu suất đến giới hạn cho đến khi việc giải mã phần cứng cuối cùng trở nên phổ biến.

Tuy nhiên, trong quy trình làm việc chuyên nghiệp, các bức tường hiệu suất vẫn tồn tại. Các biên tập viên miệt mài nghiên cứu các cảnh quay thô trong nhiều ngày, các nhà chỉnh màu làm việc với các bậc thầy 8K 16-bit, các nghệ sĩ VFX kết xuất video ACEScg dấu phẩy động 32-bit và các nhà lưu trữ xử lý các bản quét phim không bị mất độ phân giải cực cao vẫn bị giới hạn về hiệu suất. Trong khi người dùng thông thường từng phải chịu đựng tình trạng thỉnh thoảng bị rớt khung hình, thì các chuyên gia ngày nay thường bị đẩy tới các giải pháp độc quyền đắt tiền hoặc máy trạm trăm lõi, làm mát bằng chất lỏng với hàng trăm gigabyte RAM.

Bài đăng này khám phá cách FFmpeg sử dụng Vulkan Computing để tăng tốc mã hóa và giải mã liền mạch thậm chí cả video cấp chuyên nghiệp trên GPU tiêu dùng - mở khóa khả năng song song tính toán GPU trên quy mô lớn mà không cần phần cứng chuyên dụng. Cách tiếp cận này bổ sung cho khả năng hỗ trợ codec chức năng cố định của Vulkan Video, mở rộng khả năng tăng tốc cho các định dạng và quy trình làm việc mà nó không hỗ trợ.

Bộ giải mã

Codec là các thuật toán khai thác sự dư thừa và các mẫu trong tín hiệu để nén nó nhằm mục đích lưu trữ hoặc truyền tải. Việc song song xử lý codec trên GPU dễ dàng đến mức nào?

Lấy JPEG, C. elegans của codec nén, làm ví dụ minh họa. Mã hóa hình ảnh yêu cầu biến đổi tần số 2D (song song một phần, xử lý hàng rồi cột), dự đoán giá trị DC (nối tiếp hoàn toàn), lượng tử hóa để loại bỏ thông tin không liên quan về mặt nhận thức (song song hoàn toàn) và cuối cùng là mã hóa Huffman (cực kỳ nối tiếp). Sự kết hợp giữa các bước song song và nối tiếp hóa ra lại là thách thức chính đối với việc tăng tốc codec GPU. Việc giải mã sẽ đảo ngược các bước này — nhưng các tắc nghẽn nối tiếp vẫn còn là vấn đề.

Đây chính là điểm căng thẳng cơ bản: các đường dẫn codec chứa đầy các phụ thuộc nối tiếp, trong khi GPU được xây dựng nhằm mục đích thực hiện đồng thời hàng nghìn hoạt động độc lập, không tương quan.

Thỏa hiệp

Cách tiếp cận hiển nhiên trước đây là giải mã kết hợp: xử lý các bước nối tiếp (như giải mã hệ số) trên CPU, tải kết quả trung gian lên GPU, sau đó để GPU chạy các bước song song ở những nơi nó vượt trội.

Trong thực tế, điều này dẫn đến một vấn đề cơ bản: GPU nằm cách xa bộ nhớ hệ thống về mặt vật lý. Ngay cả với truyền DMA và băng thông cao, độ trễ khứ hồi thường khiến quá trình giải mã kết hợp chậm hơn so với việc chỉ thực hiện các bước song song trên CPU — đặc biệt là khi xét đến khả năng của các CPU hỗ trợ SIMD hiện đại đã trở nên như thế nào.

Kết quả thực tế với việc triển khai codec lai đã xác nhận điều này. Bộ giải mã dav1d đã cố gắng giảm tải bộ lọc cuối cùng của nó — phức tạp nhưng có khả năng song song hóa cao — tới GPU, nhưng không thấy hiệu quả gì đối với CPU, ngay cả trên thiết bị di động. x264 đã thêm hỗ trợ OpenCL™ cơ bản, nhưng độ trễ tải lên khung đã giết chết mọi lợi thế về hiệu suất và cuối cùng mã bị bitrot.

Những thất bại này đã khiến việc triển khai kết hợp bị mang tiếng xấu trong cộng đồng đa phương tiện. Bài học rất rõ ràng: để triển khai codec dựa trên máy tính nhanh chóng, có thể bảo trì và được áp dụng rộng rãi một cách nhất quán cần phải hoàn toàn dựa trên GPU — không cần chuyển giao CPU.

Nơi nào có di chúc...

Hầu hết các codec đều được thiết kế dành cho phần cứng ASIC — công cụ video chuyên dụng có trên các GPU hiện đại và được hiển thị thông qua Vulkan Video. Nhưng ngay cả ASIC cũng không nhanh vô hạn: codec thường thỏa hiệp và xác định đơn vị công việc song song tối thiểu, được gọi là lát hoặc khối, đại diện cho đoạn nhỏ nhất có thể được xử lý độc lập.

Hầu hết các codec phổ biến đều được thiết kế từ nhiều thập kỷ trước, khi độ phân giải video còn nhỏ hơn nhiều. Khi độ phân giải bùng nổ, các đơn vị tối thiểu có kích thước cố định đó giờ đây chiếm một phần nhỏ hơn nhiều của khung hình - điều đó có nghĩa là nhiều đơn vị tối thiểu có thể được xử lý song song. Các GPU hiện đại cũng đã có được các tính năng cho phép giao tiếp nhiều lệnh, mở ra nhiều cơ hội tối ưu hóa hơn nữa.

Cùng với nhau, những xu hướng này khiến cho việc triển khai hoàn toàn một số codec nhất định trong trình đổ bóng điện toán ngày nay trở nên thực sự khả thi — không cần sự tham gia của CPU.

Bộ mã hóa dựa trên điện toán cũng có lợi thế hơn ASIC mà dễ bị bỏ qua: chúng không bị hạn chế về thời gian sử dụng bộ nhớ và thời gian tìm kiếm. Với đủ luồng để quét toàn diện từng khối, việc đạt được chất lượng phù hợp hoặc thậm chí vượt qua bộ mã hóa phần mềm là hoàn toàn có thể đạt được.

Khả năng tiếp cận

FFmpeg là bộ sưu tập các thư viện và công cụ mã nguồn mở và miễn phí để cho phép làm việc với các luồng đa phương tiện, bất kể định dạng hoặc codec. Mặc dù nổi tiếng với việc triển khai codec với tối ưu hóa lắp ráp viết tay trên nhiều nền tảng, FFmpeg cũng cung cấp khả năng truy cập dễ dàng vào các bộ tăng tốc phần cứng.

Điều quan trọng là khả năng tăng tốc phần cứng trong FFmpeg được xây dựng dựa trên codec phần mềm. Việc phân tích cú pháp các tiêu đề, phân luồng, lập lịch khung, lát cắt và sửa/xử lý lỗi đều diễn ra trong phần mềm. Giải mã tất cả dữ liệu video là phần duy nhất được giảm tải. Điều này kết hợp mã mạnh mẽ đã được kiểm tra kỹ lưỡng với khả năng tăng tốc phần cứng. Chúng tôi có thể dịch trực tiếp luồng của các khung độc lập mà việc triển khai phần mềm thực hiện bằng cách gửi nhiều khung để giải mã song song nhằm bão hòa hoàn toàn GPU.

Nó cũng cho phép người dùng chuyển đổi linh hoạt giữa việc triển khai phần mềm và phần cứng thông qua chuyển đổi mà không cần phân biệt việc giải mã phần cứng được triển khai bằng cách sử dụng trình đổ bóng Vulkan Video hay Vulkan Computer.

Việc sử dụng rộng rãi FFmpeg trong phần mềm chỉnh sửa, trình phát đa phương tiện và trình duyệt, kết hợp với khả năng thêm hỗ trợ tăng tốc phần cứng cho bất kỳ triển khai phần mềm nào, khiến nó trở thành điểm khởi đầu lý tưởng để giúp triển khai codec dựa trên máy tính có thể truy cập rộng rãi, thay vì triển khai thư viện chuyên dụng.

FFv1

Phiên bản FFmpeg Video Codec số 1 đã trở thành một phần không thể thiếu trong cộng đồng lưu trữ và trong các ứng dụng yêu cầu nén không mất dữ liệu. Nó mở, miễn phí bản quyền và là tiêu chuẩn chính thức của IETF.

Công việc triển khai codec trong bộ đổ bóng điện toán trong FFmpeg đã bắt đầu từ đây. Bộ mã hóa và giải mã FFv1 chạy rất chậm trên CPU, mặc dù hỗ trợ tới 1024 lát. Điều này một phần là do băng thông lớn cần thiết cho video RGB có độ phân giải cao và thiết kế mã hóa entropy có phần bị tắc nghẽn.

FFv1 phiên bản 3 đã được thiết kế hơn 10 năm trước và nhờ cộng đồng lưu trữ đã áp dụng nó nên nó đã được sử dụng rộng rãi. Tuy nhiên, những trở ngại khiến việc mã hóa và giải mã các bản quét phim lưu trữ có độ phân giải cao trở nên cực kỳ tốn thời gian.

Như vậy, nhờ cộng đồng lưu trữ mà bộ mã hóa và giải mã FFv1 đã được viết ra. Chúng bắt đầu dưới dạng chuyển đổi bộ mã hóa và giải mã phần mềm, nhưng dần dần được tối ưu hóa nhiều hơn với các chức năng dành riêng cho GPU.

Thách thức lớn nhất khi mã hóa FFv1 là làm việc với hệ thống bộ mã hóa phạm vi, hệ thống này thiếu các tính năng tối ưu hóa mà bộ mã hóa phạm vi của AV1 có. Mỗi ký hiệu (giá trị chênh lệch pixel) có mỗi bit có giá trị thích ứng 8 bit riêng, do đó cần tra cứu ngẫu nhiên 32 giá trị liền kề từ một tập hợp hàng nghìn (trên mỗi mặt phẳng!) khi mã hóa hoặc giải mã. Chúng tôi tăng tốc quá trình này bằng cách có quy mô nhóm làm việc là 32, với mỗi lệnh gọi cục bộ tra cứu và thực hiện việc điều chỉnh song song, trong khi một lệnh gọi duy nhất thực hiện mã hóa hoặc giải mã thực tế. Đối với RGB, Chuyển đổi màu có thể đảo ngược (RCT) được thực hiện để giải mã các giá trị pixel hơn nữa. Ban đầu, một shader riêng biệt được sử dụng cho việc này, nó được mã hóa thành một hình ảnh riêng biệt. Tuy nhiên, yêu cầu về băng thông để thực hiện điều này đối với hình ảnh có độ phân giải rất cao lại vượt xa những lợi thế. Vì chỉ cần 2 dòng để giải mã hoặc mã hóa hình ảnh nên chúng tôi phân bổ các hình ảnh width*horizontal_slices*2 và thực hiện RCT trước khi mã hóa từng dòng với sự trợ giúp của 32 lệnh gọi trợ giúp.

APV

APV là một codec mới được Samsung thiết kế nhằm phục vụ như một giải pháp thay thế mở, miễn phí bản quyền cho việc nén video tầng lửng. Gần đây, nó cũng đã trở thành một tiêu chuẩn IETF. Nó đang thu hút được sự chú ý của cộng đồng VFX và sản xuất phương tiện truyền thông chuyên nghiệp, cũng như định dạng ghi camera trên điện thoại thông minh.

Không giống như hầu hết các codec được đề cập trong bài viết này, APV được thiết kế để chạy song song ngay từ đầu. Tương tự như JPEG, mỗi khung hình được chia thành các thành phần và mỗi thành phần được chia thành các ô, trong đó mỗi ô có nhiều khối. Mỗi khối được biến đổi đơn giản, lượng tử hóa thông qua bộ lượng tử hóa vô hướng (phép chia đơn giản) và được mã hóa thông qua các mã có độ dài thay đổi. Thậm chí không có bất kỳ dự đoán DC nào.

Để triển khai nó như một trình đổ bóng điện toán, trước tiên, chúng tôi xử lý việc giải mã trên mỗi ô trong một trình đổ bóng và chạy trình đổ bóng thứ hai để biến đổi một hàng của một khối cho mỗi lệnh gọi.

ProRes

ProRes là codec lửng tiêu chuẩn trên thực tế, được sử dụng để chỉnh sửa, cảnh quay camera và mastering. Đó là một codec tương đối đơn giản, tương tự như JPEG và APV, cho phép triển khai bộ giải mã và do nhu cầu phổ biến, bộ mã hóa.

Để giải mã, về cơ bản chúng tôi thực hiện quy trình tương tự như với APV. Tuy nhiên, để mã hóa, chúng tôi thực hiện kiểm soát và ước tính tốc độ thích hợp bằng cách chạy trình đổ bóng để tìm ra bộ lượng tử hóa nào làm cho khối phù hợp với ngân sách bit của khung.

Thật không may, không giống như các codec khác trong danh sách, codec ProRes không miễn phí bản quyền cũng như không có thông số kỹ thuật mở. Việc triển khai trong FFmpeg là không chính thức. Nhưng do tính phổ biến tuyệt đối của chúng, việc triển khai như vậy là cần thiết để có khả năng tương tác với phần lớn thế giới chuyên nghiệp. Tuy nhiên, dogfood của nhà phát triển về quá trình triển khai và kết quả đầu ra của họ được giám sát để phù hợp với quá trình triển khai chính thức.

ProRes RAW

ProRes RAW có dòng bit có ít điểm chung với ProRes, vì nó được tạo ra để nén dữ liệu cảm biến bị mất RAW (không được gỡ lỗi). Nó sử dụng DCT được thực hiện trên từng thành phần và bộ mã hóa hệ số dự đoán DC trên các thành phần và mã hóa hiệu quả các giá trị AC từ nhiều thành phần theo thứ tự ngoằn ngoèo thông thường. Hệ thống mã hóa entropy không hẳn là một mã có độ dài thay đổi truyền thống mà gần giống với mã hóa hàm mũ hơn. Các lát cắt có nhiều khối, trong đó mỗi thành phần có thể được giải mã song song. Không giống như FFv1, không có giới hạn về số lượng ô trên mỗi hình ảnh, có khả năng yêu cầu giải mã hàng trăm nghìn khối độc lập. Điều này rất tốt cho sự song song, dẫn đến việc triển khai hiệu quả.

Bộ giải mã được triển khai theo cách tiếp cận 2 bước, với trình đổ bóng đầu tiên giải mã từng ô và trình đổ bóng thứ hai chuyển đổi tất cả các khối trong mỗi ô theo tính song song hàng/cột (được gọi là cấu hình cắt nhỏ do có thể bão hòa hoàn toàn giới hạn kích thước nhóm làm việc của GPU).

DPX

DPX không phải là codec mà là một thùng chứa đóng gói pixel có tiêu đề. Đây là tiêu chuẩn SMPTE chính thức và khá phổ biến với các máy quét phim. Thay vì được bố trí một cách tối ưu và đóng gói chặt chẽ các pixel, nó có thể đóng gói các pixel thành các khối 32 bit, đệm nếu cần. Hoặc nó có thể... không đóng gói pixel, tùy thuộc vào chuyển đổi tiêu đề.

Đây là một định dạng không nén với các quy định lỏng lẻo, được thực hiện từ nhiều thập kỷ trước, có nghĩa là nó có rất nhiều nhà cung cấp khá sáng tạo trong việc diễn giải các thông số kỹ thuật, theo những cách phá vỡ hoàn toàn việc giải mã. Rất may, có một trường văn bản "nhà sản xuất" còn sót lại trong tiêu đề để các triển khai như vậy ký tên vào tính nghệ thuật của họ, trường này có thể được sử dụng để tìm ra cách giải nén chính xác mà không nhìn thấy cầu vồng ngoài hành tinh.

Tất cả những điều này bắt nguồn từ việc viết các phương pháp phỏng đoán trong shader. Chi phí chung sẽ không bao giờ là các phép tính cần thiết để tìm một tập hợp pixel mà thực sự là lấy dữ liệu từ bộ nhớ và ghi nó vào nơi khác.

VC-2

VC-2 là một codec lửng khác. Được biên soạn bởi BBC, dựa trên codec Dirac của nó, nó miễn phí bản quyền, với các thông số kỹ thuật chính thức của SMPTE. Trường hợp sử dụng chính của nó là phát trực tuyến theo thời gian thực, đặc biệt phù hợp với video có độ phân giải cao qua kết nối gigabit với độ trễ khung hình phụ. Không giống như APV hay ProRes, nó dựa trên các phép biến đổi wavelet. Mỗi khung được chia thành các lát có kích thước bằng hai.

Wavelet khá thú vị khi biến đổi. Họ chia khung hình thành hình ảnh có độ phân giải một phần tư và 3 hình ảnh có độ phân giải một phần tư nữa làm phần dư. Không giống như DCT, chúng có tính định vị cao, có nghĩa là chúng có thể được thực hiện riêng lẻ trên từng lát, tuy nhiên khi được lắp ráp, chúng hoạt động như thể toàn bộ khung đã được chuyển đổi. Điều này giúp loại bỏ hiện tượng chặn mà tất cả các codec dựa trên DCT gặp phải.

Điều này cũng có nghĩa là chúng kém hiệu quả hơn trong việc mã hóa vì khả năng phân tách tần số của chúng bị ảnh hưởng. Ngoài ra, đặc điểm biến dạng của chúng về cơ bản kém hấp dẫn về mặt thị giác hơn so với khả năng làm mờ của DCT. Đây là một trong những lý do chính khiến họ không thu hút được sự chú ý trong các codec sau những năm 2000.

Các hệ số kết quả được mã hóa thông qua các mã Golomb-exp xen kẽ đơn giản, mặc dù không thể song song hóa nhưng có thể được đơn giản hóa một cách đẹp mắt trong bộ giải mã để loại bỏ tất cả phân tích cú pháp bit và thay vào đó hoạt động trên toàn bộ byte.

JPEG

Codec được đưa ra làm ví dụ ở đầu hóa ra lại có một cuộc tấn công rất thú vị, không chỉ mở ra cơ hội song song hóa mà còn song song hóa các tiêu chuẩn nén dữ liệu tùy ý như DEFLATE.

Ý tưởng là mặc dù các luồng VLC không có cách nào để song song hóa, nhưng bộ giải mã VLC và trên thực tế là tất cả các mã thỏa mãn bất đẳng thức Kraft–McMillan, có thể đồng bộ hóa lại một cách giả mạo. Sau một khoảng thời gian trễ ngắn đáng ngạc nhiên, bộ giải mã VLC có xu hướng xuất ra dữ liệu hợp lệ.

Tất cả những gì cần làm là chạy 4 trình đổ bóng để dần dần đồng bộ hóa các điểm bắt đầu trong mỗi luồng JPEG. JPEG cũng có nhiều biến thể, chẳng hạn như cấu hình lũy tiến và không mất dữ liệu, cũng có thể được song song hóa ở mức độ như vậy.

Dự đoán DC có thể được thực hiện thông qua tổng tiền tố song song, đây là một trong những thao tác phổ biến nhất được thực hiện thông qua trình đổ bóng điện toán. DCT có thể được thực hiện thông qua cấu hình cắt nhỏ, giống như các codec khác.

Tương lai

Với việc phát hành FFmpeg 8.1, chúng tôi đã triển khai mã hóa và giải mã FFv1, mã hóa và giải mã ProRes, giải mã ProRes RAW và giải nén DPX. Quá trình xử lý dựa trên GPU được bật và sử dụng tự động nếu bật giải mã tăng tốc Vulkan.

Bộ mã hóa và giải mã VC-2, cùng với bộ giải mã JPEG và APV, vẫn đang được tiến hành và cần công việc bổ sung trước khi có thể hợp nhất chúng.

Nhìn xa hơn, các codec duy nhất còn lại có tiềm năng tăng tốc GPU đáng kể là JPEG2000 và PNG — các codec còn lại có trường hợp sử dụng thực tế hạn chế hoặc không được hưởng lợi từ khả năng tăng tốc dựa trên điện toán.

Thật không may, JPEG2000 — và theo phần mở rộng JPEG2000HT — không giống hầu hết các codec hiện đại, mang theo những tính năng tồi tệ nhất của một số tính năng kết hợp: một hệ thống mã hóa bán tuần tự hóa yêu cầu kiến ​​thức về miền mở rộng và dòng bit phức tạp đủ để khiến hầu hết các cơ quan hành chính hiện đại phải tạm dừng. Giải mã phần mềm của JPEG2000 được xếp vào loại chậm nhất trong số các codec được sử dụng rộng rãi, do thiết kế lấy ASIC làm trung tâm và bộ mã hóa số học kém kỹ thuật. Bất chấp tất cả những điều này, nó vẫn là codec chính được sử dụng trong điện ảnh kỹ thuật số, y học và pháp y.

Khả năng tăng tốc PNG là một câu hỏi mở: khả năng tồn tại của nó với tư cách là mục tiêu GPU sẽ phụ thuộc vào mức độ hiệu quả của DEFLATE có thể được song song hóa.

Điện toán Vulkan

Vulkan thường được coi là một API đồ họa có tính năng tính toán bổ sung - nhưng khung đó đã lỗi thời. Khả năng tính toán của nó đã phát triển để phù hợp và trong một số trường hợp còn vượt xa các API tính toán chuyên dụng. Vulkan hiện đại cung cấp con trỏ, hoạt động nhóm con mở rộng, bí danh bộ nhớ dùng chung, hoạt động theo bit gốc, mô hình bộ nhớ được xác định rõ, chuyên môn hóa trình đổ bóng, địa chỉ 64 bit và truy cập trực tiếp vào các đơn vị ma trận GPU. Cùng với nhau, các tính năng này cho phép lập trình viên tối ưu hóa ở mức thấp hơn so với các API trừu tượng hơn.

Mặc dù vậy, API điện toán Vulkan vẫn chưa phát huy hết tiềm năng vì nó chưa phát huy hết khả năng của SPIR-V™, vốn là một đại diện trung gian có tính biểu cảm đáng chú ý. Hỗ trợ cho bộ tính năng SPIR-V rộng hơn đang tích cực mở rộng - các con trỏ chưa được gõ và địa chỉ 64 bit đã có sẵn, đồng thời hỗ trợ các thao tác theo bit trên các loại số nguyên không phải 32 bit đang được triển khai.

Các API điện toán cạnh tranh từ các nhà cung cấp GPU thường gói hàng trăm triển khai thuật toán chuyên biệt và được tối ưu hóa cụ thể, có thể truy cập được thông qua các ngôn ngữ lập trình thoải mái hơn — một gói hấp dẫn. Tất nhiên, vấn đề nằm ở việc khóa nhà cung cấp, đây có thể là mối lo ngại nghiêm trọng đối với phần mềm di động, tồn tại lâu dài như FFmpeg.

FFmpeg có thể không còn xa lạ khi viết các triển khai thuật toán phổ biến của riêng mình để tránh sự phụ thuộc, chẳng hạn như hàm băm, thuật toán sắp xếp, CRC hoặc biến đổi tần số. Nhưng mặt khác, các API hướng đối tượng mở rộng có thực sự cần thiết không? Thông thường, việc định dạng dữ liệu được sử dụng phổ biến Việc triển khai mất nhiều thời gian hơn và tạo ra mã ít tối ưu hơn so với việc chỉ viết một triển khai nhỏ của một thuật toán chuyên biệt cho một trường hợp sử dụng nhất định. Trong nhiều trường hợp, OOP có thể được xử lý bằng cách tạo khuôn mẫu thông qua bộ tiền xử lý. Việc liên kết nhiều đoạn mã có thể chỉ là #include. Và, mã dễ vỡ nhắm vào một phiên bản API đơn lẻ của nhà cung cấp, do đó phụ thuộc vào một phiên bản gcc cũ cụ thể, có thể được thay thế bằng một trình đổ bóng đáng tin cậy, lâu dài và tự cung cấp.

Vulkan có mặt khắp mọi nơi - từ SoC nhỏ, đến máy tính bảng, GPU nhúng, GPU rời và GPU máy chủ chuyên nghiệp - và mô hình quản trị dẫn đầu ngành của nó tạo ra động lực mạnh mẽ để hỗ trợ rộng rãi các tiện ích mở rộng mới. Kiểm tra tự động liên tục được thực hiện bằng bộ kiểm tra sự phù hợp toàn diện. Cuối cùng, Vulkan có một hệ sinh thái rộng lớn gồm các công cụ gỡ lỗi, tối ưu hóa và lập hồ sơ, đồng thời cộng đồng nhà phát triển toàn cầu lớn có nghĩa là hầu hết mọi thủ thuật tối ưu hóa hoặc giải quyết vấn đề GPU mà bạn khám phá đều đã được tìm thấy, ghi lại và đưa trở lại thông số kỹ thuật.

Cho dù sử dụng trình tạo bóng điện toán Vulkan Video hay Vulkan, Vulkan đã trở thành một API hấp dẫn để truy cập quá trình xử lý video được tăng tốc bằng GPU.

Tải xuống FFmpeg: https://ffmpeg.org/download.html

Khronos® và Vulkan® là các nhãn hiệu đã đăng ký và SPIR-V™ là nhãn hiệu của The Khronos Group Inc. OpenCL™ là nhãn hiệu của Apple Inc. được Khronos sử dụng theo giấy phép. Tất cả tên sản phẩm, nhãn hiệu và/hoặc tên công ty khác chỉ được sử dụng để nhận dạng và thuộc về chủ sở hữu tương ứng của chúng.