madVR v0.80
* added IVTC algo with decimation and support for 3:2, PAL and Anime cadences
* Ctrl+Alt+Shift+T switches between video (DXVA) and film (IVTC) content type
* fixed: moving media player to another monitor made DXVA deinterlacing crash
* fixed: DXVA deinterlacing produced wrong colors (only with HD videos + ATI)
* fixed: after a refresh rate change the composition rate didn't update
* fixed: calculation of consumed GPU RAM was wrong
* fixed: minimizing ZoomPlayer with playing video made some problems
* fixed: v0.79 didn't always detect external refresh rate changes
* fixed: some h264 AVI files made madVR crash, depending on the splitter
* fixed: improved internal decoder MPEG2 timestamp handling
* fixed: zooming video extremely small made madVR close the media player
* fixed: video was positioned wrong when media player cropped top/left
* fixed: a couple of small Direct3D related bugs
* fixed: a little resource leak
* improved presentation timestamp correction a bit
* improved "IMadVRExclusiveModeInfo::IsExclusiveModeActive"
* improved "IMadVRExclusiveModeControl::DisableExclusiveMode"
* added window size checks to detect to-be-expected exlusive mode failures
* added new interface "IMadVRDirect3D9Manager" for XBMC (work in progress)
* modified automatic queue sizes
* improved logging during media player shutdown
(1) As noted in the changelog, the software decoders are *experimental*. Because of that they are disabled by default. You need to enable them in the settings dialog before you can use them. Don't cry if they don't work as well as they should yet. I'm aware of several problems, occasional instability being one of them, bad timestamps being another, which can result in non-smooth playback, or delayed/dropped frames.
(2) The software decoders currently expect splitters to behave perfectly. If splitters don't, there might be some corrupted frames after a seek, or even at movie start. The Haali Media Splitter seems to work nicely. The LAV Splitter sometimes doesn't. I've notified nevcairiel about the problem. But of course in a future version I'll make the decoders more robust against non-optimal splitter behaviour.
(3) The libav/ffmpeg decoders support MPEG2 with both 4:2:0 and 4:2:2. They also support 8bit, 9bit and 10bit, 4:2:0 and 4:4:4 h264 decoding. Of course everything is decoded in full quality and passed to the madVR processing chain without any downconversion.
(4) There's no (zero, nada) support for deinterlacing at this point in time, so using the decoders for anything other than progressive content probably doesn't make much sense right now.
(5) While working on the decoders, I've found a nice trick to pre-buffer video frames. As a result madVR is now delaying playback start by up to 2 seconds (if necessary). Basically, at the start of movie playback and after every seek, madVR puts the player into paused mode, until all madVR queues are full. Only after that playback starts (at the latest after 2 seconds). The benefit of this approach is that there should be much less dropped/delayed frames at playback start and when seeking. If you don't like this new behaviour, you can turn it off in the settings, of course.
I'd like to get some feedback from you guys now. Do the decoders work as expected? E.g. can you find out and tell me which limitations the Intel decoders have exactly, so that I can switch to libav/ffmpeg on the fly, if necessary? Another question is whether the Intel decoders are worth shipping with madVR at all, anyway. Maybe the libav decoders are better in every way? But then the Intel VC-1 decoder can do interlaced decoding, I believe, which libav/ffmpeg can't do yet. However, for VC-1 interlaced decoding probably the MS VC-1 decoder is the best choice? I'm curious to hear your feedback.
P.S: You might be wondering why I'm adding video decoders to madVR now. There are several reasons for that. One is that I wanted to finally have high bitdepth and 4:2:2 and 4:4:4 decoding with full quality. There's at least one other reason I'm not ready to talk about yet. But I think you might be able to guess it...
最新版的3dlut,只能使用yCMS,但我用yCMS的时候,cpu占用率100%,ycms.exe占了50%的cpu,然后影片卡死并且 ...
doublestage 发表于 2010-6-7 03:20
To be honest, I'm disappointed with the special Aero rendering path. I was hoping to get a much higher performance (allowing higher scaling settings to be used) with noticeably higher reliability (less dropped/delayed frames). I was hoping that "Present" calls would never block, anymore, except if the Aero queues are full. But not so. Here's my impression of madVR's new "special Aero rendering path":
(1) slightly higher reliability, if GPU + Aero can handle the load
(2) maybe ever so slightly higher performance, but not much
(3) "Present" calls often unexpectedly block, which I don't understand
(4) there's no proper way to empty the queues, which results in artifacts when using trick play
Because of (4) the new rendering path is only an option right now, which is not even enabled by default. Please play with it and report your results. Thanks.
The new "use special Aero rendering path" option only shows effect after you've restarted your media player !!
欢迎光临 POPPUR爱换 (https://we.poppur.com/) | Powered by Discuz! X3.4 |