View Full Version : Media Player Classic Home Cinema (MPC-HC) - DXVA!
peek
5th September 2009, 19:46
Have a look at the "Filter" submenu during playback to see what's really loaded by MPC-HC. Or load the same video into graphstudio to find out what's going wrong. Third method: Use Process Explorer and open the properties page of MPC-HC there to watch the threads. Maybe you can upload a sample of one of these clips.
ADude
5th September 2009, 20:39
But yes, it's not about HD video decoding, it's about tearing. Somebody refuses to provide the info and graph screenshots that has been asked, so nothing can be done to possibly help and fix this until somebody decides he wants to be a team player, not someone that constantly refuses to do the simple things asked for.
It's amazing how fast a myth can be established in people's minds.
One person asked for a screenshot. That person is not a developer, and the things they asked for indicate that they do not understand the problem.
Currently, the number of developers replying or commenting about sync-related issues is zero.
The number of developers available to work on sync-related issues is zero.
Somehow, people decided that they want to blame me for not wanting to provide the wrong data, when there is no one interested or available to work on the issues.
This after a number of other people pointed out that they were clueless when they kept asking me to get a different graphics card. It is interesting that people are siding with the attackers, even after the attackers are proved clueless.
Perhaps you are desperate to attack someone, anyone ??
tetsuo55
5th September 2009, 20:57
Adude, i'm not sure what your problem is, but as you know very well i am the program manager (which boils down to vice-president).
Among other things, its my job to decide which bugs get fixed, most bugs get fixed at random voluntairily by our developers, however most bugs are not "fun to work on" getting these bugs fixed means focusing on something.
The problem you claim to have is one of the most important bugs being dealt with at the moment, several dev's are working on it.
However no-one is working on the exact symptoms you describe (because it works on 20+ dev systems and an unknown amount of beta tester systems)
All bugs related to your problems can only be dealt with through CTRL+J screenshots
I have instructed all developers to ignore your reports until you post the screenshots asked for.
I have also reported your trolling to the site moderators.
foxyshadis
5th September 2009, 21:28
Adude: Shut up. Everyone else: Stop replying to him.
Sorry, Adude, that things aren't working right. That doesn't give you the right to rant and harass the developers and the rest of the forum to make up for the fact that they don't know how to fix it, particularly given your repeated refusals to cooperate with them. When no developer and no other tester sees the issue, you have to cooperate as much as possible if you want to see it fixed, otherwise you just have to accept that it won't be fixed. It's much easier when one of them can reproduce it.
Further posts on this issue will result in a rule 4 strike.
Umi
5th September 2009, 23:44
Have a look at the "Filter" submenu during playback to see what's really loaded by MPC-HC. Or load the same video into graphstudio to find out what's going wrong. Third method: Use Process Explorer and open the properties page of MPC-HC there to watch the threads. Maybe you can upload a sample of one of these clips.
This is what Graphedit says:
http://img269.imageshack.us/img269/9586/problem2p.png
And this is the filters + process explorer:
http://img267.imageshack.us/img267/651/problemj.png
The sample is http://dl.getdropbox.com/u/1907430/Q-R_Utawarerumono_OP_-_Musouka_%28BD_x264_1920x1080_VFR%29.mp4
The thing is, I could play that video file using DXVA with svn 1265 first, but then I switched to 1271 and it wouldn't use DXVA, then I went back to 1265, but the video wouldn't even start.
Snowknight26
6th September 2009, 00:02
Would be nice to get the option to downmix PCM audio (when FLAC is used for the audio, for example). There's the option to downmix audio for AAC, AC3, and DTS to stereo, but not PCM (which could supersede all settings, too..). Should be a piece of cake to do, any I'm sure everyone that uses FLAC and other formats that decode to PCM would appreciate the effort.
The sample is http://dl.getdropbox.com/u/1907430/Q-R_Utawarerumono_OP_-_Musouka_%28BD_x264_1920x1080_VFR%29.mp4
Plays fine (with DXVA) here using only MPC-HC's internal filters.
Jimerb
6th September 2009, 00:46
forgive me if this is in the previous 480 pages of this tread.... Does MPC Cinema install any codecs? I'm looking to take advantage of built in codecs but I don't want the KLite codec pack installed.
Does the install of just MPC Cinema install codecs? Thank you.
saint-francis
6th September 2009, 01:09
Does MPC Cinema install any codecs?
Nope. In fact if you only have the .exe it installs nothing at all. The xvidvideo.ru builds are available in an installer. I'm not sure what they do as I've never tried one. Probably only put the folder with the .exe and other stuff in program files and created a start menu entry.
BTW. What do you mean by " install codecs"? Something like registering filters?
noee
6th September 2009, 14:52
Some results testing X1250 IGP on a TA690G mobo:
Setup: MPC-HC Build 1271, XPSP3, FFDshow 3063, RGB HQ 32bit output, no dithering, AMD X2@2.8Ghz, dual-monitor, LG HDTV 1080P as playback monitor (24Hz, secondary, HDMI), ReClock 1.8.4.8, all vsync turned off.
Just have MKVs with MPEG2 and AVC video, DVD SD rez (will test HD stuff when I get it to this machine)
Using VMR9 Renderless, letting FFDshow do the resize to 1080, I get perfect playback, no tearing. If I tell MPC-HC to resize using Bicubic, I get bad tearing and choppy playback. Changing to Bilinear, again, brings back perfect playback.
Using EVR-CP, same results as above except if I use FFdshow to resize, I get some minor tearing. Using Bilinear resize provides for perfect playback.
I'll try to do some HD content next.....
clsid
6th September 2009, 16:17
Resizing with pixelshaders (PS) unfortunately requires a powerful graphics processor. Your problem is thus not really fixable.
noee
6th September 2009, 17:11
Yeah, I realize that. This is my "old" HTPC that I resurrected to see what would happen with X1250 and XP3 (CCC9.2) just for reference sake (and Adude's ;))
ADude
6th September 2009, 21:32
Yeah, I realize that. This is my "old" HTPC that I resurrected to see what would happen with X1250 and XP3 (CCC9.2) just for reference sake (and Adude's ;))
It is interesting to see your results.
I am not using XP and I am not using ffdshow for video. My results with bicubic and bilinear are similar.
The main difference is that my display is 60 hz, rather than 24 hz.
Umi
6th September 2009, 22:37
Plays fine (with DXVA) here using only MPC-HC's internal filters.
What about ffmpeg?
Plays fine for me too with DXVA, but the video won't even start if I disable DXVA.
peek
7th September 2009, 00:49
The thing is, I could play that video file using DXVA with svn 1265 first, but then I switched to 1271 and it wouldn't use DXVA, then I went back to 1265, but the video wouldn't even start.
Did you follow the suggestions in the tutorials regarding the blocking of "External Filters" like the "fddshow Video Decoder"?
Step 7 in this tutorial: http://forums.techarena.in/guides-tutorials/1192826.htm
http://gallery.techarena.in/data/516/step007.JPG
http://gallery.techarena.in/data/516/step007-2.JPG
Or step 6 in here: http://nunnally.ahmygoddess.net/watching-h264-videos-using-dxva
I prefer to set the "fddshow Video Decoder" filter to a merit of "00400000" instead of blocking it totally. Try blocking first!
To make use of the DivX H.264 decoder load its filter and set the merit to "00800000".
You can also load and block the "DirectVobSub(autoloading version) filter.
After changing these settings you must restart MPC-HC, of course. And please, watch the "Filter" submenu to see what's really loaded during playback.
You can also set the merit globally for the matching decoder filters for a certain video by loading the video file with DXVA Checker via "Check DirectShow Decoders..." and then using the submenu "Change Merit..." when pointing on mode lines or "Unsupported" below the filter names. You can check out your clips by playing them directly from DXVA Checker or GraphEdit too.
Keiyakusha
7th September 2009, 02:17
I'm using Win7. On this screenshot (http://i26.tinypic.com/douvkx.jpg) we can see that MS's decoder is used and MPC-HC indicates that DXVA is active. So DXVA really used here? Doesn't seems so, looking on 30% CPU usage... Also this is mpeg2 DVD.
EDIT: I know that MPC-HC doesn't have DXVA decoder for mpeg2 but maybe MS's one have it or something...
thuan
7th September 2009, 06:49
It is interesting to see your results.
I am not using XP and I am not using ffdshow for video. My results with bicubic and bilinear are similar.
The main difference is that my display is 60 hz, rather than 24 hz.
Vista Home Basic and Windows XP have no desktop composition engine so the result should be quite similar.
tetsuo55
7th September 2009, 12:10
Here is a troubleshooting / limitations guide aimeded at jitter, judder, tearing and artifacts.
Description:
Jitter > Difference between clocks, basically a slight offset between expected and actual timing
Judder > Difference between video refresh rate and actual refresh rate causing a stuttery image
Tearing > the previous frame gets overwritten by the next somewhere during the vsync period causing a visable tear on the screen
Artifacts > frames that are dropped or repeated unexpectedly.
Limitations:
jitter > we cannot control everything, and the finest grain is 1ms
judder > this will always be present in non matching refresh rates without interpolation, we can make sure the jitter is kept in check with pulldown.
Tearing > Requires the videocard to be honest about the refresh rate, and the rate has to be low enough for the time required for painting
Artifacts > unless there is a 100% match between video and display rate, artifacts will occur, we can try to minimise them by moving them as far as possible into the future. Non matching rates will constantly have artifacts.
One more limitation is subtitles, due to a couple of performance problems the subtitle overhead causes a lot of timing problems, depending on the hardware some videos can become unwatchable.
Troubleshooting:
When you suffer from any of these problems follow these steps:
1. Make sure your using up to date drivers for the videocard and display(s)
2. Try to use matching refresh rates
3. Completely disable subtitles, and use a file that doesnt have subtitles at all
4. Try the gothsync branch with the following settings EVR-CP/0-255/syncnearest(Present at nearest vsync)
5. Make as screenshot of the CTRL+J display while running the gothsync version with the above settings and a video that matches your prefered refreshrate
Upload the screenshot so we can try to help you fix the problem, if we cannot fix it by using settings the devs can use it to try and reproduce the problem . If further information is required they will contact you.
Umi
7th September 2009, 14:35
Did you follow the suggestions in the tutorials regarding the blocking of "External Filters" like the "fddshow Video Decoder"?
Step 7 in this tutorial: http://forums.techarena.in/guides-tutorials/1192826.htm
http://gallery.techarena.in/data/516/step007.JPG
http://gallery.techarena.in/data/516/step007-2.JPG
Or step 6 in here: http://nunnally.ahmygoddess.net/watching-h264-videos-using-dxva
I prefer to set the "fddshow Video Decoder" filter to a merit of "00400000" instead of blocking it totally. Try blocking first!
To make use of the DivX H.264 decoder load its filter and set the merit to "00800000".
You can also load and block the "DirectVobSub(autoloading version) filter.
After changing these settings you must restart MPC-HC, of course. And please, watch the "Filter" submenu to see what's really loaded during playback.
You can also set the merit globally for the matching decoder filters for a certain video by loading the video file with DXVA Checker via "Check DirectShow Decoders..." and then using the submenu "Change Merit..." when pointing on mode lines or "Unsupported" below the filter names. You can check out your clips by playing them directly from DXVA Checker or GraphEdit too.
"DirectVobSub(autoloading version)" seems to be the problem.
By disabling it I can now play 1080p24 videos that has 4 reference frames or lower with DXVA and all other videos with DivX7. Though, using the internal ffmpeg filter or ffdshow ffmpeg-mt still desynchs with audio and lags behind. I wonder why. On my other computer that has an intel pentium 4 3.0ghz ht, ffmpeg-mt seems to be faster than DivX7, though I've never been able to play 1080p that is over 1.5mbps on that computer.
But anyway. Thanks a lot!
rt87
7th September 2009, 15:30
I'm encountering a sudden raise of green line when watching subtitle and font muxed mkv files, and I assume the internal subtitle loader just load the whole font (which can be 10MB+ in size) from the mkv file in time, but cause noticeable lags.
http://xs843.xs.to/xs843/09371/_01604.jpg.xs.jpg (http://xs.to/xs.php?h=xs843&d=09371&f=_01604.jpg)
http://xs843.xs.to/xs843/09371/_02967.jpg.xs.jpg (http://xs.to/xs.php?h=xs843&d=09371&f=_02967.jpg)
Spec:
Pentium Dual Core E6300
2GB DDR2-667
ATi Radeon X1900 Pro 256MB
Win XP SP3 w/ .NET 3.5
tetsuo55
7th September 2009, 15:32
I'm encountering a sudden raise of green line when watching subtitle and font muxed mkv files, and I assume the internal subtitle loader just load the whole font (which can be 10MB+ in size) from the mkv file in time, but cause noticeable lags.
http://xs843.xs.to/xs843/09371/_01604.jpg.xs.jpg (http://xs.to/xs.php?h=xs843&d=09371&f=_01604.jpg)
http://xs843.xs.to/xs843/09371/_02967.jpg.xs.jpg (http://xs.to/xs.php?h=xs843&d=09371&f=_02967.jpg)
Spec:
Pentium Dual Core E6300
2GB DDR2-667
ATi Radeon X1900 Pro 256MB
Win XP SP3 w/ .NET 3.5see this post: http://forum.doom9.org/showthread.php?p=1322789#post1322789
Jong
7th September 2009, 19:59
Description:
Jitter > Difference between clocks, basically a slight offset between expected and actual timing
Judder > Difference between video refresh rate and actual refresh rate causing a stuttery image
Tearing > the previous frame gets overwritten by the next somewhere during the vsync period causing a visable tear on the screen
Artifacts > frames that are dropped or repeated unexpectedly.
Limitations:
jitter > we cannot control everything, and the finest grain is 1ms
judder > this will always be present in non matching refresh rates without interpolation, we can make sure the jitter is kept in check with pulldown.
Tearing > Requires the videocard to be honest about the refresh rate, and the rate has to be low enough for the time required for painting
Artifacts > unless there is a 100% match between video and display rate, artifacts will occur, we can try to minimise them by moving them as far as possible into the future. Non matching rates will constantly have artifacts.
One more limitation is subtitles, due to a couple of performance problems the subtitle overhead causes a lot of timing problems, depending on the hardware some videos can become unwatchable.
Troubleshooting:
When you suffer from any of these problems follow these steps:
1. Make sure your using up to date drivers for the videocard and display(s)
2. Try to use matching refresh ratesOne qualification to what you have written:
Although mismatched refresh rates cause brief 'blips' of judder at an interval which depends on the difference in rates, the worst cases of judder are when refresh rates and frame rates DO match, as close as things ever 'match' on a PC, and there is no vsync correction. Then, when frames are being presented at just the wrong time, randomly at start of playback or after a period of time due to 'drift', the natural variability in presentation leads to almost continuous judder and if the refresh rates are very closely matched that judder can go on for many minutes, even up to an hour. It is why Reclock also has vsync correction built in.
If using closely matched rates you really need to use either:
- Reclock vsync correction, but you need to be sure you are using a suitable renderer - Overlay, VMR9 D3D or EVR D3D mode.
- Beliyaal's EVR CP, if it works for you! (let's not start that again!)
- Gothsync branch - ideally option 1 or option 2. Option 3 a good fallback if the other options cannot be used.
One further tip:
Reclock can be used to match refresh rates to video frame rate, whether they are necessarily different, eg. 24p @50Hz for PAL TVs ,or just slightly out due to clock errors. This will reduce the 'blips' of judder due to these errors, but will increase exposure to the above problem without vsync correction.
tetsuo55
7th September 2009, 20:16
The goal (eventually) is to merge the gothsync branch into trunk, and have synctonearest be the default setting for matching and non-matching refreshrates.
Now that we have our own audio-renderer, reclock like solutions might be possible too.
Jong
7th September 2009, 20:27
The goal (eventually) is to merge the gothsync branch into trunk, and have synctonearest be the default setting for matching and non-matching refreshrates.It seems to me that day is potentially pretty close, but to avoid any unpleasantness as has happened before ;) we probably need to actively encourage as much testing of the gothsync branch as possible. At the moment I think few are using it. Should we post a link to each new (non-private) build in this thread, with a request to post issues specific to gothsync (not shown in the equivalent main build) in the gothsync thread?
tetsuo55
7th September 2009, 20:37
It seems to me that day is potentially pretty close, but to avoid any unpleasantness as has happened before ;) we probably need to actively encourage as much testing of the gothsync branch as possible. At the moment I think few are using it. Should we post a link to each new (non-private) build in this thread, with a request to post issues specific to gothsync (not shown in the equivalent main build) in the gothsync thread?it wont be merged soon, but the sooner we find problems the better so go ahead.
ar-jar is busy with real-life(tm) and he still has some stuff on his to-do list, some more dev's have shown interest and are digging into the subject.
But even at this stage, the new code works wonderfully on my systems.
Jong
7th September 2009, 20:42
...and here.
Kotik
7th September 2009, 21:04
@Jong
So what would you suggest for a smooth playback with the following setup:
MPC-HC with non of the VSYNC settings on, DXVA ON, VMR9 and reclock as audio renderer. Should people go for VSYNC under reclock and DXVA or will it be more smooth without VSYNC in reclock.
We are always talking regarding 23.976 fps played on 23.976 HZ display.
ADude
7th September 2009, 22:03
The goal (eventually) is to merge the gothsync branch into trunk, and have synctonearest be the default setting for matching and non-matching refreshrates.
I do not see "synctonearest" on ar-jar's site, nor on the thread discussing his branch.
Do you mean " Alternative 3: Present at nearest vsync " ?
Casshern
7th September 2009, 22:42
One qualification to what you have written:
Although mismatched refresh rates cause brief 'blips' of judder at an interval which depends on the difference in rates, the worst cases of judder are when refresh rates and frame rates DO match, as close as things ever 'match' on a PC, and there is no vsync correction. Then, when frames are being presented at just the wrong time, randomly at start of playback or after a period of time due to 'drift', the natural variability in presentation leads to almost continuous judder and if the refresh rates are very closely matched that judder can go on for many minutes, even up to an hour. It is why Reclock also has vsync correction built in.
If using closely matched rates you really need to use either:
- Reclock vsync correction, but you need to be sure you are using a suitable renderer - Overlay, VMR9 D3D or EVR D3D mode.
- Beliyaal's EVR CP, if it works for you! (let's not start that again!)
- Gothsync branch - ideally option 1 or option 2. Option 3 a good fallback if the other options cannot be used.
One further tip:
Reclock can be used to match refresh rates to video frame rate, whether they are necessarily different, eg. 24p @50Hz for PAL TVs ,or just slightly out due to clock errors. This will reduce the 'blips' of judder due to these errors, but will increase exposure to the above problem without vsync correction.
Installed Win7 x64 for fun and did some tests. Before those findings let me sum up my Win XP experience (XP SP3 x86, ATI 2600 PRO AGP, Cat 9.8)
- VMR9 renderless with GPU Flush options works: no tearing, full dxva support for h264 and vc-1
- EVR CP no H264 dxva and tearing
Now Win 7 professional (this will become important in a moment) with the included WDM driver for the ATI:
- VMR9 renderless does not work anymore (no matter what settings) without tearing or judder
- But EVR CP works nicely IF AND ONLY IF aero desktop composition is NOT disabled. If i disable aero there is no way to get rid of tearing (tried all combinations by brute force)
This explains the experience of some users without aero. With aero it works pretty good - will keep you posted.
Mercury_22
7th September 2009, 23:18
Installed Win7 x64 for fun and did some tests. Before those findings let me sum up my Win XP experience (XP SP3 x86, ATI 2600 PRO AGP, Cat 9.8)
- VMR9 renderless with GPU Flush options works: no tearing, full dxva support for h264 and vc-1
- EVR CP no H264 dxva and tearing
Now Win 7 professional (this will become important in a moment) with the included WDM driver for the ATI:
- VMR9 renderless does not work anymore (no matter what settings) without tearing or judder
- But EVR CP works nicely IF AND ONLY IF aero desktop composition is NOT disabled. If i disable aero there is no way to get rid of tearing (tried all combinations by brute force)
This explains the experience of some users without aero. With aero it works pretty good - will keep you posted.
Yes ! I thought I'm the only one :) on Win7 MPC-HC (EVR CP) works better with aero ! Also (for me at least) for DXVA compatible files Win7's filters H264, MPEG2 ... are working (better) very well (with MPC-HC's splitters)
yesgrey
7th September 2009, 23:21
Now that we have our own audio-renderer, reclock like solutions might be possible too.
Is the mpc-hc's audio renderer already available for testing?
I have looked for it but did not find it...
w0rd™
7th September 2009, 23:32
@ w0rd™ > Sample please.
Hi, I'm not sure what you mean by sample, just a small split of the video?
The problem is, if I split 1min of the video in videoredo, the resulting split plays fine in mpchc. For some reason MPCHC doesn't like the original dvbviewer recording.
It plays in all other players though.
I have also recorded a small 30 second clip direct from DVBV, but the resulting size is around 60-100MB, I think too large to upload?
I could record only maybe a few seconds, but would it help?
It will still show double the remaining time (6sec instead of 3secs) but of course it will not be possible to test the press forward skip and video jumps back to earlier time.
Is there any other info about the file that could be of use?
I'm also having all sorts of video quality issues, again not sure when this started to happen. I don't have ffdshow/xvid/divx codecs installed or any codec packs.
These are crops of the most noticeable bits from 3 xvid/1 mkv(hd crop, 720p mkv) video. The original resolution is not the high, so it looks worse when made full screen. They never looked like this when I first got these videos, again, not sure which version of mpchc I was using back then.
http://img34.imageshack.us/img34/603/mpchc.jpg
Also, if I pause a video, and the screensaver activates or I lock the desktop, when I activate the desktop again, just the edges of MPCHC can be seen, the video is not there, the wallpaper can be seen behind it, and it will not respond, must manually terminate it.
http://img201.imageshack.us/img201/4528/mpchcdt.jpg
this is all with v1.3.1265.0
(besides which link is the default, I got this from xvid.ru, but there seem to be many in this thread)
Thanks again.
tetsuo55
8th September 2009, 06:43
I do not see "synctonearest" on ar-jar's site, nor on the thread discussing his branch.
Do you mean " Alternative 3: Present at nearest vsync " ?Yes that's what i mean, i clarified my posting.
@w0rd™ > if you use megaupload you can upload up to 250mb i think.
Mixer73
8th September 2009, 06:59
The problem is, if I split 1min of the video in videoredo, the resulting split plays fine in mpchc. For some reason MPCHC doesn't like the original dvbviewer recording.
This would normally indicate that the video is corrupted and VRD will not export the corrupt frames, you can probably change some options regarding the way VRD handles this.
littleD
8th September 2009, 09:09
ADude, for your and our good, try my little tutorial, it may help with your playback problems.
1. Enable aero theme in vista home basic (for aero synch)
http://www.ghacks.net/2007/05/13/enable-vista-aero-in-windows-vista-home-basic/
http://www.metacafe.com/watch/324426/windows_vista_aero_manual_activation/
2. Manual enabling Aero glass
Now if you have only aero basic (vista revert to this when running on old gpu), go to the Control Panel>>Appearance and personalization>>Windows color and Appearance then click Open Classic Appearance Properties for More Color Options and finally from the Color Scheme list choose: Aero Glass.
3. Turn off Vsync in newest MPC HC. Let Aero do the job
I do not guarantee it'll resolve your problem. But at least try.
From http://www.notebookcheck.net/ATI-Radeon-Xpress-X1250.6946.0.html
The graphic chip supports Windows Vista Aero surface and all 3D effects run fluently. Due to HyperMemory Aero is supported with high resolutions (tested with 1280x800 + 1920x1200).
Jong
8th September 2009, 10:02
@Jong
So what would you suggest for a smooth playback with the following setup:
MPC-HC with non of the VSYNC settings on, DXVA ON, VMR9 and reclock as audio renderer. Should people go for VSYNC under reclock and DXVA or will it be more smooth without VSYNC in reclock.
We are always talking regarding 23.976 fps played on 23.976 HZ display.Well I've learnt that no 2 PCs are ever the same, but if you are happy to use VMR9 D3D I would recommend Reclock with Reclock vsync correction. You may want to play with the Reclock vsync slider your self, but I find just past half way works for me ("3b" (hex) in the registry). Ignore comments in Reclock that vsync is not recommended for DXVA. It works perfectly, just you cannot display the vsync markers on screen.
But you might want to try just using the MPC-gothsync (without Reclock)with "option 1" synchronisation selected. As you are not changing the frame rate at all this may be simpler and almost as effective.
peek
8th September 2009, 10:39
"DirectVobSub(autoloading version)" seems to be the problem.
By disabling it I can now play 1080p24 videos that has 4 reference frames or lower with DXVA and all other videos with DivX7. Though, using the internal ffmpeg filter or ffdshow ffmpeg-mt still desynchs with audio and lags behind. I wonder why. On my other computer that has an intel pentium 4 3.0ghz ht, ffmpeg-mt seems to be faster than DivX7, though I've never been able to play 1080p that is over 1.5mbps on that computer.
But anyway. Thanks a lot!
Disabling "Deblocking" on the DivX properties page gives much better performance and the quality loss is still acceptable, although you might not need that on your powerful i7 CPU. And if you don't need subtitles then you should use VMR7-windowed mode instead of VMR9-renderless. With both settings I can play "Lia_Tori_no_Uta.mkv" with 25-26 FPS on my XP 32 with P4 630 3.0 GHz and HD3450 PCIe x1. And I've also no problems to play more than 32 MBit/s with DXVA. Just didn't test higher rates yet. With DivX it's possible to play up to 8-12 MBit/s at least on my P4 not losing A/V sync.
http://www.alice-dsl.net/pkeunecke/H264_without_DXVA.jpg
Leak
8th September 2009, 12:21
These are crops of the most noticeable bits from 3 xvid/1 mkv(hd crop, 720p mkv) video. The original resolution is not the high, so it looks worse when made full screen. They never looked like this when I first got these videos, again, not sure which version of mpchc I was using back then.
Turn on the "YV12 Chroma Upsampling" shader to fix this - that's your graphics card mucking up the chroma upsampling in the YV12 to RGB conversion...
clsid
8th September 2009, 12:21
@w0rd™
Try the "YV12 Chroma upsampling" shader. That should help correct the problem with the red colors.
@tetsuo55
If aero enabled gives the best results on 7, then the "optimal" renderer settings should be changed (for 7 only).
tetsuo55
8th September 2009, 12:51
Is the mpc-hc's audio renderer already available for testing?
I have looked for it but did not find it...not yet.
@w0rd™
Try the "YV12 Chroma upsampling" shader. That should help correct the problem with the red colors.
@tetsuo55
If aero enabled gives the best results on 7, then the "optimal" renderer settings should be changed (for 7 only).on my system there is no difference, but if it helps for a lot of people we should definately consider it.
thuan
8th September 2009, 13:55
@Leak: So ATI haven't fixed the bug? I left them because of that bug and I will soon buy a new GFX card, so I need to know.
Leak
8th September 2009, 14:44
@Leak: So ATI haven't fixed the bug? I left them because of that bug and I will soon buy a new GFX card, so I need to know.
Pardon my french, but basing which graphics card to buy on that one point is silly.
(I dimly remember that using NV12 gave proper upsampling, but I haven't actually tested that in months...)
np: New Order - True Faith (Shep Pettibone Remix) (Brotherhood Extras)
thuan
8th September 2009, 18:35
It's not IMO, because the fact that I noticed that before your shader is available to work around the driver bug and going through the trouble of reporting to them about the bug only to be asked back where do these screenshots I made with ffdshow color conversion and ATI color conversion differ by the ATI operator. It was quite annoying for me so I decided to leave them at least until it's fixed. Besides I need to experiment on GPGPU for HPC which is easier on nvidia currently with their platform and drivers.
nijiko
9th September 2009, 04:02
Internal AVI splitter (gabest) reads video streaming wrong.
RGB555 will be recognized to RGB565.
leowong1
9th September 2009, 04:17
For now, I think the big "bug" to users is the old, un-userfriendly, and space-consuming UI.
In comparison to say, Zoomplayer, SMplayer (front-end for Mplayer) and Splayer (MPC-HC mod), MPC-HC has the most un-userfriendly UI. Listed below are some "problems" of its UI:
1. Space-consuming "Menu": For most of the time, users DO NOT need to use "menu" if a player has a nice UI. It is space-consumingm disturbing, especially for notebooks and netbooks. Although this "menu" can be hidden manually, once hidden, the "windows bar" on top of the "menu" also disappears which is very annoying. There should be an option for users to decide whether they want to keep the "windows bar" or not.
2. Un-userfriendly-design control bar: There is no need to separate "Seek bar", "Control bar" and "Status bar". In fact, developers should look at other players like Zoomplayer and SMplayer. If well-designed, these three can merge into one. This would make MPC-HC much more userfriendly and space-consuming for PCs with small display.
3. Problematic control "bars": If users decide to hide the seek bar, status bar, etc, the user can no longer seek the video, know the duration of video, etc (The seek bar just totally disappears, even in FULL screen mode). My suggestion would be to follow the example of SMplayer to make MPC's control bar appear temporarily when the mouser pointer reach bottom of the video, so that users who want a compact UI can still seek the video and control the video.
These are the main problem of MPC-HC I can think of now. I also attach a screenshot of the Splayer UI for you developers to take a look. I just hope MPC-HC can have a compact UI like Splayer and SMplayer.
nijiko
9th September 2009, 04:19
The right info is:
Video: 320x178 10.00fps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB555 {E436EB7C-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 88
VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 1000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 320
biHeight: 178
biPlanes: 1
biBitCount: 16
biCompression: 0
biSizeImage: 113920
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 40 42 0f 00 00 00 00 00 ........@B......
0030: 28 00 00 00 40 01 00 00 b2 00 00 00 01 00 10 00 (...@..........
0040: 00 00 00 00 00 bd 01 00 00 00 00 00 00 00 00 00 ...............
0050: 00 00 00 00 00 00 00 00 ........
But Gabest's AVI splitter reads to:
Video: 320x178 10.00fps 9113Kbps
AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_RGB565 {E436EB7B-524F-11CE-9F53-0020AF0BA770}
formattype: FORMAT_VideoInfo {05589F80-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 170880
cbFormat: 88
VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 9113600
dwBitErrorRate: 0
AvgTimePerFrame: 1000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 320
biHeight: 178
biPlanes: 1
biBitCount: 16
biCompression: 0
biSizeImage: 113920
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 10 8b 00 00 00 00 00 40 42 0f 00 00 00 00 00 .......@B......
0030: 28 00 00 00 40 01 00 00 b2 00 00 00 01 00 10 00 (...@..........
0040: 00 00 00 00 00 bd 01 00 00 00 00 00 00 00 00 00 ...............
0050: 00 00 00 00 00 00 00 00 ........
That makes video outputing wrong.
leeperry
9th September 2009, 04:33
I just hope MPC-HC can have a compact UI like Splayer and SMplayer.
where do I sign? http://forum-images.hardware.fr/images/perso/jack_power.gif
thuan
9th September 2009, 05:16
Well you can just use splayer till then and hope for an English translation, heck if it did have workable English interface and video playback as good as the current MPC-HC I would have switched. IMO MPC-HC UI is still usable to watch movie but video playback currently sill have some major problems for users (not me currently) which need more attention. It also depends on what you view as important and if there's willing developer. It's how FOSS work.
Banta
9th September 2009, 05:24
Hi friends,
I have compiled MPC HC on VS2008 and generated exe from VS2008. I am able play all files using it, however if I try to step into AVI Parser code while I am debugging AVI stream I am not able to step in. I just wanted to know if it possible debug the code at that level.
Mixer73
9th September 2009, 05:45
I have to use full screen D3D playback to get good playback on my system so I never see the GUI anyway, am I the only one who doesn't care if MPC-HC is like the girl-next-door?
I mean she's a bit plain but all right when the lights are out :)
tetsuo55
9th September 2009, 06:35
For now, I think the big "bug" to users is the old, un-userfriendly, and space-consuming UI.
In comparison to say, Zoomplayer, SMplayer (front-end for Mplayer) and Splayer (MPC-HC mod), MPC-HC has the most un-userfriendly UI. Listed below are some "problems" of its UI:
1. Space-consuming "Menu": For most of the time, users DO NOT need to use "menu" if a player has a nice UI. It is space-consumingm disturbing, especially for notebooks and netbooks. Although this "menu" can be hidden manually, once hidden, the "windows bar" on top of the "menu" also disappears which is very annoying. There should be an option for users to decide whether they want to keep the "windows bar" or not.
2. Un-userfriendly-design control bar: There is no need to separate "Seek bar", "Control bar" and "Status bar". In fact, developers should look at other players like Zoomplayer and SMplayer. If well-designed, these three can merge into one. This would make MPC-HC much more userfriendly and space-consuming for PCs with small display.
3. Problematic control "bars": If users decide to hide the seek bar, status bar, etc, the user can no longer seek the video, know the duration of video, etc (The seek bar just totally disappears, even in FULL screen mode). My suggestion would be to follow the example of SMplayer to make MPC's control bar appear temporarily when the mouser pointer reach bottom of the video, so that users who want a compact UI can still seek the video and control the video.
These are the main problem of MPC-HC I can think of now. I also attach a screenshot of the Splayer UI for you developers to take a look. I just hope MPC-HC can have a compact UI like Splayer and SMplayer.The Splayer dev has already joined the MPC-HC team.
We are working on the gui, but its mostly minor touchups.
Currently we are thinking about a way to intergrate the splayer gui as a off-by-default option.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.