Saya sedang membaca artikel ini dan saya melihat bahwa CPU lebih baik untuk kompresi video daripada GPU.
Artikel itu hanya mengatakan itu terjadi karena prosesor dapat menangani algoritma yang lebih kompleks daripada GPU, tetapi saya ingin penjelasan yang lebih teknis, saya melakukan beberapa pencarian di internet tetapi saya tidak menemukan apa pun.
Jadi, ada yang tahu untuk menjelaskan atau menautkan situs ke saya memiliki penjelasan yang lebih mendalam tentang ini?
Jawaban:
Artikel yang Anda tautkan tidak terlalu bagus.
Biasanya, pengkodean bitrate laluan mengubah bitrate Anda menjadi nilai RF dengan batas bitrate maksimum dan membawanya dari sana.
one-pass ABR ratecontrol tidak diimplementasikan sebagai batas CRF +. Dia benar bahwa 2pass sejauh ini merupakan cara terbaik untuk mencapai bitrate target.
Dan dia tampaknya tidak menyadari bahwa dia dapat memulai x264 dengan utas = 3 atau sesuatu, untuk membiarkan waktu CPU kosong untuk tugas-tugas lain. Atau atur prioritas x264 menjadi sangat lambat, sehingga hanya mendapatkan waktu CPU yang tidak diinginkan oleh tugas lain.
Dia juga mencampur untaian = 1 dengan menggunakan CUDA, atau sesuatu. Tidak heran Anda memiliki pertanyaan, karena artikel itu memiliki penjelasan yang MENGERIKAN. Seluruh artikel pada dasarnya bermuara pada: gunakan x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, atau mungkin menggunakan penyaringan cahaya dengan skrip AviSynth input. Dia sebenarnya merekomendasikan "plasebo". Lucu sekali. Saya belum pernah melihat file bajakan yang dikodekan dengan plasebo. (Anda dapat mengetahui dari me=esaatau me=tesa, alih-alih me=umhuntuk semua preset berkualitas baik, hingga veryslow.
Dia juga tidak menyebutkan menggunakan kedalaman warna 10bit. Lebih lambat untuk menyandikan dan mendekode, tetapi bahkan setelah downconverting kembali ke 8bit, Anda mendapatkan SSIM 8-bit yang lebih baik. Memiliki presisi yang lebih untuk vektor gerakan tampaknya membantu. Juga, tidak harus membulatkan ke nilai 8 bit persis membantu. Anda dapat menganggap 8-bit per komponen sebagai peretasan kecepatan; kuantisasi dalam domain frekuensi dan kemudian mengompresi itu dengan CABAC berarti bahwa koefisien kedalaman bit yang lebih tinggi tidak harus mengambil lebih banyak ruang.
(BTW, h.265 mendapat manfaat lebih sedikit dari 10-bit encode untuk video 8-bit karena sudah lebih presisi untuk vektor gerak. Jika ada manfaat menggunakan 10-bit x265 untuk input video 8-bit, itu lebih kecil daripada dengan x264. Jadi kecil kemungkinannya bahwa penalti kecepatan akan sepadan.)
sunting: doom9 lagi sekarang, jadi saya akan merapikan tautan. Pergi ke sana untuk mengutip yang tepat dari yang mengatakan apa.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
Google hanya melakukan cache versi cetak bodoh yang tidak menunjukkan kutipan dengan benar. Saya tidak yakin bagian mana dari pesan-pesan ini yang merupakan kutipan, dan mana yang dikaitkan dengan orang itu sendiri.
Pola percabangan yang sangat tidak teratur (mode lewati) dan manipulasi bit (pengkodean kuantisasi / entropi) tidak sesuai dengan GPU ini. IMO satu-satunya aplikasi yang benar-benar bagus saat ini adalah algoritma ME pencarian lengkap, pada akhirnya meskipun pencarian penuh yang dipercepat masih lambat walaupun itu lebih cepat daripada pada CPU.
- MfASebenarnya, pada dasarnya semuanya bisa dilakukan secara wajar pada GPU kecuali CABAC (yang bisa dilakukan, itu tidak bisa diparalelkan).
x264 CUDA akan mengimplementasikan algoritma fullpel dan subpel ME pada awalnya; nanti kita bisa melakukan sesuatu seperti RDO dengan pendekatan sedikit-biaya daripada CABAC.
Karena harus melakukan segalanya pada floating point presisi tunggal
- MfASalah, CUDA mendukung matematika bilangan bulat.
- Dark Shikari
Dark Shikari adalah pengelola x264, dan pengembang sebagian besar fitur sejak 2007 atau lebih.
AFAIK, proyek CUDA ini tidak berjalan dengan baik. Ada dukungan untuk menggunakan OpenCL untuk mengeluarkan beberapa pekerjaan dari thread lookahead (keputusan I / P / B cepat, bukan penyandian akhir frame yang berkualitas tinggi).
Pemahaman saya adalah bahwa ruang pencarian untuk pengkodean video adalah SANGAT besar bahwa heuristik cerdas untuk penghentian awal jalur pencarian pada CPU mengalahkan GPU dengan kekuatan besar, setidaknya untuk pengkodean berkualitas tinggi. Ini hanya dibandingkan dengan di -preset ultrafastmana Anda mungkin memilih encoding HW lebih dari x264, esp. jika Anda memiliki CPU yang lambat (seperti laptop dengan dual core dan tidak ada hyperthreading). Pada CPU yang cepat (i7 quad core dengan hyperthreading), x264 superfastmungkin akan secepat, dan terlihat lebih baik (pada bitrate yang sama).
Jika Anda membuat enkode di mana penyimpangan laju (kualitas per ukuran file) penting, Anda harus menggunakan x264 -preset mediumatau lebih lambat. Jika Anda mengarsipkan sesuatu, menghabiskan lebih banyak waktu CPU sekarang akan menghemat byte selama Anda menyimpan file itu.
catatan, jika Anda pernah melihat pesan dari deadrat di forum video, itu tidak akan membantu. Dia salah tentang banyak hal yang dia bicarakan di setiap utas yang pernah saya lihat. Postingnya muncul dalam beberapa utas yang saya googled tentang penyandian GPU x264. Tampaknya dia tidak mengerti mengapa itu tidak mudah, dan telah diposting beberapa kali untuk memberi tahu pengembang x264 mengapa mereka bodoh ...
Pembaruan 2017:
ffmpeg mendukung encoding video yang dipercepat GPU h264 dan h265 NVENC . Anda dapat melakukan pengodean 1-pass atau 2-pass pada kualitas yang Anda pilih, baik hevc_nvenc atau h264_nvenc, atau dan bahkan dengan GPU entry-level, itu jauh lebih cepat daripada pengkodean non-akselerasi dan pengkodean dipercepat Intel Quick Sync.
2-pass encoding berkualitas tinggi:
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4
Pengodean default 1-pass:
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4
Bantuan dan opsi NVENC ffmpeg:
ffmpeg -h encoder=nvenc
Gunakan itu, ini jauh lebih cepat daripada pengkodean CPU.
Jika Anda tidak memiliki GPU, Anda dapat menggunakan codec Intel Quick Sync, h264_qsv, hevc_qsv, atau mpeg2_qsv, yang juga jauh lebih cepat daripada pengkodean yang tidak dipercepat.
ffmpegdengan -vcodec h264_qsvpada notebook Intel lama saya dengan Intel HD Grpahics 4000 membuat rendering lebih cepat!
Untuk menguraikan sedikit lebih jauh tentang apa yang Peter katakan, secara umum menggunakan beberapa prosesor membantu dalam kasus di mana Anda memiliki beberapa tugas independen yang semuanya harus dilakukan tetapi tidak memiliki ketergantungan satu sama lain, atau satu tugas di mana Anda melakukan hal yang sama matematika pada sejumlah besar data.
Namun, jika Anda perlu output kalkulasi A sebagai input kalkulasi B, dan output kalkulasi B sebagai input ke kalkulasi C, maka Anda tidak dapat mempercepatnya dengan memiliki inti yang berbeda bekerja pada setiap tugas ( A, B, atau C) karena yang satu tidak bisa mulai sampai yang lain selesai.
Namun, bahkan dalam kasus di atas, Anda mungkin dapat memparalelasinya dengan cara lain. Jika Anda dapat memecah data input Anda menjadi potongan-potongan, Anda mungkin memiliki satu pekerjaan inti melakukan A, lalu B, lalu C dengan satu potongan data, sedangkan inti lain bekerja pada melakukan A, lalu B, lalu C pada potongan data yang berbeda .
Ada pertimbangan lain juga. Mungkin Anda bisa menemukan cara untuk memparalelkan perhitungan, tetapi hanya membaca data dari disk, atau melalui jaringan, atau mengirimkannya ke GPU akan memakan waktu lebih lama daripada melakukan perhitungan. Dalam hal itu, tidak masuk akal untuk memparalelasinya karena hanya memasukkan data ke dalam memori membutuhkan waktu lebih lama dari jumlah waktu yang Anda hemat dengan melakukan perhitungan secara paralel.
Dengan kata lain, itu adalah seni dan juga sains.
-c:v libx264 -preset slower(yang tidak terlalu lambat, seperti hampir realtime untuk 1920x1080p24 pada Skylake i7-6700k.)