785G硬解AVC上限的研究
 

一點閒聊 大家將就看看吧...

話說最近在下的電腦在拖了2年半終於更新了
既然都更新了 就想說玩玩看785G的硬解 玩著玩著就發現了一個怪現象:
網路上不是說UVD2開DXVA的上限是Profile Lv.5.1嗎?
為什麼有的檔案是5.1的 但是DXVA開的起來?
查著查著就查到了本站vxr先進的文 裡面有列了些測試
發現似乎跟解析度及Ref Frame數目有關係

經過了幾天無聊的浪費能源之後 終於研究出了一點東西:
1.UVD2硬解AVC並不是看Profile(但是iPhone3GS跟PS3是)
其實真的是看解析度及Ref Frame
先看實驗設定:
實驗是用MEnocder+WinMEnc做的
只下兩個固定參數:CRF設20 Lv設5.1 然後透過frameref來設定Ref Frame的數目
其餘皆照預設參數 沒改動

以下是實驗後的結果:
1920*1080時 能開DXVA的Ref Frame上限是4
1280*720時 能開DXVA的Ref Frame上限是8
8XX*480/480*320時 能開DXVA的Ref Frame上限是11
在下去的解析度因為有無硬解意義不大 就沒測了

從結果來看 如果是目前的影片 UVD2是夠用了
但是如果將來為了要有更小了檔案大小而使Ref Frame=16的設定開始普及
那問題就大了...

測完之後也有些疑問:
1.這個限制應該是根據某項規格而來 不知道是DXVA還是BD的Profile呢?
2.由結果看 個人猜測ATi遲遲不把Ref Frame上限提升的原因 可能是出在ATi於通用運算的能力不夠強?(Ref Frame愈高 運算力的要求愈高)但是這點因為手邊無有UVD2.2的卡測試 所以僅止於猜想
3.同樣僅止於猜想 由於nV的GPU在通用運算效能做的比ATi好多了 nV的VP2/3/4會不會也有可能是透過CUDA來讓GPU執行硬解的呢?
也因此 在DXVA的支援也比ATi好?

難得有很棒的分享文 來敗讀一下........

對於文中幾點有點問題
1.測試結果方面
目前我所知的內容都指出ATI可以L4.1(含)以下的都沒問題
而根據http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC所述之內容
1280X720時ref frame最多可以到9而非實驗結果的8
而且照道理來說 可接受的ref frame的最大值 應該可以直接推的

2.計算能力部分
根據http://en.wikipedia.org/wiki/Reference_frame_(video)文中所述
ref frame提高在編碼時是確實需要更多的計算能量
而在解碼時似乎比起計算能量的增加
所消耗記憶體的增加才是重點
(至少文中並沒有特別提到所需計算能量的提升)

由於資料來源的不同以及所得資料內容的不同
所以我得到的結論也不大一樣
首先我認為DXVA的能力未必跟通用計算能力掛勾
或許該說 效能評量是一個複雜的技術 並非可以如此輕易的評論
加上根據上面第二點所述的[ref frame對解碼的負擔主要是在記憶體上]
我們只能合理的推斷ati的記憶體配置有點問題
而非ati的通用計算能力不佳
不知大家以為這個推論適當否?

我也想知道硬解高清能力有多少.
有硬解能力的顯卡,極限多少呢?
本人...
我的副機-低級CPU intel c420原本裝上ATI3850,給哥哥用...一向沒有大問題.
只是看HD TV,全螢幕不能多次轉台,轉台有時會擋機.認為ati driver一向有問題,
9.4,9.6,9.8,10.2很多很亂,
後來借用一低級8500GT,嘗試裝上,開硬解, 雖然CPU沒有100%loading,
發現看youtube HD很不順,HD TV更不行.
可能我我CPU太弱.
雖然有人軟解才是王道,.
但用舊CPU,環保一些,裝上有硬解能力的顯卡,
就更需要知道硬解高清能力,顯卡不用買錯.

我也想知道硬解高清能力有多少.
有硬解能力的顯卡,極限多少呢?
本人...
我的副機-低級CPU intel c420原本裝上ATI3850,給哥哥用...一向沒有大問題.
只是看HD TV,全螢幕不能多次轉台,轉台有時會擋機.認為ati driver一向有問題,
9.4,9.6,9.8,10.2很多很亂,
後來借用一低級8500GT,嘗試裝上,開硬解, 雖然CPU沒有100%loading,得40-50%
發現看youtube HD很不順,HD TV更不行.
可能CPU太弱.
所以,用低級CPU更需要知道硬解高清能力,顯卡不用買錯.

1. Ref Frame數目 的限制「我猜」是來自BUFFER大小，而這個BUFFER大小「我猜」受限於UVD當初的設計…

所以UVD只能定址一定大小的記憶體當BUFFER，這塊BUFFER能擺幾張 FRAME的資料 就取決於 FRAME的解析度了

2.Ref Frame 數目越大，解碼時要更多資源（記憶體），編碼時除了記憶體、CPU的資源也是以倍數計… 但是效果 卻不試成正比的，所以一般壓縮不見得會用到 15以上的數目，事實上，大多時候 3∼6就很夠用了 （可以參考 MENCODER和X264的相關文件）

3.UVD在PP階段跑得是SHADER，所以3450/4350之類低階卡的後處理很吃力（或著說關掉PP還比較好點 ）NV的VP可以參考 http://en.wikipedia.org/wiki/Nvidia_PureVideo 裡面也有 uvd和vp的簡單比較

"nV的VP2/3/4會不會也有可能是透過CUDA來讓GPU執行硬解的呢?"..
這是毫無關係的...

要取決於ISV有沒有使用...
ISV如果使用DXVA API去呼叫...
那就是乖乖使用微軟的DXVA...
DXVA轉而調用GPU的Driver..

否則要另外用別的API(ex: CUDA)去呼叫VP去加速解碼...
目前只有CoreAVC這個方案(nVDIA提出的CUDA去加速解碼依然是用VP去加速，而非透過SP..)...
其餘像Cyberlink的PDVD這種則是把CUDA用在別地方..

您可使用DXVA Checker去追蹤到底在DXVA的狀態下..
建立的哪些東西出來?!..

恩 這個在下也不知道怎麼解釋 因為實驗的情況其實跟看到的資料落差不小
1.Lv 4.1理論上應該都可以以開啟DXVA 但是個人實驗結果顯示開不開的了DXVA的上限 L4.1跟5.1是一致的(重壓或是透過IDC Changer改都試過)
2.1280*720時Ref Frame設成9是可以開DXVA 但是會發生Seek Bar一拖動距離超過12分鐘就會導致撥放程式Freeze住.基於保險起見 所以還是說8為上限



恩 但是在下根據下列敘述來設定實驗上限的時候 跟預期有些差異

"还有一点， --level=4.1时720p以下的--ref 不能大于16，720p以上的不能大于6
也是网上查到的。
有个计算公式可以大家研究一下。（选自漫游酷论坛的techneek发言）
硬件解码的限制主要是在帧缓存DPB上，DPB是Decoded Picture Buffer，已解码图像缓存，已经解码的图像放在缓存里用来做其他帧的参考，所以DPB以参考帧密切相关。
L4.1规定的DPB是12288KB，相当于对少bit呢？12288*1024*8bit=100663296bit
由于MPEG4的图像一律是4：2：0格式，所以每个像素占用12bit数据，那么帧缓存中允许的像素数量就是100663296/12=8388608。
所以：8388608/(长*宽)=参考帧的数量
这是他的研究成果，我觉得可以作为一个参考。
能不能硬解，除了采用这种办法计算之外，当然最简单的就是只下载sample预览一下，以确保万无一失。"(原文出自思路論壇此篇)

個人本來推測的各常用解析度的硬解上限是4/9/16
但是一測下去就發現不是這麼回事...
8XX*480這個解析度在下就是從16開始一路往下測 測到11才能開DXVA



會做這個實驗其實也是因為在下個人最近抓到了幾套動畫
在Lv 5.1的條件下 設的Ref Frame都不低
像PSS的交響情人夢最終篇 1280*720 Lv 5.1 搭配的Ref Frame數是11或12
當然 這套硬解開不了.所以才會開始思考:UVD2的上限在哪裡? 還能撐多久? 才有今天這個無聊的實驗出來...

這種估算方式可能多少會有誤差的…如何配置記憶體，要看UVD硬體的設計，單純以「DPB」除以每個畫面/FRAME記憶體是不夠的…UVD能分到的記憶體裡，還要提撥一小部份作為解碼過程使用…

所以UVD能硬解的REF frame數目，應該會比我們用各種「推估」方式來的少

另外，UVD本身的「運算能力」也可能是一個限制也不一定…

所以要探討UVD的硬解能力，可能得找UVD的SPEC來看才行…



之前提到一般用3∼6的數目就很夠用（速度/品質 尖的平衡點），這個是用大多倏地影像來源…

「動畫/CG」是比較特別，用較大的數值，的確可以進一步把檔案壓小點，不過換來的就是壓蘇時間的大幅增加了…

如果遇上魔人級的作法，哪絕對是不計時間/成本，一切「畫質最上」為目標，那麼有這種壓縮參數設定就一點都不奇怪了 ︿︿

魔人級的應該是保留原有格式,完全不壓縮
畢竟再怎麼壓縮也是會減損畫質,不可能壓縮後畫質會更好
花時間去研究怎麼儘量減少畫質損失,不過換來的還是畫質損失
直接存在大容量硬碟還是省時省力許多