davis0725 wrote:
i7-3612qm 只是顆低電壓的筆電CPU
雖然有4C8T，但效能沒你想像中那麼快（雖然網站顯示與測試軟體數據差距超大）
但實際使用CPU轉檔的時候，...(恕刪)
請用Quick Sync Video功能，轉檔便會有感，可用免錢的Media Coder或是Handbrake Nightly Build。
我現在就是用3612QM這顆，可軟轉，可硬轉，但是以硬轉居多，省時兼轉檔時電腦可續用不頓呆，那些軟轉/硬轉品質云云，除非心裡潔癖，一般消費者的應用不需在意。
我也常用WiDi把NAS的1080p影片從筆電無線播放到65"的電視上觀看，WiDi的傳輸過程中也會用到Quick Sync Video硬體去壓縮WiDi程式本身所捕捉的Windows桌面成為視訊串流，再透過WiFi Direct的無線頻寬傳輸（手機/平板的Miracast功能也是運用到手機SoC的H.264硬壓功能，然後將壓縮後的畫面透過WiFi Direct傳輸），就我以自家家人進行測試，沒人感覺到WiDi方式跟DLNA[註]播放方式有差異。
[註]DLNA是原檔直接串流後在本地端播放，因此少了畫面捕捉/重壓縮過程的可能品質差異。
wizardry91 wrote:
Q8400換Q955...(恕刪)
謝謝～
已決定暫時繼續撐著點用
Edkang wrote:
如果是64位元的作業系統...
系統牒改SSD....與增加記憶體會比較有感...
Q8400換Q9550 還是會有差的...
大概就是90C.C摩托車換成100C.C的感覺...
五年來一直是64為元作業系統+16G記憶體DDR3-1333
硬碟則一直是RAID 0 + RAID 1
當初是因為一跑分析或是轉檔就是CPU滿載才會考慮
Whistle Blow wrote:
請用Quick Sync Video功能，轉檔便會有感，可用免錢的Media Coder或是Handbrake Nightly Build。
我現在就是用3612QM這顆，可軟轉，可硬轉，但是以硬轉居多，省時兼轉檔時電腦可續用不頓呆，那些軟轉/硬轉品質云云，除非心裡潔癖，一般消費者的應用不需在意。
謝謝告知，從用兩年前2370m時就有用了
（順便說一下當時也發現3612qm 用QSV轉檔會比2370m慢一點，原因是因為顯示晶片頻率較低）
優缺點也都有發現～
至於轉檔品質確實有差，差距是 一眼即可看出
forumstartw wrote:
3630QM 的話
4C8T 你的Q9550 也要超到 3.8G 才有勝算啊
可是耗電...
不好意思，我只有3612qm這顆低耗電的（滿載2.1～2.8G）
之前跑全滿載4小時下來好像也只快沒多少
溫度倒是多了30度以上
筆電雖沒降頻還turbo 在2.8G，但看到幾乎要破百溫度真的會嚇到
（雖說是後更新加改善有降一點，但一連滿載4小時下來還是90度上下飄）而Q8400之前超到3.2G(400*8，正確除頻)其實跟低電壓的3612qm 相當，又不用改散熱(滿載60度上下）
所以才會考慮桌機升Q9550來超（但現在放棄了，確實如你所提的耗電，而且過保的主機板哪天掛也不知道）
davis0725 wrote:
不好意思
可能我的電眼太敏感了吧
（20年前在竹科修掃描器時，要用肉眼在最短的時間內去找影像中的瑕疵，大概是這樣養成我對影像的敏感度很高吧）
總歸一句，某些情況下轉出來真的讓我不是很滿意...(恕刪)
不過您還是沒有提到所用的轉檔程式跟參數，下面是針對MediaCoder的QSV設定建議：
https://obsproject.com/forum/threads/need-more-options-for-quick-sync-quality-for-streaming.12709/
我是搞視訊壓縮/解壓縮演算法的，念茲在茲的就是Motione Estimation快速演算法精確度/最佳化、PSNR/SSIM壓縮前/壓縮後品質比較、bit rate分配/控制這些.....舉個例子，快速移動場景是最難壓縮的，因此碰到這種場景，bit rate分配習慣上應該要拉高，但某些快速移動場景在視覺上一閃即逝，另一種說法是既然如此，bit rate不用分配太多，把bit rate留給靜態對話或是較長的重要場景。
若在bit rate有限的情況下，哪一種邏輯對？如果被抓出來跟原檔比較的剛好是快速移動場景？跟單張的掃描器圖像相比，瑕疵較容易定義，但在由動輒幾萬張畫面構成的一段視訊的全域觀點上上，這問題卻沒有絕對的答案....好萊塢用母帶過帶輸出藍光發行版本跟DVD版本時，是一小段一小段下去調整壓縮bit rate、然後再前後段參酌觀看分配調整，當然，消費者轉檔不用這麼苦命。
內文搜尋
從 APP 打開
X