引用:
|
作者a9607
這個圖表顯示的是
FFmpeg 在 單一線程(某些audio codec先天限制)下 比 PAT(你的多線程轉碼程式)慢
有損codec 大概慢了 5.7x~6.1x
無損codec 大概慢了 1.68x~1.83x
如果這樣來看的話， PAT的單執行緒效率其實是落後於FFmpeg的
以FFmpeg多核心的轉碼方法來測試的話，結果應該是FFmpeg反超PAT一截
（以有損code為例）
1、取得wav檔時間總長 9031秒，分成15段的話每段約602秒
2、用FFmpeg 的切塊指令 把原檔切成15個wave檔，然後用腳本一次叫出15個ffmpeg對個別切片檔作平行轉檔
3、這時 16核的cpu使用率應該都吃滿了
4、腳本監測 15個 task 都成功執行完畢後，把15個結果檔 用FFmpeg 依序 join成一個輸出檔
5、源檔、15個切片檔、15個轉碼檔、最終輸出檔 全都丟在 tmpfs(記憶體中)，所有的讀寫都以接近記憶體寬的速率操作
根據以往的經驗，這種作法雖然達不到15倍... |
對我而言，這個問題的重點是，當你把WAV切開，再編碼尤其是AAC及MP3時，會有兩個明顯的障礙：
1.你需要極大的RAM或硬碟空間，如果你的原始WAV是六聲道超高精度，32bits等等。
2.FFmpeg對音訊天生沒有多線程及綁定實體核心加速的編碼方式，因此縱使有你提到的Gapless問題，但他現在還是最快的。
gapless的問題，我在用AI寫這個轉碼器的時候就想過了。但是這是一個可以考慮改進的方向。
至於切塊轉碼沒有快過FFmpeg，這我還會再改進切塊的算法跟分配。
最後，我這個轉碼器會試著直接從AAC轉MP3，反之亦然。並沒有一定要靠WAV。
我是個懶人，有的人會說為什麼不做一個GUI的FFmpeg自動切塊多核心就好，是的，現在任何人都可以這樣做，我之所以做PAT是因為跟AI討論的時候，他自己就開始花我的token實作了，所以將錯就錯把它做完了。