MP 1.3.x dshowhelper development (1 Viewer)
- Thread starter Owlsroost
- Start date
- November 7, 2007
- 166
- 41
- Home Country
-
Germany
Thanks for the new version.
Could you please give us a short explanation on those DWM Buffers and what a higher value than 3 might achieve? Do more buffers introduce and/or increase a delay between video and audio?
Thanks!
Could you please give us a short explanation on those DWM Buffers and what a higher value than 3 might achieve? Do more buffers introduce and/or increase a delay between video and audio?
Thanks!
- Thread starter
- #24
Basically, DWM = Desktop Window Manager = Aero.
It operates in two modes - the default mode where there is no 'presentation' queue (of rendered video/graphics frames, coming from MP in our case) or the optional mode with the presentation queue enabled. The queue length is set by the 'NumDWMBuffers' reg value, and this queue of frame buffers is between MP and the screen.
In theory more buffers might help to avoid dropped frames after MP (which won't show up in the render stats), but I've never noticed much difference in performance between 3 and larger amounts (3 has always been the default). Also more buffers use up more GPU memory.
Because the queue is after dshowhelper (where the video part of A/V sync is controlled), as far as I know it creates a delay to the video of (queue length * display frame time) i.e. the longer the queue the greater the delay.
Hope that helps
Tony
It operates in two modes - the default mode where there is no 'presentation' queue (of rendered video/graphics frames, coming from MP in our case) or the optional mode with the presentation queue enabled. The queue length is set by the 'NumDWMBuffers' reg value, and this queue of frame buffers is between MP and the screen.
In theory more buffers might help to avoid dropped frames after MP (which won't show up in the render stats), but I've never noticed much difference in performance between 3 and larger amounts (3 has always been the default). Also more buffers use up more GPU memory.
Because the queue is after dshowhelper (where the video part of A/V sync is controlled), as far as I know it creates a delay to the video of (queue length * display frame time) i.e. the longer the queue the greater the delay.
Hope that helps
Tony
666 version: I do see a change in the render stats. ??
Watching a 720p/60 signal with 3 buffers, I get about 1 drop per second, maybe a little more. With 7 buffers, I get about 1 drop per 10 seconds. I've tried to determine what windows process is running on such a schedule, but couldn't find any. If I raise the priority of MP and TVserver to "real-time," the drops go away in either case. (I normally run TVserver "above normal" and MP "high" without much reason.)
Watching a 720p/60 signal with 3 buffers, I get about 1 drop per second, maybe a little more. With 7 buffers, I get about 1 drop per 10 seconds. I've tried to determine what windows process is running on such a schedule, but couldn't find any. If I raise the priority of MP and TVserver to "real-time," the drops go away in either case. (I normally run TVserver "above normal" and MP "high" without much reason.)
- Thread starter
- #27
You could try setting the 'EnableMMCSSforSchedulerThread' and/or 'EnableMMCSSforDWM' registry settings to '1' (I suggest you try all the combinations).
MMCSS = Multimedia Class Scheduler Service - 'EnableMMCSSforDWM' (when '1') puts the DWM system under it's control, 'EnableMMCSSforSchedulerThread' (when '1') puts the dshowhelper presentation timing thread under it's control.
Tony
Hi Owlsroost.
What will basically be the result of this development?
6 months ago I bought a Zotac AD10 with an AMD E-350 fusion processor, hoping this could be sufficient for the next couple of years.
Playback of 1080P MKV works flawlessly, but 1080P HDTV seems to have many dropped frames and even MePo seems to have low framerate, when TV is windowed.
I don't hope 1.3 will require further CPU/GPU ressources - Because when comparing MePo against XBMC, then XBMC seems to advance on this area. Right now we see XBMC running of a raspberry Pi - even with PVR over Tvheadend - So is MePo a ressource hog?
/Morten
What will basically be the result of this development?
- Increased Stability
- Smoother playback - Less dropped frames in video/TV playback and/or MePo skin?
- What effects will this have on CPU/GPU usage? (Pro and cons?)
- Better playback handling between Server/Client? (Especially for wireless setups)
6 months ago I bought a Zotac AD10 with an AMD E-350 fusion processor, hoping this could be sufficient for the next couple of years.
Playback of 1080P MKV works flawlessly, but 1080P HDTV seems to have many dropped frames and even MePo seems to have low framerate, when TV is windowed.
I don't hope 1.3 will require further CPU/GPU ressources - Because when comparing MePo against XBMC, then XBMC seems to advance on this area. Right now we see XBMC running of a raspberry Pi - even with PVR over Tvheadend - So is MePo a ressource hog?
/Morten
Last edited:
I enabled both MMCSS -- worse. About the same as 3 buffers and no MMCSS -- perhaps 150-200 drops in 10000 frames.
Enabled MMCSS Scheduler -- much better. 1 reported drop in 10000 frames. (7 buffers).
Enabled MMCSS DWM -- very good. 5 reported drops in 10000 frames. (7 buffers).
As it was (with 7 buffers, neither MMCSS enabled) it was about 15-20 reported drops in 10000.
The actual display may have been drop-free in many cases if renderer can be late but buffering covers it up. I can't tell for sure, but the display is not noticeably interrupted when a single drop is reported. In every case, there is a burst of drops (just a few) as the channel starts. I have ignored these.
As soon as wife leaves (she hates debugging -- I love it), I'll try to lower buffers and see what happens, although the memory usage is not a problem here, I think.
Enabled MMCSS Scheduler -- much better. 1 reported drop in 10000 frames. (7 buffers).
Enabled MMCSS DWM -- very good. 5 reported drops in 10000 frames. (7 buffers).
As it was (with 7 buffers, neither MMCSS enabled) it was about 15-20 reported drops in 10000.
The actual display may have been drop-free in many cases if renderer can be late but buffering covers it up. I can't tell for sure, but the display is not noticeably interrupted when a single drop is reported. In every case, there is a burst of drops (just a few) as the channel starts. I have ignored these.
As soon as wife leaves (she hates debugging -- I love it), I'll try to lower buffers and see what happens, although the memory usage is not a problem here, I think.
Last edited:
- Thread starter
- #30
There is no particular target in mind - as it says in the first post, people have been requesting an MP 1.3.x compatible dshowhelper with DWM 'queued' mode support. While I was adding this, it seemed sensible to port across (from the other dev versions) some things which I think improve the performance in some circumstances, and also allow more user control of how it operates (via the registry settings).
As far as I know, GPU usage on 1.3.x should be the same as 1.2.x, but 1080i HDTV is the toughest thing for a GPU to handle (due to the HW deinterlacing load), so I'm not surprised you are getting dropped frames. The HD 5450 (basically the same architecture as the E350 GPU) I have in my work PC also struggles with 1080i content.
Tony
Last edited: