... 這篇文章的數據和結果, 在下也略有涉入一點點, 你可能沒有將整個評測看完, 有些結果即然你問了, 我就回答吧. (這份是比較技術性一點點, 本不打算在此篇討論)
首先請看最後一段, 在看完後繼續我的後面說明.
http://www.pcinlife.com/article/graphics/2009-04-06/1239027193d770_8.html
Q: 什麼是 CRI SuperCoder 呢? 它和 PxVC1100 又有什麼關係? 為何用它來測跟用 TMPGEnc 來測有不同結果呢?
ANS:
記得先前我有提到一些所謂 Adobe Plug IN 程式嗎? 它就是這支程式, 負責上層應用程式與 SpursEngine Firmware 溝通的橋梁, 當你安裝好 PxVC1100 後, 每次開機除了 Driver 有啟用外, 還會載入 SpursEngine 的 Firmware 到晶片裡面, 如此整張卡才會開始正常工作. 在 SpursEngine 的架構裡面, 有兩個硬體 CODEC, 一個是 MPEG2, 另一個是 H264, 再加上四顆 1.5GHz 的 CELL CPU. 如果啟用 Super Resolution 才會用到 CELL, 僅做轉檔壓縮是啟用硬體的 CODEC, 和 四核 CELL 不太有關聯. 這點在運作觀念上先要說明.
內建的兩個 HW CODEC 在運作時有兩個模式, 一個是給 real time transcoding 用, 也就是你要求必需即時進入時, 並且即時轉出時使用, 一般在廣播或監控及網路串流時使用, 會略降低畫質, 但時間上可以達到要求, SpursEngine 會根據你給的影像資料量和格式來分析, 決定要如何壓縮都是以速度為優先考量.
另一個模式是以畫質考量, 一般用在編輯軟體上, 如 Adobe CS3/CS4 上面, 重畫質的一種應用, 當然速度上會略為變慢, 因為我手上沒有這套軟體, 所以無法比較出使用 TMPGEnc 和 CS3/CS4 兩者的結果差異. (也就是說, TMPGEnc 目前採用第一種方式, 而 Adobe Plug IN 是後者), 這也就是, 是否開放壓縮 "品質 vs 速度" 的參數出來供不同應用的調整考量. 而這份比較的是"降轉"為主題, 比的是在相同解析度下的 low bitrate 表現能力.
最後的那段結果, 你也會發現, 就算用 CRI 的結果仍不如 x264, 但差據已經縮小, 原因在 Average Bitrate vs Peak Bitrate 間的關係. SSIM 這個比較方式, 是用 frame by frame 的方式, 也就是它在計算你每個 frame 重建回來時, 與原來的原始 frame 相似度有多少, 1.0 代表百分之百相同, 這當然不可能, 而 0.9 就代表有 90% 的相似度, 差異的最後 10% 就是剩下來的細節, 應該說主要的部份都 OK, 最後必須要借助 Peak Bitrate 來補強了, 換言之一些動態很大的畫面, 可以用瞬間加大資料流來記錄動態變化, 誰能加最大, 誰就能補的最多. 一般來說硬壓的晶片, 當你設定好 average bitrate 後, 它會有個最大 peak bitrate 限制, 不允許你和 average bitrate 差太多, 約在 1.5 ~ 3 倍之間, 而用軟體來做的 (如 MeGUI 軟體), 你要設十倍差都可以, 這是為何最後那 10% 不易拉近距離的關係. 但肉眼已經看不太出差異了.
至於 peak bitrate 高出 average bitrate 太多有何負面作用呢? (請待續)
[
本文最後由 PaoPaoDragon 於 2009-4-19 00:08 編輯 ]
