PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   顯示卡討論區 (https://www.pcdvd.com.tw/forumdisplay.php?f=8)
-   -   請教是何故,同一FullHD影片,Kmplayer/PotPlayer用單核心運算,但mediaplayer classic能平均分配4核心運算? (https://www.pcdvd.com.tw/showthread.php?t=898739)

bonoc 2010-07-02 09:30 PM

請教是何故,同一FullHD影片,Kmplayer/PotPlayer用單核心運算,但mediaplayer classic能平均分配4核心運算?
 
硬體:同簽名檔上網機

CPU:I7 920 2.66Ghz未超

實驗影片:太空戰士7 AC 40GB mkv

以Kmplayer、PotPlayer、mediaplayer classic播放

Kmplayer、PotPlayer都只使用單核心運算,使用率高達9X%
在片尾高速公路漂亮風景的片段,會頓,不順暢

但用k-lite內建的mediaplayer classic播,

可發現平均地使用4核心,使用率都平穩的落在20~25%

播放效果十分順暢

想請教達人

會有這種差異是(1.播放軟體本身對多核心的支援度(2.播放軟體使用的解碼器支援多核與否

假如是(2,是否可藉由指定/更換解碼器,使Kmplayer、PotPlayer播放影片支援多核心?

orakim 2010-07-02 09:50 PM

關鍵字
ffdshow-mt
其他的問Google比較快

bonoc 2010-07-02 10:20 PM

引用:
作者orakim
關鍵字
ffdshow-mt
其他的問Google比較快

小弟有找到這段:
===============================================
ef第一季,全12集含评论音轨,附带所有特典

ef的BD画面非常锐利,和bandai visual那些模糊的片子一对比就更明显了。

但也有一个致命的弱点,暗处的banding非常严重。对比图见发布内的截图

因此,为了达到理想的播放效果,在CPU允许的情况下,推荐使用ffdshow的DeBand滤镜进行回放
为什么要说CPU允许,因为在渲染器前加其他滤镜的话,就不能DXVA硬解了,而且DeBand滤镜是单线的,处理高分辨率的负担也较高。两个加起来,较弱的CPU可能就要吃瘪了

负担较轻的设置:CoreAVC1.9以上开启CUDA硬解+ffdshow

单一解决方案:ffdshow-mt


========================================
雖然看不大懂

但推測與使用的濾鏡有關

似乎濾鏡有分支援多線程與否的差異...

先前有試著安裝mega k-Lite,再從potplayer中調整使用的濾鏡

但不曉得是沒調成功,沒調對,仍然使用單核心在運算,

才有此問

謝謝大大賜教^^

vxr 2010-07-02 11:01 PM

簡言之..
完全是設定上的問題..

u3350829 2010-07-02 11:25 PM

基本上這問題跟player程式本身無關,除非您開了一堆Filter(絕大多數都是單
Thread),主要問題在您的H.264/AVC1 decoder上面,免錢好找的目前就是
ffdshow的Multi-thread版本,要錢的就Power DVD 9的H.264/AVC1 decoder
,但是以要錢的版本來說您的情況在下會比較推薦使用CoreAVC,畢竟GTX210
本身可以支援CoreAVC加速而且效果不錯,即便是原版BD且流量爆高也不用
擔心會不順:)

不過在下好奇的是FF7 AC原版BD來說,在下用未超的Q9450+potplayer原始
設定去播放(沒開硬解)整片都很順,用上I7 920反而會不順倒是第一次聽到...

iorittn 2010-07-03 08:56 AM

Kmplayer改用ffdshow做軟解輸出試試
k-lite的cpu使用率不高是它的mpc預設就有開硬解

bonoc 2010-07-03 08:57 PM

引用:
作者iorittn
Kmplayer改用ffdshow做軟解輸出試試
k-lite的cpu使用率不高是它的mpc預設就有開硬解

感謝您

雖然小弟還是不大清楚怎麼做,從何設定起,但剛用POTEPlayer找了個片段頡取資訊

視訊編碼:AVC1
輸入格式AVC1(0bits)
輸出格式YUY2(16bits)
標準FPS:23.98
目前FPS:23.62
位元率:41261.5kbps
輸入大小:1920x1080(1.78:1)
輸出大小:1920x1134(1.69:1)

[音訊資訊]
音訊編碼: Dolby AC3(0x2000)
採樣率: 48000 -> 48000 樣本/秒
取樣率: 0 -> 16 位元/樣本
聲道數: 6 -> 2 聲道
Bitrate: 640 kbps

[濾鏡使用清單]
(1) MPEG2 TS Source
(2) Video Codec/Transform
(3) Overlay Mixer
(4) Audio Codec/Transform
(5) DirectSound Audio Renderer
(6) Video Renderer


這個片段可以讓我的I7其中一個執行緒100%滿載,其它7執行緒躺平...orz

由於該片段是由直升機高空攝影風景,有大量的草木,砂石,道路,複雜的畫面構成
加上全景不斷移動+旋轉,使得流量始終在40MB上下,到了這段就不是很順
但在正片中,流量都在2~30MB左右時,是很順暢的


另比較了:39.3GB的變型金鋼2,在片尾最複雜的吸塵器大魔王片段,流量37084.3kbps
單執行緒使用率也不過才80%~非常順暢

[視訊資訊]
視訊編碼: AVC1
輸入格式: AVC1(0 bits)
輸入大小: 1920 x 1080(1.78:1)
輸出格式: YUY2(16 bits)
輸出大小: 1920 x 1080(1.78:1)
幀率: 23.98
BitRate: 37084.3kbps

[濾鏡使用清單]
(1) MPEG2 TS Source
(2) Video Codec/Transform
(3) Overlay Mixer
(4) Audio Codec/Transform
(5) DirectSound Audio Renderer
(6) Video Renderer



[音訊資訊]
音訊編碼: DTS(0x2001)
採樣率: 48000 -> 48000 樣本/秒
取樣率: 0 -> 16 位元/樣本
聲道數: 6 -> 2 聲道
Bitrate: 1509 kbps



再來試30.2GB的新世紀福音戰士m2ts檔

一樣是使用單執行緒在運作

在流量42MB時,CPU使用率同樣接近滿載

[視訊資訊]
視訊編碼: AVC1
輸入格式: AVC1(0 bits)
輸入大小: 1920 x 1080(1.78:1)
輸出格式: YUY2(16 bits)
輸出大小: 1920 x 1134(1.69:1)
幀率: 23.98
BitRate: 42737.9kbps

[濾鏡使用清單]
(1) MPEG2 TS Source
(2) Video Codec/Transform
(3) Overlay Mixer
(4) Audio Codec/Transform
(5) DirectSound Audio Renderer
(6) Video Renderer

[音訊資訊]
音訊編碼: DTS(0x2001)
採樣率: 48000 -> 48000 樣本/秒
取樣率: 0 -> 16 位元/樣本
聲道數: 6 -> 2 聲道
Bitrate: 1509 kbps


=========================================
另試播10.9GB的暮光之城2

流量平均在10~20MB左右,CPU使用率也等比例的落在50%上下

[視訊資訊]
視訊編碼: AVC1
輸入格式: AVC1(24 bits)
輸入大小: 1920 x 800(2.40:1)
輸出格式: YUY2(16 bits)
輸出大小: 1920 x 840(2.29:1)
幀率: 23.98
BitRate: 12601.6kbps


[濾鏡使用清單]
(1) MKV Source
(2) Video Codec/Transform
(3) Video Renderer
(4) Audio Codec/Transform
(5) DirectSound Audio Renderer


[音訊資訊]
音訊編碼: DTS(0x2001)
採樣率: 48000 -> 48000 樣本/秒
取樣率: 0 -> 16 位元/樣本
聲道數: 6 -> 2 聲道
Bitrate: 0 kbps


================================
除了AVC編碼,H264編碼情況相同,POTEPlayer都是用單執行緒在運算

但...以上影片用mediaplayer classic HD播...

是分配給8執行緒運算....使用率都只有個位數到1x%..


所有的時間均為GMT +8。 現在的時間是01:41 AM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。