引用:
|
作者dabochi
硬件解码的限制主要是在帧缓存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
|
這種估算方式可能多少會有誤差的…如何配置記憶體，要看UVD硬體的設計，單純以「DPB」除以每個畫面/FRAME記憶體是不夠的…UVD能分到的記憶體裡，還要提撥一小部份作為解碼過程使用…
所以UVD能硬解的REF frame數目，應該會比我們用各種「推估」方式來的少
另外，UVD本身的「運算能力」也可能是一個限制也不一定…
所以要探討UVD的硬解能力，可能得找UVD的SPEC來看才行…
引用:
|
作者dabochi
會做這個實驗其實也是因為在下個人最近抓到了幾套動畫
在Lv 5.1的條件下 設的Ref Frame都不低
像PSS的交響情人夢最終篇 1280*720 Lv 5.1 搭配的Ref Frame數是11或12
當然 這套硬解開不了.所以才會開始思考:UVD2的上限在哪裡? 還能撐多久? 才有今天這個無聊的實驗出來
|
之前提到一般用3∼6的數目就很夠用（速度/品質 尖的平衡點），這個是用大多倏地影像來源…
「動畫/CG」是比較特別，用較大的數值，的確可以進一步把檔案壓小點，不過換來的就是壓蘇時間的大幅增加了…
如果遇上魔人級的作法，哪絕對是不計時間/成本，一切「畫質最上」為目標，那麼有這種壓縮參數設定就一點都不奇怪了 ︿︿