PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   顯示卡討論區 (https://www.pcdvd.com.tw/forumdisplay.php?f=8)
-   -   如果GTX470跟GTX460價格接近的話.. 你會選哪一張? (https://www.pcdvd.com.tw/showthread.php?t=899791)

siis 2010-07-16 03:36 PM

引用:
作者u3350829
雖然在下有開發CUDA相關的軟體...不過老實說,在目前用CUDA
去跑Video轉檔這塊實用性很低,除非您能接受差很多的畫質或者
慢到幾乎快跟CPU轉檔一樣快的速度,movie editor也好不到哪去
效果平平(一些特殊處理除外)...
基本上這個問題在沒有重新針對CUDA這類平行運算研發新的影音
壓縮格式/技術之前是很難加以克服的,畢竟平行運算/處理不是萬
靈丹很多東西還是有先天限制,現階段除了科學/數學運算外還是
別對CUDA有太多幻想.


這個我就不太懂了, 改成平行運算為什麼會影響畫質? 應該是跟編解碼演算法有關不是嗎? 一些軟體如adobe premiere pro, sony vegas, avid Media Composer 等都支援 cuda. apple mac 全系列都是 nvidia 晶片, 跑 FCP 都比前順多了~~ 有些轉檔軟體(如 xilisoft) 號稱轉檔速度加快了 4,5 倍

如果單使用 CPU power 去轉檔/編輯 HD files, 真的很慢. 如果 cuda 真的不實用的話, 不曉得有什麼好方法 ?

山寨主 2010-07-16 04:01 PM

引用:
作者siis
這個我就不太懂了, 改成平行運算為什麼會影響畫質? 應該是跟編解碼演算法有關不是嗎? 一些軟體如adobe premiere pro, sony vegas, avid Media Composer 等都支援 cuda. apple mac 全系列都是 nvidia 晶片, 跑 FCP 都比前順多了~~ 有些轉檔軟體(如 xilisoft) 號稱轉檔速度加快了 4,5 倍

如果單使用 CPU power 去轉檔/編輯 HD files, 真的很慢. 如果 cuda 真的不實用的話, 不曉得有什麼好方法 ?



因為你想的太美好了
CUDA算法 都需要重新寫過
重寫 是會有bug的
寫這種東西 一句話就是bug滿天飛 一個轉碼器 有1000個以上的bug並不奇怪

cpu的解碼器 幾乎都是10年以上的除錯累積 才有目前的成果
CUDA+平行處理開發難度 是用傳統用cpu撰寫難度30倍以上
也就是說 相同人力下大約還需要50年以上 才能有穩定的轉碼畫質

scapegoat 2010-07-16 04:24 PM

50年咧... :jolin:
想知道怎麼得來的數據.
前幾天, 剛好試過對岸CUDA版的轉影音軟件
http://cuda.broadintel.com/
內有英文版.

引用:
作者山寨主
因為你想的太美好了
CUDA算法 都需要重新寫過
重寫 是會有bug的
寫這種東西 一句話就是bug滿天飛 一個轉碼器 有1000個以上的bug並不奇怪

cpu的解碼器 幾乎都是10年以上的除錯累積 才有目前的成果
CUDA+平行處理開發難度 是用傳統用cpu撰寫難度30倍以上
也就是說 相同人力下大約還需要50年以上 才能有穩定的轉碼畫質

u3350829 2010-07-17 12:11 AM

引用:
作者scapegoat
50年咧... :jolin:
想知道怎麼得來的數據.
前幾天, 剛好試過對岸CUDA版的轉影音軟件
http://cuda.broadintel.com/
內有英文版.


這東西在下是不知道是不是山寨版....Orz
原本的MediaCoder是完全不用錢而且已經很久了:
[url]http://www.mediacoderhq.com[\url]
至於CUDA支援轉檔也算還可以,只是實際上使用和轉出來的東西
麻煩您自己親自比較過後再來說吧! 很多地雷其實很先進都已經踩
過也把經驗po出來了....

Adsmt 2010-07-17 01:14 AM

引用:
作者山寨主
因為你想的太美好了
CUDA算法 都需要重新寫過
重寫 是會有bug的
寫這種東西 一句話就是bug滿天飛 一個轉碼器 有1000個以上的bug並不奇怪

cpu的解碼器 幾乎都是10年以上的除錯累積 才有目前的成果
CUDA+平行處理開發難度 是用傳統用cpu撰寫難度30倍以上
也就是說 相同人力下大約還需要50年以上 才能有穩定的轉碼畫質

寫程式是很簡單的,軟體編碼器十年來一直在發展,那是因為一直在增加功能上的完整性。並不是因為有什麼 bug.

編碼器最困難的地方在「演算法」,想出怎樣才能達到最好的效果,需要很複雜的數學推導和無數的實驗,但要數學式子化成程式,其實是很簡單的事。

以我的碩士論文來說,我推導幾個月的式子,寫成程式只需要一、兩個禮拜。然後執行實驗測試,需要三個禮拜。

所以「寫程式」是最簡單,最不花時間的步驟。

所以為什麼寫程式會餓死呢?因為這本來就是很簡單的東西。 :think:

如果以 X.264 這種幾 MB 的程式,會寫到有除不完的 bug, 那作者也未免太弱了(而且人家演算法和數學公式都幫他寫好了)。:jolin:

同理,CUDA 硬體編碼也絕對不是因為有什麼 bug 才畫質不好,而是因為「支援度」不夠完整,

你如果用過 CUDA Encoder 就知道,它根本沒什麼參數可以調整,只有幾個弱弱的 preset, 和 X.264 比起來就跟天與地的差別一般。

但如果同壓縮時間和同流量下,CUDA Encoder 還是可以電爆 X.264.

再來 CUDA 也不是完全沒用,事實上不用它來壓縮,也可以用它來解碼。軟解至少要耗 20~30% 的 CPU, 如果使用硬解,這些多出來的資源就可以給軟體編碼器使用了。這也是為什麼 TMPGEnc 編碼會純軟體編碼程式稍快一點的關係。

bebo1210 2010-07-17 09:41 PM

根據DGDecNV/AVC/MPG/VC1 Decoder and Frame Server
作者表示,cuda的解碼速度與時脈和記憶體有關。(在哪頁忘了,應是這個月提到的)
http://neuron2.net/dgdecnv/dgdecnv.html
http://forum.doom9.org/showthread.php?t=147945
依個人使用心得,使用cuda解碼再用x264編碼的速度,較之directshow解碼與x264編碼,前者在megui為one pass/35fps,two pass/14fps,後者為one pass/8fps,two pass/8fps。(環境:vistax64/i7920/8gram/gts250)
若作者所言屬實,則460的效能在cuda的表現與250其實不遠。(比較兩者的硬體條件)

s30zx2000 2010-07-18 08:38 PM

我個人比較煩惱的到是另一個問題

N460GTX 1GB & N465GTX 1GB(黃金版)

這兩張兩張哪個比較划算,實際來說兩張的價差,在散熱片用料上剛好補足

理論上買N465GTX,因為可刷470,但不知為何還是很猶豫...OTL

大貓貓 2010-07-18 09:08 PM

引用:
作者s30zx2000
我個人比較煩惱的到是另一個問題

N460GTX 1GB & N465GTX 1GB(黃金版)

這兩張兩張哪個比較划算,實際來說兩張的價差,在散熱片用料上剛好補足

理論上買N465GTX,因為可刷470,但不知為何還是很猶豫...OTL


至少不用像我一樣搞散熱搞到哭杯=3=

u3350829 2010-07-18 09:10 PM

引用:
作者Adsmt
43...
你如果用過 CUDA Encoder 就知道,它根本沒什麼參數可以調整,只有幾個弱弱的 preset, 和 X.264 比起來就跟天與地的差別一般。

但如果同壓縮時間和同流量下,CUDA Encoder 還是可以電爆 X.264.

再來 CUDA 也不是完全沒用,事實上不用它來壓縮,也可以用它來解碼。軟解至少要耗 20~30% 的 CPU, 如果使用硬解,這些多出來的資源就可以給軟體編碼器使用了。這也是為什麼 TMPGEnc 編碼會純軟體編碼程式稍快一點的關係。

用CUDA去做encode目前除了那些細部參數和present外,和CPU做encode最大的
差別點在於filter...很多和畫質相關的filter都需要插在encode過程中,而CUDA這
種平行運算是不能夠這樣做的,天生的問題無解,另TMPGEnc是反過來只有Filter
用CUDA這不能比較,所以才會說需要重新為平行運算架構新的codec才能克服...
以現在的情況來看同時間同流量做H.264 encode真要比畫質掛上Filter那CUDA保
證是完敗Orz.

至於寫程式最簡單這點是離題太多不多說,只是會說寫程式最簡單代表的是接觸的
coding不夠多啊! 有很多東西有原理有規劃有照樣是寫不出來...Orz

weirock 2010-07-18 10:22 PM

引用:
作者大貓貓
至少不用像我一樣搞散熱搞到哭杯=3=


賣掉換460也行哦XDDD


所有的時間均為GMT +8。 現在的時間是11:09 PM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。