İşlemci neden kodlama için GPU'dan daha iyi?

Bu makaleyi okuyordum ve CPU'nun video sıkıştırma için GPU'dan daha iyi olduğunu gördüm.

Makale sadece bunun, işlemci GPU'dan daha karmaşık algoritmaları işleyebileceği için olduğunu söylüyor, ancak daha teknik bir açıklama istiyorum, internette bazı aramalar yaptım, ancak hiçbir şey bulamadım.

Peki, bir siteyi açıklamayı veya bağlantılandırmayı bilen biri bunun daha derin bir açıklamasına sahip miydi?

Bağladığınız makale çok iyi değil.

Normalde, tek geçişli bit hızı kodlamaları, bit hızınızı maksimum bit hızı sınırı olan bir RF değerine dönüştürür ve oradan alır.

x264'ün tek geçişli ABR hız kontrolü CRF + limiti olarak uygulanmaz. Yine de, 2 geçişin bir hedef bit hızına ulaşmanın en iyi yolu olduğu konusunda haklı.

Ve görünüşe göre, diğer görevler için CPU zamanını serbest bırakmak için x264 iş parçacığı = 3 veya başka bir şeyle başlayabileceğini fark etmiyor. Veya x264'ün önceliğini çok düşük olarak ayarlayın, böylece yalnızca başka bir görevin istemediği CPU zamanı alır.

Ayrıca = 1 numaralı konuları CUDA veya başka bir şey kullanarak karıştırır. Hiç şüphesiz sorularınız var, çünkü bu makalenin KORKUNÇ bir açıklaması var. Makalenin tamamı temel olarak aşağıdakilerle ilgilidir: x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkvgiriş AviSynth betiği ile hafif filtreleme kullanmak veya belki de kullanmak. Aslında "plasebo" önerir. Bu çok komik. Daha önce plasebo ile kodlanmış korsan bir dosya görmedim. ( tüm kaliteli önayarlar yerine me=esaveya me=tesayerine söyleyebilirsiniz .me=umhveryslow

Ayrıca 10 bit renk derinliği kullandığından bahsetmiyor. Kodlama ve kod çözme daha yavaştır, ancak 8 bit'e geri dönüştürüldükten sonra bile daha iyi 8 bit SSIM elde edersiniz. Hareket vektörleri için daha fazla hassasiyete sahip olmak yardımcı olur. Ayrıca, tam bir 8 bit değerine yuvarlamak zorunda değilsiniz yardımcı olur. Bileşen başına 8 bit hız kesmesi olarak düşünebilirsiniz; frekans alanında nicelendirmek ve daha sonra bunu CABAC ile sıkıştırmak, daha yüksek bit derinliği katsayılarının daha fazla yer kaplaması gerekmediği anlamına gelir.

(BTW, h.265, hareket vektörleri için zaten daha fazla hassasiyete sahip olduğu için 8 bit video için 10 bit kodlardan daha az yararlanır. 8 bit video girişleri için 10 bit x265 kullanmanın bir yararı varsa, Bu nedenle hız cezasının buna değeceği daha az olasıdır.)

Asıl sorunuza cevap vermek için:

edit: doom9 şimdi tekrar hazır, bu yüzden bağlantıyı toparlayacağım. Kimin ne söylediğini doğru bir şekilde anlatmak için ona gidin.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

google yalnızca alıntıyı düzgün bir şekilde göstermeyen aptal baskı sürümünü önbelleğe alır. Bu mesajların hangi kısımlarının alıntı olduğuna ve hangisinin kişinin kendisine atfedildiğinden emin değilim.

Son derece düzensiz dallanma modelleri (atlama modları) ve bit manipülasyonu (nicemleme / entropi kodlaması) mevcut GPU'lara uygun değildir. Şu anda tek gerçekten iyi bir uygulama IMO tam arama ME algoritmaları, sonunda hızlandırılmış tam arama hala CPU daha hızlı olsa bile hala yavaş.
- MfA

Aslında, temelde her şey GPU'da CABAC dışında makul bir şekilde yapılabilir (bu yapılabilir, sadece paralelleştirilemezdi).

x264 CUDA başlangıçta bir fullpel ve subpel ME algoritması uygulayacaktır; daha sonra CABAC yerine bir bit maliyet yaklaşımı ile RDO gibi bir şey yapabilirdik.

Çünkü her şeyi tek bir hassas kayan noktada yapmak zorunda
- MfA

Yanlış, CUDA tamsayı matematiği destekliyor.

- Karanlık Shikari

Dark Shikari, 2007'den beri x264 sürdürücüsü ve özelliklerin çoğunun geliştiricisidir.

AFAIK, bu CUDA projesi tamamlanmadı. Önden okuma iş parçacığından bazı işleri boşaltmak için OpenCL kullanma desteği vardır (çerçevenin yüksek kaliteli bir son kodlaması değil, hızlı I / P / B kararı).

Anladığım kadarıyla , video kodlama için arama alanının çok büyük olması, CPU'lardaki arama yollarının erken sonlandırılması için akıllı sezgisel taramaların, en azından yüksek kaliteli kodlama için, kaba kuvvet GPU'ları masaya getirdiği yendi. Sadece -preset ultrafastx264, esp üzerinden HW kodlamasını makul bir şekilde seçebileceğiniz yerle karşılaştırılır . Yavaş bir CPU'nuz varsa (çift çekirdekli ve hiper iş parçacığı olmayan dizüstü bilgisayar gibi). Hızlı bir CPU'da (hiper iş parçacıklı i7 dört çekirdekli), x264 superfastmuhtemelen bu kadar hızlı olacak ve daha iyi görünecek (aynı bit hızında).

Hız bozulmasının (dosya boyutu başına kalite) önemli olduğu bir kodlama yapıyorsanız, x264 -preset mediumveya daha yavaş kullanmalısınız . Bir şeyi arşivliyorsanız, şimdi biraz daha fazla CPU zamanı harcamak, o dosyayı sakladığınız sürece bayt tasarrufu sağlayacaktır.

yan not, bir video forumunda deadrats'tan mesajlar görürseniz, yardımcı olmayacaktır. Gördüğüm her iş parçacığında bahsettiği çoğu şey hakkında yanılmıştı. Mesajları x264 GPU kodlaması hakkında googled birkaç konu geldi. Görünüşe göre neden kolay olmadığını anlamıyor ve x264 geliştiricilerine neden aptal olduklarını anlatmak için birkaç kez yayınladı ...

2017 güncellemesi:

ffmpeg, h264 ve h265 NVENC GPU hızlandırmalı video kodlamayı destekler . Hevc_nvenc veya h264_nvenc için seçtiğiniz kalitede 1 geçişli veya 2 geçişli kodlama yapabilirsiniz ve hatta giriş seviyesi GPU ile hızlandırılmamış kodlamadan ve Intel Quick Sync hızlandırmalı kodlamadan çok daha hızlıdır.

2 geçişli yüksek kaliteli kodlama:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4

1 geçişli varsayılan kodlama:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4

NVENC ffmpeg yardım ve seçenekleri:

ffmpeg -h encoder=nvenc

Kullanın, CPU kodlamasından çok daha hızlıdır.

GPU'nuz yoksa, hızlandırılmamış kodlamadan çok daha hızlı olan Intel Quick Sync kodek, h264_qsv, hevc_qsv veya mpeg2_qsv'yi kullanabilirsiniz.

Peter'ın söylediklerine biraz daha ayrıntılı olarak bakmak için, genellikle birden fazla işlemci kullanmak, hepsinin yapılması gereken ancak birbirinize bağımlı olmayan veya birbirini bağımlı olmayan bir göreve sahip olduğunuz birkaç bağımsız göreve sahip olduğunuz durumlarda yardımcı olur. büyük miktarda veri matematiği.

Bununla birlikte, B hesaplamasının girişi olarak A hesaplamasının çıktısına ve C hesaplamasına giriş olarak B hesaplamasının çıktısına ihtiyacınız varsa, her görevde farklı bir çekirdek çalışma yaparak hızlandıramazsınız ( A, B veya C) çünkü biri diğeri bitene kadar başlayamaz.

Bununla birlikte, yukarıdaki durumda bile, başka bir yolla paralelleştirebilirsiniz. Girdi verilerinizi parçalara ayırabiliyorsanız, A, ardından B, sonra C'yi bir veri yığınıyla yapmak için bir çekirdek çalışmanız olabilir, başka bir çekirdek ise A, sonra B, C'yi farklı bir veri yığını üzerinde çalışır .

Başka düşünceler de var. Belki hesaplamaları paralelleştirmenin bir yolunu bulabilirsiniz, ancak verileri diskten veya ağ üzerinden okumak veya GPU'ya göndermek hesaplamaları yapmaktan daha uzun sürebilir. Bu durumda, paralelleştirmek mantıklı değildir, çünkü sadece verileri belleğe almak hesaplamayı paralel yaparak tasarruf ettiğiniz zamandan daha uzun sürer.

Başka bir deyişle, bir bilim olduğu kadar bir sanattır.