![]() |
||
Master Member
![]() ![]() ![]() ![]() 加入日期: Sep 2003
文章: 1,810
|
簡單的說 就看影片來說實做方式很多
不一定要從AMD、intel、Nvidia來做選擇 像我用的方式主要是依賴ffmpeg 理論上靠ffplay(或者跟ffmpeg 淵源很深厚的mplayer) 可以實做部份過程 而這些光靠CPU就可以了,GPU大概只剩下輸出的功能 是哪個牌子也就不重要了 啊 SVP 也有要移植到mpv(mplayer fork)的計畫 此文章於 2015-10-10 07:55 PM 被 orakim 編輯. |
|||||||
![]() |
![]() |
Regular Member
![]() ![]() 加入日期: Jun 2010
文章: 75
|
大大你寫個教學文吧
mpv 我也在用,Macbook Pro 上我就是用 mpv mpv 的 smooth motion 跟 madvr 一樣是 frame blending 而不是 interpolation mpv 在 opengl 上下了不少工夫,內建的 jinc, deband 主要是靠顯卡處理 可以全 cpu 硬幹我還真不知道,就算可以至少也要 5960X 等級的 U mpv 目前最大的優勢還是在跨平台上,畫質和功能依然不如 madVR+AMD 而且 cpu 佔用明顯比較偏高
__________________
![]() |
||
![]() |
![]() |
Advance Member
![]() ![]() 加入日期: Aug 2003 您的住址: Hong Kong
文章: 308
|
引用:
1920x1080x30i->3840x2160x60p真的可以只用CPU, 不用GPU, 而我的CPU (i7-4771)也已經可以足夠應付。 還有就是處理速度, 不是受CPU所限, 而是受記憶體頻寛所限。 我的記憶體頻寛實測約有16GBytes/s(讀取), 光是做YUV->RGB和Resize/Deinterlace共要約13GB/s的頻寛, 還要讀檔和解碼等, 因此記憶體頻寛只是剛剛好足夠。 P.S. 我的RAM是1600MHz CL11 (Dual Channel)
__________________
我寫的程式: HQMP (2005/09/04): http://sswroom.no-ip.org:5080/compprog/smp/hqmp.html AVIRead 0.927 (2006/01/28): http://sswroom.no-ip.org:5080/compp...read/index.html SMP (04/09/02): http://sswroom.no-ip.org:5080/compprog/smp/index.html Subtitle Editor 0.6 (05/01/23): http://sswroom.no-ip.org:5080/compp...edit/index.html ADX Decoder Directshow Filter 0.61: http://sswroom.no-ip.org:5080/compp...xdec/index.html PSSADPCM Directshow Filter 0.61: http://sswroom.no-ip.org:5080/compp...dpcm/index.html XA Filter 0.61: http://sswroom.no-ip.org:5080/compp...lter/index.html |
|
![]() |
![]() |
Regular Member
![]() ![]() 加入日期: Jun 2010
文章: 75
|
1920x1080→3840x2160 用 i7 EVR resizer 不是問題
30i→60p 只是單純的倍增,用 ffdshow 也可以辦到 但要達到 madVR 的畫質+AMD 補幀那又是另一回事 所以我才說有其他方法的話歡迎分享教學,至少我是不知道怎麼弄啦....
__________________
![]() |
![]() |
![]() |
Advance Member
![]() ![]() 加入日期: Aug 2003 您的住址: Hong Kong
文章: 308
|
引用:
我是指用CPU進行實時Linear Lanczos Resizer (3-Tap), Lanczos Resizer(Vertical)+Linear Reizer(Horizontal)進行YUV 4:2:0->YUV 4:4:4, 用10-bit RGB with Color Management輸出等。 由於找不到方法令MadVR輸出10-bit RGB with Color Management, 因此畫質算是比MadVR高。 還有ffdshow有個問題是只能夠用Single Thread進行Resize, 因此Latency過高而不能輸出60fps。
__________________
我寫的程式: HQMP (2005/09/04): http://sswroom.no-ip.org:5080/compprog/smp/hqmp.html AVIRead 0.927 (2006/01/28): http://sswroom.no-ip.org:5080/compp...read/index.html SMP (04/09/02): http://sswroom.no-ip.org:5080/compprog/smp/index.html Subtitle Editor 0.6 (05/01/23): http://sswroom.no-ip.org:5080/compp...edit/index.html ADX Decoder Directshow Filter 0.61: http://sswroom.no-ip.org:5080/compp...xdec/index.html PSSADPCM Directshow Filter 0.61: http://sswroom.no-ip.org:5080/compp...dpcm/index.html XA Filter 0.61: http://sswroom.no-ip.org:5080/compp...lter/index.html |
|
![]() |
![]() |
Master Member
![]() ![]() ![]() ![]() 加入日期: Sep 2003
文章: 1,810
|
> 像我用的方式主要是依賴ffmpeg
> 理論上靠ffplay(或者跟ffmpeg 淵源很深厚的mplayer) 可以實做部份過程 ...我是再說最近這一串我試著用的方式 可以有部份被重現 硬把他塞成 這一串從頭到尾所有的都可以被重現那是你的問題 另外就像上面說的,可以單獨用CPU 也有使用opencl 的方式 (不過依舊是不限廠牌的GPU 只要有支援opencl) 像是我使用的 chroma sharp 就可以(不是很需要就是了) 一定要搞成看影片 要依賴GPU 內建的filter? 基本上GPU 內建的filter 我能不用就不用,雖然很少人發現但他有規格限制 這個限制下會導致一些可能發生的問題 譬如:filter 不能被使用、filter的使用干涉了原本採取的處理措施 此文章於 2015-10-11 05:37 AM 被 orakim 編輯. |
![]() |
![]() |
Regular Member
![]() ![]() 加入日期: Jun 2010
文章: 75
|
>硬把他塞成 這一串從頭到尾所有的都可以被重現那是你的問題
"只能實作部分過程"、"只能用 CPU 處理" 意思不就是你的濾鏡跟 madVR/AMD 相比並不是成熟的方案? 語氣也不用這麼酸,我是在好好請教你有什麼更好的方法 對我來說 Chroma Subsampling 4:2:0 並不是什麼大問題 我平常是用 Sony 55吋接 HTPC 把 mode 調成 4:4:4 跟 4:2:0 差別我看不太出來 但是 Sony TV 只要調成 4:4:4 很多後處理功能都不能用了 下一代4K BD 規格把10bit, BT.2020, 60FPS 都納入了標準,但色取樣依然維持 4:2:0 可見得連 BDA 官方都覺得色取樣重要性遠不如色階和影格數這些明顯可見的差別 4:2:0 大概會維持下一個十年 另外我的看法跟你相反,能讓顯卡去做的盡量丟給顯卡實作 madVR 的開發理念也是如此,因為效率跟 CPU 差太多了 家中五台桌上型電腦就是沒一台 i7,我的 U 效能還沒高到能同時處理升頻、補幀、解碼這些有的沒的 現在就等 AMD 下一代 400 series 納入10bit硬解,完美影音卡就此誕生 最好 CPU 在播放時維持極低的使用率,其它全給顯卡處理
__________________
![]() |
![]() |
![]() |
Master Member
![]() ![]() ![]() ![]() 加入日期: Sep 2003
文章: 1,810
|
所以我也好好回答你了啊
你有在其他地方看過有人這麼仔細回文的嗎 建議你下次文看清楚一點,都寫的這麼明了 想想看如果你碰到一個人 總是忽略你自己的說法,把他往想要的地方扭曲你會有什麼感覺 而這就是我對你的感覺 > 意思不就是你的濾鏡跟 madVR/AMD 相比並不是成熟的方案? 意思是我使用的方式跟AMD無關 沒錯以上這一點你至少之前在兩個post以上 都看得到 另外大部分filter 你可以在mplayer、ffplay 找到其他解 而我只針對想用的用了一兩個下去使用,只用想用的 就叫做不成熟...這也太誇張了吧 如果真的要比哪個不成熟,我會說是AMD(NV、intel 應該也是類似的狀況) 理由上面也說過了 也就是硬體的東西 規格被寫死 導致應用彈性不足,而這些大部分不太需要由GPU接手 CPU就可以做了 唯一的一點會有差的地方大概就是motion blur 是有SVP的存在 但是他不能在mplayer、ffplay 下使用 SVP雖然有計畫要在mpv上推出他的版本,但目前的確沒有 而AMD的fluid motion也有規格限制 特定狀況下不能使用,但是SVP卻可以 要再說清楚的話,我試過硬體fliter(如AMD)的是全滅,不只fluid motion 一個 而播放影片要往好的方向鑽,那最終就會碰到硬體fliter 不能使用的狀況 > madVR 的開發理念也是如此,因為效率跟 CPU 差太多了 這個跟我說的是兩回事,我也有用opencl啊 我是說直接寫死在硬體的filter 跟opencl 是兩回事 此文章於 2015-10-11 09:53 AM 被 orakim 編輯. |
![]() |
![]() |
*停權中*
加入日期: Oct 2015
文章: 3
|
繼續支持N 因為驅動寫得比較好
![]() |
![]() |
![]() |
Master Member
![]() ![]() ![]() ![]() 加入日期: Jun 2002
文章: 2,332
|
![]() 引用:
MadVR本身的對應色彩管理3D LUT是用直接Mapping的導致它精度就8bit... 所以你要的"10-bit RGB with Color Management"已經超過它的能力範圍, 對於同樣要求色彩正確而非好看的情況下,目前的確是CPU硬上為最佳解.
__________________
Es muss sein! |
|
![]() |
![]() |