您也知道轉檔這東西靠的就是硬體的運算速度啊
試試心理作用吧
不然找個時間測試超頻穩定度吧
工作完畢再降回來
如果無法超頻
那就只好心理作用吧

鵝就知道有人會這麼說 ....看樣子除了砸$$好像也沒有更好的法子了....BTW,鵝想試試在64bit下會不會好一點(64bit應付吃記憶體兇的AP比較吃香,不知道轉檔算不算),不過因為鵝平常用的linux distribution沒有把multimedia相關的library包進來,要DIY好像不是小case就是了....

試著用不一樣的壓縮軟體....

鵝很少跑Windows(所以也不熟Win中的AP),平時大概都是在linux/XWin下跑VLC或ffmpeg/transcode/x264,不過網路上包好的package沒有X86-64版本而且好像也不支援multi thread(沒辦法完全榨乾兩個core,一顆有100%,另一棵只有3-40%,看來鵝非DIY不可了),而在Win32下VLC開超過4GB的VOB檔轉檔時有點問題(NTFS,非FAT32的問題,BTW,播放時時間顯示有問題,但畫面顯示正常),不知這樣跑起來(1:1)還算正常嗎 ....

你提到的CPU使用率的問題 是軟體設計的問題 至少在XviD上是如此

我猜你用ffmpeg/x264應該是有用到 AVISynth 假如是這樣了話 那有一個核心會被AVISynth給佔了 另一個被ffmpeg/x264.exe使用 而ffmpeg/x264.exe需要的運算比較多 所以才會有這種現象
這在XviD 1.1.2 (XviD 1.1.2 不支援多核心) 上也會出現這樣的情況

我記得x264.exe支援multicore/multithread. 用 megui 設定應該會讓你看的到參數如何設定

Athlon64 X2 似乎在兩個核心之間交換更改過的資料 都要先把資料寫入記憶體 不能直接由另一個核心的快取記憶體讀出來 因此比較浪費時間 因此CPU會在等資料的時候休息. 這個就看的出來 在我的電腦上DVD轉XviD在 first pass建立記錄檔的時候可以看到兩個核心都有9x%的使用率 但是無法長時間留在100%

其實 要榨乾雙核心或是多核心的處理能力還有另一個方法 就是同時轉多個檔案 有幾個核心就同時轉幾個檔案 這樣 所有的核心都同時被使用 都可以到100%使用率 也可以盡量避免在不同核心之間進行資料交換 這在AMD 多CPU (K8) 的機器上應該特別有用 因為每個CPU都有自己的記憶體控制器, 都有自己的主記憶體

Intel Core2 Duo因為每個處理器要共享記憶體頻寬 這個方法所帶來的效能增進應該比較小

但是 用這個方法要注意的一點就是 每一份轉檔程式的記錄檔 (state file) 要分開 要不然程式會當掉

雙核處理器資料交換效率: http://www.xbitlabs.com/articles/cp...r-analysis.html

上面所提到的方法 我現在正在使用中 輸出效率增加20% - 80% 端看CPU核心花多少時間在AVISynth 以及x264/XviD的運算上

而你上面提到的 CPU 使用率 有一個核心到不了100% 那個問題 因為是軟體的問題 因此 即使換了Intel Core2 Duo 應該也一樣

我的Athlon64 X2 3800+ (90nm, DDR supporting) 在做XviD + AVISynth轉單一vob檔 First Pass 進行建立記錄檔的時候 兩個核心都可以到9x%使用率, 但是在Second Pass, 其中一個核心的使用率就跑到100%, 另一個就只剩3x%. 那個100%的核心應該是被XviD給佔了 另一個核心應該是用來執行AVISynth

用x264轉檔 時間比1:1 在Athlon64 X2 3800+上應該是正常的 但是看你怎麼設定

不過鵝平常都是跑linux/XWindow居多,看來鵝非拿Windows試試了....



您提的這點應該是舊PD的狀況(A社還以此批評I社是"假"雙核過),鵝印象中X2系列inter core communication是透過on die SRU/CrossBAR進行的(請參考附檔,節自AMD Processor Performance Evaluation Guide,BTW,A社多CPU的場合是透過hypertransport互聯的),至於C2D應該是透過shared L2/cache snoop進行的,不過鵝的經驗/專長算是偏資管/資工方面而非資科方面,說的不一定完全正確就是了,至於您提的"兩個核心都有9x%的使用率 但是無法長時間留在100%"或許不見得是CPU的問題,有可能真的是資料相依性造成一個core非得停下來等另一個core不可----畢竟不是每件事都能multi process/multi thread的 ....



鵝也想過這麼搞,不過這麼搞時各個source/destination的HD最好完全分開(i.e.同時轉兩個檔就須要四棵HD),才能降低HD seek帶來的影響(免得得不償失),實在是有點麻煩,看來鵝還是想辦法在X86-64中DIY一個support multi thread的ffmpeg/transcode/x264試試好了....

雖然Intel 跟AMD 都說他們的CPU有在他們的產品裡面做了讓兩個核心交換資料的技術 但是上面我提供的那篇文章裡面的測試結果顯示的似乎完全是另一回事....

至於你擔心資料搜尋的問題 其實 以MPEG2的資料流量來說 每秒大約2 - 8Mbps 也就是250KBps - 1MBps (bit to byte conversion).以3X速度做壓縮 電腦在壓縮每一部電影時會從硬碟讀取資料 而資料流量就是3x 原先MPEG2的資料流量, 所以每秒電腦會從硬碟讀取750Kbyte - 3Mbyte. 現在硬碟的讀取速度很快 這樣的資料流量 對它來講很輕鬆 多來幾個也不會喘不過氣. 更何況硬碟有自己的快取記憶體 影音壓縮軟體也都有內建的緩衝 可以一次讀取較多的資料來減少搜尋

沒考慮mencoder?
常聽到超過1:1的時間
大概參數太低檔了,我都可以跑1/8的時間
參數拿來見識一下