允許MEncoder使用更多CPU

我正在使用MEncoder將大量jpg圖片合併爲延時視頻。我有兩個主要文件夾與每以自動化過程大約10個子文件夾我運行：允許MEncoder使用更多CPU

find . -type d -name img -exec sh -c '(cd {} && /Volumes/SAMSUNG/PedestrianBehaviour/BreakableBonds/jpg2avi.sh t*)' ';'

其中jpg2avi是MEncoder的設置。

mencoder 'mf://t00*.jpg' -mf fps=10 -o raw.avi -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=2000 -o out.avi

爲了並行化我在兩個文件夾BreakableBonds和UnBreakableBonds開始了這個命令。然而，每個過程僅使用約27％，因此總共略高於50％。有什麼方法可以加速這個嗎？使每個過程佔用約50％。（我知道每個過程中有50％是不可能的。）

來源

2015-10-27 Nicky Mattsson

沒有合併'jpg2avi.sh'（旁白：對可執行腳本使用'.sh'擴展名不是一個好的做法;請參閱https://www.talisman.org/~erlkonig/documents/commandname-extensions-considered -harmful.shtml進行討論），這個問題相當不完整。 –

我現在用jpg2avi更新了它。 –

根據您使用的視頻編解碼器（x264是一個不錯的選擇），一個編碼應該能夠飽和幾個CPU核心。我通常直接使用ffmpeg，因爲mencoder被設計爲具有類似AVI的假設。

請參閱ffmpeg's wiki page關於如何做到這一點。

同樣，我強烈推薦在mkv或mp4容器中使用h.264，而不是在avi容器中的任何東西。 avi中的h.264是黑客，avi的常用編解碼器是divx（h.263）。 h.264是一大進步。

h.264適用於視頻mp3是用於音頻的：第一個編碼器的性能足夠好，隨着CPU速度的提高，實時傳輸，磁盤和網絡能夠處理文件尺寸產生良好的質量。與ffmpeg as a frontend for libx264一起使用。

h.265（和vp9）都是比h.264更好的編解碼器（就壓縮效率而言），但支持得少得多，需要更多的CPU時間。如果您想使用它們，請將ffmpeg用作libx265或libvpx的前端。 x265正在大力發展，所以它可能會有所改進，但幾個月前，如果CPU編碼時間相同，則x265在每比特率下的質量不會超過x264。鑑於多更多的CPU時間，x265可以做一個偉大的工作，並儘可能比x264低得多的比特率編碼好看。

所有這些編解碼器都是多線程的，即使在快速設置下也可以飽和4個內核。在更高的設置下（每塊花更多的CPU時間），我猜你可以飽和至少16個內核。我不確定，但我認爲你可以高效地利用HD x265編碼器上的64個核心，甚至更多。

在快速設置和高比特率下，gzip樣式的熵編碼最後階段（即x264的CABAC）限制了您可以保持繁忙的CPU數量。這是一個串行任務，因此整個編碼速度只有一個CPU可以壓縮最終比特流。

來源

2015-10-27 14:33:25

允許MEncoder使用更多CPU

回答

相關問題