Tôi đã đọc bài viết này và tôi thấy rằng CPU tốt hơn cho việc nén video so với GPU.
Bài báo chỉ nói rằng điều đó xảy ra vì bộ xử lý có thể xử lý các thuật toán phức tạp hơn GPU, nhưng tôi muốn một lời giải thích kỹ thuật hơn, tôi đã thực hiện một số tìm kiếm trên internet nhưng tôi không tìm thấy gì.
Vì vậy, bất cứ ai biết để giải thích hoặc liên kết một trang web với tôi đã có một lời giải thích sâu sắc hơn về điều này?
Câu trả lời:
Bài viết bạn liên kết không tốt lắm.
Thông thường, mã hóa bitrate pass đơn chuyển đổi bitrate của bạn thành giá trị RF với giới hạn bitrate tối đa và lấy nó từ đó.
Công cụ kiểm tra ABR một lần của x264 không được triển khai dưới dạng giới hạn CRF +. Mặc dù vậy, anh ta đúng rằng 2pass là cách tốt nhất để đạt được tốc độ bit mục tiêu.
Và rõ ràng là anh ta không nhận ra rằng anh ta có thể bắt đầu x264 với các luồng = 3 hoặc thứ gì đó, để dành thời gian rảnh cho CPU cho các tác vụ khác. Hoặc đặt mức độ ưu tiên của x264 thành rất thấp, do đó, nó chỉ nhận được thời gian CPU mà không có tác vụ nào khác muốn.
Anh ta cũng trộn các chủ đề = 1 với việc sử dụng CUDA, hoặc một cái gì đó. Không có gì ngạc nhiên khi bạn có câu hỏi, bởi vì bài viết đó có một lời giải thích TERRIBLE. Toàn bộ bài viết về cơ bản tập trung vào: sử dụng x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkvhoặc có thể sử dụng một số bộ lọc ánh sáng với tập lệnh AviSynth đầu vào. Ông thực sự khuyên bạn nên "giả dược". Điều đó thật vui nhộn. Tôi chưa bao giờ thấy một tập tin lậu được mã hóa bằng giả dược. (bạn có thể nói từ me=esahoặc me=tesa, thay vì me=umhcho tất cả các cài đặt trước chất lượng tốt, ngay đến veryslow.
Ông cũng không đề cập đến việc sử dụng độ sâu màu 10 bit. Chậm hơn để mã hóa và giải mã, nhưng ngay cả sau khi chuyển đổi trở lại 8 bit, bạn vẫn nhận được SSIM 8 bit tốt hơn. Có độ chính xác hơn cho các vectơ chuyển động rõ ràng giúp. Ngoài ra, không phải làm tròn chính xác toàn bộ giá trị 8 bit. Bạn có thể nghĩ 8 bit cho mỗi thành phần là hack tốc độ; lượng tử hóa trong miền tần số và sau đó nén nó với CABAC có nghĩa là các hệ số độ sâu bit cao hơn không phải mất nhiều không gian hơn.
. với x264. Vì vậy, ít có khả năng hình phạt tốc độ sẽ có giá trị.)
chỉnh sửa: doom9 đã hoạt động trở lại, vì vậy tôi sẽ thu gọn liên kết. Đi đến nó để trích dẫn thích hợp của những người nói những gì.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
google chỉ lưu trữ phiên bản in ngu ngốc không hiển thị đúng trích dẫn. Tôi không chắc chắn phần nào của những tin nhắn này là trích dẫn và phần nào được quy cho chính người đó.
Các mẫu phân nhánh không đều (chế độ bỏ qua) và thao tác bit (mã hóa lượng tử / entropy) không phù hợp với các GPU hiện tại. IMO ứng dụng thực sự tốt duy nhất tại thời điểm này là thuật toán ME tìm kiếm đầy đủ, cuối cùng mặc dù tìm kiếm đầy đủ được tăng tốc vẫn chậm ngay cả khi nó nhanh hơn trên CPU.
- MfATrên thực tế, về cơ bản mọi thứ đều có thể được thực hiện một cách hợp lý trên GPU ngoại trừ CABAC (có thể được thực hiện, nó không thể được song song hóa).
x264 CUDA sẽ triển khai thuật toán ME fullpel và subpel ME ban đầu; sau này chúng ta có thể làm một cái gì đó như RDO với xấp xỉ chi phí bit thay vì CABAC.
Bởi vì nó phải làm mọi thứ ở điểm nổi chính xác duy nhất
- MfASai, CUDA hỗ trợ toán học số nguyên.
- Shikari tối
Dark Shikari là người duy trì x264 và là nhà phát triển của hầu hết các tính năng kể từ năm 2007 trở đi.
AFAIK, dự án CUDA này đã không được triển khai. Có hỗ trợ cho việc sử dụng OpenCL để giảm tải một số công việc từ luồng tìm kiếm (quyết định I / P / B nhanh chóng, không phải là mã hóa chất lượng cao cuối cùng của khung).
Tôi hiểu rằng không gian tìm kiếm cho mã hóa video quá lớn, các phương pháp phỏng đoán thông minh để kết thúc sớm các đường tìm kiếm trên CPU đánh bại các GPU mạnh mẽ mang đến, ít nhất là cho mã hóa chất lượng cao. Nó chỉ được so sánh với -preset ultrafastnơi bạn có thể chọn mã hóa CTNH một cách hợp lý trên x264, đặc biệt. nếu bạn có CPU chậm (như máy tính xách tay có lõi kép và không siêu phân luồng). Trên CPU nhanh (lõi tứ i7 với siêu phân luồng), x264 superfastcó thể sẽ nhanh như vậy và trông đẹp hơn (ở cùng tốc độ bit).
Nếu bạn đang thực hiện mã hóa ở mức độ biến dạng tỷ lệ (chất lượng trên mỗi kích thước tệp), bạn nên sử dụng x264 -preset mediumhoặc chậm hơn. Nếu bạn đang lưu trữ một cái gì đó, việc dành thêm một chút thời gian CPU bây giờ sẽ tiết kiệm byte miễn là bạn giữ tệp đó xung quanh.
lưu ý phụ, nếu bạn từng thấy tin nhắn từ deadrats trên một diễn đàn video, nó sẽ không hữu ích. Anh ấy đã sai về hầu hết mọi thứ anh ấy nói về mọi chủ đề tôi từng thấy. Các bài đăng của anh ấy xuất hiện trong một vài chủ đề mà tôi đã hiểu về mã hóa GPU x264. Rõ ràng anh ta không hiểu tại sao điều đó không dễ dàng và đã đăng nhiều lần để nói với các nhà phát triển x264 tại sao họ lại ...
Cập nhật năm 2017:
ffmpeg hỗ trợ mã hóa video tăng tốc GPU h264 và h265 NVENC . Bạn có thể thực hiện mã hóa 1-pass hoặc 2-pass với chất lượng mà bạn chọn, cho hevc_nvenc hoặc h264_nvenc, và thậm chí với GPU cấp nhập cảnh, nó nhanh hơn nhiều so với mã hóa không tăng tốc và mã hóa tăng tốc Intel Quick Sync.
Mã hóa 2-pass chất lượng cao:
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4
Mã hóa mặc định 1 lượt:
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4
Các tùy chọn và trợ giúp của ffmpeg NVENC:
ffmpeg -h encoder=nvenc
Sử dụng nó, nó nhanh hơn nhiều so với mã hóa CPU.
Nếu bạn không có GPU, bạn có thể sử dụng codec Intel Quick Sync, h264_qsv, hevc_qsv hoặc mpeg2_qsv, tốc độ này cũng nhanh hơn nhiều so với mã hóa không tăng tốc.
ffmpegvới -vcodec h264_qsvmáy tính xách tay Intel cũ của tôi với Intel HD Grpahics 4000 giúp kết xuất nhanh hơn nhiều!
Để giải thích thêm một chút về những gì Peter nói, nói chung, việc sử dụng nhiều bộ xử lý sẽ giúp ích trong trường hợp bạn có một số nhiệm vụ độc lập mà tất cả cần phải thực hiện nhưng không phụ thuộc lẫn nhau hoặc một nhiệm vụ khi bạn thực hiện giống nhau toán học về số lượng lớn dữ liệu.
Tuy nhiên, nếu bạn cần đầu ra của phép tính A làm đầu vào của phép tính B và đầu ra của phép tính B làm đầu vào cho phép tính C, thì bạn không thể tăng tốc nó bằng cách có một công việc cốt lõi khác nhau trên mỗi tác vụ ( A, B hoặc C) vì người ta không thể bắt đầu cho đến khi người kia kết thúc.
Tuy nhiên, ngay cả trong trường hợp trên, bạn có thể song song với nó theo cách khác. Nếu bạn có thể chia dữ liệu đầu vào của mình thành các khối, bạn có thể có một lõi làm việc A, sau đó B, sau đó C với một khối dữ liệu, trong khi lõi khác hoạt động trên A, sau đó B, sau đó C trên một khối dữ liệu khác .
Có những cân nhắc khác, quá. Có thể bạn có thể tìm cách song song hóa các phép tính, nhưng chỉ cần đọc dữ liệu từ đĩa hoặc qua mạng hoặc gửi nó tới GPU sẽ mất nhiều thời gian hơn so với thực hiện các phép tính. Trong trường hợp đó, sẽ không có ý nghĩa gì khi song song hóa nó bởi vì việc đưa dữ liệu vào bộ nhớ sẽ mất nhiều thời gian hơn thời gian bạn tiết kiệm được bằng cách thực hiện phép tính song song.
Nói cách khác, đó là một nghệ thuật cũng như một môn khoa học.
-c:v libx264 -preset slower(điều này không chậm, như gần thời gian thực cho 1920x1080p24 trên Skylake i7-6700k.)