View Full Version : MPC-HC-Beliyaal-build testing thread
Beliyaal
23rd February 2009, 00:20
NOTE: All my changes are currently integrated into SVN
I will use this thread in the future for testing of experimental new features.
carnage_pl
23rd February 2009, 01:27
Hi! Thanks for changes but with new version i can't use skip forward and backward button. I didn't do anything expect copying new file
~bT~
23rd February 2009, 01:31
^ works fine here.. are the files in the playlist?
carnage_pl
23rd February 2009, 01:38
I mean navigate previous, next and jump to... audio, video and subtitle works. It's nothing related with favorites and playlist. I checked on files which it worker with v13. normal rev1004 is ok. It isn't false of haali splitter nor internal
~bT~
23rd February 2009, 01:40
^ i meant the same thing. works fine here.. vista sp2 x86
Beliyaal
23rd February 2009, 01:55
I mean navigate previous, next and jump to... audio, video and subtitle works. It's nothing related with favorites and playlist. I checked on files which it worker with v13. normal rev1004 is ok. It isn't false of haali splitter nor internal
Sorry, some debug code was left where I had disabled anything that enumerated the graph in timers. Fixed in version 15.
carnage_pl
23rd February 2009, 02:08
^ i meant the same thing. works fine here.. vista sp2 x86
So really there was something wrong ^^
Sorry, some debug code was left where I had disabled anything that enumerated the graph in timers. Fixed in version 15.
Everything Ok now. Once again I appreciate Your effort!
Pyr0
23rd February 2009, 02:46
standby after playback is broken in vista x64
i like the other small changes and options though :)
Beliyaal
23rd February 2009, 03:10
standby after playback is broken in vista x64
i like the other small changes and options though :)
But thats the case with the regular SVN build as well right?
Pyr0
23rd February 2009, 03:24
yes, unfortunately.
since the svn 983 change - Prevent display or computer to sleep during playback.
i've never had any probs with the display or system entering sleep during playback *shrug*
gngn
23rd February 2009, 03:32
OS: Win XP SP3
GPU: 8600GTS , driver 182.05 , 17" CRT@75hz
Renderer: VMR9renderless (3d-surfaces , vmr mixer mode, lock back-buffer, accurate vsync ON)
i have a number of problems involving tearing:
- if i check "Alternative VSync" then i have to adjust VSync differently with every file to get rid of tearing. without it, no tearing occurs. there is actually no need to use it, right?
- if i set "subpicture prebuffering" to anything more than 1, i also end up with tearing somewhere on top of the video (but with it set to 1, karaokeeffects dont work, even if there are no spikes in the jittercurve when every dialogeline is inserted). if i set it to 2 or more, karaoke works, but i end up with tearing (the moment i deselect subtitles in MPC-HC tearing stops).
screens:
buffers on + subs on http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_subs.png (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/subs.png)
buffers on but subs off http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_no_subs.png (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/no_subs.png)
buffers off http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_no_buffers.png (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/no_buffers.png)
ranpha
23rd February 2009, 04:44
* Operating system, and service pack - Windows 7 beta.
* Graphics card, and driver version - nVidia 9800GT with driver 182.06
* Which output renderer you are using - EVR custom presenter
* If in Vista, are you running aero with desktop composition (transparent window title bars) - not Vista, but has Aero.
* If possible also include a screencap with statistics enabled - doesn't really apply here.
* All problems should be compared to regular MPC-HC to make sure its not a regular MPC-HC problem - doesn't happen with regular SVN 998 at least. I use r15 of your build BTW.
If I set MPC-HC to repeat playback after a video has ended (Options --> Playback --> Repeat Forever), the subsequent playback repeats will not show the video, only audio. First-time playback is OK, but if I let the video ends and wait for it to rewind and started playing again, all I will get is the audio playing, and no video (black screen). Happened with all codecs I tested (internal MPC-HC, CoreAVC and DiVX).
cca
23rd February 2009, 08:52
lol, you posted this a bit late for me, was asleep. I will test this afternoon and report back! Thanks Beliyaal.
Mercury_22
23rd February 2009, 11:42
Sorry to have to say this but the WRONG FRAME RATE for VC-1i BUG (http://forum.doom9.org/showthread.php?t=123537&page=323) introduced in your ver 12 Ver 12:
* Fixed out of sync because incorrect correction of frame times. it's still there ! :(
Sample VC-1 1080i60 M2TS (http://rapidshare.com/files/201547004/VC-1_1080i60.M2TS.html)
I don't know about you, but for me (and others A.F.A.I.K. ) this is a MJOR BUG since almost ALL VC-1 m2ts ( blu-ray) are i !
P.S. You have to use WMVideo Decoder DMO since internal filters for VC-1 still NOT working with VC-1i :mad:
Just a REMINDER the DTS BUG (http://forum.doom9.org/showthread.php?p=1242349#post1242349)is still there ( in SVN too ) also :o
EDIT LINK UPDATED :o
Beliyaal
23rd February 2009, 12:25
Sorry to have to say this but the WRONG FRAME RATE for VC-1i BUG (http://forum.doom9.org/showthread.php?t=123537&page=323) introduced in your ver 12 it's still there ! :(
Sample VC-1 1080i60 M2TS (Sample VC-1 1080i60 M2TS)
I don't know about you, but for me (and others A.F.A.I.K. ) this is a MJOR BUG since almost ALL VC-1 m2ts ( blu-ray) are i !
P.S. You have to use WMVideo Decoder DMO since internal filters for VC-1 still NOT working with VC-1i :mad:
Just a REMINDER the DTS BUG (http://forum.doom9.org/showthread.php?p=1242349#post1242349)is still there ( in SVN too ) also :o
Yes I know they are still there. No hidden changes to the builds except for those in the changelist. The VC-1 bug I will try to fix as soon as possible, but the DTS bug is a little harder.
You sample link for the VC-1i file doesn't work.
Kado
23rd February 2009, 13:19
@gngn
I have no tearing but I can confirm that the subs don't show up with 1 buffer, but if I toggle fullscreen the current subtitle "frame" is drawn. And some times the the subs show up like 1 frame only.
STaRGaZeR
23rd February 2009, 13:31
If I set MPC-HC to repeat playback after a video has ended (Options --> Playback --> Repeat Forever), the subsequent playback repeats will not show the video, only audio. First-time playback is OK, but if I let the video ends and wait for it to rewind and started playing again, all I will get is the audio playing, and no video (black screen). Happened with all codecs I tested (internal MPC-HC, CoreAVC and DiVX).
Yesterday I was playing with some files and some of them didn't suffer from this. However I couldn't find the source of the problem.
cca
23rd February 2009, 13:32
Just did my first tests, I can confim Kado's findings, with buffers set to 1, no animation occurs. I always have it at 10 anyway, so I never noticed. The memory leaks seem fixed, I'll know better by tonight since I plan to spend my evening watching lots of anime!
The fact is, if you want high res subtitles, you need a good CPU, that won't improve a lot as far as I can see. My Phenom seem OK for now.
Another thing, Belyaal can you take a look in the EVR Custom Presenter if it misses some kind of flag or something? You have noticed by now that the latest ATI drivers cause problems with the video levels, but ONLY with the EVR Custom. I believe it is a MPC problem because I had the same issue a year ago when I had an nvidia card and the Service pack 1 for windows Vista was released. They fixed something in EVR, then nvidia foxed something in the drivers, the result was that normal EVR works fine, levels are PC levels, but EVR Custom always has TV Level, colors are washed out.
Mercury_22
23rd February 2009, 14:07
Yes I know they are still there. No hidden changes to the builds except for those in the changelist. The VC-1 bug I will try to fix as soon as possible, but the DTS bug is a little harder.
You sample link for the VC-1i file doesn't work.
SORRY ! :o LINK UPDATED !
So ver 11 reports 60 FRAME ver 12,13,14,15 are reporting 30 FRAMES
And sorry if I seem pushy about the DTS but I'm just thinking that solving a bug by introducing another it's not the way to go for the SVN version
This is the last time i'm mentioning the DTS bug! Promise ! :)
P.S. My VC-1i sample it's from the same BD as the one from the first post of MPC-HC's thread * VC-1 Interlaced Material Bug (sample provided)
link (http://forum.doom9.org/showpost.php?p=1139064&postcount=1973)
but its a m2ts container not mkv and maybe I should mention that with the mkv sample ( NO SOUND ! ) the frame rate it's CORRECT with all your versions ! So I CAN'T say if it's the container or the missing audio stream :confused:
EDIT I've remux my m2ts to mkv (with sound) and all your versions are reporting correct FRAME RATE ( 60 ) so it's a splitter / container problem
EDIT 2 I had to test this :) I've tested the DTS bug in a mkv file and it's NOT there
cca
23rd February 2009, 14:14
OK, red flag here, blinking subtitles are still here, and in a video which doesn't even have real time effects, it just uses ass subtitles with simple styling. Something still needs fixing in the subtitle renderer.
EDIT: Red card to myself, I forgot I had the buffer at 2 instead of 10. Can this buffer be increased more than 10, to like 40 or even more? It will help slower PCs for sure.
Beliyaal
23rd February 2009, 15:23
Ok, I think I will force at least 3 buffers when animated subtitles are enabled. I could add options for 40 frames of buffering, but the problem is that the graphics memory might run out on consumer cards and result in bad performance. 40 buffers in 1080p is 316 MiB of data. Maybe add up to 40 and add a warning.
cca
23rd February 2009, 15:29
Thank you. Is there a way to know how many we can use in a given setup? Or is it possible for the player to automatically reduce them if it queries the drivers for available video memory? I know Haali's renderer has a setting about how much video memory it can use, and another for the buffers, can you do something like this in the worse case?
BTW, I didn't know I could use the animated subtitles with Haali Renderer, I just tried it and it's working properly!
Kado
24th February 2009, 03:13
But with haali you don't have DXVA and mpc will suffer from dropped frames as well if you disable buffering.
gngn
24th February 2009, 03:20
OS: Win XP SP3
GPU: 8600GTS 256M, driver 182.06 , 17" CRT@75hz
Renderer: VMR9renderless (3d-surfaces , vmr mixer mode, lock back-buffer, accurate vsync ON)
i think i finally got rid of tearing even with more than 1 buffers set for the subtitles (even 10 is not a problem).
but i have to set following limitations:
- no AA or anisotropic filtering for MPC-HC in nvidia's control panel
- subtitles texture resolution set to 800x600, "round up to power of 2" unchecked (which of course, results in messy looking subtitles)
why do i have these limitations? because of the older graphic-card or the old dual-core?
cca
24th February 2009, 09:47
But with haali you don't have DXVA and mpc will suffer from dropped frames as well if you disable buffering.
True, but since it's a testing version I thought I should test ;)
Egh
24th February 2009, 12:05
Nice to see new thread opened finally properly for this great experimental build (hopefully soon to be merged with main SVN ;).
I've confirmed animated subs bug in the current Ver15.
Yes it does show animation with subs buffer == 0, and shows here all correctly with some value of 5 or 10 (i only tested simple {\k} effect so far). However it does indeed revert to normal SVN behaviour if prebuffering is set to 1.
BTW, I didn't know I could use the animated subtitles with Haali Renderer, I just tried it and it's working properly!
Why would they not work? I had them ages ago, just with buffer set to 0 :) Worked quite nice on SD videos.
Regarding guys who always complain about CPU overheating on mpc subs. C'mon, when watching SD video with simple animated subs effects (like \k above) it doesn't take more than 10% cpu power (and I'm using Desktop resolution which is 1280x1024 for the subs). And it is not 10% for subs, it is 10% for 720x480 playback as well :)
Of course more complicated effects might take more cpu and with 1080p you might experience some slowdowns.
But with haali you don't have DXVA and mpc will suffer from dropped frames as well if you disable buffering.
You may (like me ;)) have the last geforce model which did NOT support DXVA anyway :) (and that is really a shame with 7900 as it is good enough to play Crysis with medium settings!). And as for dropped frames etc I haven't seen any problems with Haali renderer. Honestly DXVA support is largely overrated anyway, especially for anime as it typically has less motion detail. Why would you need to speed the things up if with the proper codec+Haali you have 15-17% cpu load on 720p AVC anyway...
cca
24th February 2009, 12:13
Nice to see new thread opened finally properly for this great experimental build (hopefully soon to be merged with main SVN ;).
I've confirmed animated subs bug in the current Ver15.
Yes it does show animation with subs buffer == 0, and shows here all correctly with some value of 5 or 10 (i only tested simple {\k} effect so far). However it does indeed revert to normal SVN behaviour if prebuffering is set to 1.
Regarding guys who always complain about CPU overheating on mpc subs. C'mon, when watching SD video with simple animated subs effects (like \k above) it doesn't take more than 10% cpu power (and I'm using Desktop resolution which is 1280x1024 for the subs). And it is not 10% for subs, it is 10% for 720x480 playback as well :)
Of course more complicated effects might take more cpu and with 1080p you might experience some slowdowns.
True, more complex effects strain your cpu more that's why I asked for more buffers but we have a limit, the buffers cannot exceed the capacity of the VGA's video ram. Currently I hope Belyaal will increase the possible buffers to at least 40 so I can take advantage of the 512MB ram of my video card for subtitle prebuffering.
The EVR buffers do exactly the same but they buffer video frammes, even the sound renderer usually buffers a few ms of audio. Buffering generally helps slower PCs, but increases the memory demands.
Kado
24th February 2009, 12:46
You may (like me ;)) have the last geforce model which did NOT support DXVA anyway :) (and that is really a shame with 7900 as it is good enough to play Crysis with medium settings!). And as for dropped frames etc I haven't seen any problems with Haali renderer. Honestly DXVA support is largely overrated anyway, especially for anime as it typically has less motion detail. Why would you need to speed the things up if with the proper codec+Haali you have 15-17% cpu load on 720p AVC anyway...
I have a 9800GTX that supports h.264 bitstream decoding and that is quite useful because since the gpu is decoding the video the cpu can do the rest like rendering the video, subs etc and give a more fluid playback, and the gpu consumes less power decoding the video than the cpu.
The problem with zero buffering is that right when the subs are about to be displayed the renderer may drop a frame or two (not always, the more text the worse). I don't know why the statistics in mpc don't count dropped frames for haali renderer though (but the drop/pause is visible).
Haali had the subtitle resolution limited to 1024x768 but that is now fixed.
tetsuo55
24th February 2009, 12:54
True, more complex effects strain your cpu more that's why I asked for more buffers but we have a limit, the buffers cannot exceed the capacity of the VGA's video ram. Currently I hope Belyaal will increase the possible buffers to at least 40 so I can take advantage of the 512MB ram of my video card for subtitle prebuffering.
The EVR buffers do exactly the same but they buffer video frammes, even the sound renderer usually buffers a few ms of audio. Buffering generally helps slower PCs, but increases the memory demands.
Yeah we need to find a buffer balance.
Haali renderer has the right idea.
We could try the following system
-Specify (Or use a clever algorithm) to define the maximum amount of Video ram that can be used.
-Reserve the memory needed for DXVA when DXVA is enabled
-Reserve the memory for the number of buffered frames needed
-Use left over memory for buffering subtitles
All if this could(and probably should) be done dynamically and on the fly.
this way performance would never suffer, and any system would have the best possible settings by default
Example:
-Check total memory in videocard
-Check available memory in videocard
-Check if DXVA is going to be used, limit memory use by subtracting the DXVA portion.
-Assign optimum number of video frame buffers for the amount of available videocard ram
-Assign the optimum number of subtitle frame buffers for the amount of available videocard ram left after the last step.
Also we should look into optimizing the subtitles in a better way.
Something like this:
-Always use Canvas(inside of the mpc-hc surface) size by default.
-Cut resolution in half when available memory becomes a problem.
Another solution/addition could be a buffer in system-ram in addition to what is in the videocard-ram
Edit:
Or something completely different:
Could we render the subtitles with any random resolution, but overlay them over the video as a small portion of the screen?
The whole frame would be 1920x1080, but the subs part could be only 1700x300, this smaller image is overlay'd in the desired location, this would mean we could buffer 3 frames in the place of one.
(this idea is based on the richt click menu idea, i don't think the right click menu renders the entire image, it only does itself and overlays nicely even over DXVA)
cca
24th February 2009, 12:54
I believe that it doesn't count the dropped with Haali because the renderer itself doen't send that information to the host application. Haali renderer just doen't support statistics. It certainly drops frames in that situation, I can clearly see it too.
I used to have Haali renderer as my default in the past, but unfortunately it has vsync issues that annoy me, sometimes it starts stuttering. EVR Custom + ReClock with vsync correction enabled is current setup.
cca
24th February 2009, 12:58
I see some interesting ideas from tetsuo55, but I'm not sure how much automatic we can do it, since some amount of video RAM is needed from windows themselves for the desktop. That amount increases in Windows Vista because of Aero. I guess it's up to Beliyaal to decide what to use, I will graldy test anything.
Kado
24th February 2009, 13:18
It's not possible in vista to determine the amount of ram the GPU has because vista manages the memory virtually (mixing System ram with GPU ram).
Videomemory usage monitoring is not available under Vista due to Vista videomemory virtualization.
Also remember that ass styled subs can have multiple lines and multiple positions in the frame simultaneously making that custom resolution option impossible to use.
The renderer/mpc could have settings similar to haali where you can put your custom memory and frame values.
tetsuo55
24th February 2009, 13:49
Also remember that ass styled subs can have multiple lines and multiple positions in the frame simultaneously making that custom resolution option impossible to use.
Completely forgot about that, still a smart dynamic algorithm would still reduce the amount of ram needed even in those cases
ADude
25th February 2009, 05:40
Beliyaal - just curious if you ever addressed the bug in your version reported a few weeks ago in the MPC-HC thread that your version breaks playback of .FLV (flash video) files ?
yevaman
25th February 2009, 16:13
Hello beliyaal,
First of all thanks for your build, it's really apprecied.
Have you seen this post on this thread : http://forum.doom9.org/showthread.php?t=123537&highlight=looping&page=335
Casshern spoke about an OLDDDD bug that cannot allow many ATI cards users to use VRM9 with DVXA.
It result that for one years I cannot use subtitles, no image ameliorations...
( I have to disable DVXA to have a correct video, but without that, my CPU is not powerfull enought to decode HD signals)
In his post, Casshern spoke about some leads to solve the problem.
Can you take a look and see if you can do something ?!
Thx for your reponse
I might finally hit on something conrete which might enable the devs to fix the jumping frame, video corruption bug with VMR9 Renderless and DXVA on some ATI cards.
First the conditions of the problem
1) VMR9 Renderless regardless of options (surfacetype/vmr mixer/direct3d etc.)
2) Win XP SP3
3) High Resolution Display of playback window. Easiest to see at 1920x1080 fullscreen
4) DXVA playback of high bitrate VC1 or H264 titles
5) Catalyst 9.2 (and all previous versions) but lets stick to this version
6) Cards: mostly AGP ATI 2400/2600/2600 PRO but also some people with PCX 2x00 report this problem
7) PowerDVD 7 works with VMR9 renderless
8) Its a little dependent on the stream - some streams show little corruption. Some - mostly high bitrate stuff which uses the whole 16:9 resolution - show very high reproducable corruption
Let me first stress that Overlay and VMR7 pose no problem as DXVA works there without problems. Albeit you got no subtitle support
NEW FINDINGS (for both regular MPC HC and the beliyaal version):
1) With lock back buffers there is no tearing even without direct3d mode.
1a) If lockback buffers are enabled - one can stop the corruption completely by opening the rightclick context menu! As long as you do not close the menu the video works perfect.
2) Without Lock Back buffers there is tearing - regardless of any other option.
2a) If the "tear" is in the middle of the video there is NO corruption. As soon as you hit pause/play a couple of times to change the "tear" position (i have exact 47.952 powerstrip timings) and the "tear" is outside the visible video area the frame corruption jumping returns. Then after a while when the tear move back into the picture the corruption gets less and finally disappears.
SPECULATIVE CONCLUSIONS: I think the timing of the changing of video buffers in relation to vsync is the problem. Probably in the MPC HC Presenter code at some point there needs to be a small timing adjustment - thats why PowerDVD7 works and the right context menu makes the problem disappear. The corruption looks like DXVA is writing to the wrong video buffer. Maybe the presenter/vmr9 directx component switches buffers to early after a vsync or to late.
Additional Info about the beliyaal version:
1)Without lockback buffers i get tearing in every other possible combination of options. Even if i increase the vsync offset so the "tear" is moved out of the visible video area (even outside the screen area) the tear soon (1-3 seconds) returns inside the video area.
2)with lockback buffers the same behaviour as in the normal version described above is shown- also no matterr which combination of options i tried (and believe me i tried all of them - even restarting the player after every change)
If the root cause cannot be found or is not within MPC HC realm (maybe its a directx/ati driver thingie) than still the right context menu phenomenon gives me hope that a simple workaroung might be possible. Maybe some 1 pixel menu could be opened somewhere - ugly but it might work.....
If you need more info testing just let me know....
iron2000
25th February 2009, 17:20
What do the "sub picture to buffer" do?
Decreased the value from 5 to 0 and testing on a video that has a panning scene.
At 5 the panning is not smooth but as the value is decreased the panning is smoother.
Feels like it slows down scenes with big changes.
And theres tearing, lock-down back buffer kind of solves it but there are visible slow downs instead of tearing.
cca
25th February 2009, 17:31
What do the "sub picture to buffer" do?
Decreased the value from 5 to 0 and testing on a video that has a panning scene.
At 5 the panning is not smooth but as the value is decreased the panning is smoother.
Feels like it slows down scenes with big changes.
And theres tearing, lock-down back buffer kind of solves it but there are visible slow downs instead of tearing.
Do you have the Vsync enabled in the renderer options? At least in my system it doesn't work properly, I have to disable it for now. Beliyaal intends to improve it at some future version.
gngn
25th February 2009, 19:09
Do you have the Vsync enabled in the renderer options? At least in my system it doesn't work properly, I have to disable it for now. Beliyaal intends to improve it at some future version.
the same goes for me. with all options regarding Vsync disabled, i can set buffers and subtitles texture resolution to any value, without tearing showing up: http://forum.doom9.org/showpost.php?p=1253933&postcount=24
Amour
26th February 2009, 07:19
http://www.olofsson.info/ not available. I cannot download the build.
Casshern
26th February 2009, 12:28
Hi,
I did send beliyaal the post via pm - but after some more testing i have doubts that the vsync offset works at all with the ATI radeon cards. Everything below is with lock back buffers turned off:
With alternate vsync and accurate vsync the "tear" (position where the frame buffers are flipped - normally this should be done in vblank to be invisible) is very stable - BUT vsync offset does absolutely nothing.
I could imagine that if this would work one could find an vsync offset where the garbled video, jumping frame error does not occur. Of course a fix which adresses the problem properly would be even better - see my long post.
Hello beliyaal,
First of all thanks for your build, it's really apprecied.
Have you seen this post on this thread : http://forum.doom9.org/showthread.php?t=123537&highlight=looping&page=335
Casshern spoke about an OLDDDD bug that cannot allow many ATI cards users to use VRM9 with DVXA.
It result that for one years I cannot use subtitles, no image ameliorations...
( I have to disable DVXA to have a correct video, but without that, my CPU is not powerfull enought to decode HD signals)
In his post, Casshern spoke about some leads to solve the problem.
Can you take a look and see if you can do something ?!
Thx for your reponse
cca
27th February 2009, 11:19
It's been several days since this build was made and it has completely replaced the SVN build for me. Mostly because it has no memory leaks anymore, and the subtitle renderer just rocks! I keep vsync disabled and use the one in reclock instead, tearing is a non-issue in windows vista with aero anyway. Muchos gracias Beliyaal :)
Jong
27th February 2009, 14:19
Hi. First post in this thread, so sorry in advance for any noob comments.
I have been a serious HTPC user for about 7 years now and had my current Core2 HTPC for just over 2 years, using MPC-HC for about a year, since I started ripping my HD-DVD/Blu-rays to mkv. It has now replaced TheatreTek for DVDs and is used for everything but full Blu-ray discs, whenI still need to use PDVD.
I use Reclock and have been very active in that community, both before the Slysoft "takeover" and since. However, since I use DXVA and VMR9 I do not/cannot use Reclock vsync tools.
This project seems really interesting and could finally solve my issues with smoothness. It has always been noticeable that occasionally (say 1 in 7 times) video will be jerky and this is solved, normally, by a quick seek or pause/play. I had hoped that this build would resolve the issue but it seems to still be there. However, your stats seem to make the situation clearer and as you are working in this whole area I am hoping a future build might be able to fix things.
My environment is:
* Operating system: XP SP3
* Graphics: ATI3850 Cat 9.2 (but this problem has been consistent over many driver versions I believe)
* output renderer: VMR9(renderless), D3D, lock back buffer, YUV Mixing, alternate vsync
Normally the jitter line is almost perfectly flat, with maybe one +/-20ms 'flip' every minute. However, every so often at startup or after a seek jitter is crazy and stays that way until playback stops or a manual seek or pause:
http://jong.pwp.blueyonder.co.uk/images/MPC_jitter_270209_01.jpg
I have tried with MPC video decoder using DXVA and with CoreAVC; It is not a decoder issue, both are affected. Is there anything you can do to trap this problem and get rid of the crazy jitter without a manual seek?
Thanks, Jon.
Jong
27th February 2009, 15:57
A few other things I have tried:
- It does not seem to be caused by Haali - Blu-ray .m2ts files have the same problem
- it is not caused by Reclock. Even if reclock is removed the issue remains the same
- It does NOT happen with PAL DVD material but does with 23.976fps DVD
- It does NOT happen if I package PAL MPEG2 in an mkv
- It happens if 24p material is played back at 47.952Hz or 50Hz (sped up by Reclock)
- I tried with and without D3D mode, without and without lock back buffer and alternate vsync and the problem remained.
- moving the vsync position whille playing a video in this state did not fix it
- I also reduced subtitle buffers to zero (from 3), increased amd reduced the subtitle texture size and toggled "power of 2". All made no difference.
So, as far as I can see it seems to be a problem with 24p material and independent of splitter, codec, filter, container and a number of other things. Does this help?!
cca
27th February 2009, 17:12
I tried to play an interlaced DVD today and the video was jerky all over the place. It seems that hardware deinterlacing doesn't work correctly with this build (EVR Custom as the renderer). The same DVD plays fine with the pure SVN build.
STaRGaZeR
27th February 2009, 19:13
I tried to play an interlaced DVD today and the video was jerky all over the place. It seems that hardware deinterlacing doesn't work correctly with this build (EVR Custom as the renderer). The same DVD plays fine with the pure SVN build.
HW deinterlacing works OK here, DVDs included.
cca
27th February 2009, 19:16
Strange, and we have similar cards. I have an ATI 4850, same OS as you, Vista x64, I'm just running Catalyst 9.2. DVD decoder is ffdshow outputting NV12, in any other colorspace ATI won't do vector adaptive deinterlacing.
EDIT: I think I found the problem. I'm using ReClock with the PAL Speedown option enabled. This basically plays all 25fps videos at 24fps, but for some reason it doesn't work correctly with Beliyaal's build and EVR Custom. It's certainly a bug, since it works with other renderers, including EVR Custom with the SVN build.
STaRGaZeR
27th February 2009, 19:43
But that's always the case, it does not depend on what player or filter you're running. NV12 is required for vector adaptive deinterlacing unfortunately, you can check it in DXVAChecker under the "Processor Device" tab. You can see there that only NV12 has "VectorAdaptiveDevice" available.
BTW I'm running 9.2, time to update my sig :p
cca
27th February 2009, 19:45
Doh, you posted as I was editing my post above! I found the problem, read my post above!
STaRGaZeR
27th February 2009, 19:47
But why deinterlacing is affected? Doesn't make any sense to me.
EDIT: HDMV LPCM is labeled as "HDMW", typo I guess.
cca
27th February 2009, 19:52
But why deinterlacing is affected? Doesn't make any sense to me.
EDIT: HDMV LPCM is labeled as "HDMW", typo I guess.
Don't have a clue really, all I can report is what I see on my screen!
ACrowley
27th February 2009, 20:00
Strange, and we have similar cards. I have an ATI 4850, same OS as you, Vista x64, I'm just running Catalyst 9.2. DVD decoder is ffdshow outputting NV12, in any other colorspace ATI won't do vector adaptive deinterlacing.
EDIT: I think I found the problem. I'm using ReClock with the PAL Speedown option enabled. This basically plays all 25fps videos at 24fps, but for some reason it doesn't work correctly with Beliyaal's build and EVR Custom. It's certainly a bug, since it works with other renderers, including EVR Custom with the SVN build.
DXVA/HW Deinterlacing cant work with ffdshow!
The Decoder must use DXVA, as Cyberlink or Arcsoft etc.
HW Deinterlacing/ VectorAdaptive works perfect here on Vistax64 with HD4870 Cat 9.2 with EVR Renderer+Cyberlink SP Video Decoder
STaRGaZeR
27th February 2009, 20:09
DXVA/HW Deinterlacing cant work with ffdshow!
The Decoder must use DXVA, as Cyberlink or Arcsoft etc.
Wrong, HW deinterlacing does not require DXVA and can work with whatever decoder you use as long as that decoder passes the flags to the renderer, your colorspace is correct, etc.
cca
27th February 2009, 20:19
DXVA/HW Deinterlacing cant work with ffdshow!
The Decoder must use DXVA, as Cyberlink or Arcsoft etc.
HW Deinterlacing/ VectorAdaptive works perfect here on Vistax64 with HD4870 Cat 9.2 with EVR Renderer+Cyberlink SP Video Decoder
That's a common misconception, I used to believe the same until some time ago but it's just not true. STaRGaZeR is correct, all you need is a decoder that flags the video as interlaced and uses an appropriate colorspace, RGB for example will never work. The recommended colorspace is NV12.
mark0077
28th February 2009, 02:48
That's a common misconception, I used to believe the same until some time ago but it's just not true. STaRGaZeR is correct, all you need is a decoder that flags the video as interlaced and uses an appropriate colorspace, RGB for example will never work. The recommended colorspace is NV12.
Sorry but I get angry when anyone mentions nv12. It gives horrible colors on nvidia cards. DO NOT use nv12 if you have an nvidia card.
STaRGaZeR
28th February 2009, 03:13
Sorry but I get angry when anyone mentions nv12. It gives horrible colors on nvidia cards. DO NOT use nv12 if you have an nvidia card.
We're using ATI cards. If you ever have one if you're not feeding it with RGB32 you want NV12: vector adaptive HW deinterlacing, good chroma upsampling, working sliders for postprocessing, etc. all will only work flawlessly with NV12.
cca
28th February 2009, 21:14
Strange, and we have similar cards. I have an ATI 4850, same OS as you, Vista x64, I'm just running Catalyst 9.2. DVD decoder is ffdshow outputting NV12, in any other colorspace ATI won't do vector adaptive deinterlacing.
EDIT: I think I found the problem. I'm using ReClock with the PAL Speedown option enabled. This basically plays all 25fps videos at 24fps, but for some reason it doesn't work correctly with Beliyaal's build and EVR Custom. It's certainly a bug, since it works with other renderers, including EVR Custom with the SVN build.
Ok, today I tried a bit more, ReClock has nothing to do with it after all. Sometimes it works, sometimes it doesn't and I have no idea why so far.
Amour
1st March 2009, 11:37
http://www.olofsson.info/ not available. I cannot download the build.
I found a way to download it: right click, "download to".
sneaker_ger
1st March 2009, 16:05
Since you're meddling with the subtitle renderer I've got one bug and one feature request:
1.) Bug: When changing the option "position subtitles relative to the video frame" all stylings are lost. (edit: can't reproduce it anymore with your newest build...strange..)
2.) Feature request:There should be a fourth option to "position subtitles relative to the video frame" which should only position subtitles relative to the video frame which have position information. Subtitles without that information should still be played as they are now with the "grey" check mark for that option. With the current behavior sometimes subtitles for signs and such things grow to big and don't fit onto the screen anymore.
Jong
1st March 2009, 19:04
A few other things I have tried:
- It does not seem to be caused by Haali - Blu-ray .m2ts files have the same problem
- it is not caused by Reclock. Even if reclock is removed the issue remains the same
- It does NOT happen with PAL DVD material but does with 23.976fps DVD
- It does NOT happen if I package PAL MPEG2 in an mkv
- It happens if 24p material is played back at 47.952Hz or 50Hz (sped up by Reclock)
- I tried with and without D3D mode, without and without lock back buffer and alternate vsync and the problem remained.
- moving the vsync position while playing a video in this state did not fix it
- I also reduced subtitle buffers to zero (from 3), increased and reduced the subtitle texture size and toggled "power of 2". All made no difference.
So, as far as I can see it seems to be a problem with 24p material and independent of splitter, codec, filter, container and a number of other things. Does this help?!No. It's not 24p material that is the problem. It seems to be a problem whenever the "frame rate" on the statistics/jitter display is not the same as the display's refresh rate.
I noticed that PAL DVDs show 50fps frame rate when using my normal MPEG2 decoder (Cyberlink), even for progressive DVDs which Reclock and the VMR9 input pin report as 25p. I cannot get these to jitter.
However, if I change the video decoder to the MPC internal MPEG2 decoder 25fps is reported on the statistics screen and after a few seeks I can get the video to jitter.
I also have 25p avi files (Divx, converted from MPEG2) that are reported on the statistics screen as 25fps and I can get these too to jitter.
So, what determines the frame rate shown on the statistics screen? Why with the Cyberlink decoder does it seem to be "uprated" to match the refresh rate?
Something that is being done whenever the frame rate is half of the refresh rate (frame doubling by the MPC presenter?) seems to be buggy and sometimes generates horrible jitter.
The last thing that seems to be interesting is that although the video noticeably judders when this jitter is occuring, the <ctrl-t> "tear bar" does not - it moves smoothly across the screen. Whatever is happening seems to happen before the tear bar is drawn.
I hope it is not, but even if this bug is outside of the scope of this project Is not not possible to spot the problem and reset (same as what happens with a quick pause/play), eliminating the jitter?
Jong
1st March 2009, 19:42
In case it helps, the problem is renderer independent. It also occurs with EVR Custom presenter (on XP).
THX-UltraII
2nd March 2009, 15:58
In case it helps, the problem is renderer independent. It also occurs with EVR Custom presenter (on XP).
Jong, normally YOU are the person with all the answers :) We go way back and I know you for some years now, also on the TT forum. I recently skipped TT too since Andrew is not developing anymore (too many 2.7 promises :)).
I was going to make a suggestion to use EVR but I see that the problem is not renderer related.
What kind of display device do you use? Did you exclude the possibility that it might be your display by trying your HTPC on different displays?
Jong
2nd March 2009, 17:20
Hi.
No I have not tried different displays But as the jitter is clearly visible in MPC-HC, not just on the display, and as the refresh rate is an exact multiple of the frame rate I do not think it can have anything to do with the display.
It is as though playback does not start properly some times - the wrong info provided to the decoder or something? :confused: It is only on average one in seven times. Sometimes it will happen two times in a row, sometimes not for twenty times. It appears random. I always thought it was when playback started at just the wrong point in the scan cycle. That is why I thought this build might fix it. I accepted it as a fact of life until this build arrived. But now I can see the problem continues whereever in the frame I set the vsync.
It seems to me there must be a way of avoiding whatever glitch causes playback to go wrong or, if it is buried deep in the driver, at least reset things when we see wild jitter when frame rates and refresh rates should give smooth playback.
Kado
2nd March 2009, 18:09
@Jong
How is the Cyberlink decoder doing the de-interlace? Weave?
Jong
2nd March 2009, 18:18
@Jong
How is the Cyberlink decoder doing the de-interlace? Weave?Hi. Are you talking of the PAL DVDs that do not show the problem? The honest answer is I do not know. They are progressive movies with PAL speedup, not 50Hz interlaced video, so I'd expect it to weave the fields together.
Interestingly the MPC stats display only shows 50fps if DXVA is being used. If I manually disable DVXA in the cyberlink SD decoder it reports 25fps and I am able to get it to jitter, just as in all the other cases. It seems just this one decoder and only in DXVA mode is doing something that gets around this problem. Even the Cyberlink AVC decoder exhibits the same problem when used to playback mkvs
Jong
3rd March 2009, 12:42
Right!
I have now managed to narrow down where the bug occurs. I'm, maybe naively, very hopefully when Beliyaal returns this is fixable.
I can absolutely definitely stop this bug occurring if I use alternate vsync and turn off Vsync using the renderer settings option. I can seek 100 times and it never ever occurs. Unfortunately on each seek the tear line randomly repositions itself anywhere on the screen. It is totally unwatchable due to tearing. But the "big jitter" seen in my first screenshot never ever occurs. A nice straight line is replaced by a very slightly wobbly one, but, outside of the area of the tear, the video is smooth.
Interestingly, if I disable the alternate vsync (presumably using the original MPC-HC vsync code) the problem returns regardless of whether "vsync" is ticked or not ticked in renderer settings. It suggests the bug is not in the alternate vsync code itself, but in a piece of vsync code from the original MPC-HC that is turned on/off by the "Vsync" option in renderer settings.
Please, please Beliyaal can you take a look at this. I am very happy to help with any debug versions/tests you may devise. I feel we are tantalisingly close to the ultimate smooth video player
Casshern
3rd March 2009, 13:13
The more you describe the problem, the more i think it is related to the ATI 2600 AGP VMR9 DXVA problems. Here also the alternate vsync does not really work (random tearing position, vsync offset has no effect whatsoever). The most striking fact is that while the right mousebutton context menu is visible the problem is gone (when lock back buffers are on).....
I am also waiting for beliyaal to come back and comment on this.....
Right!
I have now managed to narrow down where the bug occurs. I'm, maybe naively, very hopefully when Beliyaal returns this is fixable.
I can absolutely definitely stop this bug occurring if I use alternate vsync and turn off Vsync using the renderer settings option. I can seek 100 times and it never ever occurs. Unfortunately on each seek the tear line randomly repositions itself anywhere on the screen. It is totally unwatchable due to tearing. But the "big jitter" seen in my first screenshot never ever occurs. A nice straight line is replaced by a very slightly wobbly one, but, outside of the area of the tear, the video is smooth.
Interestingly, if I disable the alternate vsync (presumably using the original MPC-HC vsync code) the problem returns regardless of whether "vsync" is ticked or not ticked in renderer settings. It suggests the bug is not in the alternate vsync code itself, but in a piece of vsync code from the original MPC-HC that is turned on/off by the "Vsync" option in renderer settings.
Please, please Beliyaal can you take a look at this. I am very happy to help with any debug versions/tests you may devise. I feel we are tantalisingly close to the ultimate smooth video player
Jong
3rd March 2009, 13:48
It may be related, but it is not the same.
Alternate vsync and offset position work. However, without it tearing is very evident and with it I get this 1 in 7 chance of truly terrible jitter.
I seem to have found a workaround, though. Someone will tell me I am imagining things and I have tried so many variants now they may be right!! However, I have found if I:
- Use VMR9(renderless) D3D
- use alternate vsync
- turn OFF vsync in renderer settings
- turn off D3D GUI support (if ON, tearing returns unless vsync is turned on in MPC)
- turn "wait for vsync" ALWAYS ON in CCC 3D settings
(lock back buffer seems to make no difference oneway or the other??)
I get tear free playback without the "big jitter" problem.
I do get +/-1.2-2.0ms "wobble". Std.Dev about 0.65ms. This compares with an Std.Dev of about 0.14ms when using vsync, but it will do for now and is much better than the big jitter.
One oddity that makes me thing I may be imagining things is that the frist time I play MPC after setting "wait for vsync" on in CCC I still get tearing, but after that first time all seems OK. :confused: However, I have toggled this several times now and it seems consistent, so if you try this and first time you still have tearing, try again!
Jong
3rd March 2009, 15:17
The most striking fact is that while the right mousebutton context menu is visible the problem is gone (when lock back buffers are on)Before I found my workaround I was experimenting with using Reclock's vsync controls. These are not ideal as they only work with software decoding, but I was desperate!
I did find that the Reclock on-screen vsync indicator moved right to the top of the screen when the right-click menu was on-screen :confused:
Jong
3rd March 2009, 19:10
It is possible that the "workaround" merely hides the problem from MPC-HC - when vsync is enabled in MPC-HC each judder is shown clearly in the MPC stats screen, but when using "wait for vsync" in CCC the same problem occurs but the MPC jitter graph doesn't see it. Is this possible?! :confused: I think it happens less often using CCC to control vsync; Hard to tell for sure as the jitter graph no longer helps, but it seems that way.
If so, it sound like the problem could be pretty deep in the driver/GPU and that might bring us back to needing a "recovery mode" - where MPC-HC uses its own vsync, spots erratic jitter and fixes it automatically by a clever version of pause/un-pause. But, who knows, maybe it is possible to identify the situation when erratic jitter occurs and stop it happening in the first place.
Jong
4th March 2009, 00:00
Continuing my personal vsync/judder blog......
Beliyaal, I have found out when this problem occurs. It happens when the "VBlank Wait Start", in its normal variability, goes backwards and forwards over the end of the frame. Each time this happens a big jitter occurs and as the position is so stable it keeps on happening. So this is exactly the frame flip near VBlank problem that I think this build is (amongst other things) trying to avoid.
We need to find a way to keep "VBlank Wait Start" well away from the end of the frame. At the moment it seems to start at any random position in the frame after each seek, which is not infrequently close enough to the end to cause this problem. I have not looked at how it drifts over a longer time period, but I would guess it may eventually hit this problem without a seek after a while and need "pulling away". This article (http://software.intel.com/en-us/articles/video-frame-display-synchronization/)talks about the problem and the potential solution. I could imagine a player that always starts playback with VBlank Wait Start around 10% of the way down the frame, checks it periodically and pulls it back to 10% when/if it ever peaks @95% of the way down, with a single frame hit. I think I am teaching grandmother to suck eggs here, as from what I have read this is exactly what you seem to be trying to do. However, from what I am seeing it does not seem to be working right now.
Jong
4th March 2009, 00:47
I could imagine a player that always starts playback with VBlank Wait Start around 10% of the way down the frame, checks it periodically and pulls it back to 10% when/if it ever peaks @95% of the way down, with a single frame hit. Interestingly, the Cyberlink SD Decoder, that is trouble free, seems to do almost exactly this (actually a bit cleverer!).
It never seems to start very close to the end of the frame. The start is often erractic for a few 10ths of second. Maybe it is finding a safe start point? On a couple of occasions I have seen it start around lines 800-900, stay there for a while, once stray over the frame boundary and then "magically" VBlank Wait Start is now around 50-150. It has been moved to avoid the danger area and no more jitter is seen. Also, if it is set in low region (0-100) and "blips" down over the frame boundary it is moved again to around 800-900. So whichever way the start positon drifts the gap between corrections is maximised. Why only the SP decoder (in DXVA mode) does this trick is a mystery!
STaRGaZeR
4th March 2009, 02:13
5 post in a row!
mariush
4th March 2009, 03:42
As I reported here (http://forum.doom9.org/showthread.php?p=1257406#post1257406), since I upgraded from the 9.0 driver version, MPC-HC no longer works with DXVA on my computer. Tried 9.1 and 9.2 drivers, no luck, tried several rendering methods though it worked before, tried with official version and the version on this thread... nothing helped.
Cyberlink Power DVD 8 plays DVDs using hardware acceleration just fine so I don't think it's because of some driver misconfiguration.
If you have some debug versions handy or some advice, I can find the time to test stuff and see what could fix this issue.
NeoteriX
4th March 2009, 08:18
As I reported here (http://forum.doom9.org/showthread.php?p=1257406#post1257406), since I upgraded from the 9.0 driver version, MPC-HC no longer works with DXVA on my computer. Tried 9.1 and 9.2 drivers, no luck, tried several rendering methods though it worked before, tried with official version and the version on this thread... nothing helped.
Cyberlink Power DVD 8 plays DVDs using hardware acceleration just fine so I don't think it's because of some driver misconfiguration.
If you have some debug versions handy or some advice, I can find the time to test stuff and see what could fix this issue.
If you're willing to go out on a limb, try this:
http://home.comcast.net/~exdeus/ati-hd2x00/
Leak
4th March 2009, 09:24
As I reported here (http://forum.doom9.org/showthread.php?p=1257406#post1257406), since I upgraded from the 9.0 driver version, MPC-HC no longer works with DXVA on my computer. Tried 9.1 and 9.2 drivers, no luck, tried several rendering methods though it worked before, tried with official version and the version on this thread... nothing helped.
Now, I haven't tried this as I don't use DXVA, but from what I heard the "AGP hotfix" version of Catalyst 9.2 (http://support.amd.com/us/kbarticles/Pages/CatalystAGPHotfix.aspx) (which was released a few builds after the regular 9.2 and which of course also works with non-AGP cards) is supposed to have DXVA fixed...
If you're willing to go out on a limb, try this:
http://home.comcast.net/~exdeus/ati-hd2x00/
ATI broke DXVA decoding in MPC-HC across the board from 9.1 on, so I really doubt any registry tweaks are going to help that...
littleD
4th March 2009, 12:43
Ive just put radeon hd 3450 AGP card into my computer. Installed only latest AGP hotfix catalyst 9.2 drivers without upgrading and h264/vc-1/mpeg-2 dxva with MPC HC worked at first try!!
My system was clean as i had nvidia gf card before. Maybe you should remove any registry entries from previous drivers?
Small question.
Now whole picture on my monitor looks like i have clear type checked (but it isnt). All stuff is so blurry but i have crt monitor. Can anyone help to get sharp picture? My eyes feel pain:devil:
mark0077
4th March 2009, 12:48
The most common form of blurryness on my video content is when watching DVD and mpc-hc's mpeg2 decoder detects the stream as interlaced...(90% of the time because of badly labelled DVDs) then does a bob deinterlace (essentially losing half the vertical resolution and resulting in blur effect).
If its blurry in DVD's I suggest going into mpc-hc's mpeg2 decoder, and forcing de-interlacing to "weave". Yes interlaced content will look ugly with mouse teeth, but at least 99% of your DVD's will now not look blurry.
littleD
4th March 2009, 12:52
Thanx for fast reply, but by whole i meant pulpit, fonts, internet browser not just video :) All stuff looks like clear type for LCD's. :( Is there an option in CCC to prevent that?
edit: I saw option like: synchronisation single Composite for older computers.. gives little help
Jong
4th March 2009, 15:32
I've just done a long run to see how the VBlank Wait Start varies over time. I do not know if it just because of the accuracy of my frame rate to refresh rate (using Reclock) or if it is something to do with what this build does ("accurate vsync"?) but it is very very stable. I repeatedly seeked until I got my "big jitter" problem. The variability from moment to moment in VBlank Wait Start seems to be about 100 lines on my system. After 45 minutes I was still getting the jitter problem, VBlank Wait Start was still crossing backwards and forwards across the boundary. It had moved, I would say, less than 5% of a frame in 45 mins.
From this admittedly brief test it seems if only we could start playback with VBlank WaitStart in the middle of the frame (say 550) or, more flexibly, define a target, it would never reach the trouble zone in a typical movie. This would be great. The only way to do it right now is to repeatedly seek with the stats displayed until we have the right figure. Not ideal!
As many will not have such a close match between frame rate and refresh rate I would still say we need a way to do what the Cyberlink SD Decoder (or the ATI MPEG2 DXVA implementation) does and be able to shift VBlank Wait Start when it starts crossing the boundary, but even just setting it far away from this boundary at the start would be a huge advance, even if only for those using Reclock.
littleD
4th March 2009, 17:54
Now whole picture on my monitor looks like i have clear type checked (but it isnt). All stuff is so blurry but i have crt monitor. Can anyone help to get sharp picture? My eyes feel pain:devil:
Ok forget it. I tried DVI > D-Sub converter and everything come back to normal.
Jong
4th March 2009, 23:52
Beliyaal, I finally got round to reading back 60 pages or so to where you first started talking about this new patch :o and it is clear from your very first post that the problem I am having is one of the main things you wanted to fix.
So:
- is it just the latest build that is broken?
- Is it XP?
- Could it be Cat 9.2? (by the way, 9.2 working fine with DXVA here, MPEG-2, VC-1 and H.264. VC-1 even working in DXVA2 mode!:confused:)
- or do you just think I am mad?!
As you can see I have tested this to death and I am sure I am seeing exactly the problem you describe in the first para on "Custom EVR" on the 5th Jan. Your fix just does not seem to be working here :confused::(
Beliyaal
5th March 2009, 02:49
Beliyaal, I finally got round to reading back 60 pages or so to where you first started talking about this new patch :o and it is clear from your very first post that the problem I am having is one of the main things you wanted to fix.
So:
- is it just the latest build that is broken?
- Is it XP?
- Could it be Cat 9.2? (by the way, 9.2 working fine with DXVA here, MPEG-2, VC-1 and H.264. VC-1 even working in DXVA2 mode!:confused:)
- or do you just think I am mad?!
As you can see I have tested this to death and I am sure I am seeing exactly the problem you describe in the first para on "Custom EVR" on the 5th Jan. Your fix just does not seem to be working here :confused::(
Sorry for not replying earlier, and thank you for the detailed analysis!
I'm aware of the problem, but haven't tried to fix it in the current code as I'm going to rewrite the vsync code (hopefully this weekend). The problem I was talking about earlier is another one related to this issue only appearing in Vista with aero enabled. Maybe the same issue with always vsync enabled in CCC, but I cannot detect this and apply the fix in XP.
Now it will try to display a frame basically after it is time to display it with an offset for how long it takes to draw the frame. This can cause it miss the VSync when it's too close to it.
What I'm going to do instead is to try to display it "directly" after the VSync before the next VSync. This will give it the maximum amount of time to hit the VSync. This has some prerequisites not currently available however, such as the exact refresh rate being detected.
Also It's not possible to change the VSync position by manipulating the video. The only thing you can do is manipulating the audio or screen refresh rate. I have been thinking about adding an option for this later that pauses the audio until it has a good position, or maybe changing the screen refresh with PStrip to something slightly below or above the target rate to make the sync pos glide into the correct position.
It might not be needed with the new VSync code, but it will be needed to have perfect audio/video syncronization. 24 FPS can vary 40 ms because of this, so it might be desirable to keep the VSync at a known location. This is a later project I have been considering however, with need for audio/video calibration support in the player.
I hope you can figure out a solution for the Vsync problems, ReClock is not doing a bad job but it has it's limitations. I use only 60Hz as my refresh rate, limitation of my TV, won't accept any other refresh rate. At this setting, I don't have a problem with 24fps videos, but 30fps is different story. ReClock is absolutely neccesary in this care or stuttering will occur.
If you manage to fix the vsync problem at least, ReClock will be limited just to audio resampling in order to sync the video with the refresh rate. There is no way to make it better than this without major tweaking, like changing the refresh rate etc, which doesn't always work due to hardware limitations, like in the case of my TV.
Jong
5th March 2009, 14:17
Sorry for not replying earlier, and thank you for the detailed analysis!
I'm aware of the problem, but haven't tried to fix it in the current code as I'm going to rewrite the vsync code (hopefully this weekend). The problem I was talking about earlier is another one related to this issue only appearing in Vista with aero enabled. Maybe the same issue with always vsync enabled in CCC, but I cannot detect this and apply the fix in XP.
Now it will try to display a frame basically after it is time to display it with an offset for how long it takes to draw the frame. This can cause it miss the VSync when it's too close to it.
What I'm going to do instead is to try to display it "directly" after the VSync before the next VSync. This will give it the maximum amount of time to hit the VSync. This has some prerequisites not currently available however, such as the exact refresh rate being detected.
Also It's not possible to change the VSync position by manipulating the video. The only thing you can do is manipulating the audio or screen refresh rate. I have been thinking about adding an option for this later that pauses the audio until it has a good position, or maybe changing the screen refresh with PStrip to something slightly below or above the target rate to make the sync pos glide into the correct position.
It might not be needed with the new VSync code, but it will be needed to have perfect audio/video syncronization. 24 FPS can vary 40 ms because of this, so it might be desirable to keep the VSync at a known location. This is a later project I have been considering however, with need for audio/video calibration support in the player.Thanks for the reply. I'll wait for the new version.
It seems to me though from looking at MPC-HC with your stats screen there are two "vsyncs", or at least approaches to vsync.
- There is what I assume (maybe wrongly) is the time the frame is written to the frame buffer relative to the VBlank. this is what seems to be meant by "Vblank Wait Start" (or at least they are closely related!). You can see it as the tear line when you use "alternate vsync" and turn vsync off in renderer settings. It starts at a random point whenever playback starts, oscillates by about 100 scanlines but is otherwise very very stable, at least when using Reclock. In 45 mins yesterday the midpoint varied by no more than 50 scanlines. This also seems to be the thing that Reclock manipulates when it is doing vsync correction. If I turn off your vsync correction and use reclock's it clearly moves the tear point.
- There is then the point of the tear when your vsync is on, altered by the vsync offset. I assume (again maybe wrongly!) this is the "flip" time and using standard vsync tools, such as the normal MPC-HC one it is firmly anchored at near Vblank (invisible).
It seems it is possible to move the first of these, by some method or other. Reclock does it (with vsync tools enabled) and it moves after every seek. It also seems that MPEG-2 DXVA moves it too at exactly the right time to avoid jitter. It appears that if we can shift this whenever it approaches the VBlank time (+/-5%?) and jump it over the VBlank boundary we could avoid the jitter.
It may be better to do this little trick in Reclock if possible (I've opened a thread (http://forum.slysoft.com/showthread.php?p=180484#post180484)there). if Reclock can do it I think it would fix the same problem in PDVD too, which would be cool! But maybe this is not possible?
But do correct me if I am misinterpreting this stuff! I know I am working laregly in the dark here with inadequate info!!
Jong
5th March 2009, 16:14
I've found something rather interesting!
If I use "alternate vsync" and turn on Reclock's Vysnc correction it almost fixes the problem (in a different way)!
If the Reclock desired vsync position is at the top of the frame VBlank wait Start rolls upwards. If it is at the bottom it rolls downwards. If it is in the middle it is almost stable. The balance point is always the same whenever a video is played.
The problem is the Reclock vsync can only be set in 0-100% integer steps. If we could increase the accuracy of the Reclock vsync tool and be able to set a target for VBlank we would have somethig even better than I thought. We could stop it ever getting hear the trouble zone! (I think!!)
edit.... not sure maybe "accurate vsync off" is also needed for this to work properly. Either way Reclock can make a difference, but it seems more predicatable what to do with accurate vsync off. Beliyaal, you will know how this affects things I guess!
I have ReClock's vsync set at exactly 50 and MPC's Vsync completely off, otherwise MPC's takes priority. It works for me hovering around the middle. Remember, I only have occasional stutter problems, tearing is an unknown thing in windows vista with Aero active.
Jong
5th March 2009, 16:44
I have ReClock's vsync set at exactly 50 and MPC's Vsync completely off, otherwise MPC's takes priority. It works for me hovering around the middle. Remember, I only have occasional stutter problems, tearing is an unknown thing in windows vista with Aero active.Are you using "alternate vsync" or the normal MPC version?
Actually, there is NO normal MPC version, the SVN version of MPC has no support for Vsync at all! All the vsync code is Beliyaal's code. Anyway, I use none of the two, I keep Vsync completely off from Render Options, because none is working correctly here.
Jong
5th March 2009, 19:17
Actually, there is NO normal MPC version, the SVN version of MPC has no support for Vsync at all! All the vsync code is Beliyaal's code. Anyway, I use none of the two, I keep Vsync completely off from Render Options, because none is working correctly here.Here at least, using XP, VMR9 and D3D there is certainly vsync correction. Turning on "alternate vsync" replaces it. Using alternate vsync and turning it off in renderer settings leaves no vsync correction and allows you to use Reclock if you wish.
Here at least, using XP, VMR9 and D3D there is certainly vsync correction. Turning on "alternate vsync" replaces it. Using alternate vsync and turning it off in renderer settings leaves no vsync correction and allows you to use Reclock if you wish.
VMR9 windowed or VMR9 Renderless? The renderless one should have no correction, but the windowed one has. I 'm always talking about normal use, NOT for D3D fullscreen, I never use that mode, it's inconvient for me.
73ChargerFan
5th March 2009, 19:47
MCE2005 SP3, Beliyaal build 15, ATI 4850, Catalyst 8.??
Speaking of the D3D fullscreen mode, I've switched to it for my HTPC, thanks Beliyaal for the menus.
I'd like to request two things which would make it perfect:
Under Options->Player, there is "Exit fullscreen at the end of playback". It doesn't work, it just stays black. I'd like mpc to completely exit, instead of making the tv look like it was turned off.
The seek bar: stay on the screen 1 second longer, move it off the bottom of the screen, and it is UGLY. My DLP is set to 1080p 1:1 mapping, no scaling, so things at the bottom (and top, left, right) of the screen disappear. I can only see the top few pixels of the seek bar.
Thanks again! :)
Kado
5th March 2009, 21:37
@73ChargerFan
It does not work because it was made to work with regular fullscreen where you can toggle it between windowed and fullscreen. To exit fullscreen using "D3D fullscreen mode" you have to close the video using "ALT+C".
Jong
6th March 2009, 09:04
VMR9 windowed or VMR9 Renderless? The renderless one should have no correction, but the windowed one has. I 'm always talking about normal use, NOT for D3D fullscreen, I never use that mode, it's inconvient for me.D3D is only available in Renderless mode. It certainly has Vsync correction here. It is historically one of the main reasons for using it
D3D is only available in Renderless mode. It certainly has Vsync correction here. It is historically one of the main reasons for using it
VMR9 Renderless doesn't seem to have any kind of vsync correction, the Vsync indicator of Reclock is all over the place, going up and down randomly. It's the same with EVR Custom. If you try the normal EVR for example, you'll see Reclock's vsync OSD staying at the top of the screen all the time, because it has active Vsync correction.
Jong
6th March 2009, 09:24
In D3D mode? :confused: I'm sure Reclock's vsync is pinned in that mode. :confused:
Well, it's not as far as I can see. And I mean with all vsync correction off in MPC and Reclock. If you have any of them active, ofcourse it will be pinned.
Jong
6th March 2009, 10:17
Yeah, I take it back sorry! I was getting confused with the Beliyaal build with alternate vsync turned off, which I thought was the same the normal build (and because it never tears). But, my bad!
Jong
6th March 2009, 10:45
cca, with the original MPC-HC try VMR9(renderless), not D3D with VMR Mixer enabled, Reclock vsync correction off. Now turn on Reclock vsync position display. That seems to have vsync correction here.
cca, with the original MPC-HC try VMR9(renderless), not D3D with VMR Mixer enabled, Reclock vsync correction off. Now turn on Reclock vsync position display. That seems to have vsync correction here.
hmm, perhaps it has, but it's not really effective. Also, things may be different on Vista with aero, which is what I use.
All this is not really helpfull, we end up spamming the thread. Let's wait for Beliyaal's new build, in the mean time use whatever works best.
Jong
6th March 2009, 11:42
I agree, but I am still keen to try to use what Beliyaal has exposed by his work here to try and find a fix in Reclock that works for other players too (especially Blu-ray in PDVD). But that I will try to keep to the Reclock thread! :o
tetsuo55
6th March 2009, 15:54
I found a workaround for the Catalyst 9.2 bug.
It might be be a MPC-HC bug, more here:
http://forum.doom9.org/showthread.php?p=1258278#post1258278
Jong
6th March 2009, 17:33
@Beliyaal,
Any chance we could have an option in your build, if even just for comparision during testing, where we get your stats, but the same vsync code as in the normal build?
With D3D EVR Custom, for example, the normal build has no vsync correction and we can use Reclock's. However, with your build vsync still seems "pinned" whatever option you choose. Well not quite true. I can unpin with the alternate vsync but then there is tearing not visible in the normal build.
73ChargerFan
6th March 2009, 19:46
@73ChargerFan
It does not work because it was made to work with regular fullscreen where you can toggle it between windowed and fullscreen.
Thanks, I don't use that mode, and didn't know that.
To exit fullscreen using "D3D fullscreen mode" you have to close the video using "ALT+C".This I did know.
My request is for an enhancement, and Beliyaal was kind enough to add menus to D3D fullscreen, so I'm asking here.
I don't have a keyboard on my HTPC, and D3D fullscreen is the best on my system - no tearing, shaders available. But a big black screen at the end is the only real down side.
Jong
6th March 2009, 19:55
But a big black screen at the end is the only real down side./close in the command line works here with D3D
Chumbo
7th March 2009, 03:53
...To exit fullscreen using "D3D fullscreen mode" you have to close the video using "ALT+C".
I believe it's Ctrl-C to exit fullscreen and Alt-X to exit the program.
Kado
7th March 2009, 04:06
@Chumbo
You are right about that, my mistake.
Beliyaal
11th March 2009, 00:58
New version available (link in signature):
* Updated to SVN 1009
* Added: The movie FPS is now estimated. A "L" will appear after the FPS when this happens. Only when this L is displayed will the time correction code be activated.
* Added: Screen refresh rate detection and detection of the number of scanlines of the display.
* Fixed: Correction of timing in VC-1 material should work again. Note that it might stutter a while until the movie FPS is detected when starting to play and when seeking.
I have not yet fixed the stuttering. I have however implemented refresh rate and scanline detection. This is needed for the new "anti stuttering" code to work. So please check if the refresh rate and number of scanlines are reported correctly on your machine:
Screenshot showing the values to check (http://www.olofsson.info/mpchc/RefreshRate.jpg)
I have marked the new move fps detection value as well. Only when this value is "locked" showing "L" after the FPS will the frame time correction code kick in and VC-1 material will be corrected.
You can also check the first post for the list of known bugs. If you feel I have forgotten a bug that should be fixed before integrating into SVN, please tell me.
Beliyaal
11th March 2009, 01:13
@Beliyaal,
Any chance we could have an option in your build, if even just for comparision during testing, where we get your stats, but the same vsync code as in the normal build?
With D3D EVR Custom, for example, the normal build has no vsync correction and we can use Reclock's. However, with your build vsync still seems "pinned" whatever option you choose. Well not quite true. I can unpin with the alternate vsync but then there is tearing not visible in the normal build.
That's not really possible. You should get pretty close to the original code if you disable alternate vsync, and disable VSync.
dzy
11th March 2009, 01:56
hi Beliyaal
Is it possible to add a font-remapper to the subtitle renderer?
So it won't just remap all unavailable fonts to the default font.
MatMaul
11th March 2009, 02:02
You can also check the first post for the list of known bugs. If you feel I have forgotten a bug that should be fixed before integrating into SVN, please tell me.
the tiny weird line at the bottom of videos is still here.
http://forum.doom9.org/showpost.php?p=1238622&postcount=5949
Kado
11th March 2009, 02:37
@Beliyaal
I suppose that the "Repeat forever will display black screen randomly" bug is the one that when the video repeats it gets stuck at the last frame but the audio stars again and eventually playback hangs but the player it self does not hang, right?
Thanks for the new build.
@MatMaul
Doesn't that happen with the regular homecinema build as well? I think he was talking about bugs introduced by his patch maybe?
STaRGaZeR
11th March 2009, 02:46
I'm not experiencing the black screen when repeat forever is enabled so far with ver 16.
However I've found another bug that is also present in the main trunk. Only with EVR Custom, when the end of the file is reached, the buffered frames are not displayed. This means that when buffers are set to 20, the last 20 frames of the file will get skipped (1 sec aprox). This can be confirmed by setting buffers to 3 and seeing how the skipped part is way smaller or by looking at the stats, the buffers never go 19->1 at the end of the file. Very small sample to test (voice till the end): http://www.megaupload.com/?d=ZP7Z4Z9S (188 KB)
Kado
11th March 2009, 03:38
Looks like you are right about the repeat bug but for the second issue the buffer runs to 1 here.
cca
11th March 2009, 10:05
The maximum subtitles buffers are still 10, please increase it in the next build. For the time being I changed it manually in the mplayerc.ini, set it at 60 and it works perfectly in my PC. I will report on the scanline test when I get in my home PC latter.
tetsuo55
11th March 2009, 10:38
While reading about windows 7 i discovered some nice things in vista.
GPU memory is virtualised and paged to the system RAM.
If system RAM is full pages are written to the Page File.
This basically means that we have access to unlimited GPU memory for things like Subtitle-Buffering.
Also i am now using windows 7 7048 and with the normal build i have tearing free but not stutter free playback. Going to try the new Beliyaal build asap
MatMaul
11th March 2009, 11:29
Doesn't that happen with the regular homecinema build as well? I think he was talking about bugs introduced by his patch maybe?
It is specific to Beliyaal build, no problem with SVN
Jong
11th March 2009, 13:06
That's not really possible. You should get pretty close to the original code if you disable alternate vsync, and disable VSync.That does not seem to be true here.
I have not tried all renderer combinations, but on XP for both VMR9 renderless D3D (VMR Mixer and YUV mixing enabled) and EVR CP D3D the standard build has no vsync enforcement, but your build does, even when alternate vsync is disabled and vsync is unchecked. It is locked about 5% down the screen. I've confirmed this with build 15 and build 16.
Jong
11th March 2009, 13:17
I have not yet fixed the stuttering. I have however implemented refresh rate and scanline detection. This is needed for the new "anti stuttering" code to work. So please check if the refresh rate and number of scanlines are reported correctly on your machine:Not reported correctly here. The number of scan lines varies from about 1123 to 1137 and doesn't really settle. The correct figure is 1127. The refresh rate says varying between 50.01 and about 50.04. Reclock says it is locked on 50.000Hz.
I don't know how accurate these need to be but it sounds similar to the problem James had with Reclock some months ago where it would incorrectly determine the number of scanlines and set up a growing number of new timings for each figure it calculated. That is why, in the end, he used the Pstrip API (if pstrip was running) and GDI, if pstrip was not present, to directly query the timings being used by the GPU.
cca
11th March 2009, 13:18
Tested the refresh rate/scanline detection. Scanlines are reported as 798 or 799, ReClock finds 799, so it seems acurate to me. Refresh rate is more or less accurate, it varies a bit but it's close.
iron2000
11th March 2009, 14:38
The refresh rate and scanline doesn't seem to show up on my PC.
Refresh rate shows 0.00000Hz and SL shows 0.
Not sure if anything is wrong on my side.
EDIT:
At first when I switched to EVR CP I can see the "L".
Then on switching back to VMR9 Renderless, SL displays -2147483648.
But on VMR9 theres no "L".
Jong
11th March 2009, 14:49
I think you have to have vsync enabled (in renderer settings)for it to work.
Jong
11th March 2009, 14:51
Not reported correctly here. The number of scan lines varies from about 1123 to 1137 and doesn't really settle. The correct figure is 1127. The refresh rate says varying between 50.01 and about 50.04. Reclock says it is locked on 50.000Hz.Just ran this again and was getting figures as low as 1020 with a mean about 1075. So definitely not right here.
Kado
11th March 2009, 15:18
@cca, tetsuo55
Remember that system memory is way slower than the gpu memory and that page file (hdd) is even slower.
If I use 60 the fluctuation in the statistics graph is way higher.
You can change it in the registry in "HKEY_CURRENT_USER\Software\Gabest\Media Player Classic\Settings" SPCSize.
cca
11th March 2009, 15:25
@cca, tetsuo55
Remember that system memory is way slower than the gpu memory and that page file (hdd) is even slower.
If I use 60 the fluctuation in the statistics graph is way higher.
You can change it in the registry in "HKEY_CURRENT_USER\Software\Gabest\Media Player Classic\Settings" SPCSize.
True, but I think my VGA can handle 60 buffers in it's own memory. I have tried many combinations until I ended up with 60, for each system that number is not the same. I 've reduced the number of EVR buffers at the minimum 3, and set the subtitle resolution to 1280x720. If you make the calculations, 60 textures of that resolution fit in 512 MB of memory with plenty to spare for aero and the video itself.
iron2000
11th March 2009, 15:28
Vsync enabled doesn't help.
Kado
11th March 2009, 15:35
@iron2000
Here only works with Vsync enabled as well under "View => Renderer Settings".
@cca
I was using 20 EVR buffers, 60 subtitle subtitle buffers @ 1680x1050 res with Suzumiya Haruhi video. 9800GTX 512MB. I will try without DXVA later.
cca
11th March 2009, 16:58
The problem I had with DVD playback with version 15 is much worse now with version 16. Playback doesn't even starts. It does work with the internal MPEG2 filter, but that filter sucks for ATI cards, it doen't output NV21 but YUY2, with totally sucks for interlaced videos. With ffdshow as the decoder, MPC totally freezes and I have to kill it. SVN 1009 works perfectly fine. I am always referring to interlaced material with the intrlaced flag enabled in the decoder.
iron2000
11th March 2009, 17:31
Hmm...
I even tried setting the vertical refresh to always on in CCC and VSync enabled in the renderer settings but still doesn't show.
Or is it a Vista-EVR thing as I'm on XP SP3?
cca
11th March 2009, 18:07
Hmm...
I even tried setting the vertical refresh to always on in CCC and VSync enabled in the renderer settings but still doesn't show.
Or is it a Vista-EVR thing as I'm on XP SP3?
It's possible. I tried it on my office PC this morning with VMR9, doesn't work. Works fine in my home PC that runs Vista x64 with EVR Custom.
STaRGaZeR
11th March 2009, 19:11
Looks like you are right about the repeat bug but for the second issue the buffer runs to 1 here.
Have you tried the sample? The last word, concentration, is completely cut off with 20 but it's fine with 3.
Kado
11th March 2009, 19:53
@STaRGaZeR
I can confirm with your sample, the video buffers remain at 19 instead of going to 0 but with haruhi that does not happen and the buffer goes all the way to 0.
@cca
Why do you want 60 buffers if MPC according to the statistics only uses 1 or 2 while playing ass styled karaoke?
cca
11th March 2009, 20:11
@cca
Why do you want 60 buffers if MPC according to the statistics only uses 1 or 2 while playing ass styled karaoke?
Because it drops subtittles when some heavy typesetting is used. Example gg's Maria+Holic episode 8. The typesetting in this episode is a killer.
While we are at the subject, the only reason I ever wanted buffers with EVR or Haali renderer was because of subtitle effects that are CPU killers. Before Beliyaal's builds, VSfilter had to do the job, so I needed Video buffers. Now that MPC does the job, I need subtitle buffers, the video decoding itself is a piece of cake for my CPU, and most the time the GPU does it with DXVA2. I agree though that the majority of anime fansubbers do no use so CPU heavy effects. But some do!
Also, although most people won't ever need it, I want to able to choose. Why should it be restricted? It works for me, I use it, that's all.
Jong
11th March 2009, 20:14
Hmm...
I even tried setting the vertical refresh to always on in CCC and VSync enabled in the renderer settings but still doesn't show.
Or is it a Vista-EVR thing as I'm on XP SP3?No. working fine on XP SP3 with VMR9(renderless) and EVR-CP here.
Kado
11th March 2009, 20:31
@cca
Can you point a specific time on that episode so I can check myself?
Found one, at 11.30 to 11.45! I'll do more tests and report later on.
cca
11th March 2009, 21:16
@cca
Can you point a specific time on that episode so I can check myself?
Found one, at 11.30 to 11.45! I'll do more tests and report later on.
Also check at 9:30 to 9:40 and 15:00 to 15:10
Egh
11th March 2009, 23:11
I can confirm the SL/RF bug on XP.
Using VMR9 in any mode (vsynс on, alternative vsync, D3D) doesn't display any values for refresh/scanlines any different from zero :D
Interesting that old detection works: i.e. SVN build shows 60Hz value and I guess the same value is displayed in brackets in this build.
Jong
11th March 2009, 23:32
:o Yeah, sorry. I had been testing VMR9 and EVR CP on XP and I really thought I had seen refresh rate and scanline data for both, but I have just checked and only EVR CP seems to work.
ADude
12th March 2009, 01:03
If you feel I have forgotten a bug that should be fixed before integrating into SVN, please tell me.
The original Beliyaal version breaks playback of .FLV (flash video) files.
Was that corrected at some point ?
Beliyaal
12th March 2009, 08:57
The original Beliyaal version breaks playback of .FLV (flash video) files.
Was that corrected at some point ?
I have it in the known bugs list:
* Flash video files (flv) not working correctly
The bug is that the movie isn't displaying at the correct FPS right?
Jong
12th March 2009, 11:03
Version 16 has broken VC-1 playback for me. Using XP, Cat9.2 with EVR CP D3D & DXVA2 and VMR9 non-D3D. 1920x1080 VC-1 in mkv container.
V16 judders continuously and very badly, like it is displaying in reverse field order (video is progressive but comes from HD-DVD source). The problem affects all my VC-1 rips. The jitter chart shows no problem at all.
V15 and SVN are both fine.
Beliyaal
12th March 2009, 16:14
Version 16 has broken VC-1 playback for me. Using XP, Cat9.2 with EVR CP D3D & DXVA2 and VMR9 non-D3D. 1920x1080 VC-1 in mkv container.
V16 judders continuously and very badly, like it is displaying in reverse field order (video is progressive but comes from HD-DVD source). The problem affects all my VC-1 rips. The jitter chart shows no problem at all.
V15 and SVN are both fine.
That is strange since VMR9 has no frame time correction. Do you have a sample or specific source that you can point to? Does it work without DXVA (Test microsoft decoder)?
Jong
12th March 2009, 18:05
It happens with all of my VC-1 encoded mkvs remuxed (not re-encoded) from HD-DVD.
It appears to think the frame rate is 47.952fps.
http://jong.pwp.blueyonder.co.uk/images/BR_Belyaal16.jpg
If you can give me an ftp address I can upload a 30 second segment (64MB).
(all is fine when not using DXVA. I used the MPC decoder, but disabled DXVA mode. Edit....Actually, VMR9 seems OK, EVR CP seems to hang more than 50% of the time with a black screen and just "Pause" in top left).
cca
12th March 2009, 19:01
Actually it thinks it's interlaced, trying to do hardware deinterlacing so you see double the framerate. Sounds familiar, I have problems with interlaced DVDs.
Jong
12th March 2009, 19:47
Well that's why I mentioned it was from an HD-DVD. All HD-DVD have 3:2 pulldown flags, right? Yes, I could have stripped them out with EAC3to but didn't. But not a problem until now.
DigitalDeviant
13th March 2009, 04:31
The problem I had with DVD playback with version 15 is much worse now with version 16. Playback doesn't even starts. It does work with the internal MPEG2 filter, but that filter sucks for ATI cards, it doen't output NV21 but YUY2, with totally sucks for interlaced videos. With ffdshow as the decoder, MPC totally freezes and I have to kill it. SVN 1009 works perfectly fine. I am always referring to interlaced material with the intrlaced flag enabled in the decoder.
I have this same problem.
Beliyaal
13th March 2009, 12:07
New version available (link in signature):
* Update to latest SVN.
* Changed: EVR buffers can now be changed to up to 60 buffers.
* Changed: Subtile buffers can now be changed to up to 60 buffers.
* Changed: Make the 32 bit version Large Address aware, allowing it to use 4 GB instead of 2 GB memory on 64 bit OS.
* Fixed: Hang when launching.
* Fixed: Option for output range in EVR CP. Finally we can use the hardware deinterlacer without loosing color resolution!
* Fixed: Corrected position of sync offset graph.
When I was trying to fix the hardware deinterlacing problems I noticed that the output space was wrong with EVR CP, so I fixed this by setting the correct flag in the EVR. Please see the new options(0 - 255 and 16 - 235) in render settings to choose the color space when doing yuv to RGB conversion with EVR.
yesgrey
13th March 2009, 12:30
Beliyaal,
I have some problems with the subtitles. It seems to be an easy thing to solve, could you take a look?
The problem is that the subtitles rendering appear to consider always a frame rate of 25fps for the timing.
If I watch a 23.976fps file, the subtitles are displayd as if it was a 25fps file. I know it's not a problem with the subtitles file, because with Zoomplayer (using Vobsub) everything works fine. I have tryed your build and it seems to be great, very smooth video playing, but the subtitles issue make it unusable to me...:(
Thanks.
mark0077
13th March 2009, 12:35
This build is really becoming excellent. If it can rival / beat ffdshow's colorspace conversion to RGB, and can sync frames to screen as good (or betteR?) than reclock then for me anways I will be able to use beliyaal's build of mpc-hc on its own with no extra filters.
The only reason I might use reclock in the future is for PAL speeddown, maybe a future project for beliyaal .
But I have a question, I am sure it has been asked many times before. If I do use reclock for the PAL speed correction, what is the best method to get frames synced to my screen. Using ReClock's "Vsync" option, or using mpc-hc evr-cp vsync option, or both. I really don't know how the two renderers work when for example both have vsync enabled. Which comes last in the chain and therefore has the last "word" in the process.
Thanks for all the work.
cca
13th March 2009, 12:59
When I was trying to fix the hardware deinterlacing problems I noticed that the output space was wrong with EVR CP, so I fixed this by setting the correct flag in the EVR. Please see the new options(0 - 255 and 16 - 235) in render settings to choose the color space when doing yuv to RGB conversion with EVR.
O.o holy crap, finally!!!
clsid
13th March 2009, 13:30
Once the EVR CP levels fix has been properly tested, can you port it back to trunk? It is useful for a lot of MPC users.
Jong
13th March 2009, 13:31
That does not seem to be true here.
I have not tried all renderer combinations, but on XP for both VMR9 renderless D3D (VMR Mixer and YUV mixing enabled) and EVR CP D3D the standard build has no vsync enforcement, but your build does, even when alternate vsync is disabled and vsync is unchecked. It is locked about 5% down the screen. I've confirmed this with build 15 and build 16.Beliyaal, any chance of a comment on this?
I would love to use your build as my main player, and so hopefully give better feedback, even before the vsync stuff is fixed, for the D3D improvements and the improved stats. But the inability to turn off your, still in development, vsync and use Reclock instead makes this impossible. Alternate vsync can be turned off, but this also seems to turn off flipping. Or at least it is impossible to eliminate on-screen tearing with alternate vsync.
Jong
13th March 2009, 13:41
Once the EVR CP levels fix has been properly tested, can you port it back to trunk? It is useful for a lot of MPC users.What is the problem here. My focus has been in other areas and I have not been inspecting for colorspace issues.
From superficial inspection levels on my XP system with ATI seem consistent with other renderers (all video expanded to 0-255), at least I didn't notice anything wrong and normally I would.
What about BT.601/BT.709 conversion? How is this being handled?
cca
13th March 2009, 13:47
What is the problem here. My focus has been in other areas and I have not been inspecting for colorspace issues.
From superficial inspection levels on my XP system with ATI seem consistent with other renderers (all video expanded to 0-255), at least I didn't notice anything wrong and normally I would.
What about BT.601/BT.709 conversion? How is this being handled?
You are lucky if you don't have a problem. I'm having wrong levels ever since I updated to ATI Catalyst 9.2 in EVR Custom, Beliyaal just fixed it!
In other news, the interlacing problems are still present, but at least now it doesn't hang the player. Some times it works, but most of the time I just see horrible stuttering, interlaced DVDs are practically unwatchable for me.
Beliyaal
13th March 2009, 14:40
Beliyaal, any chance of a comment on this?
I would love to use your build as my main player, and so hopefully give better feedback, even before the vsync stuff is fixed, for the D3D improvements and the improved stats. But the inability to turn off your, still in development, vsync and use Reclock instead makes this impossible. Alternate vsync can be turned off, but this also seems to turn off flipping. Or at least it is impossible to eliminate on-screen tearing with alternate vsync.
The vsync code that is enabled when you are not using alternate VSync is the same as the normal build. It simply tells D3D to do the vsync. I have noticed that the vsync position in this case is wrong when you use PStrip to change the refresh rate. I think that the driver doesn't know about the refresh rate change and syncs to the wrong position, but I'm not sure if this is the case.
Beliyaal
13th March 2009, 14:45
Once the EVR CP levels fix has been properly tested, can you port it back to trunk? It is useful for a lot of MPC users.
I could easily change it to default to 0 - 255 instead of undefined, but I would rather not adding the settings for choosing the output levels in SVN, as this is a lot more work with all the localizations.
Jong
13th March 2009, 14:54
The vsync code that is enabled when you are not using alternate VSync is the same as the normal build. It simply tells D3D to do the vsync. I have noticed that the vsync position in this case is wrong when you use PStrip to change the refresh rate. I think that the driver doesn't know about the refresh rate change and syncs to the wrong position, but I'm not sure if this is the case.Well it is very odd. With the normal build Reclock's vsync indicator shows a different position for vsync on every seek (Reclock correction off). And when Reclock correction is turned on it quickly pulls vsync to the correct location.
However, with your build and alternate sync not selected, Reclock shows the vsync location pinned to the top 5% of the screen even with vsync "off" and it does not move when Reclock's correction is turned on, although it does cause a "rolling" of the "Present Wait" time with judder as this passes through zero.
I don't know how else to explain this other than vsync is truly off with the normal build, but on in yours. Even if I am wrong in that they certainly behave very differently!
Your comments about vsync and pstrip are very interesting though. Something to ponder.
Beliyaal
13th March 2009, 14:57
Well it is very odd. With the normal build Reclock's vsync indicator shows a different position for vsync on every seek (Reclock correction off). And when Reclock correction is turned on it quickly pulls vsync to the correct location.
However, with your build and alternate sync not selected, Reclock shows the vsync location pinned to the top 5% of the screen even with vsync "off" and it does not move when Reclock's correction is turned on, although it does cause a "rolling" of the "Present Wait" time with judder as this passes through zero.
I don't know how else to explain this other than vsync is truly off with the normal build, but on in yours. Even if I am wrong in that they certainly behave very differently!
Your comments about vsync and pstrip are very interesting though. Something to ponder.
It might be Reclock that doesn't detect the renderer as one that it can do correction with. Or something I change causes it not to be able to correctly detect the vsync position.
Jong
13th March 2009, 15:01
You are lucky if you don't have a problem. I'm having wrong levels ever since I updated to ATI Catalyst 9.2 in EVR Custom, Beliyaal just fixed it.Maybe it is an XP/Vista thing. But as I said I have not really been inspecting for levels this week and only moved to EVR custom when I discovered it allowed DXVA2 acceleration of VC-1 along with Reclock vsync correction. I will look closer.
Yeah. That judder with my VC-1 material is the worst I have seen and sounds related to the interlaced issues.
Jong
13th March 2009, 15:06
It might be Reclock that doesn't detect the renderer as one that it can do correction with. Or something I change causes it not to be able to correctly detect the vsync position.Hmmm. Maybe. But with alternate sync on and vsync off Reclock shows vsync position is unpinned and it CAN control it. It is just that there seems to be no flipping so a tear is clearly visible at the vsync location.
It is just with alternate sync off that vsync on/off seems to do nothing (other than change the stats so "Present Wait" varies from seek to seek instead of "VBlank Wait"). :confused:
Jong
13th March 2009, 15:21
Beliyaal, do you need this VC-1 clip of mine or are you on top of this now?
clsid
13th March 2009, 15:34
I could easily change it to default to 0 - 255 instead of undefined, but I would rather not adding the settings for choosing the output levels in SVN, as this is a lot more work with all the localizations.
I guess it is time for a shared resource file that is included by all localized ones. I suggested it to Casimir long ago, but neither of us has had time to implement it.
Its main purpose is to contain non-translatable stuff. But it would also be useful for temporarily containing 'new' resources that are not yet localized.
Ger
13th March 2009, 16:04
EVR buffers seems to have gone up from 5 to 20 now (between v16 and v17). Is this an intentional new default value or perhaps a side effect of the extended buffer range? Should we set it back to 5 manually?
Also, regarding the new 0-255/16-235 renderer option, should this be set to whatever your monitor uses to get the correct output level?
If that's the case, perhaps it would be better if this was a per monitor setting so it doesn't have to be changed manually when you move between monitors. Aleksoid's multi-monitor fullscreen code already detects the different monitors in MPC-HC, so I think it should be possible to store a separate setting for each monitor/TV?
cca
13th March 2009, 16:04
BUG: To the EVR buffers value selected 3 more are used. Example: if I select 3 EVR buffers, 6 are used, if I select 10, 13 are used.
STaRGaZeR
13th March 2009, 16:58
I post here too a bug report that you've missed:
EDIT:
http://thumbnails13.imagebam.com/2686/371f9626851837.gif (http://www.imagebam.com/image/371f9626851837)
Looks like the old issue with bicubic resizer, the transparent grid, is back in your builds too. Look at their faces and eyes. I think this was an issue before but Casimir found a solution and it's not present in SVN builds. This does not happen just after opening the player, maybe you have to open several files to see it because it's totally random.
As I say I've not found the reason or the steps to reproduce the issue, but maybe Casimir or leeperry (I think it was him the one who reported this the first time) can help you.
BUG: To the EVR buffers value selected 3 more are used. Example: if I select 3 EVR buffers, 6 are used, if I select 10, 13 are used.
Yup, confirmed.
mark0077
13th March 2009, 18:52
Just testing your new build and a 1080p vc1 .ts file that I use for testing. I was actually testing mpc-hc's decoder vs ffdshow's for dropping frames and notice mpc-hc to be MUCH smoother. To try and see could I even get mpc-hc to register 1 dropped frame I begin enabling things in ffdshow like I forced de-interlacing....OK the image didn't look correct, but two things happened.
With de-interlacing enabled (just to try and stress the player out)
1) mpc-hc slowed to a crawl, video played at half speed (even though cpu usage was only 18%).
2) After turning off de-interlacing and seeing mpc-hc begin to play at normal speed, i noticed the sound was out of sync by about a minute. I always expected your builds to be great with regard to sync of video and audio.
3) Just adding this as I confirm interlaced content seems to play with the fields in the wrong order, looks like that anyways.
This is my benchmark for any future versions, to see can the evr-cp handle the stress of being sent 48 1080p frames per second (24 * 2 because of de-interlacer) and see after finishing this can the audio and video still be in perfect sync. I know its a pointless test but still something the player should handle with ease I think.
Klaus_1250
13th March 2009, 18:57
Refresh rate detection (still) doesn't work in combination with Reclock/Powerstrip.
Beliyaal
13th March 2009, 19:14
Just testing your new build and a 1080p vc1 .ts file that I use for testing. I was actually testing mpc-hc's decoder vs ffdshow's for dropping frames and notice mpc-hc to be MUCH smoother. To try and see could I even get mpc-hc to register 1 dropped frame I begin enabling things in ffdshow like I forced de-interlacing....OK the image didn't look correct, but two things happened.
With de-interlacing enabled (just to try and stress the player out)
1) mpc-hc slowed to a crawl, video played at half speed (even though cpu usage was only 18%).
2) After turning off de-interlacing and seeing mpc-hc begin to play at normal speed, i noticed the sound was out of sync by about a minute. I always expected your builds to be great with regard to sync of video and audio.
3) Just adding this as I confirm interlaced content seems to play with the fields in the wrong order, looks like that anyways.
This is my benchmark for any future versions, to see can the evr-cp handle the stress of being sent 48 1080p frames per second (24 * 2 because of de-interlacer) and see after finishing this can the audio and video still be in perfect sync. I know its a pointless test but still something the player should handle with ease I think.
Well, if the decoder cannot keep up there is nothing EVR CP can do about it. If ffdshow and all other filters were threaded it would probably work better, but as it stands now there is a "chain" of filters that needs to keep up. We need a "pipeline" to increase performance on multiple processors. EVR CP has no problem handling 1080p at 60 Hz. Just use a hardware deinterlacer to test it.
Originally in my build I would pause the audio as soon as the video couldn't keep up, but that wasn't liked, so I increased the limit to be much larger before pausing the audio.
mark0077
13th March 2009, 19:21
Well, if the decoder cannot keep up there is nothing EVR CP can do about it. If ffdshow and all other filters were threaded it would probably work better, but as it stands now there is a "chain" of filters that needs to keep up. We need a "pipeline" to increase performance on multiple processors. EVR CP has no problem handling 1080p at 60 Hz. Just use a hardware deinterlacer to test it.
Originally in my build I would pause the audio as soon as the video couldn't keep up, but that wasn't liked, so I increased the limit to be much larger before pausing the audio.
Thanks for the reply. :(
1) Bit disappointed that video / audio sync can go wrong so easily though. I am using a Core i7 @ 4ghz and none of the cores even reach 40% when de-interlacing in software. Usually one or two hovers around 20%. The video still gets out of sync with audio and continues to get worse until I disable de-interlacing. I think this indicates a problem somewhere, at least if one core got maxed out then I would know thats the problem.
2) As a second point simply regarding audio video sync in general, I wonder if people don't like the audio being paused, that the video could sped up or skipped forward to keep sync. I can get my video / audio out of sync so easily and its sad to know it will never go back to sync with the current builds. It stays PERFECTLY the same distance out of sync with no attempt to get back to sync....
Any future plans for alternatives to stopping audio to keep sync, ie skipping frames? Seems like theres no audio / video sync attempts at all ATM. Even using ReClock doesn't help at all with video / audio getting out of sync.
Beliyaal
13th March 2009, 19:32
Thanks for the reply. :(
1) Bit disappointed that video / audio sync can go wrong so easily though. I am using a Core i7 @ 4ghz and none of the cores even reach 40% when de-interlacing in software. The video still gets out of sync with audio and continues to get worse until I disable de-interlacing. I think this indicates a problem somewhere, like mpc-hc is playing at exactly half the frame rate it should or something like that.. I will investigate more.
2) As a second point simply regarding audio video sync in general, I wonder if people don't like the audio being paused, that the video could sped up or skipped forward to keep sync. I can get my video / audio out of sync so easily and its sad to know it will never go back to sync with the current builds. It stays PERFECTLY the same distance out of sync with no attempt to get back to sync....
Any future plans for alternatives to stopping audio to keep sync, ie skipping frames?
It will skip frames, and should catch up eventually. Check the statistics for how many buffers are available. If it's "Buffers used: 0" it means that the decoder chain isn't supplying the enough pictures to be displayed. There is a caveat here though. If you have not enabled "Alternate VSync" and have disabled VSync in renderer settings it can cause the buffers not to be filled. This is because while it's waiting for VSync (in D3D) no new buffers can decoded. Basically, always have renderer setting VSync enabled if your decoder chain is using much CPU.
And it will not help to try to skip the video forward to keep in sync. It will just use even more CPU. A good example of this is VLC, that will try to seek to keep the video up with the audio. It is annoying as hell.
Edit: The usage of a single core says nothing. One thread will hop between many cores and spread the usage between them. You can check the CPU usage of a single thread with process explorer and see if one of them reach 100%
mark0077
13th March 2009, 19:56
OK thanks for that. Processexplorer says mpclayerc.exe is using between 18 and 22 %. De-interlacing off its about 8%.
So now after a minute or two of de-interlacing enabled, and now turning off de-interlacing the audio is behind the video by about 10 seconds, after 5 minutes more it still hasn't even got any closer to sync. It doesn't seem to be dropping frames at all to get back to sync in my situation. I see 46 dropped frames but now I am not dropping any and the audio is still miles off sync...
I have VSync and accurate Vsync enabled. EVR Buffers 20, Lock backbuffer disabled. GEtting Buffer used :22, free : 1
Anything else you think might stop it dropping frames to catch up? I can reproduce this again and again so if you need me to do any testing I would love to help. This is something that definitely needs to be "fixed".
Beliyaal
13th March 2009, 20:12
OK thanks for that. Processexplorer says mpclayerc.exe is using between 18 and 22 %. De-interlacing off its about 8%.
So now after a minute or two of de-interlacing enabled, and now turning off de-interlacing the audio is behind the video by about 10 seconds, after 5 minutes more it still hasn't even got any closer to sync. It doesn't seem to be dropping frames at all to get back to sync in my situation. I see 46 dropped frames but now I am not dropping any and the audio is still miles off sync...
I have VSync and accurate Vsync enabled. EVR Buffers 20, Lock backbuffer disabled. GEtting Buffer used :22, free : 1
Anything else you think might stop it dropping frames to catch up? I can reproduce this again and again so if you need me to do any testing I would love to help. This is something that definitely needs to be "fixed".
Hmm, does the statistics say "Corrected Frame Time: Yes" when it's out of sync?
Edit: It would be great if you could provide a screenshot with statistics on when it's out of sync and not catching up.
Cyber-Mav
13th March 2009, 22:10
EVR buffers seems to have gone up from 5 to 20 now (between v16 and v17). Is this an intentional new default value or perhaps a side effect of the extended buffer range? Should we set it back to 5 manually?
i set my buffers to the max limit of 60. more buffers = more memory usage. if you have the free memory then just use more buffers.
also my haali splitter is set with 1gb input buffer, so when watching a film with media player classic home cinema it has a ram usage of around 1.21gb.
not sure what the benefit of having such a large buffer is other than data stream interruptions being minimal to non existant, but if you have the ram in you pc you may as well put it to use.
Leak
13th March 2009, 23:58
OK thanks for that. Processexplorer says mpclayerc.exe is using between 18 and 22 %. De-interlacing off its about 8%.
Did you actually double-click on the "mplayerc.exe" entry and and switch to the "threads" page? Because that's where you'll see if a thread pegs a core, since a thread can't use more than (100/<number of cores>) percent.
Actually, if you have hyperthreading turned on it might count as 8 cores, so said thread would peg at 12.5%...
np: Harmonic 313 - Word Problems (When Machines Exceed Human Intelligence)
mark0077
14th March 2009, 01:42
Hmm, does the statistics say "Corrected Frame Time: Yes" when it's out of sync?
Edit: It would be great if you could provide a screenshot with statistics on when it's out of sync and not catching up.
Yeah no problem. Well watching the stats, Correct Frame Time is set to Yes. In this image I had started the clip, enabled de-interlacing for maybe 30 seconds total. After disabling, the audio was approximately 10 seconds behind the video and stayed that way until I exited the clip about 5 minutes. No frames were dropped after I disabled de-interlacing. It seems most frames get dropped in the initial second or two after enabling de-interlacing.....
Anyways here is an image while the audio is 10 seconds. I can run any amount of tests needed. Definitely found something here thats not supposed to happen.
http://img18.imageshack.us/img18/1877/problemg.th.png (http://img18.imageshack.us/my.php?image=problemg.png)
Leak
In "Threads", none of the thread's have an associated CPU. The Performance Graph for mplayerc.exe shows the same low usage, 8% with no de-interlacing (seeing 0 dropped frames, perfect playback). Just the audio stays lagged behind after being stressed out for a few seconds. Never catches back up or even attempts to.
Edit: Managed to get it to stop dropping frames when enabling de-interlacing. I turned off the "Drop Frame On Delay" setting in ffdshow, aswell as enabled queued output samples. I find it nearly impossible to get a dropped frame now which is good I guess. The problem of the delay still remains, mpc doesn't seem to try to sync up again.
iron2000
14th March 2009, 14:57
The refresh rate and SL now show in EVR CP only in Windows XP.
So the new stuff only work on EVR CP?
pdanpdan
14th March 2009, 17:53
Latest MPC started on monitor 1, play video with D3D with GUI Support on monitor 2 (fullscreen) - when I open options, or properties or filter properties, they all open on monitor 2, instead of monitor 1 where the interface is. Can this be changed/configured?
Thank you
Casshern
15th March 2009, 03:08
Hi,
heres the status on version 17 and the Radeon 2x00 AGP DXVA problems. VMR7 and Overlay work, the following is only applicable to vmr9 renderless.
System: Win XP SP3 Catalyst 9.2 (same with any other version), VMR9 Renderless, DXVA, Screen Refresh 49.752, Material Frame rate 23.976, high bit rate vc1, display 1920x1080
1) the refresh rate is not reported properly stats show 0.0000 Hz (60Hz) - in previous versions it would say 60hz (probably from registry). Reclocks refresh rate detection works perfectly.
2)in all modes using V-SYNC, Alternativ V-Sync, different sync options, d3dfullscreen on/off there is tearing!
3)only with out all vsync options and lock back buffers enabled there is no tearing in VMR9 Renderless
4)jumping frames and corruption is shown with lock back buffers enabled, all vsync options off and vmr9 renderless (regardless of any other option settings)
5)the jumping frames completely disappear when the right click context menu is on screen - then everything is fine
6) Using the vsync options also shows corruption and jumping frames but interestingly only if the position of the "tear" is outside the visible screen.
7) the vsync information if turned on seems in line with the visible tear (line number is approx the position where the tear is located judging by eye).
8) the dxva engine is somehow sensitive to when exactly frame buffers are switched - it works perfect in powerdvd with dxva and vmr9 renderless
This leads me to the conclusion that either powerdvd waits for another directx signal before flipping the frame buffer or it has permanently something in the drawing pipeline (Like right mouse button context menu) which completley eliminates the problem. Probably the additional time to draw the menu(hidden powerdvd item) each frame somehow adjusts the timing. Or the drawing engine for the menu waits for the correct signal from the dxva engine - something what mpc hc without any menus open does not do at the moment.
Beliyaal: I hope that helps to fix the problem or at least gives us a workaround option (invisible one pixel menu somewhere in the corner).... Or even better a real fix by waiting for the correct signal....
STaRGaZeR
15th March 2009, 04:44
A 64-bit build is possible?
thuan
15th March 2009, 06:40
Sometimes, I get this problem playing files in your build randomly
http://xs137.xs.to/xs137/09110/untitled551.jpg.xs.jpg (http://xs.to/xs.php?h=xs137&d=09110&f=untitled551.jpg)
It drops frame a lot. This happens with either VSync+AccurateVSync on or off in all possible cases. This happens right after a screen lock though. I haven't tested if this case is consistently reproducable.
Vista x64 SP1 with Aero enabled
Nvidia 9500GT, 182.08
EVR CP
MPC-HC Beliyaal b17
Beliyaal
15th March 2009, 08:27
A 64-bit build is possible?
If someone gives me a step by step instruction ("download from here", "extract here", "copy this", "change this setting" etc) of how to get mingw/GCC to compile in 64 bits. I don't have time to research this at the moment.
DeepBeepMeep
15th March 2009, 12:43
Beliyaal, could you please commit the fix that prevented the scrollbar from diseapearing in VMR9 Full screen mode on the official builds ?
I would be grateful as it will be useful as long as the official build offers a more stable playback.
Thanks a lots
yesgrey
15th March 2009, 13:08
Beliyaal,
Could you please add your list of preferable options for playback into your first post? I have looked for them in the main mpc-hc thread but only have found them for Vista. Could you also list the options for XP?
It would be very helpfull having that list so we could try to see which fits better our needs.
Thanks.
Jong
15th March 2009, 14:04
Beliyaal, could you please commit the fix that prevented the scrollbar from diseapearing in VMR9 Full screen mode on the official builds ?
I would be grateful as it will be useful as long as the official build offers a more stable playback.
Thanks a lots...and the D3D context menu fix .....and the improved stats...... please!
DigitalDeviant
15th March 2009, 14:38
Because it drops subtittles when some heavy typesetting is used. Example gg's Maria+Holic episode 8. The typesetting in this episode is a killer.
While we are at the subject, the only reason I ever wanted buffers with EVR or Haali renderer was because of subtitle effects that are CPU killers. Before Beliyaal's builds, VSfilter had to do the job, so I needed Video buffers. Now that MPC does the job, I need subtitle buffers, the video decoding itself is a piece of cake for my CPU, and most the time the GPU does it with DXVA2. I agree though that the majority of anime fansubbers do no use so CPU heavy effects. But some do!
Also, although most people won't ever need it, I want to able to choose. Why should it be restricted? It works for me, I use it, that's all.
I've noticed the line at 4:01-4:06 doesn't show when full screened. Sometimes it shows for a split second with 60 subtitle buffers but not the full length.
thuan
15th March 2009, 14:41
Found out the cause: This will happen after UAC prompt appearance or lock screen.
Sometimes, I get this problem playing files in your build randomly
http://xs137.xs.to/xs137/09110/untitled551.jpg.xs.jpg (http://xs.to/xs.php?h=xs137&d=09110&f=untitled551.jpg)
It drops frame a lot. This happens with either VSync+AccurateVSync on or off in all possible cases. This happens right after a screen lock though. I haven't tested if this case is consistently reproducable.
Vista x64 SP1 with Aero enabled
Nvidia 9500GT, 182.08
EVR CP
MPC-HC Beliyaal b17
turbojet
15th March 2009, 14:46
Hey Beliyaal thanks for these builds. Since you are actively developing your own builds and I can't seem to get through to the other developers (tried this forum and sourceforge) could you take a look at this bug (http://forum.doom9.org/showthread.php?t=145381)?
Also if you don't mind, some feature requests I have:
- chapter support from m2ts
- subtitles from m2ts not changing shape (gets taller) when switching from windowed to fullscreen
STaRGaZeR
15th March 2009, 14:55
If someone gives me a step by step instruction ("download from here", "extract here", "copy this", "change this setting" etc) of how to get mingw/GCC to compile in 64 bits. I don't have time to research this at the moment.
How about compile libavcodec with VS2008 like xvidvideo.ru does for ffdshow's 64-bit releases? It's just for testing purposes, ffdshow would handle all the decoding. No need for high perfomance internal decoders.
Beliyaal
15th March 2009, 15:59
How about compile libavcodec with VS2008 like xvidvideo.ru does for ffdshow's 64-bit releases? It's just for testing purposes, ffdshow would handle all the decoding. No need for high perfomance internal decoders.
Just out of curiosity, is there any real reason why a 64-bit version is better than the 32-bit version?
STaRGaZeR
15th March 2009, 17:29
Just out of curiosity, is there any real reason why a 64-bit version is better than the 32-bit version?
At the player level, no. But some ffdshow filters are faster in ffdshow64, and ffdshow64 requires a 64-bit player. Plus, at least in Vista, the 32-bit MPC has some problems when working with 64-bit explorer.exe, like registering itself to autoplay DVDs. It would be nice to have your changes in 64-bit too.
cca
15th March 2009, 17:37
I've noticed the line at 4:01-4:06 doesn't show when full screened. Sometimes it shows for a split second with 60 subtitle buffers but not the full length.
When it shows "Scary" shaking on the screen? It appears fine here with 60 buffers. I use 1280x720 as the resolution of the subtitles. Even with 60 buffers you still need a fast CPU. From what I 've seen the subtitle rendering engine is not multithreaded, it can only use one core, so the absolute speed in MHz of the CPU matters.
Beliyaal
15th March 2009, 19:14
New version (Link in signature):
* Added: Support for high color resolution. When this option is enabled A2R10B10G10 format is used as surface and backbuffer, and as display mode in fullscreen if possible.
* Added: Option for enabling frame time correction. Press 'C' to enable/disable frame time correction. You will need to enable this manually for VC-1 content in ts/m2ts files (default is off).
* Added: Shader for converting 0-255 to 16-235.
* Changed: Lock back buffer removed in favor of Event Query (always enabled). Check if alternate VSync is working better now (more stable).
* Fixed: Frame time correction could cause video to be perpeptually out of sync.
* Fixed: Aspect ratio is simplified as far as possible.
* Fixed: VMR9 now forces 4 surfaces that are exchanged. Might fix Radeon 2x00 AGP corruption bug. Might cause new bugs, please test.
* Fixed: Refresh rate now detected in VMR9 as well.
* Fixed: Refresh rate detection should now be more accurate.
* Fixed: Number of EVR buffers now displayed correctly in options.
Someone asked for recommended settings:
* EVR CP
* If Vista disable Aero (disable desktop composition on properties of the mplayerc.exe file)
* Alternate VSync
* Accurate VSync
* If you still need fullscreen to remove tearing, disable fullscreen gui support
I wont be integrating anything into SVN until everything is ready to be integrated (too much overhead taking time).
Note that VC-1 time correction now has to be enabled manually.
VSync code have been changed. Lock backbuffer is gone, and another technique (Event query) is now used instead and always enabled. You might want to give alternative VSync another try and check if it's working better now. If not please report how the "PresentEnd" statistic relates to the vsync position.
In this version I have tried to add support for 10 bit color in the whole pipeline, but at least on my drivers I'm not able to get the display into 10 bit mode. It might work with other drivers though. Fullscreen mode must be enabled for this to work. Statistics reports which format all the different stages of the pipeline is in.
Some bugs in the known bug list might be fixed, please check them in the "Bugs with unknown status" section of first post.
If a bug is still in the known bugs list I haven't tried to fix it for this version.
cca
15th March 2009, 19:46
Thank you for the new build, did some quick testing:
Vsync seems to work way better now, in my brief tests I detected no stutter at all.
I tried an interlaced DVD, I think the problem is indeed fixed, no stutter here either.
About the highcolor, I think my ATI only outputs 888, reasonable since I have it connected with a VGA cable in the TV.
More extensive testing later.
EDIT: VMR9 Renderless crashes the player immediately.
yesgrey
15th March 2009, 20:02
* Added: Option for enabling frame time correction.
Sorry if it's a dumb question, but why would we need this? An example would be helpfull...
Someone asked for recommended settings
It was me. Thanks.:)
I think it would be better put those settings in the first post...;)
About the subtitles request, it's not a problem anymore, I've remembered that ffdshow has a subtitle filter, and it works great, so I only need to disable mpc subtitle internal renderer.
Thank you for all your great work in mpc-hc, I have switched again to it...
Beliyaal
15th March 2009, 21:31
Thank you for the new build, did some quick testing:
Vsync seems to work way better now, in my brief tests I detected no stutter at all.
I tried an interlaced DVD, I think the problem is indeed fixed, no stutter here either.
About the highcolor, I think my ATI only outputs 888, reasonable since I have it connected with a VGA cable in the TV.
Because VGA is analog, if you TV supports it it should give you 10 bits. I'm interested in if it works in the driver. Only works in fullscreen. All "Formats" in display should be A2R10G10B10 and if not I'm interested in the value of D3DExError.
Does alternative VSync work without tearing with the VSync position at 0?
EDIT: VMR9 Renderless crashes the player immediately.
Does it work if without DXVA, or does it always crash?
Beliyaal
15th March 2009, 21:37
Sorry if it's a dumb question, but why would we need this? An example would be helpfull...
VC-1 is stuttering with the internal m2ts splitter, and the correction I implemented causes problems with some other content, so we need an option to turn it off.
About the subtitles request, it's not a problem anymore, I've remembered that ffdshow has a subtitle filter, and it works great, so I only need to disable mpc subtitle internal renderer.
Well I would still like to fix it if possible :) So if you could confirm if it's still a problem it would be great.
cca
15th March 2009, 22:00
Because VGA is analog, if you TV supports it it should give you 10 bits. I'm interested in if it works in the driver. Only works in fullscreen. All "Formats" in display should be A2R10G10B10 and if not I'm interested in the value of D3DExError.
Does alternative VSync work without tearing with the VSync position at 0?
Does it work if without DXVA, or does it always crash?
Well, in D3D fullscreen with highcolor on I get blank screen, no video displayed at all. The alternative Vsync works just fine in position 0, but note I always have Aero enabled. I can try with it disabled for testing purposes if you like, but I don't see the point to disable it for normal use.
VMR9 Renderless crashes the player immediately regardless of DXVA used or not. Open File -> instant crash.
EDIT: Tried a video without Aero, no tearing observed with alternate Vsync at position 0.
BTW, when the statistics are on I get stuttering, same goes when the tearing test is on. Without them I have smooth playback.
STaRGaZeR
15th March 2009, 22:11
Version 18 has broken hardware deinterlacing, as soon as the flag is sent to the renderer it causes a crash in "atiumdva.dll". Version 17 and previous are fine. Tested with ffdshow and internal DXVA decoder.
The x64 build works like the x86 so far :)
Beliyaal
15th March 2009, 22:16
Version 18 has broken hardware deinterlacing, as soon as the flag is sent to the renderer it causes a crash in "atiumdva.dll". Version 17 and previous are fine. Tested with ffdshow and internal DXVA decoder.
The x64 version works like the x86 so far :)
I have seen this with High Color Support enabled. Is this your case?
Beliyaal
15th March 2009, 22:17
BTW, when the statistics are on I get stuttering, same goes when the tearing test is on. Without them I have smooth playback.
I have seen this as well, but only with Aero enabled (think this started with Catalyst 9.1). Can you confirm that your experience is the same? This is the reason I turn off desktop composition for for mplayerc.exe
carnage_pl
15th March 2009, 22:18
Confrimed on x86. When High color support enabled it crashes on ATI/Vista no Areo/ffdshow. Suttering also appears without Areo
Beliyaal
15th March 2009, 22:22
Confrimed on x86. When High color support enabled it crashes on ATI/Vista no Areo/ffdshow. Suttering also appears without Areo
Yes, it seems to be a bug in the ATI driver. I don't think any other player has enabled 10 bit path before (crashes with 16 bits as well) so they havn't tested they code with this feature in mind. Also the it doesn't seem to support 16-235 levels in 10 bit either, but I'm not sure if I should blame Microsoft or ATI for this.
What kind of stuttering are you experiencing?
carnage_pl
15th March 2009, 22:27
http://img7.imageshack.us/img7/6066/stuuer.th.jpg (http://img7.imageshack.us/my.php?image=stuuer.jpg)
Something like that.
Someone a little earlier desrcibed this in that kind of way : ---^^^---^^^---^^^ :P
Beliyaal
15th March 2009, 22:33
http://img7.imageshack.us/img7/6066/stuuer.th.jpg (http://img7.imageshack.us/my.php?image=stuuer.jpg)
Something like that.
Does it improve if you increase EVR buffers to 10 and subtitle buffers to 10? Also try larger values.
Also try if Alternative VSync works better.
What hardware are you using?
cca
15th March 2009, 22:43
I have seen this as well, but only with Aero enabled (think this started with Catalyst 9.1). Can you confirm that your experience is the same? This is the reason I turn off desktop composition for for mplayerc.exe
Disabling aero makes no difference in my case. Still stutters if I enable the statistics or the tearing test.
carnage_pl
15th March 2009, 22:48
both options cause even worse results. Alternative Vsync ^^^^^^^^ all the time. More buffers i can't even watch smooth anything. These are the best settings for me. 3 buffers for video and about 5 subtitles. my rig Radeon HD2300 (i have notebook)
ooferomen
15th March 2009, 22:57
my setup
Vista SP1 x64
9600gt primary video card
9300(onboard) secondary video card
i'v got my tv hooked up to the onboard DVI port at 23hz(23.97 i believe)
under formats i have
Surface A2R10G10B10 Backbuffer A2R10G10B10 Display X8R8GB8 Device D3DDevEX D3DExError:
when you say fullscreen mode do you mean D3D Fullscreen?
Beliyaal
15th March 2009, 23:06
when you say fullscreen mode do you mean D3D Fullscreen?
You you need D3D Fullscreen for the display to be 10 bit.
Casshern
15th March 2009, 23:11
Hi Beliyaal,
congratulations! The AGP Bug seems fixed! I don't know whether it was fixed by using "event query" or the allocation of 4 surface buffers - but it worked. Also no tearing with just VMR9 renderless, YUV Mixing and VMR9 Mixer Mode enabled (all vsync stuff turned off and no d3d fullscreen mode) - also correct cropping of 1088 to 1080 (Was always a prob with overlay and vmr7), but thats normal with vmr9 mixer mode.
GREAT JOB!
Only thing: the refresh rate detection still does not work (at least not with the above settings) - Still reports : 0.0000hz SL 0 (60Hz).
But without the vsync stuff it does not seem to effect mpc hcs behaviour.
Question: If i now want to use the vsync stuff (so i dont have to hit pause/play if vsync heads into the critical area when the refresh rate - 47.952 is an exact multiple of frame rate) how does this interact with reclocks vsync correction?
Should one turn Reclocks off?
Thanks again,
Casshern
cca
15th March 2009, 23:18
Hi Beliyaal,
congratulations! The AGP Bug seems fixed! I don't know whether it was fixed by using "event query" or the allocation of 4 surface buffers - but it worked. Also no tearing with just VMR9 renderless, YUV Mixing and VMR9 Mixer Mode enabled (all vsync stuff turned off and no d3d fullscreen mode) - also correct cropping of 1088 to 1080 (Was always a prob with overlay and vmr7), but thats normal with vmr9 mixer mode.
GREAT JOB!
Only thing: the refresh rate detection still does not work (at least not with the above settings) - Still reports : 0.0000hz SL 0 (60Hz).
But without the vsync stuff it does not seem to effect mpc hcs behaviour.
Question: If i now want to use the vsync stuff (so i dont have to hit pause/play if vsync heads into the critical area when the refresh rate - 47.952 is an exact multiple of frame rate) how does this interact with reclocks vsync correction?
Should one turn Reclocks off?
Thanks again,
Casshern
Good news then. I don't really mind that VMR9 crashes in my setup, I don't use it anyway in favor of EVR Custom. I only find a bit annoying the stutters when the statistics OSD is on, but since it doesn't prevent me from watching smoothly my videos, I consider it low priority problem.
STaRGaZeR
15th March 2009, 23:31
I have seen this with High Color Support enabled. Is this your case?
Yep, exactly.
EDIT:
http://thumbnails13.imagebam.com/2980/c25b9529795575.gif (http://www.imagebam.com/image/c25b9529795575) http://thumbnails15.imagebam.com/2980/e8383829795724.gif (http://www.imagebam.com/image/e8383829795724)
I'm also getting this stutter, but I don't know if it's the same as other people are reporting. Same video with and without VSync (dunno why it shows 70Hz here, it's always at ~75Hz). Happens with and without statistics on screen, ffdshow and the internal H.264 decoder, but not with DXVA. This could point to a perfomance problem, but all 20 buffers are always full and running healthy.
yesgrey
15th March 2009, 23:36
You you need D3D Fullscreen for the display to be 10 bit.
When I check D3D Fullscreen the stats are not displayed, so how can I confirm that the screen surface is in the high color resolution format?
If I uncheck D3D Fullscreen, I can see the stats and the surface and backbuffers are in high color, but the display color is X8R8G8B8.
I'm using XP.
Beliyaal
15th March 2009, 23:41
Only thing: the refresh rate detection still does not work (at least not with the above settings) - Still reports : 0.0000hz SL 0 (60Hz).
But without the vsync stuff it does not seem to effect mpc hcs behaviour.
You need to enable VSync for the refresh rate detection to be enabled.
Question: If i now want to use the vsync stuff (so i dont have to hit pause/play if vsync heads into the critical area when the refresh rate - 47.952 is an exact multiple of frame rate) how does this interact with reclocks vsync correction? Should one turn Reclocks off?
I it works with reclock you should keep it as is. They don't really do the same thing. Reclock moves the audio position (resamples) so the vsync coincides with the vsync. The different VSync options in mpc-hc just syncronizes to the VSync in different ways.
Good news then. I don't really mind that VMR9 crashes in my setup, I don't use it anyway in favor of EVR Custom. I only find a bit annoying the stutters when the statistics OSD is on, but since it doesn't prevent me from watching smoothly my videos, I consider it low priority problem.
The only startup crash I have experienced is that it crashes when I have raw video enabled in ffdshow (for deinterlacing content from all other codecs). The last ffdshow version I have found working is ffdshow_rev2653_20090202.zip. Maybe you could try if it works with this version to see if the crash is related.
You stuttering will probably be fixed when I update the VSync code. Does the refresh rate detection work correctly now?
Beliyaal
15th March 2009, 23:43
When I check D3D Fullscreen the stats are not displayed, so how can I confirm that the screen surface is in the high color resolution format?
If I uncheck D3D Fullscreen, I can see the stats and the surface and backbuffers are in high color, but the display color is X8R8G8B8.
I'm using XP.
If that happens the renderer probably failed to initialize. I also thought that D3D9Ex only worked in Vista, but your screenshot shows it working in your Windowed mode, so I'm not sure what is going on.
Mercury_22
15th March 2009, 23:44
High Color Resolution it's crashing VC-1 i, AVC i, MPEG-2 i, but not VC-1 p or AVC p or MPEG-2 p ! => Interlace = crashing with High Color Resolution :)
Edit Also enabling Dynamic contrast in ATI's AVIVO Video settings results in crashing with High Color Resolution no matter if i or p
tetsuo55
15th March 2009, 23:44
Windows 7, using ATi beta drivers (not 9,2 vista)
Using your recommended settings
surface: A2R10G10B10 backbuffer: A2R10G10B10 Display: X8R8G8B8
looks like it working
However when i enable D3D fullscreen mode I get error
0x8876086C
The screen gets dark (looks like EVR is expanding to 0-255 ), need a reboot to recover.
My hd2400pro agp is connected with a DVI2HDMI cable to my 12bit capable display. To get the monitor to actually do something in more than 8bit requires some driver changes is guess?
EDIT1:
If the player hangs or shuts down ungracefully during DXVA playback the videocard becomes stuck and a reboot is needed to be able to play DXVA content again (non DXVA seems to work fine though)
cca
15th March 2009, 23:54
The only startup crash I have experienced is that it crashes when I have raw video enabled in ffdshow (for deinterlacing content from all other codecs). The last ffdshow version I have found working is ffdshow_rev2653_20090202.zip. Maybe you could try if it works with this version to see if the crash is related.
You stuttering will probably be fixed when I update the VSync code. Does the refresh rate detection work correctly now?
No, doesn't appear to be ffdshow related, it crashes even if I use the internal decoders of MPC. I do not have raw video input enabled in ffdshow either. Anyway, don't care for VMR9 much as I said, I just mentioned it for you to be informed that it is not working in my setup.
The Vsync is the best we had so far, but still needs some improvements, I had a few stutters earlier when watching a 29.97fps video with refresh rate 60Hz. ReClock was enabled but without it's vsync function.
The refresh rate oscillates between 59.795 and 59.825, ReClock detects as 59.805 and it is locked there.
carnage_pl
15th March 2009, 23:55
[QUOTE=tetsuo55]If the player hangs or shuts down ungracefully during DXVA playback the videocard becomes stuck and a reboot is needed to be able to play DXVA content again (non DXVA seems to work fine though)[QUOTE]
sometimes i have the same problem.
gngn
15th March 2009, 23:56
OS: Win XP SP3
GPU: 8600GTS , driver 182.06 , 17" CRT@75hz
Renderer: VMR9renderless (3d-surfaces , vmr mixer mode)
if i enable just "Alternative Vsync" i get tearing
when i then enable "Vsync" tearing stops
screenshot with both enabled:
http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_vsyncr1010.png (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/vsyncr1010.png)
Beliyaal
16th March 2009, 00:00
Windows 7, using ATi beta drivers (not 9,2 vista)
Using your recommended settings
surface: A2R10G10B10 backbuffer: A2R10G10B10 Display: X8R8G8B8
looks like it working
However when i enable D3D fullscreen mode I get error
0x8876086C
The screen gets dark (looks like EVR is expanding to 0-255 ), need a reboot to recover.
My hd2400pro agp is connected with a DVI2HDMI cable to my 12bit capable display. To get the monitor to actually do something in more than 8bit requires some driver changes is guess?
Yes, I think there is a driver problem (interlacing crash and no 16-235 support). The driver enumerates that it supports 10 bit display modes, but only returns 0x8876086C. I might be doing something wrong in the code that causes the 0x8876086C error though. It would be interesting to know if a NVidia user can make it work.
As for sending 10 bit to the display, I'm not sure if the driver actually supports it yet. My main reason for implementing this support was for YCbCr pixel format that I can enable in my driver options. Theoretically I this should allow us to keep most of the color resolution of the content and decrease banding.
Right now we do:
8 bit YUV -> 8 bit RGB -> 8 bit RGB -> 8 bit RGB -> x bit YUV in screen
Right now we do with high color:
8 bit YUV -> 10 bit RGB -> 10 bit RGB -> 8 bit RGB -> x bit YUV in screen
What we want to do:
8 bit YUV -> 10 bit RGB -> 10 bit RGB -> 10 bit RGB -> 8 bit YCbCr -> x bit YUV in screen
Basically we want to keep more precission so we don't loose color resolution while the content is in RGB format. So even if we can't get the graphics card to send 10 bit color, we might be able to decrease banding anyway.
Beliyaal
16th March 2009, 00:07
If the player hangs or shuts down ungracefully during DXVA playback the videocard becomes stuck and a reboot is needed to be able to play DXVA content again (non DXVA seems to work fine though)
I have seen this many times as well, it must be a driver bug. If I get this and right click on the desktop the whole computer hangs, and a program shouldn't be able to cause this to happen. With 9.2 it happens much less often though, before it would happen almost any time I tried to use DXVA.
OS: Win XP SP3
GPU: 8600GTS , driver 182.06 , 17" CRT@75hz
Renderer: VMR9renderless (3d-surfaces , vmr mixer mode)
if i enable just "Alternative Vsync" i get tearing
when i then enable "Vsync" tearing stops
screenshot with both enabled:
http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/th_vsyncr1010.png (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/vsyncr1010.png)
That is as it should be. If you disable VSync while alternative vsync is enabled, it will do no VSync at all, and thus the tearing.
BatKnight
16th March 2009, 00:15
I have seen this as well, but only with Aero enabled (think this started with Catalyst 9.1). Can you confirm that your experience is the same? This is the reason I turn off desktop composition for for mplayerc.exe
Aero off gives me a lot of tearing. Aero on removes the tearing. I only use EVR CP.
I've noticed that with ver 18 Haali mkv splitter gives me stutter/jitter (small spikes on the graph on a constant basis) but MPC internal mkv splitter doesn't. This didn't happen on ver 17 and before.
Bat
BatKnight
16th March 2009, 00:17
http://img7.imageshack.us/img7/6066/stuuer.th.jpg (http://img7.imageshack.us/my.php?image=stuuer.jpg)
Something like that.
Someone a little earlier desrcibed this in that kind of way : ---^^^---^^^---^^^ :P
I get that too if I enable Vsync. Try disabling it, since you have 60Hz refresh rate.
Bat
tetsuo55
16th March 2009, 00:20
DXVA completely broken now, need sleep will revert to older build tonight.
Seems like something is stuck in registry or something, no matter how i play with the settings MPC always crashes when trying DXVA
carnage_pl
16th March 2009, 00:46
I get that too if I enable Vsync. Try disabling it, since you have 60Hz refresh rate.
Bat
OK now, but what about Vsynch since that build is what is all about?:P
BatKnight
16th March 2009, 00:53
OK now, but what about Vsynch since that build is what is all about?:P
I don't know, but on my opinion vsyinc is only needed to remove tearing. On my case I have no tearing with EVR Custom + Aeron ON, so I don't need vsync at all.
Bat
Casshern
16th March 2009, 01:00
You need to enable VSync for the refresh rate detection to be enabled.
I it works with reclock you should keep it as is. They don't really do the same thing. Reclock moves the audio position (resamples) so the vsync coincides with the vsync. The different VSync options in mpc-hc just syncronizes to the VSync in different ways.
I am not sure that reclocks vsync correction works like you describe. My impression is that it works different. Its objective is to eliminate the cases when the vsync buffer flip is to close (timewise) to a video frame to be rendered. If this occurs - due to small timing variations - sometimes the frame cannot be rendered when it should, leading to a constant judder until the video frames and vsync buffer timings drift wide enough apart again. This is of course becomes very relevant if the refresh rate in an near exact multiple of frame rate, as then this state can occur for a rather long period of time because the time differential of vsyncs and current rendered frame drift apart only very slowly. As reclock does not know anything about the video frames being rendered and does not even temper with the timestamps in the pipeline - it uses a neat trick: the reclock magic adjusts the master clock for the whole graph slightly according to the vsync flips.
Thats also the reason why it isn*t automated in reclock and you have to manually find a position which is judder free! Reclock has no information what frame is rendered at what point in time, it can only do a vsync correction in relation to the master clock.
If one has this knowlege and if one controls the video stream like in the presenter code it might be possible to come up with the perfect solution.
I did not try all vsync options in your player - because for me overlay, VMR7 and even vmr9renderless with lockbackbuffer (now this is obsolete) always worked without any tearing. This has been working with all the ati cards starting from the 9x00 series and my current 2600 HD - it might help to set vsync to always on in the catalyst settings though.
So i was under the impression that you tackled the same problem as reclocks - namely that if refresh rate and frame rate are a close exact multiple of each other you want to avoid these judder positions. I would even prefer the MPC HC doing this instead of reclock, because you HAVE much more information about the video stream - and reclocks does not work with dxva (at least not dxva1).
And with your recent advances i am pretty sure it can be done perfectly without the trial and error method of finding a good vsync position in reclock.
Ok one other thing. One fantastic and easy feature to add would be to have an option to have the seekbar/statusdisplay not at the bottom of the screen but at the top. Many people and myself have speakers outside the 2.35:1 frame so we cant really use the seek bar all to well. It would be neat to have it optionally at the top.
regards,
casshern
ooferomen
16th March 2009, 01:03
i can't get D3D Fullscreen to work with aero enabled, it seems like mpc is struggling to turn off aero? the screen blinks on and off.
also when i turn off aero i see D3DExError 0x08876086c
high color is off, when it is on EVR doesn't load, its just "Video Renderer"
Beliyaal
16th March 2009, 01:13
I am not sure that reclocks vsync correction works like you describe.
And with your recent advances i am pretty sure it can be done perfectly without the trial and error method of finding a good vsync position in reclock.
Ok, Reclock wasn't as fancy as I expected, and you are right I should be able to accomplish the same thing as reclock in this case. But only now that I have the refresh rate detected can I do it perfectly. We will see how this works out when I get to writing the code in question (the current code does do some things, but not enough).
yesgrey
16th March 2009, 01:29
As for sending 10 bit to the display, I'm not sure if the driver actually supports it yet. My main reason for implementing this support was for YCbCr pixel format that I can enable in my driver options.
I'm not sure this would be helpfull... I think the idea of the YCbCr format that you can enable in your driver options is to avoid the conversion to RGB when outputing to the display. If you need to convert to RGB in the middle, IMHO it makes no sense to convert back to YCbCr... you should keep it as RGB.
What we want to do:
8 bit YUV -> 10 bit RGB -> 10 bit RGB -> 10 bit RGB -> 8 bit YCbCr -> x bit YUV in screen
I think what we should look for is:
8 bit YUV -> 10 bit RGB -> 10 bit RGB -> 10 bit RGB -> x bit RGB in screen
So even if we can't get the graphics card to send 10 bit color, we might be able to decrease banding anyway.
For that we need to use dithering...;)
mark0077
16th March 2009, 01:30
Have to say very impressed with the latest version. Excellent work. My de-interlacing stress test that caused audio / video sync issues seems to be gone. I actually can't get the player to get audio / video out of sync now ;) I wonder is it because frame time correciton is now off by default for vc-1? Thanks Beliyaal keep up the good work.
Beliyaal
16th March 2009, 01:51
I'm not sure this would be helpfull... I think the idea of the YCbCr format that you can enable in your driver options is to avoid the conversion to RGB when outputing to the display. If you need to convert to RGB in the middle, IMHO it makes no sense to convert back to YCbCr... you should keep it as RGB.
As long as we can keep it in higher than 8 bit resolution, yes, but if this is not possible, we should aim for YCbCr instead as this should give better resolution than the 8 bit RGB. Provided the source format is YUV(YCbCr) of course. The YCbCr fromat is good for nothing otherwise, at least in Vista as you cannot actually render something in YCbCr format. Not sure if it works with overlay though. That might be possible.
I think what we should look for is:
8 bit YUV -> 10 bit RGB -> 10 bit RGB -> 10 bit RGB -> x bit RGB in screen.
I agree, but regardless, both options are implemented with the same method: 10 bit display mode. Which isn't working now.
For that we need to use dithering...;)
Optimally yes, but even without it it should be less banding.
Egh
16th March 2009, 02:16
Hi Beliyaal,
compare two screens:
http://xs.to/xs.php?h=xs137&d=09110&f=tzd1574.png
and
http://xs.to/xs.php?h=xs137&d=09110&f=tzd2444.png
Both are all same settings and same file, just first is what is shown upon starting the file, the other is when you move it to a different monitor :confused: BTW, if you move the window back to original monitor it still works. ASS subs are also displayed w/o any problem as well as the (obviously) stats but video is initialized in a wrong way (so in effect requires reinitialization to be displayed properly).
And what is X8R8G8B8 colourspace anyway? :P
Also there's kind of a strange chain in EVRCP. Even using internal MPC AVC decoder (no DXVA here for it) it apparently produces the output in YUY2, then a AVI decompressor is inserted in the chain, and then Color Space convertor and only then the EVR comes. Probably some broken filter or MPC indeed doesnt properly create a chain with EVR?
Seems I found a reason for that: just tried it on VMR9 and it does as normal, i.e. MPC Video => VMR9 Renderless. However when I move the window to another monitor, it does rebuild the chain inserting the two aforementioned filters. I'll later check if the last SVN has same problem and if so, will report in the relevant thread as well.
Edited in: just as I checked it seems same thing with VMR9 and SVN 1010 build, will report in the relevant thread as well.
@Beliyaal: you sure that "High color" is a proper name for this? It is typically 15/16bit color. If you plan to venture beyond 8bit per color channel (long overdue in my opinion:P) you should use the term DeepColor http://en.wikipedia.org/wiki/Deep_Color
neoufo51
16th March 2009, 02:48
Ver 18 crashes big time on all AVI and WMV files when playing with VMR9 output. Other formats play without error.
XP SP3
Nvidia 8400GS 182.02
Amour
16th March 2009, 03:01
I can't get the latest file (x86).
Anybody with a mirror link?
neoufo51
16th March 2009, 03:08
I can't get the latest file (x86).
Anybody with a mirror link?
http://www.mediafire.com/?h4yyhyqnajj
yesgrey
16th March 2009, 03:26
The YCbCr fromat is good for nothing otherwise, at least in Vista as you cannot actually render something in YCbCr format.
but can you access the source image in YCbCr format inside the EVR, before the rendering, or as soon as the YCbCr image enters EVR it's imediatelly converted to RGB?...
cca
16th March 2009, 10:04
I Just tried VMR9 Renderless in crap old office PC which runs windows 2000. Instant crash. I can't figure it out.
EDIT: Tried checking VMR Mixer mode, now it doesn't crash.
Jong
16th March 2009, 10:27
and reclocks does not work with dxva (at least not dxva1).With the latest beta it is possible to enable vsync correction with DXVA (1&2) and I believe it works. Obviously there is no on screen display, so you have to set the vsync position blind, but it really does seem to work, even fixing vsync for PDVD Blu-ray.
Casshern
16th March 2009, 10:32
Yeah, James enabled it but is not convinced it really works in all configurations. If it works and i trust you experiments from your posts in the reclock forum its a step in the right direction. But a much better solution would be to do it in MPC HC:
1) No more manual vsync position guessing
2) no need to change vsync position for different filter chains
3) it could just work without the user ever having to worry about such things....
With the latest beta it is possible to enable vsync correction with DXVA (1&2) and I believe it works. Obviously there is no on screen display, so you have to set the vsync position blind, but it really does seem to work, even fixing vsync for PDVD Blu-ray.
cca
16th March 2009, 10:45
Yeah, James enabled it but is not convinced it really works in all configurations. If it works and i trust you experiments from your posts in the reclock forum its a step in the right direction. But a much better solution would be to do it in MPC HC:
1) No more manual vsync position guessing
2) no need to change vsync position for different filter chains
3) it could just work without the user ever having to worry about such things....
Totally agree with this, it's preferable to be done in the player/renderer itself. At this time Alternate vsync is very good, but not up to par with ReClock's vsync, still getting some stutters occasionally. But the code is not yet complete, so just keep making test, Beliyaal will get it right sooner or later.
Jong
16th March 2009, 10:54
I agree too. Much better if the player handles this. Trouble is most of us still need multiple players at the moment. It is a mess.
Regarding Reclock, with all forms of vsync correction i have seen so far you definitely have to be careful that you do not have both player and Reclock doing correction; with DXVA and no onscreen stats that can be hard to determine! Like all things Reclock it is not for the faint hearted!
I have not tested the new Beliyall build yet, but based on previous tests I would be surprised if having MPC-HCs and Reclock's vsync correction enabled was a good idea.
Jong
16th March 2009, 12:01
I have tested the new build.
- It is still possible with sufficient seeks to hit a point where synchronised frame rate/refresh rate repeating judder occurs (when VBlank Wait Start passes though the "danger zone" around 1080/0). I'm not sure it really has any protection against this. It doesn't seem to. You just need to seek enough times to hit the critical area. VBlank Wait Start is random after each seek.
http://jong.pwp.blueyonder.co.uk/images/Beliyaal18_001.jpg
Most of my testing was done with VMR9, D3D, VMR Mixer and YUV mixing "on", but the same is true for EVR CP (on XP at least). The vsync position seems fixed, but the VBlank Wait start value is still random and when it is around 1080/0 judder occurs.
http://jong.pwp.blueyonder.co.uk/images/Beliyaal18_003.jpg
- it is definitely not a good idea to have both Reclock vsync protection and MPC protection turned on. This, as with earlier tests, causes "rolling sync", where the further the Reclock target is from the MPC target the faster the "roll". With the Reclock target at the bottom of the screen this roll takes about 18 seconds here, with a brief burst of judder on each cycle as Vblank Wait Start passes though the "danger zone".
http://jong.pwp.blueyonder.co.uk/images/Beliyaal18_002.jpg
By the way Reclock vsync correction behaves identically in DXVA1 mode to software mode, just without the OSD of course.
- Vsync definitely behaves as if on in this build, when using VMR9 D3D, VMR Mixer "on", alternate sync "off", vsync "off". In the normal build it is off. Reclock shows it fixed at the top and if you enable Reclock's vsync correction it "rolls" (as above). Whatever the cause I do think this needs fixing. We need a tear-free, vsync free mode, as provided by the normal build.
yesgrey
16th March 2009, 12:44
but can you access the source image in YCbCr format inside the EVR, before the rendering, or as soon as the YCbCr image enters EVR it's imediatelly converted to RGB?...
I have been reading a little about EVR, so let me rephrase my question:
Can the EVR Custom Presenter used in mpc-hc receive YCbCr from the EVR Mixer, or the EVR Mixer only outputs RGB?
I'm asking this to know if we could perform the conversion from YCbCr->RGB inside the custom presenter.
Of course if mpc-hc also has a EVR custom mixer we could do it, but that should be more work...
Jong
16th March 2009, 13:36
My VC-1 rips still playback disastrously with this build regardless of renderer or whether frame time correction is enabled.
And turning on "High color" causes lines 1081-1088 to be displayed in 1080p rips, with consequent AR distortion and noise in the bottom few lines in some.
Klaus_1250
16th March 2009, 14:10
* Fixed: Refresh rate now detected in VMR9 as well.
* Fixed: Refresh rate detection should now be more accurate.
Thanx, confirmed working on XP SP3/VMR9 renderless/ATi Cat 9.2. I do see it occasionally go wrong though, e.g. the detected refreshrate can drop well over 10Hz when using some h264's even though I'm pretty sure it is not the actual case. For mpeg2, it seems to slowly oscillate +1/-1Hz.
Only issue I still have is that subs cause way more jitter in your build than the normal MPC-HC one.
Shakey_Jake33
16th March 2009, 15:55
Dunno what it is about the new Vsync code, but it causes major frame drops with a specific 1080i H.264 video file that I have. This occurs both with and without Reclock, and is rectified by ticking 'Alternative Vsync' in the options menu (which I assume reverts to the older code).
This is using ffdshow w/ ffmpeg-mt to decode.
flanger216
16th March 2009, 16:05
Ok, Reclock wasn't as fancy as I expected, and you are right I should be able to accomplish the same thing as reclock in this case. But only now that I have the refresh rate detected can I do it perfectly. We will see how this works out when I get to writing the code in question (the current code does do some things, but not enough).
[if you replicate Reclock's jitter correction and manage to add a WASAPI audio renderer, your build of MPC-HC would be the ultimate stand-alone media solution for Windows...]
Casshern
16th March 2009, 17:24
Just one small question why do you need to use D3D fullscreen? With vmr9 mixer mode and yuv mixing enabled (and no vsync stuff) vmr9 crops 1088 correctly to 1080 and i get no tearing with an ATI 2x00 card - both with dxva and with software decoding. I am just wondering why anybody would use d3d fullscreen mode at all nowadays with an ATI board. I had numerous radeon cards from 7x00, 9x00 and now the 2600 HD - and never any probs with tearing under XP - naturally vmr7 and overlay were always tearingfree - and vmr9 renderless has been tearingfree since the lockback buffer option became available (which is no longer needed since ver 18). Does this change with VISTA/win7?
My VC-1 rips still playback disastrously with this build regardless of renderer or whether frame time correction is enabled.
And turning on "High color" causes lines 1081-1088 to be displayed in 1080p rips, with consequent AR distortion and noise in the bottom few lines in some.
Jong
16th March 2009, 18:17
Just one small question why do you need to use D3D fullscreen? Well with the normal build D3D does not enforce vsync (so I can use Reclock), but non-D3D does....and it makes no difference at all to any of the problems above.
Come to think of it, maybe this is a pointer to why Beliyaal's build behaves differently with alternate vsync "off", Maybe in making his changes the D3D vsync approach became the same as non-D3D?
Egh
16th March 2009, 18:46
Thanx, confirmed working on XP SP3/VMR9 renderless. I do see it occasionally go wrong though, e.g. the detected refreshrate can drop well over 10Hz when using some h264's even though I'm pretty sure it is not the actual case. For mpeg2, it seems to slowly oscillate +1/-1Hz.
it is NOT confirmed to work. XP x64 SP2 / VMR9 Nvidia 182.08.
Same as ver16. Refresh rates work in EVRCP but not in VMR9.
Tried AVC and MPEG2 files with and w/o internal decoders.
Can anyone confirm that Beliyaal's build works with VMR9 Renderless with VMR9 Mixer option off? It doesn't work here but works with SVN build. Actually Beliyaal's build crashes immediately with VMR9 Mixer off and 3D surfaces used.
Klaus_1250
17th March 2009, 01:20
it is NOT confirmed to work. XP x64 SP2 / VMR9 Nvidia 182.08.
Sorry, should have posted my specifics. XP SP3 32bit, VMR9 Renderless and ATi Cat 9.2 works.
mikegun
17th March 2009, 10:57
latest build seems to forget my external filters
maybe this is the reason why it crashes so often on
xp sp2 cat 9.2 hd2600pro agp
Casshern
17th March 2009, 23:29
Hi,
i noticed an interesting small bug in the frame rate detection code in conjunction with dxva playback. Bluray to test with "any given sunday" title sequence.
Config: MPC HC V18, WinXP SP3, Catalyst 9.2, VMR9 Renderless, no vsync stuff - just VMR9 Mixer mode and Yuv Mixing checked, dxva1 vc1. ATI 2600 HD 512 MB
1) during the fade to blacks in the title sequence - there is for a second or so just a black screen - the detected frame rate drops and the tearing bar shows judder
2) Cross-checking with a software vc-1 decoding shows that everything works normal then - no change in frame rate
3) Speculation: the decoding during the black screen phase with dxva is extremely fast. Maybe the frame rate detection routine needs a minimum amount of time to pass for the decoder to come up with a new frame.
3b) Speculation2: frame rate detection uses screen difference to check for a new frame- and black screen does not show any difference. But this is unlikely
3c) Speculation3: could it be normal behaviour for DXVA decoding - instead of displaying a couple of black frames it just displays a few black frames longer? Also highly unlikely...
4) all other options (vsync, alt. vsync) do not make a difference. EVR CP also shows this behaviour
5)In VMR7 and Overlay i cannot check if the problem occurs because with dxva i do not get a tearing bar from mpc hc or reclock
6)In EVR its the same as in VMR9 renderless - also D3D fullscreen does not change it. Same judder during black phase
7)enabling frame time correction in EVR CP - changes the prob slightly. Instead of juddering the tearing bar stops for a fraction of a second and then resumes normally.... strange
8)GPU time normally is above 20ms - when the juddering starts its about 18ms and jitter shoots up
9)most importantly probably. Last frame time jumps up from 41.xxx to 83.xxxx when juddering
At the moment its not really a big problem because i only noticed it during black phases in the decoded stream - and usually one doesn't watch with the tearing bar (except for me and Jong). But still it might crop up in other situations to....
Episode
18th March 2009, 22:24
Btw, are these builds supposed to crash whenever you are trying to change player's logo from options?
Egh
18th March 2009, 23:41
Btw, are these builds supposed to crash whenever you are trying to change player's logo from options?
doesn't crash here at least (with version18)
Kado
19th March 2009, 01:53
Custom logo and EVR CP works fine here.
Casshern
19th March 2009, 03:54
If dxva is used by the internal h264 decoder sometimes "display stats" will report falsely "no dxva". But DXVA is definatly being used (CPU usage low, Filter property page of mpc filter says dxva is used). Happens mostly on h264 stuff but not on all - strange!
Kado
19th March 2009, 09:17
Can you provide a sample?
mark0077
19th March 2009, 22:11
I am not sure if this is problem with just the Beliyaal builds or not. But recently I have noticed that with my current power settings, (Turn off display after 20 minutes, screensaver after 10 minutes) that watching movies fullscreen, no screensaver comes on or the TV doesn't turn off. It is only when I exit mpc after the movie completes, that it seems like the screensaver is running BEHIND the movie, and oddly the TV then turns off.
I wonder could someone look into this. Something isn't right with regard to "talking" to windows with relation to screensavers, power options.
STaRGaZeR
20th March 2009, 06:18
Bug: when high color resolution is used, screenshots look like this:
http://thumbnails16.imagebam.com/3024/0620cc30236573.gif (http://www.imagebam.com/image/0620cc30236573)
Casshern
20th March 2009, 10:59
BD of IP-MAN. Unfortunately i can't post a sample due to copyright.
Can you provide a sample?
diman1982
20th March 2009, 17:21
Belyiaal, thanks a lot for your work and for your №18 build of mpc-hc!
I had a problem:
Hello. I have a tearing problem in 24p(basic for hd material) refresh mode, my config:
- winxp sp3 x86
- athlon x2 5600+ (not o/c)
- nvidia 9500gt with 182,08 drivers(btw cuda with coreavc works fine even with hdrips)
- mpc-hc 1.2.1011.0
- signal is going to panasonic lcd tv via hdmi
So, i tried diffent renderers in mpc-hc:
- overlay mixer gives zero tearing and zero stuttering BUT it has a progressive a/v desync.
- vmr9 renderless gives excellent a/v sync but an awfull tearing
other renderers also have either tearing or a/v desync
I tried software and hw(cuda, dxva) decoding with different codecs(mpchc vide decoder, coreavc, ffdshow) - same results
I tried several sync options: vsync in nvidia drivers, checkboxes in "output" section of mpc - same results
SO, how can i fix my problem? maybe i should change something in nvidia driver sattings?
Or should i buy another video card, sometging like Ati 4650?
p.s. the one thing that i REALLY don't want to do is change my OS to Vista. I heard that EVR renderer on vista is good, but i just dont like this os.
thanks in advance.
i've tried your build №18. It seems to me that my problem is solved. With evr custom there are zero tearing. May be there is a little stuttering, but you have to look hard for it to see it. And it somehow manages to dynamically eliminate a/v desync. I think it's the best 24p solution for me.
I ve tested it using coreavc with nvidia cuda enabled. For test i used 720p and 1080p mkv bdrips(even one with subtitles, for them i have directvobsub), no problems with subs.
Little bugs:
- sync offset is going from -40ms then it is increasing to -70-80ms(during 1 min of playing), then stutter occurs which takes desync back to 40ms - is this normal? I am not complayning, it is barely visible, but may be there is a way to make 1 stutter in, say, 5-6 minutes - that would be perfect.
- when using a step forward/backward, sound of the new index point starts playing immideatly, but video needs some time(3-4 sec.)
Question: what does the "evr buffers" parameter meen? What value should i choose for it?
And what is "increase/decrease offset"?
What is "frame time correction"?
Did you compare the picture quality in (your build + evr cp) to, say, (regular build + overlay mixer)?
what renderer gives reference pq?
BatKnight
22nd March 2009, 19:56
Belyiaal, after clean installing ATI Catalyst 9.3 drivers your MPC ver18 showed tearing and stuttering with EVR Custom.
This problem doesn't happen with SVN 1014.
Thanks
Bat
MatMaul
22nd March 2009, 20:27
the tiny weird line at the bottom of videos is still here.
http://forum.doom9.org/showpost.php?p=1238622&postcount=5949
I just change my configuration to an integrated GeForce 7100.
with latest stable drivers (182.08), same weird line.
EDIT : I am using VMR9 renderless with mixer mode, XP SP3
Beliyaal
22nd March 2009, 22:52
New version (Link in signature):
* Updated to lastest SVN
* Fixed: Stutters minimized (EVR only). Tested matrix: (23.976fps, 24fps, 25fps, 50fps, 59.94ps) x (23.796Hz, 24Hz, 47.952Hz, 50Hz, 59.94Hz, 60Hz)
* Fixed: Normal VSync now stutters less (not at all hopefully) as the VSync pre wait has a larger margin (5 ms instead of 1.8 ms)
* Fixed: VMR9 crash when not using mixer mode.
* Fixed: When Aero is enabled the screen no longer flickers or crash when using full screen mode.
* Fixed: Options dialog and other dialog no longer appear on the fullscreen window, unless fullscreen gui support is enabled.
* Fixed: 10 bit dislay mode now works in fullscreen mode.
* Changed: VSync position when desktop composition is enabled moved to middle of screen, instead of top of screen.
This build should have all stutters minimized as far as possible. Please test it with VSync ENABLED in mpc-hc. If you are using ATI hardware with latest drivers you should enable Alternative VSync as this works well. In your 3D options make sure you don't have VSync to "Always On" as this could interfere with the code.
If you find that you have problems with stuttering, please include a screenshot with statistics enabled in the bug report as this helps a lot with locating the problem.
This new anti-stuttering code only works in the EVR Custom renderer. I will not be making any fixes for stuttering in the VMR9 renderer.
This version is a candidate for submitting the patches to SVN. If no mayor problems are found with this build I will aim at submitting everything to SVN next weekend.
ooferomen
22nd March 2009, 23:04
nice! D3D Fullscreen works now!
Mercury_22
23rd March 2009, 00:29
New version (Link in signature):
* Updated to lastest SVN
* Fixed: Stutters minimized (EVR only). Tested matrix: (23.976fps, 24fps, 25fps, 50fps, 59.94ps) x (23.796Hz, 24Hz, 47.952Hz, 50Hz, 59.94Hz, 60Hz)
* Fixed: Normal VSync now stutters less (not at all hopefully) as the VSync pre wait has a larger margin (5 ms instead of 1.8 ms)
* Fixed: VMR9 crash when not using mixer mode.
* Fixed: When Aero is enabled the screen no longer flickers or crash when using full screen mode.
* Fixed: Options dialog and other dialog no longer appear on the fullscreen window, unless fullscreen gui support is enabled.
* Fixed: 10 bit dislay mode now works in fullscreen mode.
* Changed: VSync position when desktop composition is enabled moved to middle of screen, instead of top of screen.
This build should have all stutters minimized as far as possible. Please test it with VSync ENABLED in mpc-hc. If you are using ATI hardware with latest drivers you should enable Alternative VSync as this works well. In your 3D options make sure you don't have VSync to "Always On" as this could interfere with the code.
If you find that you have problems with stuttering, please include a screenshot with statistics enabled in the bug report as this helps a lot with locating the problem.
This new anti-stuttering code only works in the EVR Custom renderer. I will not be making any fixes for stuttering in the VMR9 renderer.
This version is a candidate for submitting the patches to SVN. If no mayor problems are found with this build I will aim at submitting everything to SVN next weekend.
10bit RGB still carshing with Interlaced material (tested mpeg2, VC-1, AVC) with m2ts, ts container BUT NOT CRASHING in MKV
Also Progressive material it's recognized as Interlaced (tested AVC, VC-1 in m2ts, ts, mkv )
yesgrey
23rd March 2009, 00:38
* Fixed: Normal VSync now stutters less
Please test it with VSync ENABLED in mpc-hc. If you are using ATI hardware with latest drivers you should enable Alternative VSync as this works well.
So, does this means that the preferable options are:
ATI:
check Alternative VSync; check VSync and check Accurate VSync.
NVidia:
uncheck Alternative VSync; check VSync and check Accurate VSync.
???
* Fixed: 10 bit dislay mode now works in fullscreen mode.
I still cannot see the statistics while in fullscreen mode, but the video plays nicelly... how can I know if it's outputing at 10bit?.... Would it be a XP incompatibility or a NVidia incompatibility?
And once again thank you very much, mpc-hc is working better day by day.:)
Beliyaal
23rd March 2009, 01:26
New version (Link in signature):
* Fixed: Mad stuttering when the whole frame is able to be drawn within the vsync.
Found a stuttering bug that occured only when statistics weren't displayed.
Beliyaal
23rd March 2009, 01:31
10bit RGB still carshing with Interlaced material (tested mpeg2, VC-1, AVC) with m2ts, ts container BUT NOT CRASHING in MKV
Also Progressive material it's recognized as Interlaced (tested AVC, VC-1 in m2ts, ts, mkv )
The 10 bit crash is a bug in the ATI driver. As well as the ATI driver only doing 0-255 conversion. I cannot fix this. Works if you deinterlace in software.
The interlaced/progressive flag is taken from the media type. It will display interlaced if you have this enabled in ffdshow. With the option to output interlaced in ffdshow, the stream is always marked as interlaced. It shouldn't matter as this flag isn't used anywhere, only for information.
So, does this means that the preferable options are:
ATI:
check Alternative VSync; check VSync and check Accurate VSync.
NVidia:
uncheck Alternative VSync; check VSync and check Accurate VSync.
???
I'm not sure about NVidia as I havn't tested it, but the ATI options are the preferred.
I still cannot see the statistics while in fullscreen mode, but the video plays nicelly... how can I know if it's outputing at 10bit?.... Would it be a XP incompatibility or a NVidia incompatibility?
10 bit mode shouldn't work in XP as it uses D3D9Ex which should be available only in Vista. If you cannot see statistics the render probably failed to initialize and you are using the default VMR9 or EVR renderer (not custom).
Beliyaal
23rd March 2009, 01:36
I have been reading a little about EVR, so let me rephrase my question:
Can the EVR Custom Presenter used in mpc-hc receive YCbCr from the EVR Mixer, or the EVR Mixer only outputs RGB?
I'm asking this to know if we could perform the conversion from YCbCr->RGB inside the custom presenter.
Of course if mpc-hc also has a EVR custom mixer we could do it, but that should be more work...
I tried to do this by telling the EVR that I wanted YUV and other YCbCr formats as output to the renderer, but it wouldn't accept it.
I don't think that it would help to create a custom mixer. The output from the mixer is already the input format (as opposed to RGB32 before).
For now it works with 10 bit output anyway, we just need to report the bugs that this exposes to the graphics card vendors.
noee
23rd March 2009, 01:44
All I can say is, this build really shines on my setup with SD (23.976fps) rips in MKV containers.
XPSP3, ATI HD2600XT, CCC9.2
CCCVSynch "OFF unless app specifies"
LG37 @ 24Hz, Reclock using Excellent, PCM to HDMI with Kernel Streaming
MPC-HC EVR-CP, D3D Fullscreen On, EVR Buffers 25, Vsync on, Accurate Vsync On, Alternative Vsync On, Output Range 16-235
:thanks:
Beliyaal
23rd March 2009, 01:46
My VC-1 rips still playback disastrously with this build regardless of renderer or whether frame time correction is enabled.
I have not tested any EVO clips, do they work with haali splitter? Note: Frame time correction only available in EVR.
And turning on "High color" causes lines 1081-1088 to be displayed in 1080p rips, with consequent AR distortion and noise in the bottom few lines in some.
Probably a driver bug, as it works in the 8 bit mode, and nothing is different between the rendering in the modes.
Well with the normal build D3D does not enforce vsync (so I can use Reclock), but non-D3D does....and it makes no difference at all to any of the problems above.
Come to think of it, maybe this is a pointer to why Beliyaal's build behaves differently with alternate vsync "off", Maybe in making his changes the D3D vsync approach became the same as non-D3D?
The normal build definately enforces VSync. If it does not it's a bug.
Hi,
8)GPU time normally is above 20ms - when the juddering starts its about 18ms and jitter shoots up
This is very high, and probably the cause of your problems. If you are using any shaders you might want to disable some of them. The GPU time might also be the DXVA acceleration, but it shouldn't interfere.
sarastro
23rd March 2009, 02:02
When I start a mkv the screen stays black but the audio works. And some mkv files only displays a black screen and if I click on it MPC-HC crashes.
Windows 7 build 7057 x 64
IGP HD3200, Ati Radeon 9.3
EVR custom
With aero enabled.
I have no trouble playing dxva enabled mkv's with the regular MPC-HC.
I have tried reinstalling the 9.3 catalyst drivers to make sure they've installed correctly. I cant make a screenshot cause as soon as I click on MPC it crashes.
STaRGaZeR
23rd March 2009, 03:03
Version 20 is smooth as butter here on 75Hz too.
BTW the "Repeat forever will display black screen randomly" bug has been fixed for some revisions now. At least is completely gone for me.
yesgrey
23rd March 2009, 03:18
10 bit mode shouldn't work in XP as it uses D3D9Ex which should be available only in Vista.
But when I select it without the Fullscreen exclusive the surface and back buffer are 10 bit, so it seems only the display cannot be 10 bit...:(
I tried to do this by telling the EVR that I wanted YUV and other YCbCr formats as output to the renderer, but it wouldn't accept it.
I think I have not explained myself correctly... I was asking if we can have YCbCr formats as input to the presenter, not as output of the renderer.
I don't think that it would help to create a custom mixer. The output from the mixer is already the input format (as opposed to RGB32 before).
The idea of creating the custom mixer is to allow us the access to the YCbCr data that enters EVR. From my readings, it appears that only in the mixer we can access it, because it seems the presenter always want a RGB format at its input.
Can you please confirm this?
Thanks.
Mercury_22
23rd March 2009, 10:42
The 10 bit crash is a bug in the ATI driver. As well as the ATI driver only doing 0-255 conversion. I cannot fix this. Works if you deinterlace in software.
The interlaced/progressive flag is taken from the media type. It will display interlaced if you have this enabled in ffdshow. With the option to output interlaced in ffdshow, the stream is always marked as interlaced. It shouldn't matter as this flag isn't used anywhere, only for information.
I'm not sure about NVidia as I havn't tested it, but the ATI options are the preferred.
10 bit mode shouldn't work in XP as it uses D3D9Ex which should be available only in Vista. If you cannot see statistics the render probably failed to initialize and you are using the default VMR9 or EVR renderer (not custom).
I DIDN'T say anything about using FFDShow, I'm refering to internal filters!
Anyway ... since you're saying that "this flag isn't used anywhere, only for information" doesn't matter I just hope to see the other bugs fixed too :thanks:
yesgrey
23rd March 2009, 11:19
About the subtitles request, it's not a problem anymore, I've remembered that ffdshow has a subtitle filter, and it works great, so I only need to disable mpc subtitle internal renderer.
Well I would still like to fix it if possible :) So if you could confirm if it's still a problem it would be great.
Beliyaal,
Yes, it's still a problem, but it's a very strange one... it's a "come and go" problem. A few days back was not working, now, I have tested, and it's working ok. I don't understand. It's only happening with mpc-hc's subtitle renderer, if I use ffdshow's subtitle renderer the results are always flawless.
The problem is the subtitles being rendered like it was a 25fps movie when it's a 24fps movie, so, the subtitles start appearing sooner that they should.
I will try to discover what's happening, because if the problem comes and go I should be able to find the reason for it...
THX-UltraII
23rd March 2009, 12:25
The only reason I might use reclock in the future is for PAL speeddown, maybe a future project for beliyaal
Would be great!
Klaus_1250
23rd March 2009, 12:51
New version (Link in signature):
* Fixed: Stutters minimized (EVR only). Tested matrix: (23.976fps, 24fps, 25fps, 50fps, 59.94ps) x (23.796Hz, 24Hz, 47.952Hz, 50Hz, 59.94Hz, 60Hz)
Could it be checked against 72Hz and 75Hz as well? Some laptops and monitors do not support 50Hz, so for 24/25fps material, 72 and 75Hz are the best/only options.
This new anti-stuttering code only works in the EVR Custom renderer. I will not be making any fixes for stuttering in the VMR9 renderer.
Is that because it is not feasible in VMR9 or because you're not interested in investing your time in it?
Thanks for your build and all the patches by the way!
diman1982
23rd March 2009, 13:56
Beliyaal
what settings would you recomend for evr, winxp sp3, nvidia 9500gt and your ver.20?
please, answer to my post on previous page.
THX-UltraII
23rd March 2009, 15:21
Please test it with VSync ENABLED in mpc-hc. If you are using ATI hardware with latest drivers you should enable Alternative VSync as this works well. In your 3D options make sure you don't have VSync to "Always On" as this could interfere with the code
Beliyaal, I can choose 4 different settings for VSync in the ATI 9.3 CCC, the far left is OFF, should this one be chosen? (I only use MPC-HC on my HTPC, no other video/gaming)
nitec
23rd March 2009, 15:53
When I start a mkv the screen stays black but the audio works. And some mkv files only displays a black screen and if I click on it MPC-HC crashes.
Windows 7 build 7057 x 64
IGP HD3200, Ati Radeon 9.3
EVR custom
With aero enabled.
I have no trouble playing dxva enabled mkv's with the regular MPC-HC.
I have tried reinstalling the 9.3 catalyst drivers to make sure they've installed correctly. I cant make a screenshot cause as soon as I click on MPC it crashes.
Second that. After build 17 all of your builds have playback and stutter problems with my rig.
Windows 7 build 7000 x64
HD4850, Ati Radeon 9.3
EVR custom
Aero enabled
yesgrey
23rd March 2009, 17:55
what settings would you recomend for evr, winxp sp3, nvidia 9500gt and your ver.20?
I've asked that and the question was this for ATI:
In the options: check Alternative VSync
In the renderer settings: check VSync and check Accurate VSync.
He only has an ATI, but I believe that for NVidia should be the same settings. I am using them with my 8600GT XP SP3 and the results are great.
diman1982
23rd March 2009, 18:56
I've asked that and the question was this for ATI:
In the options: check Alternative VSync
In the renderer settings: check VSync and check Accurate VSync.
He only has an ATI, but I believe that for NVidia should be the same settings. I am using them with my 8600GT XP SP3 and the results are great.
well, if so then nothing have changed for me from ver.18 to 20. No tearing at all, but one stutter(skipped frame) in 1min10sec. Do you have it?
(with evr custom + this settings)
Jong
23rd March 2009, 19:18
I have not tested any EVO clips, do they work with haali splitter? Note: Frame time correction only available in EVR. This is an HD-DVD movie, remuxed to mkv. It is not an EVO. It works fine with the normal build and your earlier builds, but was broken two builds back. I have yet to try your new build. As I said earlier I tried it with VMR9 and EVR, both have the same problem. And when using EVR it makes no difference whether frame time correction is enabled.
Probably a driver bug, as it works in the 8 bit mode, and nothing is different between the rendering in the modes.Well OK, not a show stopper. But this is Cat.9.2 on XP with a 3850, nothing wacky.
The normal build definately enforces VSync. If it does not it's a bug.It does in non-D3D mode but definitely does not in D3D mode. It is very simple to test. This is very useful as it allows us to use Reclock to fix vsync.
I will try your new build. However, I still say if you are to introduce an "alternate vsync" the old methods should still work as they did before or you are breaking functionality that people may depend upon. All I ask is when we disable vsync in "normal" (non-alternate) mode, it actually does that and behaves as the normal build. Not unreasonable I hope.
Beliyaal
23rd March 2009, 20:12
This is an HD-DVD movie, remuxed to mkv. It is not an EVO. It works fine with the normal build and your earlier builds, but was broken two builds back. I have yet to try your new build. As I said earlier I tried it with VMR9 and EVR, both have the same problem. And when using EVR it makes no difference whether frame time correction is enabled.
Ok, does it exhihit the same behaviour in the normal build with VMR9 (Only working with EVR custom in normal build)?
It does in non-D3D mode but definitely does not in D3D mode. It is very simple to test. This is very useful as it allows us to use Reclock to fix vsync.
I will try your new build. However, I still say if you are to introduce an "alternate vsync" the old methods should still work as they did before or you are breaking functionality that people may depend upon. All I ask is when we disable vsync in "normal" (non-alternate) mode, it actually does that and behaves as the normal build. Not unreasonable I hope.
I'm not sure what I need to restore here. With EVR Custom it's not possible to bring back the old behaviour. With VMR9 it should be possible if I have changed something I'm not aware of. Should I see tearing if its working? Could you provide a step by step reproduction and explain what you see in my version, and what you see in the official version (with and without Reclock)?
nijiko
23rd March 2009, 20:15
Excuse me. I try to use your edition. But I found it is slower than original offical edition in decoding X264 video. Can you improve it? Thank you.
Beliyaal
23rd March 2009, 20:16
I think I have not explained myself correctly... I was asking if we can have YCbCr formats as input to the presenter, not as output of the renderer.
That's what I meant, I tried having YCbCr as input to the presenter, but it wouldn't accept the format.
The idea of creating the custom mixer is to allow us the access to the YCbCr data that enters EVR. From my readings, it appears that only in the mixer we can access it, because it seems the presenter always want a RGB format at its input.
Can you please confirm this?
Thanks.
Yes, this might be possible, but would be quite a hack needing to transfer the data outside of the EVR pipeline, probably loosing hardware deinterlacing and other HW acceleration.
Beliyaal
23rd March 2009, 20:18
Excuse me. I try to use your edition. But I found it is slower than original offical edition in decoding X264 video. Can you improve it? Thank you.
If you were using the 64 bit edition, yes, my version doesn't have GCC libavcodec for the 64 bit version. If you need to use 64 bit version you should use ffdshow for decoding vc1 and h264 instead.
Beliyaal
23rd March 2009, 20:30
Beliyaal,
Yes, it's still a problem, but it's a very strange one... it's a "come and go" problem. A few days back was not working, now, I have tested, and it's working ok. I don't understand. It's only happening with mpc-hc's subtitle renderer, if I use ffdshow's subtitle renderer the results are always flawless.
The problem is the subtitles being rendered like it was a 25fps movie when it's a 24fps movie, so, the subtitles start appearing sooner that they should.
I will try to discover what's happening, because if the problem comes and go I should be able to find the reason for it...
It's probably only on subtitles that are using frame numbers instead of absolute time for timing. It would rely on the FPS reported by the stream. There isn't really any other way to detect the FPS. It could be done by checking the frame times, but other filters in the chain can change individual frame times, such as deinterlacers. You can check the stream FPS in statistics. It's the first value inside parenthesis.
Beliyaal
23rd March 2009, 20:35
Could it be checked against 72Hz and 75Hz as well? Some laptops and monitors do not support 50Hz, so for 24/25fps material, 72 and 75Hz are the best/only options.
I don't have access to such monitors, if there is a problem it would be good is someone reports it.
Is that because it is not feasible in VMR9 or because you're not interested in investing your time in it?
I see no obvious way to achieve this as the VMR9 timing code is not custom (provided by Microsoft). It might be possible to customize the timing code, but I don't feel that it's worth the effort to invest time in XP.
Beliyaal
23rd March 2009, 20:40
Second that. After build 17 all of your builds have playback and stutter problems with my rig.
Windows 7 build 7000 x64
HD4850, Ati Radeon 9.3
EVR custom
Aero enabled
Probably some incompatibility problem with Windows 7. Will test when I have time.
Beliyaal
23rd March 2009, 20:42
well, if so then nothing have changed for me from ver.18 to 20. No tearing at all, but one stutter(skipped frame) in 1min10sec. Do you have it?
(with evr custom + this settings)
This is the difference between 24 and 23.976 FPS. It takes about 1 minute before you need to display one frame two times to keep the audio in sync.
You either need to set your display mode to 23.976 FPS (ATI needs Power Strip for this) or use reclock to resample the audio so the movie plays in 24 FPS.
Matching_Mole
23rd March 2009, 20:48
Hi all,
Thanks Beliyaal for your new version. It works perfectly on my two PC and all is as smooth as possible except when I use subtitles.
I mean, if I use an external subtitle file (or if it is attached in a mkv too), the jitter stat become "crazy" as soon as a subtitle is print on the screen and become again a flat line as soon as the subtitle disappears of the screen.
I have this issue on my two PC and with MKV or M2TS files. I try several set up (different buffers, different texture resolutions,...) but with no effect. Obviously, if I use FFDSHOW instead of MPCHC to print the subtitles, I have no more this issue but I lost too the override placement ability.
My configs :
XP SP3
ATI 2400 / 2600pro
EVR custom.
mark0077
23rd March 2009, 20:52
Very impressed with latest version. Whatever you're doing its working. Watched entire 1080p vc-1 .ts file and only got 1 frame drop while also browsing internet. Only using 3 evr-cp buffers to minimize delays when using dvd-menu's and all working perfectly.
tetsuo55
23rd March 2009, 20:53
Probably some incompatibility problem with Windows 7. Will test when I have time.
another confirm.
windows7 7057, ati catalyst 9.3.
problem started 2 or 3 builds ago
Matching_Mole
23rd March 2009, 20:55
Just a precision about my subtitle issue. I make a little tes and i discovered that if I use the internal h24 filter I have any issue. It is just when I use ffdshow as h264 decoder.
Jong
23rd March 2009, 21:00
Ok, does it exhihit the same behaviour in the normal build with VMR9 (Only working with EVR custom in normal build)?
I'm not sure what I need to restore here. With EVR Custom it's not possible to bring back the old behaviour. With VMR9 it should be possible if I have changed something I'm not aware of. Should I see tearing if its working? Could you provide a step by step reproduction and explain what you see in my version, and what you see in the official version (with and without Reclock)?VC-1 video displays fine in both VMR9 and EVR modes in the normal build and fine with your earlier builds, but a couple of builds back, it started jumping like crazy, almost like it was displaying in reverse field order, except this is a progressive file. It happens will all my HD-DVD VC-1 rips. As we said, it may have something to do with the fact that the mkv still has 3:2 pulldown flags in place, but this never affected earlier versions of MPC-HC.
Regarding my vsync concerns, thanks for looking into this. I am talking about VMR9 D3D mode. In the official version there is no tearing, but vsync is not pinned. It behaves mcuh as the overlay renderer does. If you bring up Reclcok's vsync indicator it varies position on each seek and if you turn on Reclock's vsync correction it successfully pulls the vsync position into line. Reclock is not able to do this in non-D3D mode (where vsync IS clearly pinned when you display its position using Reclock). The easiest way to test is to use Reclock's vsync indicator, with Reclock correction off, obviously with a non-DXVA decoder.
cca
23rd March 2009, 21:19
This build is certainly moving to the right direction. Stutters are almost gone, still getting some but very rarely anymore. Only noticeable when playing 29.97fps videos, my refresh is 59.805Hz so I use ReClock to match the fps to the refresh rate. Most people won't notice anything probably.
Beliyaal
23rd March 2009, 22:25
I just noticed that I managed to disable half the VSync correction code in version 20. Forgot to enable it after fixing the stuttering bug that I released version 20 for. Will try to get you a new build tonight.
DeepBeepMeep
23rd March 2009, 22:38
I don't know if it is related, but I have noticed that very often when mplayer subtitles popup and disappears (like in most dialogue) a frame is skipped (this was tested while playing a 23.976fps movie on a 23.976Hz screen)
In addition support for 72Hz screen with 23.976 doesn't seem to work well : stutter comes and go
My config: XP, EVR, CoreAVC, NVidia8600GTS
cca
23rd March 2009, 22:48
I just noticed that I managed to disable half the VSync correction code in version 20. Forgot to enable it after fixing the stuttering bug that I released version 20 for. Will try to get you a new build tonight.
Doh! Ok, in a way this is funny :devil:
Kado
23rd March 2009, 23:19
@DeepBeepMeep
That only happens if you set subtitle buffering to zero, it's already known.
DeepBeepMeep
24th March 2009, 00:31
@Kado: thanks I have disabled animated subtitles and it works much better
I have noticed that I can prevent mplayer from giving some judder at 72h/75h if I disable the VSync feature of Reclock
I think I might have spotted a bug: sometime when leaving a file played using EVR / D3DFull screen mode, the GUI interface of mplayer remains frozen as if the Exclusive mode was still on. I am then forced to kill mplayer.
Edit: it seems the internal subtitle engines interferes with the vsync algorithm even if there are multiple buffers for the subtitles (although in this case the frame skips are less frequent). It is quite obvious if I switch to ffdshow subtilte engine as the judder disapears.
yesgrey
24th March 2009, 01:59
It's probably only on subtitles that are using frame numbers instead of absolute time for timing.
That's the reason I said it was strange... even subtitles with absolute timing show the problem.
Currently it's working ok, but a few days back it wasn't.:confused:
It seems like those movies when a person sees something and the next moment it's not there...;)
I will continue trying to find a way of reproducing the problem...:sly:
yesgrey
24th March 2009, 02:02
That's what I meant, I tried having YCbCr as input to the presenter, but it wouldn't accept the format.
Sorry, I did not understood it... Thanks for testing it.
St Devious
24th March 2009, 04:34
I'm confused. I'm new to MPC HC. I have a 8800GT , so DXVA is working perfectly.
But I'm confused as to what this build does that the MPC HC in the other thread does not ?
neoufo51
24th March 2009, 07:06
Just so Beliyaal and others following his builds are aware.
DirectX Redist March 2009 and DirectX SDK March 2009 released.
http://download.microsoft.com/download/3/C/4/3C46A69A-CB0F-4CCA-B1E8-248D43270D5F/directx_mar2009_redist.exe
http://download.microsoft.com/download/3/A/5/3A53CE87-F5C9-4CE5-92E1-5E2AF4841741/DXSDK_Mar09.exe
Kado
24th March 2009, 09:54
@wolf2009
Read the first post!
cca
24th March 2009, 11:23
Any news on the updated build?
THX-UltraII
24th March 2009, 11:57
Beliyaal, I can choose 4 different settings for VSync in the ATI 9.3 CCC, the far left is OFF, should this one be chosen? (I only use MPC-HC on my HTPC, no other video/gaming)
Beliyaal, any idea?
cca
24th March 2009, 12:36
@THX-UltraII
He only said not to turn VSync on, so one of the 2 first options should be OK. I use the default, OFF Unless otherwise specified.
Jong
24th March 2009, 12:41
I realise there is a new build due any moment, but just to say that build20 is just as vulnerable to synchronised frame rate/refresh rate judder (alternate Vsync "enabled", vsync "on"). On every seek "Vblank Wait start" is random and if it crosses 1080/0 as it varies from frame to frame judder occurs.
EVR seems to have a worse problem (much easier to make it happen, maybe 1 in 4 times instead of 1 in 10). but it is not as easy to tell any more from the stats screen what the cause is. I think it may just be that VBlank Wait Start is more variable from frame to frame, causing it to cut through the threashold for a wider range of start values.
http://jong.pwp.blueyonder.co.uk/images/Beliyaal20_001.jpg
Also build 20 has the same bug in VC-1 playback.
Jong
24th March 2009, 13:01
I am talking about VMR9 D3D mode. In the official version there is no tearing, but vsync is not pinned. It behaves mcuh as the overlay renderer does.By the way, just tested and it is also true of EVR CP - in the normal build vsync is not pinned, but in build20 even with alternate vsync "disabled" and vsync "off" it is.
Both VMR9 and EVR CP tested with the last stable release of MPC-HC and svn 1015
Cyber-Mav
24th March 2009, 13:30
just thought i would give some additional info, video memory usage is 459.31mb using MPCHC and coreavc cuda playing back transformers 1080p mkv i made. using windows XP EVR CP and 50 buffers. 60 buffers is too much and doesnt leave enough memory for cuda to work.
will test more.
Cyber-Mav
24th March 2009, 13:32
same test above but using 55 evr buffers and the memory usage is 492.06mb.
need to add that my screen rez is 1280x1024 on this pc so memory usage will go higher with more resolution.
Leak
24th March 2009, 13:50
I realise there is a new build due any moment, but just to say that build20 is just as vulnerable to synchronised frame rate/refresh rate judder (alternate Vsync "enabled", vsync "on"). On every seek "Vblank Wait start" is random and if it crosses 1080/0 as it varies from frame to frame judder occurs.
Yeah, well...
I just noticed that I managed to disable half the VSync correction code in version 20. Forgot to enable it after fixing the stuttering bug that I released version 20 for. Will try to get you a new build tonight.
...having half the code disabled might just cause that... :D
diman1982
24th March 2009, 14:14
This is the difference between 24 and 23.976 FPS. It takes about 1 minute before you need to display one frame two times to keep the audio in sync.
You either need to set your display mode to 23.976 FPS (ATI needs Power Strip for this) or use reclock to resample the audio so the movie plays in 24 FPS.
ok, so how can i set my 9500gt to 23.976hz instead of 24hz?
Jong
24th March 2009, 14:15
...having half the code disabled might just cause that... :DYeah, that's why I mentioned it! However, others had reported good results with this build so I thought it was worth a try in case this was one area where things had changed. Sadly, behaviour is as with all previous builds. We will see if build 21 fixes it.
I am still not sure if this is even in the scope of what Beliyaal is trying to fix or if he is just trying to get smoother more stable play after you have manually caught the vsync correctly (i.e. we still need to re-seek if the video is juddering at the start or after a seek). It would be good to know, because if there is no intention to fix this "synchronised judder at start/after seek" I can stop going on about it! Although it would make it all the more important that any move of this code to the svn does not break the ability to use Reclock vsync correction instead. This is what worries me the most at the moment, although I love the other enhancements Beliyaal has made.
Beliyaal
24th March 2009, 16:38
Yeah, that's why I mentioned it! However, others had reported good results with this build so I thought it was worth a try in case this was one area where things had changed. Sadly, behaviour is as with all previous builds. We will see if build 21 fixes it.
I am still not sure if this is even in the scope of what Beliyaal is trying to fix or if he is just trying to get smoother more stable play after you have manually caught the vsync correctly (i.e. we still need to re-seek if the video is juddering at the start or after a seek). It would be good to know, because if there is no intention to fix this "synchronised judder at start/after seek" I can stop going on about it! Although it would make it all the more important that any move of this code to the svn does not break the ability to use Reclock vsync correction instead. This is what worries me the most at the moment, although I love the other enhancements Beliyaal has made.
There are two causes of stuttering/judder. Trying to display too close to the VSync. This would before manifest with "VSync start wait" being close to the vsync point. Version 20 has code for this that keeps the VSync start wait point as close after the vsync as possible. It should be stable in your version. Your screenshot says about 300. It should stay about there, and if this value is unstable it doesn't matter. Without statistics enabled, which takes about 10 ms to draw even on my fast Core i7 it will be moved much closer to after the VSync point.
The other reason for stuttering/judder that you are experiencing is that the clock and/or the video display time is not stable. For example for h264 in mkv the frame time alternates between 41 and 42 ms to give an average of 41.708375041708 ms. This "alternating" causes one frame to be "correctly" displayed above the VSync and the other below the VSync, thus the judder you are experiencing.
The code that corrects for this "alternating" is what I accidentally disabled in version 20. So hopefully this problem will be fixed in the next build.
Jong
24th March 2009, 17:30
There are two causes of stuttering/judder. Trying to display too close to the VSync. This would before manifest with "VSync start wait" being close to the vsync point. Version 20 has code for this that keeps the VSync start wait point as close after the vsync as possible. It should be stable in your version. Your screenshot says about 300. It should stay about there, and if this value is unstable it doesn't matter. Without statistics enabled, which takes about 10 ms to draw even on my fast Core i7 it will be moved much closer to after the VSync point.So, OK. You try to set this point around 300. Sounds good. In the past this would vary about +/-50 from the mean. I did notice this with EVR CP, but not VMR9, right? Do you plan to implement in VMR9?
The interesting thing is though that although the mean point on EVR CP seemed to be fixed and sometimes this was fine about one time in four things would vary a lot more from frame to frame, sufficient for even a midpoint of 300 to cross the 0/1080 boundary and re-introduce judder. Hopefully though this will get better with the next version, but have I misunderstood you? Are you saying the stats display itself can cause judder? That would make it hard to assess things.
nijiko
24th March 2009, 21:44
If you were using the 64 bit edition, yes, my version doesn't have GCC libavcodec for the 64 bit version. If you need to use 64 bit version you should use ffdshow for decoding vc1 and h264 instead.
Sorry. I am using XP SP3 now. When I play some X264 videos (I'm using CyberLink PowerDVD 9 Decoder), your edition will drop many frames and lag (compare to offical). And, my CPU is a kind old as P4.
totozero
24th March 2009, 23:29
Hi all.
This last build works very well even without d3d setting. Kudos 2 U, beliyaal.
Just wondering 1 thing : what's the difference b/w pixel shaders / space pixel shaders settings ?
Actually what's the space pixel shaders stuff meant for ? I don't get it. :confused:
TIA.
Casshern
25th March 2009, 00:38
This is very high, and probably the cause of your problems. If you are using any shaders you might want to disable some of them. The GPU time might also be the DXVA acceleration, but it shouldn't interfere.
Hi, this must be another bug - as turning off the shaders completely still shows the same behaviour, even with wait for GPU at 7ms. The frame time has been 41.708 so both the 20ms and the 7ms are well within that.
The strange thing is that it only happens during times when the screen is completely black the jitter graph also shows negative spikes. Also the vc1 frame correction does not make a difference.
On the upside - the bug where the on-screen-stats did not show dxva acceleration seems fixed, at least the bd of ip-man now reports correctly.
Finally i want to ask/beg for you to reconsider doing the vsync code for vmr9. The evr cp does not support h264 dxva with many ati boards under Xp. Under VMR9 it does support both h264 and vc1.
thanks again for your wonderful builds!
Jong
25th March 2009, 15:32
@beliyaal,
I thought I had checked this before, but clearly not:o
Your build only has vsync pinned in D3D mode (alternate vsync disabled) if D3D fullscreen GUI support is enabled. Maybe this is inevitable, if so it is a great shame because D3D GUI support is one of the greatest enhancements of your build. But if you can make D3D GUI support work without affecting vsync it would be great.
sarastro
25th March 2009, 23:52
Second that. After build 17 all of your builds have playback and stutter problems with my rig.
Check! With Windows 7 its back to build 16.
Beliyaal
26th March 2009, 11:17
Check! With Windows 7 its back to build 16.
Does it start working if you disable desktop composition?
Beliyaal
26th March 2009, 11:18
@beliyaal,
I thought I had checked this before, but clearly not:o
Your build only has vsync pinned in D3D mode (alternate vsync disabled) if D3D fullscreen GUI support is enabled. Maybe this is inevitable, if so it is a great shame because D3D GUI support is one of the greatest enhancements of your build. But if you can make D3D GUI support work without affecting vsync it would be great.
I think I need to ask the RClock developer what exactly the requirements are for it to work.
Jong
26th March 2009, 12:13
I think I need to ask the RClock developer what exactly the requirements are for it to work.I think you just need to know how Reclock measures the vsync location.
If Reclock vsync correction is turned off, but the vsync location indicator is turned on the location varies from seek to seek if D3D GUI support is off but it is pinned to the top if GUI support is turned on. There is clearly something very different between these two modes even before Reclock tries to actually do anything.
My (crude) understanding of the way Reclock vsync correction works is it speeds up or slows down the master clock slightly until the subsequently measured vsync location falls within the target zone selected. Clearly if this location is pinned by the player to a specific scanline this can never be achieved. If the player's vsync location is outside of the Reclcok target the video runs perpetually slightly fast/slow, and periodic judder occurs.
ps. is there anything I can do to help with the VC-1 issue. This has to be a show stopper I would think.
Beliyaal
26th March 2009, 14:42
I think you just need to know how Reclock measures the vsync location.
If Reclock vsync correction is turned off, but the vsync location indicator is turned on the location varies from seek to seek if D3D GUI support is off but it is pinned to the top if GUI support is turned on. There is clearly something very different between these two modes even before Reclock tries to actually do anything.
The only difference between D3D gui support on and off is two flags. One is that the backbuffer is lockable, the other is that SetDialogBoxMode on the device is set to true.
My (crude) understanding of the way Reclock vsync correction works is it speeds up or slows down the master clock slightly until the subsequently measured vsync location falls within the target zone selected. Clearly if this location is pinned by the player to a specific scanline this can never be achieved. If the player's vsync location is outside of the Reclcok target the video runs perpetually slightly fast/slow, and periodic judder occurs.
If there is no tearing the vsync position is by definition locked to scanlane 0. What Reclock must correct is the audio/video sync in relation to the VSync. I think the problem is how Reclock determines the audio/video sync position. I need to know how Reclock determines this.
ps. is there anything I can do to help with the VC-1 issue. This has to be a show stopper I would think.
A sample would help a lot.
cca
26th March 2009, 15:11
I don't understand the problem, I just tested the D3D fullscreen mode with and without D3D GUI support. I see no difference, ReClocks VSync indicator is stable at the top of the screen in both cases. Settings used: Alternate VSync ON, Accurate VSync ON, VSync ON. ReClock's VSync correction off, only resampling and indicator active.
BTW Beliyaal, I tried 10bit RGB again, in D3D fullscreen now it says Display: A2R10G10B10, last version I tried was only blank screen. Am I benefiting from this, is it how it's supposed to work?
Jong
26th March 2009, 15:16
A sample would help a lot.I have a sample, I made it when you first asked, but it is 64MB in size. [/B]. Do you have a location I can upload to?
totozero
26th March 2009, 15:17
Just wondering 1 thing : what's the difference b/w pixel shaders / space pixel shaders settings ?
Actually what's the space pixel shaders stuff meant for ? I don't get it. :confused:
TIA.
Bump Bumpy...
Any clue Beliyaal ?
THX.
Jong
26th March 2009, 15:22
I don't understand the problem, I just tested the D3D fullscreen mode with and without D3D GUI support. I see no difference, ReClocks VSync indicator is stable at the top of the screen in both cases. Settings used: Alternate VSync ON, Accurate VSync ON, VSync ON. ReClock's VSync correction off, only resampling and indicator active.The problem is this Beliyaal's vsync correction does not work right now with VMR9 (and may never?), so I want vsync OFF (as measured by Reclock), so Reclock can correct it.
The normal build allows this in D3D mode (EVR and VMR9 on XP).
Beliyaal's build allows this in D3D mode with Alternate vsync OFF, Vsync OFF and D3D GUI support OFF. It does not work when you turn ON D3D GUI support (vsync becomes "pinned" to the top).
So is there a way we can have D3D GUI support AND allow vsync location (as measured by Reclock) to "float" so Reclock can correct it?
Clearly Reclock's method of determining vsync location is not so different, as in all other cases, when vsync is on Reclock shows the location "pinned" and when off Reclock's vsync indicator "floats". It appears D3D does something different.
cca
26th March 2009, 15:31
Ah, VMR9, I only tested EVR Custom using Windows Vista.
STaRGaZeR
26th March 2009, 15:39
Beliyaal, the refresh rate detection is broken in the 64-bit version, and thus vsync too. It displays values varying very quickly, and I think I see an #IND in there.
sarastro
26th March 2009, 15:41
Does it start working if you disable desktop composition?
Unchecked desktop composition, rebooted, tried playing a couple of DXVA compliant mkv's.
MPC still crashes. Some with audio continuing for a few seconds some crash upon opening.
Beliyaal
26th March 2009, 15:42
Bump Bumpy...
Any clue Beliyaal ?
THX.
One is in video space, where each pixel in the shader generates one pixel with the same resolution as the video.
Screen space shaders operates in screen resolution, after the resize of the video to display resolution. This is useful as you want for example sharpen shaders to run in screen resolution, not video resolution.
Beliyaal
26th March 2009, 15:50
Unchecked desktop composition, rebooted, tried playing a couple of DXVA compliant mkv's.
MPC still crashes. Some with audio continuing for a few seconds some crash upon opening.
I thought we were talking about stuttering in Windows 7 version? Is this some other problem that is Windows 7 only? Have you enabled 10 bit color?
tetsuo55
26th March 2009, 15:52
He's talking about the windows7 problem where since build 16 or 17 playing DXVA files result in a black screen instead of video playabck
Egh
26th March 2009, 16:05
Screen space shaders operates in screen resolution, after the resize of the video to display resolution. This is useful as you want for example sharpen shaders to run in screen resolution, not video resolution.
Thanks for that, I've been :confused: for quite a while with these shaders ;)
As for the screen space shaders, the thing I tried to do was to used them after video renderer. Is it possible? As of course normal shaders do not work with Haali renderer. Is it possible to use screen space shaders with Haali?
Leak
26th March 2009, 16:21
Is it possible to use screen space shaders with Haali?
Shaders only work with MPC-HC's custom renderers because those renderers use Direct3D directly and have full control over how it's being used.
Using any other renderer, no matter if it uses Direct3D or not, will prevent MPC-HC's shaders, resizers etc. from being used since something else besides MPC-HC is then using the 3D hardware.
noee
26th March 2009, 16:52
Could the different shader types be used together, for example, could one use the YV12 Chroma Upsampling video shader with the 0-255->16-235 screen space shader? What does the Shader menu then reflect in the the shader list?
sarastro
26th March 2009, 17:28
I thought we were talking about stuttering in Windows 7 version? Is this some other problem that is Windows 7 only? Have you enabled 10 bit color?
I havent enabeld 10bit RGB color.
He's talking about the windows7 problem where since build 16 or 17 playing DXVA files result in a black screen instead of video playabck
Build 16 & 17 work fine, from build 18 on the problems occur.
Symptom: Black screen but as soon as you click on mpc it crashes, it doesnt even start playing and instantly crashes.
totozero
26th March 2009, 17:36
One is in video space, where each pixel in the shader generates one pixel with the same resolution as the video.
Screen space shaders operates in screen resolution, after the resize of the video to display resolution. This is useful as you want for example sharpen shaders to run in screen resolution, not video resolution.
K, gotcha.
Nice feature, I'll try it asap.
C'ya.
Egh
26th March 2009, 18:17
Shaders only work with MPC-HC's custom renderers because those renderers use Direct3D directly and have full control over how it's being used.
Using any other renderer, no matter if it uses Direct3D or not, will prevent MPC-HC's shaders, resizers etc. from being used since something else besides MPC-HC is then using the 3D hardware.
Pity. Would be nice to implement some additional shaders after Haali's colorconversion/resizing pipeline... Though of course there's no need there for colormatrix conversion etc as it is already implemented.
mark0077
27th March 2009, 00:05
Getting alot of freezing recently with build 20. One DVD I use to test completely freezes after the initial frame or two of copyright ads. This doesn't happen with normal EVR. I noticed the following output in the pin output.
Filter : ffdshow Video Decoder - CLSID : {04FE9017-F873-410E-871E-AB91661A4EF7}
- Connected to:
CLSID: {9B8C4620-2C1A-11D0-8493-00A02438AD48}
Filter: DVD Navigator
Pin: Video
- Connection media type:
Unknown
AM_MEDIA_TYPE:
majortype: MEDIATYPE_DVD_ENCRYPTED_PACK {ED0B916A-044D-11D1-AA78-00C04FC31D60}
subtype: MEDIASUBTYPE_MPEG2_VIDEO {E06D8026-DB46-11CF-B4D1-00805F6CBBEA}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 136
VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 0
VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x2a0d2581
dwReserved2: 0x00000000
MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 0
dwProfile: 0x00000002
dwLevel: 0x00000002
dwFlags: 0x00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 576
biPlanes: 1
biBitCount: 0
biCompression: 0
biSizeImage: 0
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 00 00 00 00 00 00 00 00 ................
0030: 00 00 00 00 00 00 00 00 10 00 00 00 09 00 00 00 ................
0040: 81 25 0d 2a 00 00 00 00 28 00 00 00 d0 02 00 00 %.*....(...Ð...
0050: 40 02 00 00 01 00 00 00 00 00 00 00 00 00 00 00 @...............
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 00 00 00 00 02 00 00 00 02 00 00 00 ................
0080: 00 00 00 00|00 00 00 00 ........
I disabled 10-Bit Color and the problem went away. Now I re-enabled it and its still gone... I can't understand that. Its like some hidden setting other than 10-bit color was effecting things. Seems kind of random but at least disabling and reenabling this seems to have fixed it temporarily.
LOGiC
27th March 2009, 07:21
@all,
I would like to ask you guys a general question. I am using the Beliyaal build of MPC-HC actually and I am very satisfied with it. I am trying to use pixelshaders to probably improve the picture, i.e. sharpen complex 2 or other stuff. For almost every shader I get the message "Couldn't load shader". I've already googled for hours and tried to find them.
Can anyone help ? Where can I find them, which dll's do I need and where do they need to be placed to work out with MPC-HC ? This comes for almost every shader and help is really appreciated.
Thanks in advance.
Andy.
Casshern
27th March 2009, 08:50
Could the different shader types be used together, for example, could one use the YV12 Chroma Upsampling video shader with the 0-255->16-235 screen space shader? What does the Shader menu then reflect in the the shader list?
Use the "combine shaders" option. But chaining to many shaders might be to much for your graphics card to handle in time for the next frame. I use YV12 chroma upsamling (absolutely necessary in VMR9 ) and "Complex sharpen 2 with 1.4 for the unsharpen part and 1.2 for the edge enhancement part". You can edit the shader source code to change parameters and the neat thing is it compiles them in the background and you can immediately see the changes on screen - even with paused images.
Leak
27th March 2009, 09:32
I would like to ask you guys a general question. I am using the Beliyaal build of MPC-HC actually and I am very satisfied with it. I am trying to use pixelshaders to probably improve the picture, i.e. sharpen complex 2 or other stuff. For almost every shader I get the message "Couldn't load shader". I've already googled for hours and tried to find them.
What graphics card do you have?
Also, have you installed the latest DirectX update (March 2009)?
LOGiC
27th March 2009, 10:42
Shaders only work with MPC-HC's custom renderers because those renderers use Direct3D directly and have full control over how it's being used.
I've got a NVIDIA 9500 GT. I just would like to chain 1-2 shaders at all.
Yes Sir, I've installed the latest March09 DirectX update.
What I would like to check, without being stupid, what exactly is meant by MPC-HC's custom renderers ? I am using EVR Custom and the internal filters for H264 and VC1. Is this wrong ?
To be honest, I am really thinking of trying the Popcornhour. We already had so many saturday evenings where we just wanted to watch a movie and the evening ended in configuring filters and renderers and out of sync playback :-(
@Casshern
I've already found the edit function. Do you think it won't work with the EVR custom or do I need to make any modifications at all ?
Jong
27th March 2009, 15:06
If there is no tearing the vsync position is by definition locked to scanlane 0. What Reclock must correct is the audio/video sync in relation to the VSync. I think the problem is how Reclock determines the audio/video sync position. I need to know how Reclock determines this.How about this?
As I understand it D3D exclusive mode uses true "flipping" between buffers (moving of pointers, not blitting) and is probably also triple buffered. Other modes use blitting from back to front buffer, which takes time and is why they are still susceptible to tearing.
Triple buffering would explain what we observe, I think! Reclock measures the time that the rendered frame gets flipped from the current "rendering buffer" to the "real" back buffer. This can happen as soon as the frame is rendered and Reclock can adjust this timing without affecting the flip of the "real" back buffer into the frame buffer. Synchronised judder can still occur when the flip from the "rendering buffer" to the "back buffer" is too close to the flip from "back buffer" to frame buffer. That is why we still need to use a vsync tool to keep the two apart.
Leak
27th March 2009, 15:13
I've already found the edit function. Do you think it won't work with the EVR custom or do I need to make any modifications at all ?
It's actually the opposite - it NEEDS EVR custom to function at all, as only that uses Direct3D directly and has total control over it.
As for the shader editor, if you edit anything (like adding a space at the end of the first line and deleting it again) or change the shader level (the combobox left of the "Delete" button) you should get an error or success message below the shader code, as that's where the output of Microsoft's shader compiler goes... perhaps that can give you a hint to what's up here?
np: Robert Babicz - Don't Look Back (Kompakt Total 9 (Disc 2))
LOGiC
27th March 2009, 15:31
@Leak
Thanks again for your help. I will test this evening. I am not at home right now, so I don't have access to the PC. What I noticed. When I tried yesterday, it gave me back some error with DX9D_XX.DLL. After that I downloaded and installed the DirectX9 End-User March09 but it didn't help. Would I need to get the DirectX10 End-User March09 or could it be something else ?
LOGiC
27th March 2009, 18:02
Leak and all,
the exact message which appears when trying to edit any shader is "cannot load D3DX9_xx.DLL, pixelshaders will not work".
Anyone has an idea for this ? I just updated the DirectX End User Environment yesterday. Is there anything else I need to activate/turn on besides EVR ?
Best regards and thanks in advance.
Andy.
cca
27th March 2009, 18:06
That's really strange, if you search in your system32 folder for that .DLL can you find it?
mark0077
27th March 2009, 18:34
Beliyaal, just trying to find the cause of extremely slow vc-1 playback when using ffdshow decoders. Tried the standard mplayerc.exe to see if it was your mpc build, doesn't seem to change from your build to normal build. I am noticing that using ffdshow decoders, reclock indicates it doesn't know the frame rate (in your and normal mpc-hc) so this might help figure out whats wrong (disabling reclock doesn't stop the problem). Anyways why I am posting is this one problem I notice with your build, it doesn't seem to register any frame drops that I know I am getting today with this problem, always seems to be 0.
I know for a fact I am losing about 50% of the frames when decoding with ffdshow (as I say trying to figure out why), but can't see this within your build of mpc-hc, they show up fine in the normal mpc build, approx 50% of the frames recorded as dropped.
Maybe this is something you know about?
LOGiC
27th March 2009, 18:42
@cca
I figured it out. It was the DirectX Developers Kit which I needed. Now all pixelshaders are working.
Leak
27th March 2009, 18:46
I figured it out. It was the DirectX Developers Kit which I needed. Now all pixelshaders are working.
I hope it wasn't the full DirectX SDK (which is several hundred MB) but just the DirectX redist, which is big enough...
But yeah, when I tried to use the web installer a few days ago when the March update came out it told me I was up to date, while the Redist of course installed a whole bunch of stuff - maybe MS buggered up their updater files?
np: Zucchini Drive - Over And Done (Goodyear Television Playhouse)
cca
27th March 2009, 18:50
I hope it wasn't the full DirectX SDK (which is several hundred MB) but just the DirectX redist, which is big enough...
But yeah, when I tried to use the web installer a few days ago when the March update came out it told me I was up to date, while the Redist of course installed a whole bunch of stuff - maybe MS buggered up their updater files?
np: Zucchini Drive - Over And Done (Goodyear Television Playhouse)
It happened to me too, but they have updated the web installer now.
Casshern
28th March 2009, 19:14
Hi,
there are still some problems with the frame rate detection of ver17-20 with VMR9 renderless and EVR CP. On some BD titles occasionally the detected frame rate fluctuates (casino royal near the end of the gondola scene). Then there is a small judder for this period. The same stream works with zoomplayer and/or other renderers (vmr7, overlay) without judder. It is unclear whether this is an anomalie with the stream which confuses the new frame rate detection routine or another sort of bug. I would advise a frame rate smoothing algo (optional of course). Take a window of the last 60 frame times. Use a median window of the middle 6 or 12 (to get all 2:3 pulldown stuff) values and average over them.
regards,
Casshern
Beliyaal
29th March 2009, 23:36
New version (Link in signature):
* Change: Made stats graph more clear by antialiasing and thicker lines.
* Change: The stats shortcut Ctrl+J now cycles between different amount of stats. Less stats take less time to draw and interferes less with playback.
* Fixed: VSync correction code accidentally disabled in version 20 enabled again.
* Fixed: VSync correction now works when refresh rate is less than movie fps (when dropping frames).
* Fixed: Removed clock smoothing and added better detection of clock speed.
* Fixed: Use detected clock speed to predict next VSync. This fixes stutter problems when using ReClock to resample audio.
* Fixed: Optimized CPU time taken by stats display.
* Fixed: DXVA deadlock when waiting for Present.
This version should get rid of all stuttering originating from renderer.
The deadlock on Windows 7 might also be fixed. I was able to reproduce this on Vista with DXVA as well.
Submitting to SVN this weekend was not possible as I still had stuttering bugs to fix. If no serious bugs is exposed during the week I will be aim at submitting it to SVN next weekend.
Fixing stuttering in VMR9 is not possible as far as I know (VMR controls when frames are rendered), and if it is I don't see the time investment as worth it. EVR is the future with support for Vista and Windows 7. I will however try to make ReClock VSync correction work corretly with VMR9. But this is after my changes has made it into SVN.
Beliyaal
29th March 2009, 23:42
Hi,
there are still some problems with the frame rate detection of ver17-20 with VMR9 renderless and EVR CP. On some BD titles occasionally the detected frame rate fluctuates (casino royal near the end of the gondola scene). Then there is a small judder for this period. The same stream works with zoomplayer and/or other renderers (vmr7, overlay) without judder. It is unclear whether this is an anomalie with the stream which confuses the new frame rate detection routine or another sort of bug. I would advise a frame rate smoothing algo (optional of course). Take a window of the last 60 frame times. Use a median window of the middle 6 or 12 (to get all 2:3 pulldown stuff) values and average over them.
regards,
Casshern
Frame rate detection already have a lot of smoothing. First there is a window of 60 frames and then a the last 500 detected frame rates are checked for the most common frame time.
It shouldn't create stuttering though, it's only used for frame time correction. You might want to turn it off to check if the stuttering disappears.
Or are you talking about refresh rate detection?
Beliyaal
29th March 2009, 23:44
Beliyaal, the refresh rate detection is broken in the 64-bit version, and thus vsync too. It displays values varying very quickly, and I think I see an #IND in there.
I can't reproduce this. Are you sure it's a problem with the 64 bit version only?
fastplayer
29th March 2009, 23:45
MPC-HC is turning into a Swiss Army knife :cool:
Anyway, are those known bugs listed in the first post exclusive to your builds, Beliyaal?
MatMaul
29th March 2009, 23:47
http://forum.doom9.org/showpost.php?p=1238622&postcount=5949
I just change my configuration to an integrated GeForce 7100.
with latest stable drivers (182.08), same weird line.
EDIT : I am using VMR9 renderless with mixer mode, XP SP3
I just add a geforce 9600GT to my system, same weird line :)
weird that nobody else reports it, I reproduced the bug with one ATI card and 2 NVIDIA ones.
an other screenshot :
http://img12.imageshack.us/img12/9936/40284546.th.png (http://img12.imageshack.us/my.php?image=40284546.png)
Beliyaal
29th March 2009, 23:47
MPC-HC is turning into a Swiss Army knife :cool:
Anyway, are those known bugs listed in the first post exclusive to your builds, Beliyaal?
Not all of them are exclusive to my builds, but I have accepted them as my responsibility.
fastplayer
29th March 2009, 23:54
Thanks for clarifiying!
I've reported a bug in the MPC-HC thread that happens with your builds too. Unfortunately, I received zero response. Can you perhaps comment on that?
http://forum.doom9.org/showpost.php?p=1266570&postcount=7024
nuhi
30th March 2009, 00:09
Hey Beliyaal, are you sure that Output Range 0-255 is the darker and 16-235 is the lighter looking output?
I would bet it's the other way around like with other renderers, for example Haali. They call 16-235 as TV out and it looks darker because it cuts out 235-255 in comparison with 0-255 aka PC output.
Point is that maybe those options in your (great!) player version should be switched in the renderer menu options. Please correct me if I'm wrong, and I'm happy that the option is even there.
Before I could only get that with Haali but that one doesn't have all the goodness of EVR and DXVA.
Anyway tomorrow I'll try to reproduce and make a valid report for the crash I'm having when resuming position from the favorites, bluray, dxva, win7.
Thanks.
STaRGaZeR
30th March 2009, 00:42
I can't reproduce this. Are you sure it's a problem with the 64 bit version only?
Yes, it was surely a problem with the 64-bit version only, version 20, retested several times to be sure. Detected frame rate was totally incorrect. Now I've retested 20 and 21 again and it's gone :confused: Nevermind.
Also, it's possible to reduce the amount of AA applied to the graph itself or remove it? It really hurts my eyes, so blurry. For the letters is perfect.
flanger216
30th March 2009, 00:43
Hey Beliyaal, are you sure that Output Range 0-255 is the darker and 16-235 is the lighter looking output?
I would bet it's the other way around like with other renderers, for example Haali. They call 16-235 as TV out and it looks darker because it cuts out 235-255 in comparison with 0-255 aka PC output.
Thanks.
It depends on what luma range your display is in. If you send 16-235 video to a 0-255 display, it will look washed out ('too bright'). If you send 0-255 video to a 16-235 display, it will look crushed ('too contrasty'). But yeah, it is more accurate simply to differentiate the two as 'TV out' and 'monitor out.'
carnage_pl
30th March 2009, 00:49
Hey! Do You plan do merge Your build with trunk as You said last weekend?
flanger216
30th March 2009, 00:52
Hey! Do You plan do merge Your build with trunk as You said last weekend?
Ten posts up:
"Submitting to SVN this weekend was not possible as I still had stuttering bugs to fix. If no serious bugs is exposed during the week I will be aim at submitting it to SVN next weekend."
carnage_pl
30th March 2009, 01:02
Oh yes. I didn't notice.
Egh
30th March 2009, 01:34
Fixing stuttering in VMR9 is not possible as far as I know (VMR controls when frames are rendered), and if it is I don't see the time investment as worth it. EVR is the future with support for Vista and Windows 7. I will however try to make ReClock VSync correction work corretly with VMR9. But this is after my changes has made it into SVN.
Maybe unfortunate but there're loads of people who stick with XP/XP64 and are more than happy ;)
MPC certainly started as DX software so better stick to oldschool ways ;)
More on the topic: using version21:
XP64 Nvidia latest drivers, EVR per se works, however videos do not even start in EVR custom presenter. Audio works but video is blank or junk video is displayed.
I already posted once that I suspect MPCHC doesn't properly arrange colourspaces in the decoding chain with EVRCP on XP system....
UPD: just retested and plain SVN version does behave this way, blank screen|junk+stats. This version however may just fallback to Video Renderer instead of EVRCP. But not everytime ;)
Example what happens: http://bayimg.com/kAoFFaABK
sarastro
30th March 2009, 01:39
New version (Link in signature):
The deadlock on Windows 7 might also be fixed. I was able to reproduce this on Vista with DXVA as well.
On Windows 7 no more crashes :).
I tried all the DXVA compatible files that made it crash before and no crashes (deadlocks) whatsoever.
Thank you for the fix!
nuhi
30th March 2009, 02:05
It depends on what luma range your display is in. If you send 16-235 video to a 0-255 display, it will look washed out ('too bright'). If you send 0-255 video to a 16-235 display, it will look crushed ('too contrasty'). But yeah, it is more accurate simply to differentiate the two as 'TV out' and 'monitor out.'
Correct but the thing is on my PC monitor which was always looking washed out with 0-255 setting, with this player it is the other way around, the 16-235 setting in the built-in renderer looks washed out while 0-255 setting looks proper and it shouldn't...it should be washed out because all the videos that I've seen were made for TV 16-235. So either those options are in reverse or it makes sense in combination with some other feature that this player is doing differently.
Casshern
30th March 2009, 02:21
Frame rate detection already have a lot of smoothing. First there is a window of 60 frames and then a the last 500 detected frame rates are checked for the most common frame time.
It shouldn't create stuttering though, it's only used for frame time correction. You might want to turn it off to check if the stuttering disappears.
Or are you talking about refresh rate detection?
I am talking about frame rate detection. If you use the most common of the last 60 this is theoretically slightly inferior to using the median in a window of the last 60 frames (sort the last 60 frame times and fetch the middle element - or avg the middle two). As in a 2:3 pulldown taking the simple median is not enough (and also not the most frequent frame rate) i would use avg. over the middle 12 frames in the 60 frame window (median sorted). Because sometimes frametimes fluctuate constantly f.e. 42ms, 41ms, 42ms, 41,ms.... with the median technique and a avg window inside the median window you smooth this to 41.5... and also account for more complex 2:3 patterns.
Frame time correction (button c) did not make a difference.
Jong
30th March 2009, 10:12
Thanks for the new build, but it still has problems with all my HD-DVD VC-1 rips to mkv (fine in current svn and your builds prior to 16).Were you unable to see the problem with the VC-1 clip I sent you?
Beliyaal
30th March 2009, 10:19
Thanks for the new build, but it still has problems with all my HD-DVD VC-1 rips to mkv (fine in current svn and your builds prior to 16).Were you unable to see the problem with the VC-1 clip I sent you?
Yes, your sample plays nicely for me. If I use the microsoft decoder it will display at 23.976 FPS, but if I use the internal VC-1 decoder (DXVA) it will double the framerate, possibly because of an interlaced flag being set and the hardware doing the deinterlacing. In EVR custom, what values do you see on the top row? Maybe you could send me a screenshot of the statistics when you are playing the sample.
Mark_A_W
30th March 2009, 10:30
Jong, can you list a number of common VC-1 titles which give you trouble? (PM me?).
I might be able to test the same movie and see what happens on my system.
Beliyaal
30th March 2009, 10:33
I am talking about frame rate detection. If you use the most common of the last 60 this is theoretically slightly inferior to using the median in a window of the last 60 frames (sort the last 60 frame times and fetch the middle element - or avg the middle two). As in a 2:3 pulldown taking the simple median is not enough (and also not the most frequent frame rate) i would use avg. over the middle 12 frames in the 60 frame window (median sorted). Because sometimes frametimes fluctuate constantly f.e. 42ms, 41ms, 42ms, 41,ms.... with the median technique and a avg window inside the median window you smooth this to 41.5... and also account for more complex 2:3 patterns.
Frame time correction (button c) did not make a difference.
In theory it would be good. I however have to deal with this pattern of frame times:
0
1001000
0
-333667
0
1001000
0
-333666
A median of these, even of 12, would be 0. Also I don't just average them, but match the average to a list of know frame rates: 60.0, 59.94, 50.0, 48.0, 47.952, 30.0, 29.97, 25.0, 24.0, 23.976
Beliyaal
30th March 2009, 10:55
New version (Link in signature):
* Fixed: Frame rate detection history only used 200 history entries instead of all 500
* Fixed: Media renegotiation could occur on the wrong thread. This could cause invalid samples to enter the chain.
* Fixed: All frames are now displayed before rewinding the media.
Beliyaal
30th March 2009, 10:57
Maybe unfortunate but there're loads of people who stick with XP/XP64 and are more than happy ;)
MPC certainly started as DX software so better stick to oldschool ways ;)
More on the topic: using version21:
XP64 Nvidia latest drivers, EVR per se works, however videos do not even start in EVR custom presenter. Audio works but video is blank or junk video is displayed.
I already posted once that I suspect MPCHC doesn't properly arrange colourspaces in the decoding chain with EVRCP on XP system....
UPD: just retested and plain SVN version does behave this way, blank screen|junk+stats. This version however may just fallback to Video Renderer instead of EVRCP. But not everytime ;)
Example what happens: http://bayimg.com/kAoFFaABK
Have you tried without DXVA? The latest version (22) could fix this issue.
Beliyaal
30th March 2009, 10:59
Correct but the thing is on my PC monitor which was always looking washed out with 0-255 setting, with this player it is the other way around, the 16-235 setting in the built-in renderer looks washed out while 0-255 setting looks proper and it shouldn't...it should be washed out because all the videos that I've seen were made for TV 16-235. So either those options are in reverse or it makes sense in combination with some other feature that this player is doing differently.
The setting is correct. Your monitor expects 0-255 range, and thus you should select this range.
You might be thinking of input range as opposed to output range. You could possibly correct for an incorrect output range by selecting another input range, but it would still not be entirely correct.
Mark_A_W
30th March 2009, 11:05
Thanks for the new versions Beliyaal...I just installed one, and the next one appeared...I can't keep up :)
Can someone remind me how to get Statistics to display? There's a trick, but I forget. I have the tearing test running, but stat's don't appear.
Casshern
30th March 2009, 11:08
In theory it would be good. I however have to deal with this pattern of frame times:
0
1001000
0
-333667
0
1001000
0
-333666
A median of these, even of 12, would be 0. Also I don't just average them, but match the average to a list of know frame rates: 60.0, 59.94, 50.0, 48.0, 47.952, 30.0, 29.97, 25.0, 24.0, 23.976
Interesting- but isn't this after they are adjusted for screen refresh? Couldn't it be smoothed directly from the timestamps of the source frame rate (time stamps of the individual decoded frames)? Is this a normal pattern ?
Jong
30th March 2009, 11:10
Jong, can you list a number of common VC-1 titles which give you trouble? (PM me?).
I might be able to test the same movie and see what happens on my system.Thanks.
Elizabeth - the Golden Age
Bourne Ultimatum
Blade Runner Final Cut
All HD-DVDs I own ripped to mkv using eac3to.
I have a (new) 30MB sample I can send via MSN or upload to an ftp server, if you or anyone else could take a look.
The problem does not seem to show up on the stats screen:
http://jong.pwp.blueyonder.co.uk/images/beliyaal_vc1prob_01.jpg
but, believe me, anyone could see waht I am seeing here. It is not something that I could be imagining!
.....And it is still in build22.
Beliyaal
30th March 2009, 11:16
Thanks.
Elizabeth - the Golden Age
Bourne Ultimatum
Blade Runner Final Cut
All HD-DVDs I own ripped to mkv using eac3to.
I have a (new) 30MB sample I can send via MSN or upload to an ftp server, if you or anyone else could take a look.
The problem does not seem to show up on the stats screen:
but, believe me, anyone could see waht I am seeing here. It is not something that I could be imagining!
.....And it is still in build22.
I think I know what could be causing it now. Could you post a screenshot of the same thing in EVR custom, with all vsync options default? (accurate on, vsync on)
Mark_A_W
30th March 2009, 11:20
Ok, I got Bladerunner on my system, converted to MKV with Flac audio.
Seems to play fine with EVR custom, ffdshow video decoder(actually using wmv9 internally) outputting RGB32. Audio is madflac connected to ffdshow audio (upconvert to 32bit), connected to Convolver wrapper (digital room correction (only 16bit or 32bit input works), with Reclock as the renderer.
My display is running 1920x1080 at 95.904hz interlaced (CRT monitor or projector).
I'm looking more carefully...
Jong
30th March 2009, 11:35
This is really odd!
If I disable the internal VC-1 decoder (both DXVA and ffmpeg) and play the video again it still loads the same filters as far as I can see, MPC Video decoder in DXVA mode, but this time it correctly determines the frame rate and all is fine :confused::confused:
http://jong.pwp.blueyonder.co.uk/images/beliyaal_vc1prob_02.jpg
Jong
30th March 2009, 11:43
Here are two images, now with vsync options at defaults as requested:
VC-1 Decoder "disabled", but still being used :confused:. All is fine:
http://jong.pwp.blueyonder.co.uk/images/beliyaal_vc1prob_deocderdisabled.jpg
VC-1 Decoder enabled. Horrible judder.
http://jong.pwp.blueyonder.co.uk/images/beliyaal_vc1prob_deocderenabled.jpg
There are no other changes between the two shots other than enabling/disabling the internal decoder.
cca
30th March 2009, 11:50
playing as interlaced still shouldn't cause such a problem, are you using Reclock's PAL speedown by the way?
Jong
30th March 2009, 11:54
Yeah I know!
And it doesn't with the normal build or Beliyaal builds up to 15.
No, not using speeddown. I am speeding up to 25Hz, but don't believe that is affecting things.
cca
30th March 2009, 11:57
Yeah I know!
And it doesn't with the normal build or Beliyaal builds up to 15.
No, not using speeddown. I am speeding up to 25Hz, but don't believe that is affecting things.
It shouldn't, but you can never know where a bug is lurking. It's best for Beliyaal to know all the parameters.
Jong
30th March 2009, 11:59
It shouldn't, but you can never know where a bug is lurking. It's best for Beliyaal to know all the parameters.Yeah. Quite right.
Jong
30th March 2009, 12:01
Ok, I got Bladerunner on my system, converted to MKV with Flac audio.
Seems to play fine with EVR custom, ffdshow video decoder(actually using wmv9 internally) outputting RGB32. Audio is madflac connected to ffdshow audio (upconvert to 32bit), connected to Convolver wrapper (digital room correction (only 16bit or 32bit input works), with Reclock as the renderer.
My display is running 1920x1080 at 95.904hz interlaced (CRT monitor or projector).
I'm looking more carefully...I too have FLAC audio, but did you strip out the pulldown flags when making your mkv. I think that is the most likely source of the problem.
Mark_A_W
30th March 2009, 12:43
I too have FLAC audio, but did you strip out the pulldown flags when making your mkv. I think that is the most likely source of the problem.
I just let eac3to do it's thing, and mux with mkvmerge Bladerunner was a very old conversion - my first one I think. From memory back then we had to do something in mkvmerge related to timings - paste in a text line to convert to 23.976 or somesuch.
I tried a number of VC-1 titles, new and old conversions (different versions of eac3to). No problems found.
Jong
30th March 2009, 12:53
Been chatting to Beliyaal in MSN and I think we have nailed the problem down.
It is not in Beliyaal's code at all. It appears in SVN1009. All is fine with SVN1008.
From SVN1009 these videos in DXVA mode (so ATI cards only) cause interlaced mode to be engaged and the decoder makes a right old hash of it.
There are maybe two bugs. The decoder probably should be able to handle this "soft pulldown" in interlaced mode, but really it should never be engaging interlaced mode at all. Or maybe it is one bug - the decoder should handle it by not engaging interlaced mode.
Does this need cross posting on the main MPC-HC thread?
Casshern
30th March 2009, 13:05
Been chatting to Beliyaal in MSN and I think we have nailed the problem down.
It is not in Beliyaal's code at all. It appears in SVN1009. All is fine with SVN1008.
From SVN1009 these videos in DXVA mode (so ATI cards only) cause interlaced mode to be engaged and the decoder makes a right old hash of it.
There are maybe two bugs. The decoder probably should be able to handle this "soft pulldown" in interlaced mode, but really it should never be engaging interlaced mode at all. Or maybe it is one bug - the decoder should handle it by not engaging interlaced mode.
Does this need cross posting on the main MPC-HC thread?
I think crossposting would be nice, so casimir can look at the dxva decoder and maybe give us an option to filter the flag...
Jong
30th March 2009, 13:14
done!
mark0077
30th March 2009, 13:32
I have a question that concerns my setup. Because of problems with my TV at 24hz I have been happily using 60hz for the past few months. When I view 24fps material at 60hz there is obviously going to be a bit of judder, but do these builds make an attempt to spread the 24 frames into the 60hz in a way that minimizes that judder, or does it just try and sync whatever frames it sees coming in, with the screen refresh rate.
I am assuming that using vista's aero to keep frames synced would be the latter, it just waits for screen refreshes to draw whatever it has. I am hoping mpc-hc is doing the first one, smartly trying to spread the input frame number into the frame refresh rate in the mathematically best way to reduce judder.
Beliyaal
30th March 2009, 15:28
I have a question that concerns my setup. Because of problems with my TV at 24hz I have been happily using 60hz for the past few months. When I view 24fps material at 60hz there is obviously going to be a bit of judder, but do these builds make an attempt to spread the 24 frames into the 60hz in a way that minimizes that judder, or does it just try and sync whatever frames it sees coming in, with the screen refresh rate.
I am assuming that using vista's aero to keep frames synced would be the latter, it just waits for screen refreshes to draw whatever it has. I am hoping mpc-hc is doing the first one, smartly trying to spread the input frame number into the frame refresh rate in the mathematically best way to reduce judder.
The EVR Customer render will spread the frames as close to the syncs as possible (mathematically best way). Every frame has a timestamp on it. This is the timestamp that is used to determine when the frame should be displayed. It doesn't just "display frames as they come in".
If you play a 24 FPS movie at 60 Hz you will see that the audio/video sync jitter graph repeats every 5 frames. If you play 23.976 content you will also see a the slight extra stutter every once in a while when it needs to display one frame one extra vsync outside of the 5 frame pattern.
The sync in the VMR9 renderer is handled by Microsoft code, and is worse at minimizing unneeded stuttering.
cca
30th March 2009, 16:02
Initial testing of version 22 is OK for .mkv files at 29.97fps. I do have a problem though, and it happens with DVDs.
We have the following scenario; The DVD is interlaced, and we are the main menu. No animation happens here, it's a static menu. Select an episode (it's a series :) ) and start playback. What happens is that instead of normal Playback, it stutters at around 22 fps, while it should play at 48 since the video is interlaced.
Crucial fact: it only happens when I use ReClock in PAL Speedown mode. If I playback the same DVD without that feature, all work normally. Still it shouldn't happen, it works properly with the SVN version. This is not a new bug, it was happening since early versions of the Beliyaal build, but I though I should wait for more important bugs to be fixed.
mark0077
30th March 2009, 16:45
The EVR Customer render will spread the frames as close to the syncs as possible (mathematically best way). Every frame has a timestamp on it. This is the timestamp that is used to determine when the frame should be displayed. It doesn't just "display frames as they come in".
If you play a 24 FPS movie at 60 Hz you will see that the audio/video sync jitter graph repeats every 5 frames. If you play 23.976 content you will also see a the slight extra stutter every once in a while when it needs to display one frame one extra vsync outside of the 5 frame pattern.
The sync in the VMR9 renderer is handled by Microsoft code, and is worse at minimizing unneeded stuttering.
Excellent, keep up the good work. :D Just need PAL Speed Down now to really make reclock unnecessary.... ;) for me atleast.
Jong
30th March 2009, 16:54
VMR9 renderer is handled by Microsoft code, and is worse at minimizing unneeded stuttering.Could you elaborate. Is it that it drops more frames than needed when e.g. Frame rate and refresh rate are not multiples or do you think VMR9 stutters without cause due to poor presentation?
cca
30th March 2009, 16:59
Could you elaborate. Is it that it drops more frames than needed when e.g. Frame rate and refresh rate are not multiples or do you think VMR9 stutters without cause due to poor presentation?
To put it simply, VMR9 sucks! EVR is much more customizable, but I understand why you need VMR9, there is no DXVA in EVR when used in Windows XP.
Jong
30th March 2009, 17:43
To put it simply, VMR9 sucks! EVR is much more customizable, but I understand why you need VMR9, there is no DXVA in EVR when used in Windows XP.Well there is for VC-1 and MPEG2, just not h.264. I still do not know if this is just a driver issue (and may go away) or if there really is something different about h.264.
Anyway, it would be good to know the specifics of how VMR9 "sucks"!:) I do see what almost looks like "ringing" when frames are dropped i.e. not one nice clean drop but a little burst. On the other hand, with Reclock correcting the clocks, frame rate and vsync I do not see VMR9 otherwise needlessly dropping frames, but maybe I am missing something.
Shakey_Jake33
30th March 2009, 17:50
To put it simply, VMR9 sucks! EVR is much more customizable, but I understand why you need VMR9, there is no DXVA in EVR when used in Windows XP.
Huh? Works lovely here.
Leak
30th March 2009, 18:01
Huh? Works lovely here.
What card?
It definitely doesn't work with my ATI Radeon 4850 - it falls back to VMR7 instead...
np: Carl Craig & Moritz von Oswald - Movement 5 (Recomposed)
cca
30th March 2009, 18:01
Each entitled to their own opinions, I never managed to play videos smoothly enough with VMR9. When I was still using Windows XP, I preferred the Haali renderer, although it also has some stuttering problems. If it works for you, keep at it.
Jong
30th March 2009, 18:17
Each entitled to their own opinions, I never managed to play videos smoothly enough with VMR9. When I was still using Windows XP, I preferred the Haali renderer, although it also has some stuttering problems. If it works for you, keep at it.Don't get me wrong, I'd prefer to move to EVR. Maybe a driver update will allow this, or I might just move to Win7 later in the year. But right now VMR9 is what I'm stuck with.
Egh
30th March 2009, 18:19
Have you tried without DXVA? The latest version (22) could fix this issue.
I've tried ver22. Still same. Video is garbled, stats and softsubs are displayed as usual.
I don't have DXVA (for AVC) capability with my NVidia card anyway.
All work regarding video is done by MPC specifically to exclude problems with other filters. I.e. files are split by internal splitter and video is decoded by internal MPC decoder (not using DXVA).
So to describe again:
AVC/MPEG2 video in mkv/m2ts container doesn't show the actual video in EVR Custom Presenter.
That is unless it is 1920x1080 video :OOO Because these files are WORKING! So all settings are same but just playing 1080p video seems to work! And again that applies both to mpeg2 and avc videos.
As for the changes from previous versions, seems the current one at least doesn't fall back to Video Renderer now... At least some progress :rolleyes:
ADD: Interesting enough in EVR (not presenter) mpchc doesn't even work here. Any video I've tried only presents a blank screen -- no subs no stats even. Funny enough the timing goes on (i.e. mpchc thinks it really plays something :D) but nothing really happens.
mark0077
30th March 2009, 18:41
Don't get me wrong, I'd prefer to move to EVR. Maybe a driver update will allow this, or I might just move to Win7 later in the year. But right now VMR9 is what I'm stuck with.
Is your cpu not fast enough to do all software decoding? I always use software decoding + evr-cp, working perfectly especially with these last few builds.
Jong
30th March 2009, 18:48
No it is not (quite!) it is a core2 duo running at 2.7Ghz and it can cope with most things, but high bitrate Blu-ray chokes it.
Anyway, I now prefer DXVA. I happen to think the latest GPUs offer the best, most dependable PQ for HD (I was very happy with my ffdshow-based SD setup) and it is the most efficient from a power/heat/noise perspective.
loretta80
30th March 2009, 19:52
hello,
is it advisable to install the newest directx redist for mpc-hc? on xvidvideo.ru there is still an advice for the november version.
ooferomen
30th March 2009, 20:33
is it expected behavior for the green line to start out high above the pink one and then very slowly work its way down to the pink one then shoot back up once it hits the pink one?
Jong
30th March 2009, 20:36
Have you got Reclock vsync correction on (and what output settings are you using)? Or is your frame rate different to your refresh rate?
nuhi
30th March 2009, 20:42
The setting is correct. Your monitor expects 0-255 range, and thus you should select this range.
You might be thinking of input range as opposed to output range. You could possibly correct for an incorrect output range by selecting another input range, but it would still not be entirely correct.
Ok, that makes sense. Thanks.
Cannot make v22 crash when resuming from the bookmark, so far too good :)
tetsuo55
30th March 2009, 21:19
hello,
is it advisable to install the newest directx redist for mpc-hc? on xvidvideo.ru there is still an advice for the november version.
Updating is always a good idea, the newer version contains all the dll's included in the older version.
BatKnight
30th March 2009, 21:39
Anyway, I now prefer DXVA. I happen to think the latest GPUs offer the best, most dependable PQ for HD (I was very happy with my ffdshow-based SD setup) and it is the most efficient from a power/heat/noise perspective.
Could you please provide screenshots or elaborate how DXVA is better Picture quality-wise over ffdshow software decoding when playing HD content?
I am not attacking your statment, I am only trying to understand how DXVA is better than software decoding when it comes to picture quality.
Thanks
Bat
cca
30th March 2009, 21:41
Could you please provide screenshots or elaborate how DXVA is better Picture quality-wise over ffdshow software decoding when playing HD content?
I am not attacking your statment, I am only trying to understand how DXVA is better than software decoding when it comes to picture quality.
Thanks
Bat
I for one cannot see any difference. DXVA has other benefits though, like low CPU usage and lower power consumption.
fastplayer
30th March 2009, 22:28
I can't play this trailer (http://playlist.yahoo.com/makeplaylist.dll?sid=81115433&sdm=web&pt=rd) [118MB] in DXVA mode with the latest version 22. There's no video output, just audio. It plays fine with SVN 1024.
Setup:
Server 2008
Radeon HD4670
Catalyst 9.3
Edit: Plays fine with version 21.
Jong
30th March 2009, 22:36
Could you please provide screenshots or elaborate how DXVA is better Picture quality-wise over It's more the noise/power thing and the dependability across players. I don't doubt at all that it is posible to get near equivalent quality in software but, unlike for SD, I don't think it is possible to do it better, and the GPU can do it silently. Plus, if I have to use a commercial player like PDVD or TMT (I currently use PDVD) for full discs (which pretty much must use DXVA) and MPC-HC for rips and other HD it is good to know you only have to set up once and get the same quality/levels etc. from both.
I'm certainly not saying software is a bad way to go, if the power/noise is not so important and if you don't mind the extra effort to get everything just right and keep it that way as players, drivers and decoders change.
rack04
30th March 2009, 22:47
I can't play this trailer (http://playlist.yahoo.com/makeplaylist.dll?sid=81115433&sdm=web&pt=rd) [118MB] in DXVA mode with the latest version 22. There's no video output, just audio. It plays fine with SVN 1024.
Setup:
Server 2008
Radeon HD4670
Catalyst 9.3
Edit: Plays fine with version 21.
No problems here.
Setup:
Windows XP SP3
Nvidia Quadro NVS 135M
179.24
VMR9 (renderless)
MPC-HC svn 1024
Egh
30th March 2009, 23:50
Right. Since people pointed me to the right tool to cut parts out of m2ts, here's the first mysterious bug ;)
It seems to be more problematic to specifically respected Beliyaal's version.
Here's 50mb cut from the end of the original m2ts file
http://www.mediafire.com/?nynridykydo
Thing is i first started cutting from the beginning of the file, but however failed to achieve bug replication. After alot of headbashing I suddenly realized that the problem might be with the entire file. So cutting from the end was the right idea. :cool:
If this small sample is played by a chain of MPC Splitter, MPC Video decoder, MPC AAC decoder then the sound/video will b0rk a bit upon start. It is not much of the problem just yet, but that is because it is such a short file :D If I cut last 500mb from m2ts then it would lag for about 20 seconds before the video actually starts. If I don't cut it at all (the total size is about 2.9gb, 30 min of video) then it takes ages for the video to start, shows only the first frame meanwhile.
If I disable MPC splitter and use Haali instead, everything works as required.
Now the thing which is not bug per se, however which is relevant to the matter or at the very least is a separate bug of its own, it is also shared between Beliyaal's and SVN versions. MPC Splitter here detects two audio tracks. Whilst both Haali and DGIndex detect only one.
kumi
31st March 2009, 00:13
one stutter(skipped frame) in 1min10sec. Do you have it?
(with evr custom + this settings)
is it expected behavior for the green line to start out high above the pink one and then very slowly work its way down to the pink one then shoot back up once it hits the pink one?
I have the same problem as the above two members. Using:
Beliyaal 22, EVR Custom, Alt Vsync On, Vsync On, Accurate Vsync On
WinXP SP3
DirectX March 2009 Redist
9800GT, Nvidia Forceware 181.22
60Hz LCD
During playback, the green line approaches the red line at a slow rate. When the two lines intersect:
1) The green line shoots back up (to about 2 increments on the y axis)
2) The red line has a short negative spike
3) Sync Offset Min jumps from -1.5ms to -17ms
4) Sync Offset changes from mode=0 to mode=1 for a few seconds
5) Jitter Max jumps from +0.2ms to +16ms
6) The video judders 1 or 2 frames
The cycle between green line jumps is about 60s with 30fps video, and 30s with 24fps video. Also, pausing/unpausing or seeking will reset the green line at a random distance from the red line. Anywhere in between the 0 and 2 markers on the y axis.
Besides this one frame judder every 30s or 60s, the video playback is silky-smooth. Kudos, Beliyaal!
By the way, when I take a screenshot (in EVR CP mode) using Alt-I, only the video is output. How can I take a screenshot of the video including display stats in EVR CP mode?
DeepBeepMeep
31st March 2009, 01:20
I am getting an almost judder free playback with EVR if I do not use mplayer internal subtitle engine.
However, the audio/video get out of sync randomly when I seek. It is funny I get that only at 23.976Hz and not at 72Hz.
Hopefully you can fix that. Thanks
flanger216
31st March 2009, 05:12
Could you please provide screenshots or elaborate how DXVA is better Picture quality-wise over ffdshow software decoding when playing HD content?
I am not attacking your statment, I am only trying to understand how DXVA is better than software decoding when it comes to picture quality.
Thanks
Bat
DXVA is generally known to have worse color reproduction/accuracy than software decoding, so long as you use ffdshow and enable HQ RGB32 conversion and rendering.
Casshern
31st March 2009, 09:13
DXVA is generally known to have worse color reproduction/accuracy than software decoding, so long as you use ffdshow and enable HQ RGB32 conversion and rendering.
It is not generally known. Not to me anyway - could you please provide evidence? The opposite is probably true as video cards have internal 10bit pathways, so a YUV to RGB conversion in hardware has - theoretically - an advantage. The ffdshow HQ RGB32 conversion, while very good, does output only 8 bit RGB values at the moment. The only problems with the ati hardware conversion is that is choses the color matrix on vertical height - which might not be optimal in all cases. But this is true for all other methods (e.g. if you use horizontal size, some 4:3 material might slip through, or if you prescale) too.
My take is that neither software decoding or hardware decoding of vc-1/H264 has an inherent advantage. If the decoder is up to spec, the output is identical and most perceived differences come from auxiliary factors: How does the filter chain expand levels, what color matrix was chosen, what postprocessing do you do, how is the image scaled and last but not least how did you calibrate you display. Judging from many posts especially the latter together with the level expansion issue accounts for a lot of statements preferring one decoder over another.
Of course there are other factors like cpu usage, material not complying with level 4.1 etc....
Jong
31st March 2009, 09:48
I have the same problem as the above two members. Using:
Beliyaal 22, EVR Custom, Alt Vsync On, Vsync On, Accurate Vsync On
WinXP SP3
DirectX March 2009 Redist
9800GT, Nvidia Forceware 181.22
60Hz LCD
During playback, the green line approaches the red line at a slow rate. When the two lines intersect:
1) The green line shoots back up (to about 2 increments on the y axis)
2) The red line has a short negative spike
3) Sync Offset Min jumps from -1.5ms to -17ms
4) Sync Offset changes from mode=0 to mode=1 for a few seconds
5) Jitter Max jumps from +0.2ms to +16ms
6) The video judders 1 or 2 frames
The cycle between green line jumps is about 60s with 30fps video, and 30s with 24fps video. Also, pausing/unpausing or seeking will reset the green line at a random distance from the red line. Anywhere in between the 0 and 2 markers on the y axis.
Besides this one frame judder every 30s or 60s, the video playback is silky-smooth. Kudos, Beliyaal!
By the way, when I take a screenshot (in EVR CP mode) using Alt-I, only the video is output. How can I take a screenshot of the video including display stats in EVR CP mode?
To repeat my post yesterday...
Have you got Reclock vsync correction on...... ? Or is your frame rate different to your refresh rate?Either of these will cause what you see.
Note: even if your screen is 60Hz, rather than, NTSC friendly, 59.940Hz this wil cause a frame repeat roughly every 42 seconds (for 24p material) and 33 seconds (for 30p material). Reclock can fix this (but with Reclock's vsync correction OFF).
Edit: actually not sure about the period for 24p material. It is possible that somewhere in the telecine process this gets changed.
tetsuo55
31st March 2009, 09:53
Just updated to version 22, i get wildly varying results.
Sometimes playback will be fine but then (usually around scene changes) audio will go wayyyyy out of sync and/or the video will stutter badly, when this happens only 1 EVR buffer gets used, no matter how many i select
my specs:
*Windows 7 7057
*DX redist march
*Catalyst 8.3 (i don't have CCC, i cannot disable forced vsync if this is enabled by default)
*ATI HD2400pro AGP with reg patches
*a7n8x-deluxe mobo (nforce 2)
*AMD Athlon XP2600+ @ 2ghz
*X-Fi platinum
*Aero completely disabled
*MPC-HC V22
*EVR CP, bilinear, alternative vsync(enabled/disabled does not matter), buffers 20(stutters occur with any number)
*Renderer settings: enable frame time correction(on or off no difference), vsync, accurate vsync, d3d fullscreen (on or off no difference)
Animated subs disabled, buffers 10
filters:
-Default directsound device
-EVR-CP
-audio switcher
-mpc-video decoder
-ffdshow audio decoder (MPC dts decoder has even worse results)
-haali splitter
Sample:
Mkv
Video: MPEG4 Video (H264) 1920x816 23.98fps [Video]
Audio: DTS 48000Hz 6ch [Audio]
Text [Subtitle]
My display is 1920x1080@59hz
Screenshot:
http://img23.imageshack.us/img23/1151/badstuttering.th.png (http://img23.imageshack.us/my.php?image=badstuttering.png)
BatKnight
31st March 2009, 10:59
DXVA is generally known to have worse color reproduction/accuracy than software decoding, so long as you use ffdshow and enable HQ RGB32 conversion and rendering.
One thing I noticed is that when using software decoding I have to check 0-255 output in Beliyaal's MPC-HC, otherwise videos are too bright.
But when using DXVA, I have to check 16-235 because videos are too dark with 0-255. Nevertheless not all HD videos have to be on 16-235. I have come across with some 1080p videos that need 0-255 even on DXVA. I have to keep changing according to the video. When on software decoding, 0-255 is good for ALL the videos.
I use an ATI Radeon over HDMI and have chosen Full Range in the Catalyst Control Center.
Could anyone please explain me why DXVA need these changes?
Thanks in advance.
Bat
Jong
31st March 2009, 11:05
One thing I noticed is that when using software decoding I have to check 0-255 output in Beliyaal's MPC-HC, otherwise videos are too bright.
But when using DXVA, I have to check 16-235 because videos are too dark with 0-255. Nevertheless not all HD videos have to be on 16-235. I have come across with some 1080p videos that need 0-255 even on DXVA. I have to keep changing according to the video. When on software decoding, 0-255 is good for ALL the videos.
I use an ATI Radeon over HDMI and have chosen Full Range in the Catalyst Control Center.
Could anyone please explain me why DXVA need these changes?
Thanks in advance.
BatIt should not. Hard to say without seeing the videos and your setup. Are you sure DXVA is always being used? The difference could be between DXVA and what your software decoders put out. eg. some videos are not DXVA compliant and fall back to software. Often software decoders have settings that can change the output level. Also, if you have an Nvidia card VC-1 will be done in software with MPC.
BatKnight
31st March 2009, 11:30
It should not. Hard to say without seeing the videos and your setup. Are you sure DXVA is always being used? The difference could be between DXVA and what your software decoders put out. eg. some videos are not DXVA compliant and fall back to software. Often software decoders have settings that can change the output level. Also, if you have an Nvidia card VC-1 will be done in software with MPC.
I can assure you that DXVA is on, because I check it by displaying the MPC-HC stats and also by noticing no CPU usage.
When using software decoding, I use ffdshow forcing NV12 (but YV12 or YUY2 does the same), no resampling, no other redenders in the way.
For example, Spiderman 2 1080p needs 0-255 when using DXVA, but almost every other 1080p video needs 16-235 when on DXVA.
Sofware decoding ALWAYS needs 0-255 to properly display brightness/contrast/colors.
Can any one with similar setup reproduce this?
Bat
PS: This happens on Win Vista, EVR Custom, Aero ON, latest Catalyst drivers. Didn't try with VRM9 yet.
Beliyaal
31st March 2009, 11:45
My display is 1920x1080@59hz
Screenshot:
http://img23.imageshack.us/img23/1151/badstuttering.th.png (http://img23.imageshack.us/my.php?image=badstuttering.png)
I see two problems. Your refresh rate isn't detected, and you are starving for buffers to display. They are probably related. It looks like some kind of driver bug. I guess that it isn't ideal to use 8.3 catalysts with Windows 7.
Also your GPU time s at 500 ms which suggests that the driver has some really bad problems.
I will add an option to turn off the event queries that is supposed to stop tearing in the next version. You can check if that is the cause of your stuttering, but it might cause other issues. I'm assuming that it's working correctly in the latest SVN, and you only have these problems in my build.
cca
31st March 2009, 11:53
GPU Wait time 500ms O.o ? Never saw more than 1-2 ms in my setup.
tetsuo55
31st March 2009, 12:33
I see two problems. Your refresh rate isn't detected, and you are starving for buffers to display. They are probably related. It looks like some kind of driver bug. I guess that it isn't ideal to use 8.3 catalysts with Windows 7.
Also your GPU time s at 500 ms which suggests that the driver has some really bad problems.
I will add an option to turn off the event queries that is supposed to stop tearing in the next version. You can check if that is the cause of your stuttering, but it might cause other issues. I'm assuming that it's working correctly in the latest SVN, and you only have these problems in my build.
1.Sorry typo, i have cat 9.3
2.My refresh rate gets detected 1 out of 3 tries.
3.Everything works normally with SVN
If anyone knows the registry key that sets Vsync to "application preference" (preferably the one for windows7) i could make sure its not the vsync option that is causing the problem
tetsuo55
31st March 2009, 12:37
Here is a screenshot of what it looks like when i get "lucky"
http://img5.imageshack.us/img5/2638/stable.th.png (http://img5.imageshack.us/my.php?image=stable.png)
Jong
31st March 2009, 13:38
Been chatting to Beliyaal in MSN and I think we have nailed the problem down.
It is not in Beliyaal's code at all. It appears in SVN1009. All is fine with SVN1008.
From SVN1009 these videos in DXVA mode (so ATI cards only) cause interlaced mode to be engaged and the decoder makes a right old hash of it.Good news! Casimir has already fixed this and all is fine in SVN 1027.
STaRGaZeR
31st March 2009, 13:41
Your refresh rate isn't detected
That's the #IND I was talking about with the x64 version :D
kumi
31st March 2009, 14:50
Note: even if your screen is 60Hz, rather than, NTSC friendly, 59.940Hz this wil cause a frame repeat roughly every 42 seconds (for 24p material) and 33 seconds (for 30p material). Reclock can fix this (but with vsync OFF).Thank you, with the Reclock renderer in the filtergraph the periodic frame skipping is gone with both 24p and 30p material. 100% jitter-free playback at last!
Jong
31st March 2009, 16:07
Thank you, with the Reclock renderer in the filtergraph the periodic frame skipping is gone with both 24p and 30p material. 100% jitter-free playback at last!Great.
Actually, as I had suspected, as a result of frame doubling and telecine, the repeat time for both is 16.66s if clocks are perfectly accurate and you are displaying telecine friendly material (23.976fps or 29.970fps) @60Hz.
Your longer repeat times suggest your TV is actually displaying @59.940Hz and the drops are probably the result of clock errors that Reclock is correcting.
flanger216
31st March 2009, 16:19
It is not generally known. Not to me anyway - could you please provide evidence? The opposite is probably true as video cards have internal 10bit pathways, so a YUV to RGB conversion in hardware has - theoretically - an advantage. The ffdshow HQ RGB32 conversion, while very good, does output only 8 bit RGB values at the moment. The only problems with the ati hardware conversion is that is choses the color matrix on vertical height - which might not be optimal in all cases. But this is true for all other methods (e.g. if you use horizontal size, some 4:3 material might slip through, or if you prescale) too.
My take is that neither software decoding or hardware decoding of vc-1/H264 has an inherent advantage. If the decoder is up to spec, the output is identical and most perceived differences come from auxiliary factors: How does the filter chain expand levels, what color matrix was chosen, what postprocessing do you do, how is the image scaled and last but not least how did you calibrate you display. Judging from many posts especially the latter together with the level expansion issue accounts for a lot of statements preferring one decoder over another.
Of course there are other factors like cpu usage, material not complying with level 4.1 etc....
Sure sure, mileage may vary. I was under the impression that, since a hardware pathway is going to have be downsampled to NV12 sooner rather than later (at least on my ATI), color reproduction is negligably better-off if you software-decode it to RGB and do all your processing in that space. Chroma quality is noticably superior in ffdshow to DXVA on my card, even if I enable the upsampling shader. Then again, DXVA quality is likely highly dependent on vender, adapter model, drivers and even operating system. I also admit that all this talk of 3D luts and matrices goes completely and utterly over my head, especially in the ffdshow thread :scared:
But I was also under the impression that 10-bit processing was independent of whether you use hardware or software decoding...? For instance, it seems to be enabled in Beliyaal's build no matter what decoding path I use. Or are you saying that 10-bit processing is always used in DXVA2, no matter what player you use, whereas it specifically has to be enabled for software decoding...?
Anyhoo, I always thought the biggest advantage of DXVA was using hardware deinterlacing.
flanger216
31st March 2009, 16:23
One thing I noticed is that when using software decoding I have to check 0-255 output in Beliyaal's MPC-HC, otherwise videos are too bright.
But when using DXVA, I have to check 16-235 because videos are too dark with 0-255. Nevertheless not all HD videos have to be on 16-235. I have come across with some 1080p videos that need 0-255 even on DXVA. I have to keep changing according to the video. When on software decoding, 0-255 is good for ALL the videos.
I use an ATI Radeon over HDMI and have chosen Full Range in the Catalyst Control Center.
Could anyone please explain me why DXVA need these changes?
Thanks in advance.
Bat
Same here. It's like a little game I have to play during the first 10-15 seconds of any HD movie I watch.
Jong
31st March 2009, 16:35
Well (stating the obvious(!)) it really should not be happening. Unless the video has been badly encoded (possible) I think it is due to different decoders/renderers being used and you have those configured differently.
For example CoreAVC can change levels, as can Haali, as can ffdshow, as can the driver. Throw a few of those into the mix in different combinations and I can see how problems can occur. It is one of the reasons I said a straight forward DXVA path for all players can be easier (but even that falls down if the stream is not DXVA compliant.).
I would look at the filter path for each video that does something different and try to spot where the config differences are.
Jong
31st March 2009, 16:40
Anyhoo, I always thought the biggest advantage of DXVA was using hardware deinterlacing.No. Hardware de-interlacing can be done independent of decoding using DXVA. CoreAVC does it. Although it is true not all decoders allow this.
littleD
31st March 2009, 17:28
@Tetsuo55
HKLM\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\UMD\VSyncControl
value/data: 30 for vsynch off, 31 or 32 for - unless application specifies, 34 - always on
Did u installed motherboard drivers (http://digg.com/microsoft/How_To_Vista_and_Nforce2_With_Full_Driver_Support)? It may or not may help in video playback, but in general system will be having better response.
I have similar setup to yours, only diff is my ati3450agp. All work fine with build 22 but when all synch stuff is turned off. Seven doesnt need it.:confused:
Looks like hd2400 isnt as good as it should be in video playback. Im so lucky that i chosen hd3000 series :)
Casshern
31st March 2009, 17:53
Same here. It's like a little game I have to play during the first 10-15 seconds of any HD movie I watch.
The problem is that within the h264 stream there are flags to tell the decoder how to convert the levels. Both the input and output can be flagged to be TV levels or PC levels. Unfortunatly some streams (e.g. sky hdtv streams) are flagged incorrectly. Fortunatly, though coreavc in the more recent versions allows to override the flags. If you set both to 0-255 you get the signal as encoded - so typically a movie would have black at 16 - now it depends how your display is calibrated, and how the renderer handles level expansion.
Here is what i use without any problems for all material (bd, mkv, xvid, dvd etc):
1) I use the ATI card to expand levels always (but beware supposedly the reg key "use bsc601" does not work with newer catalysts on some cards)
2) In core avc both flags are set to 0-255
3) No further expansion in mpc hc, and no further expansion in ffdshow
4)calibrate display for pc levels
This gives consistent levels for pc gaming and htpc playback. Some people prefer the opposite and never expand, leaving levels as is - this is fine if you only watch movies and can live with you desktop looking greyish. Some use the picture controls in the control center or playback software to do a manual expansion. Your milage may vary.
DXVA mostly ignores the flags and therefore has less probs than software decoding. But beware, there might be material which needs correct handling of the flags - i never encountered such a beast though.
flanger216
31st March 2009, 17:54
No. Hardware de-interlacing can be done independent of decoding using DXVA. CoreAVC does it. Although it is true not all decoders allow this.
Ach, that's true... I keep forgetting you only need NV12 nowadays to kick in the hardware deinterlacer / post-processor with ATI.
73ChargerFan
31st March 2009, 19:33
I have similar problems with color conversion, because I watch 20% hd movies at 1080p, and 50% hi-def television content re-encoded to a lower resolution, and 30% standard def material. The hi-def tv stuff always has bad contrast, which I adjust for, and then have to undo when watching something else. I'm on XP SP3, ATI 4850 & Cat. 8.12.
Jong
31st March 2009, 19:35
The problem is that within the h264 stream there are flags to tell the decoder how to convert the levels. Both the input and output can be flagged to be TV levels or PC levels. Unfortunatly some streams (e.g. sky hdtv streams) are flagged incorrectly. Fortunatly, though coreavc in the more recent versions allows to override the flags. If you set both to 0-255 you get the signal as encoded - so typically a movie would have black at 16 - now it depends how your display is calibrated, and how the renderer handles level expansion.
Here is what i use without any problems for all material (bd, mkv, xvid, dvd etc):
1) I use the ATI card to expand levels always (but beware supposedly the reg key "use bsc601" does not work with newer catalysts on some cards)
2) In core avc both flags are set to 0-255
3) No further expansion in mpc hc, and no further expansion in ffdshow
4)calibrate display for pc levels
This gives consistent levels for pc gaming and htpc playback. Some people prefer the opposite and never expand, leaving levels as is - this is fine if you only watch movies and can live with you desktop looking greyish. Some use the picture controls in the control center or playback software to do a manual expansion. Your milage may vary.
DXVA mostly ignores the flags and therefore has less probs than software decoding. But beware, there might be material which needs correct handling of the flags - i never encountered such a beast though.You learn something new every day. Thanks.
But it does illustrate the danger of playing with these too. Hard to keep track and ensure consistency when you can change the levels in CoreAVC, ffdshow, Haali renderer (if you use it), the driver.....
tetsuo55
31st March 2009, 19:42
@Tetsuo55
HKLM\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\UMD\VSyncControl
value/data: 30 for vsynch off, 31 or 32 for - unless application specifies, 34 - always on
Did u installed motherboard drivers (http://digg.com/microsoft/How_To_Vista_and_Nforce2_With_Full_Driver_Support)? It may or not may help in video playback, but in general system will be having better response.
I have similar setup to yours, only diff is my ati3450agp. All work fine with build 22 but when all synch stuff is turned off. Seven doesnt need it.:confused:
Looks like hd2400 isnt as good as it should be in video playback. Im so lucky that i chosen hd3000 series :)
Thanks, i will try that key asap.
I installed the drivers offered by windows update, as these are all newer and win7 compatible unlike the last original drivers. (benchmarks also give me higher results)
the 2400 is a piece of crap, especially in the AGP flavour.
It even says on the box that it was not designed for 1080p full hd, it works through registry keys.
Note however that the regular SVN build has no problem at all playing full-hd video, regardless of bitrate. (Except for the known problems of occasional macroblocking and tearing when not using 3d exclusive mode)
BatKnight
31st March 2009, 21:23
Ach, that's true... I keep forgetting you only need NV12 nowadays to kick in the hardware deinterlacer / post-processor with ATI.
I've noticed that since catalyst 9.2 that the post-processing edge enhancement or noise-filtering that you can adjust over the Avanced Quality in Catalyst Control Center no longer work with NV12 or any other colorspace. It did with catalyst 8.12.
Do you notice that too? Because I even tried to put those settings to the maximum to be obviously noticed and they just don't work. Can you, ATI users, please confirm it's a catalyst issue and software-based?
Bat
cca
31st March 2009, 21:33
I've noticed that since catalyst 9.2 that the post-processing edge enhancement or noise-filtering that you can adjust over the Avanced Quality in Catalyst Control Center no longer work with NV12 or any other colorspace. It did with catalyst 8.12.
Do you notice that too? Because I even tried to put those settings to the maximum to be obviously noticed and they just don't work. Can you, ATI users, please confirm it's a catalyst issue and software-based?
Bat
For Catalyst 9.2 I can't say, it works fine for me with Catalyst 9.3, my config in my signature.
BatKnight
31st March 2009, 21:43
For Catalyst 9.2 I can't say, it works fine for me with Catalyst 9.3, my config in my signature.
Do you use EVR Custom? Do you have to force any colorspace for it to work? Anything I should know?
Bat
cca
31st March 2009, 22:06
Do you use EVR Custom? Do you have to force any colorspace for it to work? Anything I should know?
Bat
I use EVR Custom indeed, enforcing NV12 in ffdshow. As far as I know NV12 is necessary for those features to work with ATi cards. Are you using Vista or XP?
Rille
31st March 2009, 22:17
I'm have problems with alot of judder using last build. Weird thing is that according to stats everything is fine (nice flat line). Switching to build 15 does however solve the problem.
Using Vista x86, HD4850 Cat. 9.3, EVRCP, Aero, 1280x720@50hz running on 2nd monitor (extended desktop) and reclock. Tried vsync, accurate vsync.
Problem doesn't occour on my second setup which is identical except HD3200 and only one monitor.
Beliyaal
31st March 2009, 22:46
I'm have problems with alot of judder using last build. Weird thing is that according to stats everything is fine (nice flat line). Switching to build 15 does however solve the problem.
Using Vista x86, HD4850 Cat. 9.3, EVRCP, Aero, 1280x720@50hz running on 2nd monitor (extended desktop) and reclock. Tried vsync, accurate vsync.
Problem doesn't occour on my second setup which is identical except HD3200 and only one monitor.
Does it work better if you disable aero?
Casshern
31st March 2009, 23:53
I encountered a similar problem recently. I could fix it by disabling the second monitor in the catalyst control center. Maybe some code fetches the refreshrate of the wrong head?
I always keep the display i want to "sync" to as the "primary" display. This did work for ages in clone mode. Then recently it exhibeted period judder - but i updated so many components in between (catalyst, reclock, mpc hc, coreavc etc) that i don't really know whats the root cause.
But maybe you can fix it just like I did, disable the second head of your card (luckily i didn't have to physically unplug the second monitor) in catalyst and see what happens.
I'm have problems with alot of judder using last build. Weird thing is that according to stats everything is fine (nice flat line). Switching to build 15 does however solve the problem.
Using Vista x86, HD4850 Cat. 9.3, EVRCP, Aero, 1280x720@50hz running on 2nd monitor (extended desktop) and reclock. Tried vsync, accurate vsync.
Problem doesn't occour on my second setup which is identical except HD3200 and only one monitor.
Rille
1st April 2009, 06:22
Does it work better if you disable aero?
Yes, seems to work fine when i disable Aero but only tested for a few minutes. Will have some time to test more tonight.
fastplayer
1st April 2009, 10:07
I can't play this trailer (http://playlist.yahoo.com/makeplaylist.dll?sid=81115433&sdm=web&pt=rd) [118MB] in DXVA mode with the latest version 22. There's no video output, just audio. It plays fine with SVN 1024.
Setup:
Server 2008
Radeon HD4670
Catalyst 9.3
Edit: Plays fine with version 21.
The same trailer in a different resolution works fine:
Trailer #1 (http://playlist.yahoo.com/makeplaylist.dll?sid=81115433&sdm=web&pt=rd) [118MB] --> 1280x534 --> EVR CP (default settings, DXVA on) --> No video
Trailer #1 (http://playlist.yahoo.com/makeplaylist.dll?sid=81115433&sdm=web&pt=rd) [118MB] --> 1280x534 --> EVR CP (default settings, DXVA off) --> OK
Trailer #2 (http://movies.apple.com/movies/wb/terminatorsalvation/terminatorsalvation-tlr3_h720p.mov) [113MB] --> 1280x544 --> EVR CP (default settings) --> OK
This is how MPC opens the video (with filters menu opened):
http://f.imagehost.org/t/0486/New_Bitmap_Image.jpg (http://f.imagehost.org/0486/New_Bitmap_Image.png)
This is when window is maximized with "Display Stats" enabled:
http://f.imagehost.org/t/0217/New_Bitmap_Image_2.jpg (http://f.imagehost.org/0217/New_Bitmap_Image_2.png)
backtohell
1st April 2009, 10:27
Hi
Latest Beliyaal Build version 22 is not using EVR Custom presenter in my system (it uses VMR 7 windowed instead in both 32/64 bit) for all videos(i verified the setup EVR CP is checked in output). When i tried using the _xxl's latest build version 1029 it correctly renders the video with the EVR Custom presenter.
My system setup is
Vista Ultimate 64 Bit
Nvidia Geforce 7600 Go
Forceware:177.13
Using standalone versions of MPC-HC(i am not using Aero/UAC)
I am not a techie and i request your help in this problem.
Thanks in advance
BatKnight
1st April 2009, 14:50
I use EVR Custom indeed, enforcing NV12 in ffdshow. As far as I know NV12 is necessary for those features to work with ATi cards. Are you using Vista or XP?
I am using Vista.
Seems like I need to completely remove my current drivers and references to it and reinstall 9.3 to see if it works again.
Bat
flanger216
1st April 2009, 15:01
I've noticed that since catalyst 9.2 that the post-processing edge enhancement or noise-filtering that you can adjust over the Avanced Quality in Catalyst Control Center no longer work with NV12 or any other colorspace. It did with catalyst 8.12.
Do you notice that too? Because I even tried to put those settings to the maximum to be obviously noticed and they just don't work. Can you, ATI users, please confirm it's a catalyst issue and software-based?
Bat
Hmmm... still working fine on my end, but I'm on 9.3 in Windows 7. If you haven't already, I'd wipe ATI completely out (drivers folder, registry, etc.) and give 9.3 a go.
mark0077
1st April 2009, 22:38
Hi, this is not a bug but something that could go down as a future improvement. I had a music dvd playing earlier with the beliyaal build, perfect with 0 frame drops. Then when a few visitors came over, I left the music playing and used my TV's content feature to get some news. When exiting this feature and going back to normal mode, the sound glitches badly for a second.
I can reproduce this and just doesn't look / good when trying to impress a friend or two ;)
I assume this could be tested / improved on your end by disconnecting a TV and reconnecting, maybe even by powering off the TV and powering back on.
Rille
2nd April 2009, 07:59
Yes, seems to work fine when i disable Aero but only tested for a few minutes. Will have some time to test more tonight.
Disabling Aero solves the problem. I do however get a constant tear at the bottom of the screen. Is alternative vsync and disabling aero a must?
yesgrey
2nd April 2009, 11:59
I do however get a constant tear at the bottom of the screen.
Are you checking the "VSync" and the "Accurate VSync" options in the "Renderer settings" menu? I only get tears if I uncheck the "VSync" option.
Beliyaal
2nd April 2009, 12:21
Disabling Aero solves the problem. I do however get a constant tear at the bottom of the screen. Is alternative vsync and disabling aero a must?
I have the same problem with my multi display setup using Radeon 4870. It seems to be a driver issue. I solve it by using Alternative VSync. Basically:
* Disable desktop composition on executable(That way you can use Aero while you aren't using MPC)
* VSync: On
* Accurate VSync: On
* Alternative VSync: On
The issue with stuttering while playing with Aero on seems to have cropped up in Catalyst 9.1 or later. I never had any problems with it before 9.1.
Jong
2nd April 2009, 12:28
Hi Beliyaal, is it possible for you to (optionally) keep a log of the number of dropped/repeated frames, or at least display it on the stats screen? Can you tell definitely when a frame has actually been dropped rather than there just being a bit of jitter?
Keeping a count would stop us having to watch the jitter chart continually during playback to look for "spikes". And I, for one, am never 100% sure how big a "wobble" needs to be before it is a "spike" and a frame is dropped.
....Oh and could we have a build that uses svn1027+ so I can test some more without the HD-DVD VC-1 bug?
I have the same problem with my multi display setup using Radeon 4870. It seems to be a driver issue. I solve it by using Alternative VSync. Basically:
* Disable desktop composition on executable(That way you can use Aero while you aren't using MPC)
* VSync: On
* Accurate VSync: On
* Alternative VSync: On
The issue with stuttering while playing with Aero on seems to have cropped up in Catalyst 9.1 or later. I never had any problems with it before 9.1.
With the latest version I don't get stutters anymore, but that's on Vista 64, perhaps you 're talking about Win 7? Using only one Display Device at a time (I have 2, monitor and TV).
Rille
2nd April 2009, 13:01
I have the same problem with my multi display setup using Radeon 4870. It seems to be a driver issue. I solve it by using Alternative VSync. Basically:
* Disable desktop composition on executable(That way you can use Aero while you aren't using MPC)
* VSync: On
* Accurate VSync: On
* Alternative VSync: On
The issue with stuttering while playing with Aero on seems to have cropped up in Catalyst 9.1 or later. I never had any problems with it before 9.1.
Thanks for the info. As you say it seems to be related to multidisplay as i can't recreate the problem on my HTPC which only have one display connected. I'll try alternative vsync when i get home. Vsync and accurate vsync is already enabled.
Edit:
To specify my setup: I have a 24" running as primary with 1920x1200@60 and then run extended desktop to my bedroom-TV which is 42" with 1280x720@50. Disabling primary isn't a good option for me as the TV is behind me when sitting at the keyboard.
mark0077
2nd April 2009, 13:50
Beliyaal,
Any idea why I get such bad playback when playing vc-1 using ffdshow's decoders. Everything plays fine using mpc-hc's vc-1 decoder.
I am using your latest build and below is a screenshot showing how bad things look using ffdshow libavcodec vc-1 decoder. If you think its ffdshow related I will post over there. I am not getting dropped frames, very low cpu usage.
http://img6.imageshack.us/img6/772/problemffdshow.th.jpg (http://img6.imageshack.us/my.php?image=problemffdshow.jpg)
This is vista 64, mpc-hc 32, ffdshow 32
Beliyaal
2nd April 2009, 14:04
Beliyaal,
Any idea why I get such bad playback when playing vc-1 using ffdshow's decoders. Everything plays fine using mpc-hc's vc-1 decoder.
I am using your latest build and below is a screenshot showing how bad things look using ffdshow libavcodec vc-1 decoder. If you think its ffdshow related I will post over there. I am not getting dropped frames, very low cpu usage.
http://img6.imageshack.us/img6/772/problemffdshow.th.jpg (http://img6.imageshack.us/my.php?image=problemffdshow.jpg)
This is vista 64, mpc-hc 32, ffdshow 32
It's probably the timing bug in the m2ts splitter. Turn on frame time correction to work around it.
mark0077
2nd April 2009, 14:10
That fixed it :D I am just wondering for future reference. Is there any disadv to having frame time correction. I am thinking of the average user, could things like this be enabled by default. I know for me it used to be enabled by default before but not anymore.
Thanks,
Beliyaal
2nd April 2009, 14:28
That fixed it :D I am just wondering for future reference. Is there any disadv to having frame time correction. I am thinking of the average user, could things like this be enabled by default. I know for me it used to be enabled by default before but not anymore.
Thanks,
The frame time correction can cause problems with certain type of content (that changes fps), seeking, and generally is a hack that shouldn't be needed. Generally I find that it can cause problems that would be hard for the user to understand, that's why it's disabled by default.
Hopefully we can get the mpeg splitter working correctly soon.
mark0077
2nd April 2009, 14:30
Ah thats excellent. I will leave it disabled and use mpc-hc internal decoders.
Casshern
2nd April 2009, 16:24
Here evr cp, falls back to vmr7 only if i use dxva for h264. This is because the catalyst drivers (9.2) offer only vc-1 dxva under winxp with the evr cp renderer. I thought this was a feature...
Hi
Latest Beliyaal Build version 22 is not using EVR Custom presenter in my system (it uses VMR 7 windowed instead in both 32/64 bit) for all videos(i verified the setup EVR CP is checked in output). When i tried using the _xxl's latest build version 1029 it correctly renders the video with the EVR Custom presenter.
My system setup is
Vista Ultimate 64 Bit
Nvidia Geforce 7600 Go
Forceware:177.13
Using standalone versions of MPC-HC(i am not using Aero/UAC)
I am not a techie and i request your help in this problem.
Thanks in advance
backtohell
3rd April 2009, 08:07
But i am using Nvidia GPU and this problem of renderer shifting to VMR 7(even if i force evr cp) windowed mode happens only with Beliyaal's build not with the _xxl ones for any video format(with/without dxva)
Kado
3rd April 2009, 08:25
9800gtx, vista x86, beliyaal rev22 and evr cp works fine , even with dxva.
mark0077
3rd April 2009, 10:30
Hi Beliyaal,
Still having the problem with your build and havn't tested against normal build. When watching a movie fullscreen my TV turns off after an hour as thats the way I have my power management settings. I wonder where the bug might lie as this doesn't seem to happen when not maximised. I am running media center also (using mpc-hc as external player) so I wonder is there some problem when both are running. I will try and get more info.
Mike5
3rd April 2009, 10:56
The stats showed with Ctrl-J have a fixed dimension, indipendent form the video resolution. Because they need approx. 1400 horizontal pixels to be entirely showed, on a 1280x720 display they are cut off on the right like in this (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/vsyncr1010.png) image.
Is there a way to reduce them to fit a 1280x720 display ?
Beliyaal
3rd April 2009, 14:40
The stats showed with Ctrl-J have a fixed dimension, indipendent form the video resolution. Because they need approx. 1400 horizontal pixels to be entirely showed, on a 1280x720 display they are cut off on the right like in this (http://i266.photobucket.com/albums/ii259/gngnmumu/dxva/vsyncr1010.png) image.
Is there a way to reduce them to fit a 1280x720 display ?
I will add automatic text size in the next version so it tries to fit everything on the screen.
Beliyaal
3rd April 2009, 14:42
Anyone see any show stoppers for integrating into SVN this weekend?
Rille
3rd April 2009, 14:50
The only problem i found is that hz detection seems to behave strange at some resolutions. For example:
1280x720@50=fine
1280x720@48=fine
1366x768@48=very strange values, if i close MPCHC and start again another value is shown that is waaaay off. Can't remember exactly but i saw as low values as 23-24 and as high as 120
1366x768@50=same as @48
I used Powerstrip to change hz. Both my TV and Reclock display correct value.
Mercury_22
3rd April 2009, 15:02
Anyone see any show stoppers for integrating into SVN this weekend?
There are "NO SHOW STOPPERS" but still some bugs like the need (sometimes) for "frame time correction a hack that shouldn't be needed" SO PLEASE DO integrate into SVN ! :D
P.S. Please add as much detailed info as you can for your new "settings" : Alternative VSync, Accurate VSync, Frame Time Correction, 10 bit RGB... in the "Tooltips" :thanks:
Mike5
3rd April 2009, 15:13
I will add automatic text size in the next version so it tries to fit everything on the screen.
Thanks.
carnage_pl
3rd April 2009, 15:41
There are "NO SHOW STOPPERS" but still some bugs like the need (sometimes) for "frame time correction a hack that shouldn't be needed" SO PLEASE DO integrate into SVN ! :D
P.S. Please add as much detailed info as you can for your new "settings" : Alternative VSync, Accurate VSync, Frame Time Correction, 10 bit RGB... in the "Tooltips" :thanks:
Second that :P
Jong
3rd April 2009, 15:46
Anyone see any show stoppers for integrating into SVN this weekend?Yeah, I think it is good to go. I would have preferred to play with a version that incorporates an up to date SVN (VC-1 bug fixed), but I doubt it will reveal anything.
Only problem I have is that thing with DVDs I mentioned. It's annoying.
tetsuo55
3rd April 2009, 16:23
Anyone see any show stoppers for integrating into SVN this weekend?
The bug i reported with DXVA is a definate show stopper.
Completely unwatchable (SVN is fine)
Beliyaal
3rd April 2009, 16:34
The bug i reported with DXVA is a definate show stopper.
Completely unwatchable (SVN is fine)
I have it on my list to add the option for event queries. I will release a new version tomorrow before submitting to SVN possibly Sunday, so hopefully that can solve your issue before I submit.
anon2243
3rd April 2009, 17:40
Dont know if this is a big change or showstopper but :
CHANGED : support for MLP/True HD in MKV
does that mean mkv's are now better quality off the bat?
Kado
3rd April 2009, 18:45
@anon2243
MKV is a container, it has noting to do with quality. That means that "MLP/True HD" audio streams are now recognized if they are in a MKV container by the internal splitter.
Kado
3rd April 2009, 19:25
I found a bug in the h.264 dxva decoder.
Playback freezes with a specific file using mpc h.264 dxva decoder but with Microsoft h264 decoder from Windows 7 build 7057 x86 it plays fine using dxva.
File has 16 reference frames but that's no problem to NVIDIA GPU's.
Vista x86 SP2 v.275 / 9800GTX 185.65 / DirectX March / MPC-HC rev1032 or Beliyaal patch 22 on rev1024.
RS link (http://rapidshare.com/files/217044035/_Chihiro__Zettai_Karen_Children_20__h264__C9010144_-001.mkv.html) (up to 10 downloads), zShare link (http://www.zshare.net/download/58142350030b6e5a/) (unlimited downloads).
anon2243
3rd April 2009, 19:43
Thanks for clarifying...was hoping to get something for nothing there :D
mark0077
3rd April 2009, 23:27
Guys, always notice the audio / video is out of sync with some clips slightly like this Aladdin avi I ripped. The graph , the red and green lines usually converge to be "within" eachother which I imagined would indicate them being syced, but as you can see in the example below, the green one stays significantly above the red.
Am I right in saying this is a visual representation of the bad audio / video sync I seem to be getting? If so I can give more details.
http://img3.imageshack.us/img3/3817/syncproblem.th.jpg (http://img3.imageshack.us/my.php?image=syncproblem.jpg)
No showstoppers here for adding to SVN. As EVRCP is b0rked in any version here that would mean at least someone finally can pay attention to the bug! (I already reported that twice on the forum and also created an entry in the bugtrack. Dully ignored, of course).
STaRGaZeR
4th April 2009, 02:16
Small bug here. Version 22 does not display the very first FBI warning when playing certain DVDs. Version 21 is fine.
Mercury_22
4th April 2009, 08:55
...Grab 64-bit Haali's splitter here
WOW ! Finally 64-bit !!:thanks:
Is this a BETA 64-bit Haali's splitter ?
ashlar42
4th April 2009, 10:32
Am I right in understanding that when "merge to SVN" is mentioned here it means that soon all these great additions are going to be available to every build of MPC-HC?
yesgrey
4th April 2009, 10:36
Am I right...
Yes, you are.
STaRGaZeR
4th April 2009, 13:23
WOW ! Finally 64-bit !!:thanks:
Is this a BETA 64-bit Haali's splitter ?
Yes, but so far it works exactly the same as the 32-bit version. Now that ffdshow64 has working ffmpeg-mt I will switch completely to 64-bit if I don't encounter any bugs.
Abut my lastest report, I've noticed that the buffers stay 0/20 until the second warning frame is displayed, then they turn to 1/19.
WOW ! Finally 64-bit !!
Is this a BETA 64-bit Haali's splitter ?
Wow? So you wasted nearly three months of your life not even knowing that first x64 haali beta was out on 19th of January?
You probably need to subscribe to the relevant thread then at least....
http://forum.doom9.org/showthread.php?p=1239215#post1239215
Mercury_22
4th April 2009, 17:44
Wow? So you wasted nearly three months of your life not even knowing that first x64 haali beta was out on 19th of January?
You probably need to subscribe to the relevant thread then at least....
http://forum.doom9.org/showthread.php?p=1239215#post1239215
I've given up hope for a new & a 64-bit version since it took about one year to be released
And you CAN'T say there were no bugs (still are a few)
:(
I've given up hope for a new & a 64-bit version since it took about one year to be released
And you CAN'T say there were no bugs (still are a few)
:(
Yes they are. I *suspect* there's a bug in Haali splitter latest beta regarding one specific case of ordered chapters merge. It has been reported to work perfectly with latest official release + latest "official" MPCHC. However doesnt' work here with Haali beta+SVN MPCHC. I don't even bovver to report it though, as in this case (as it happened already several times) this bug will be dully ignored.
Also Haali is quite bad with m2ts splitting with AAC tracks, audio desyncs (clicks etc) do happen. Not that MPCHC is ideal with m2ts, especially beliyaal's version, however reported that and again, dully ignored. I even uploaded the samples to illustrate the issue and posted that to bugtrack, not that anyone bovvers...
flanger216
5th April 2009, 01:43
Maybe you should just be grateful that people are pouring their free time into surprisingly fantastic products and then providing them free of charge. And then you should be doubly grateful if they happen to have the time fix your specific problems. Alternatively, you could learn how to fix it yourself.
Or I guess you could whine about it, as if anyone is at your specific beck and call. Also, the word is 'duly.'
STaRGaZeR
5th April 2009, 03:53
Someone please call the whaaaambulance.
Spec-Chum
5th April 2009, 11:22
Maybe you should just be grateful that people are pouring their free time into surprisingly fantastic products and then providing them free of charge. And then you should be doubly grateful if they happen to have the time fix your specific problems. Alternatively, you could learn how to fix it yourself.
Or I guess you could whine about it, as if anyone is at your specific beck and call. Also, the word is 'duly.'
Hear, hear, well said mate
+1 from me
nuhi
5th April 2009, 12:50
Beliyaal, I have two interesting notes to report, not sure if it was already mentioned in this thread as I read only half of it.
In Vista\Win7 with Aero ON I have to disable the MPC VSYNC in order to have 2 straight lines in the stats with low StdDev.
If I enable VSYNC it will have that ^^^^^ stat with 8ms StdDev jitter.
Key point here is that it seems like Aero-enabled desktop is having VSYNC already enabled and when MPC enables it it goes into 8ms jitter. This was already reported in this thread but no one seemed to really noticed it. And I was debugging this 8ms jitter for days.
Btw when I disable Aero (stopping Desktop Composition service) then I get screen tearing, confirming VSYNC-enabled by Aero.
Second note is that 10bit color option works, compared the same frame and with 8bit it looks yellow in comparison, nice work.
Mangix
5th April 2009, 20:21
what's the difference between A8R8G8B8 and X8R8G8B8? i noticed that VMR9 uses the former for its surfaces whereas EVR does not.
Spec-Chum
5th April 2009, 20:29
what's the difference between A8R8G8B8 and X8R8G8B8? i noticed that VMR9 uses the former for its surfaces whereas EVR does not.
A is alpha (transparency), X just means it's ignored, so assuming you're not running a video with 50% opaqueness on the desktop or something, they should be identical, outputwise, so nothing to worry about :)
Spec
Beliyaal
5th April 2009, 21:50
Guys, always notice the audio / video is out of sync with some clips slightly like this Aladdin avi I ripped. The graph , the red and green lines usually converge to be "within" eachother which I imagined would indicate them being syced, but as you can see in the example below, the green one stays significantly above the red.
Am I right in saying this is a visual representation of the bad audio / video sync I seem to be getting? If so I can give more details.
http://img3.imageshack.us/img3/3817/syncproblem.th.jpg (http://img3.imageshack.us/my.php?image=syncproblem.jpg)
Beliyaal, I have two interesting notes to report, not sure if it was already mentioned in this thread as I read only half of it.
In Vista\Win7 with Aero ON I have to disable the MPC VSYNC in order to have 2 straight lines in the stats with low StdDev.
If I enable VSYNC it will have that ^^^^^ stat with 8ms StdDev jitter.
Key point here is that it seems like Aero-enabled desktop is having VSYNC already enabled and when MPC enables it it goes into 8ms jitter. This was already reported in this thread but no one seemed to really noticed it. And I was debugging this 8ms jitter for days.
Btw when I disable Aero (stopping Desktop Composition service) then I get screen tearing, confirming VSYNC-enabled by Aero.
Second note is that 10bit color option works, compared the same frame and with 8bit it looks yellow in comparison, nice work.
You shouldn't disable VSync to get a straight line. The VSync is there for the reason of avoiding stuttering. Without VSync when Aero is enabled you can experience stuttering because the player tries to draw the frame at the same time as Windows is updating the display.
The graph is showing you the judder. When you disable VSync all you are doing is hiding the judder from the graph. Disabling VSync will only make the player perform worse.
Judder occurs when you display try to display a video that has a FSP isn't a multiple of your screen refresh rate.
This is why I didn't want the VSync option to be saved. I think I might remove the VSync option entierly :) It has no reason for existing, except for debugging.
Small bug here. Version 22 does not display the very first FBI warning when playing certain DVDs. Version 21 is fine.
Abut my lastest report, I've noticed that the buffers stay 0/20 until the second warning frame is displayed, then they turn to 1/19.
I'm not sure what could be causing this, but it might be fixed with the latest version when it doesn't wait for the event queries.
Keep in mind that it might also be the decoder that isn't delivering frames to the randerer quickly enough. It's not much you can do about this as the audio will start playing at once, and when the decoder finally starts delivering frames it will drop those that are behind the audio.
Beliyaal
5th April 2009, 21:57
New version (Link in signature):
* Added: Options for GPU flushing behaviour.
* Added: Errors creating EVR Custom and VMR9 renderers are reported by message box.
* Added: Default and optimal renderer settings reset option.
* Added: Option to disable desktop composition.
* Added: Renderer settings displayed in stats.
* Changed: By default the renderer doesn't block waiting for GPU flushes. (Might fix Radeon 2400 HD AGP problems)
* Changed: All renderer settings available from right click menu.
* Fixed: Jitter is 126 instead of 125 frames for better FPS average in most cases.
* Fixed: Cleaned up stats. Only stats that are currently valid are displayed.
* Fixed: Stats text scaled according to screen size.
* Fixed: All render settings except D3D fulscreen now applies without restart
I can't submit to SVN this weekend either. I need to update the language translations with the GUI changes I have made, and it's taking a lot of more time. Hopefully I will be able to finish these updates next weekend.
This version hopefully fixes the stuttering with DXVA on some computers.
If you have changed many settings, you might want to reset the settings with the option for doing this in the renderer settings menu. I have also added an optimal settings option that will enable the settings that I know gives the best performance. This will however disable desktop composition while the player is running. That's why it's not the default.
fastplayer
5th April 2009, 22:03
The same trailer in a different resolution works fine:
Trailer #1 (http://playlist.yahoo.com/makeplaylist.dll?sid=81115433&sdm=web&pt=rd) [118MB] --> 1280x534 --> EVR CP (default settings, DXVA on) --> No video
Trailer #1 (http://playlist.yahoo.com/makeplaylist.dll?sid=81115433&sdm=web&pt=rd) [118MB] --> 1280x534 --> EVR CP (default settings, DXVA off) --> OK
Trailer #2 (http://movies.apple.com/movies/wb/terminatorsalvation/terminatorsalvation-tlr3_h720p.mov) [113MB] --> 1280x544 --> EVR CP (default settings) --> OK
This is how MPC opens the video (with filters menu opened):
http://f.imagehost.org/t/0486/New_Bitmap_Image.jpg (http://f.imagehost.org/0486/New_Bitmap_Image.png)
This is when window is maximized with "Display Stats" enabled:
http://f.imagehost.org/t/0217/New_Bitmap_Image_2.jpg (http://f.imagehost.org/0217/New_Bitmap_Image_2.png)
Fixed with the latest version 23.
Thanks a lot, Beliyaal! :thanks:
By the way, is having 8ms jitter "normal" in all videos I play?
Beliyaal
5th April 2009, 22:10
Fixed with the latest version 23.
Thanks a lot, Beliyaal! :thanks:
By the way, is having 8ms jitter "normal" in all videos I play?
If you play 23.976 or 24 FPS videos on a 60 Hz display, then 8ms stddev jitter and 4ms stddev sync offset is normal.
fastplayer
5th April 2009, 22:14
Thanks! I guess I must get used to it, since previously jitter was almost always zero (as reported in Play --> Filters --> EVR CP).
Edit:
There are some menu entries missing under Play --> Shaders:
http://f.imagehost.org/t/0682/New_Bitmap_Image.jpg (http://f.imagehost.org/0682/New_Bitmap_Image.jpg)
have a couple of problems under windows 7 7068
Intel Atom Z530
intel 500 Dxva
1024 Mb ddr2 667
Windows 7
using ver 22
1. when aero is enablet ther is no tearing at all but the sound sounds like crap and i cant activate stats with evr custom or show sound volume, play, pause(stats and sound volume, play, pause works fine with evr but then the subtitles dodsnt work any more)
2. with aero disablet there is tearing in every file except the 1080P mkv i use to test with but sound is ok and still cant se stats and play, pause
The problem is in the svn too
Beliyaal
5th April 2009, 22:19
have a couple of problems under windows 7 7068
Intel Atom Z530
intel 500 Dxva
1024 Mb ddr2 667
Windows 7
using ver 22
1. when aero is enablet ther is no tearing at all but the sound sounds like crap and i cant activate stats with evr custom or show sound volume, play, pause(stats and sound volume, play, pause works fine with evr but then the subtitles dodsnt work any more)
2. with aero disablet there is tearing in every file except the 1080P mkv i use to test with but sound is ok and still cant se stats and play, pause
The problem is in the svn too
Try Ver23 with EVR Custom and check if you get any error messages when you start the video.
Beliyaal
5th April 2009, 22:20
Thanks! I guess I must get used to it, since previously jitter was almost always zero (as reported in Play --> Filters --> EVR CP).
Well yes. The old EVR Custom didn't report the jitter correctly. It didn't calculate the std deviation.
fastplayer
5th April 2009, 22:23
Well yes. The old EVR Custom didn't report the jitter correctly. It didn't calculate the std deviation.
Thanks for the explanation!
I hope that you can add some tooltips to the new GUI controls, so that we mortals can understand any of this :)
Beliyaal
5th April 2009, 22:50
New version (Link in signature):
* Fixed: Crash when event queries isn't available from the GPU driver.
fastplayer
5th April 2009, 22:50
Another bug report:
This MPEG-1 video (http://www.speedyshare.com/410384723.html) doesn't play. Works fine with the SVN builds.
Beliyaal
5th April 2009, 22:54
Another bug report:
This MPEG-1 video (http://www.speedyshare.com/410384723.html) doesn't play. Works fine with the SVN builds.
Works fine here. Does it crash, or something else?
fastplayer
5th April 2009, 22:56
Works fine here. Does it crash, or something else?
Same behavior as in the 1st pic as reported here:
http://forum.doom9.org/showthread.php?p=1268391#post1268391
MPC opens in minimized view and that's it.
Edit:
Plays fine in EVR but not in EVR CP.
Setup:
Server 2008 (Aero enabled)
Radeon HD4670
Catalyst 9.3
gngn
5th April 2009, 23:09
QuickTime movie files with AAC sound crash ver23 & v24. all the files work with v22 and SVN
edit: if i uncheck "disable desktop composition" it will work. it was checked because i did a settings reset
it seamed i was missing DirectX runtime redist after installing that there is only slight tearing in V trailer 1080P mov file and none in the onther ones that i can see an now play, pause, volume, time and stats are working i youds assumed that it was installed since it worked with evr
STaRGaZeR
5th April 2009, 23:26
I'm not sure what could be causing this, but it might be fixed with the latest version when it doesn't wait for the event queries.
Keep in mind that it might also be the decoder that isn't delivering frames to the randerer quickly enough. It's not much you can do about this as the audio will start playing at once, and when the decoder finally starts delivering frames it will drop those that are behind the audio.
It seems the decoder is not the cause, and also there is no audio to be played. Version 23-24 still have the issue. I've uploaded the menu of one of these DVDs here (http://www.megaupload.com/?d=R3JHNSQH) (22MB) so you can take a look. Compare Version 21 against the newer ones to see it clearly.
Another bug report:
This MPEG-1 video (http://www.speedyshare.com/410384723.html) doesn't play. Works fine with the SVN builds.
hav the same problem with that file but some times the file plays after like 10-15 tries
Edit: works fine if i use ffshow video decoder insted of mpeg video decoder so i think the decoder i broken
Casshern
6th April 2009, 02:03
Nice to have the addítional gpu settings. First a question: Am i right in assuming that GPU Flush after vsync and wait for GPU flush are the settings that would correspond to ver22? With these two enabled everything seems like before.
1) The any given sunday fade to black problem is still there - regardless of gpu settings, vmr9 rl or evr cp, vsync, altvsync etc. But i am now of the opinion that it is more likely the mpc hc dxva decoder which is at fault.
2)The ATI DXVA Bug seems to be related to GPU Flushing - because without any flushing the bug is back - jumping frames etc. even though not as severe as the early builds
3)if i turn of wait for GPU Flush, i always have tearing - no matter what (vsync,alt vsync,vmr9 rl, evr cp - and all combinations)
4)If i turn on D3D mode DXVA h264 is no longer working and the renderer falls back to vmr7 windows. Strange! this happened before only with h264 and evr cp in Winxp. That makes d3d fullscreen kind of useless..
5)With vsync, altvsync and accurate vsync on in evr cp and vc-1 dxva i get a strange occilating jitter graph - playback is still rather smooth
6)I get a lot more crashes with this version - especially with m2ts bd files. Might be sound format related - but the dolby true hd playback is much improved (channels). But often the player just closes itself.
7)If the first soundtrack in an M2TS file is pcm, one gets static when switching to other soundtracks
8)The stats display does not scale with window resizing - but i am not sure that you intended that.
thats my first impressions....
New version (Link in signature):
* Fixed: Crash when event queries isn't available from the GPU driver.
kumi
6th April 2009, 06:07
Disable Desktop Composition makes my MPC crash. What problem is that setting supposed to address?
MPC-HC Beliyaal ver24, WinXP SP3, DirectX Mar. 2009, GeForce 9600 GT, Drivers v181.22
littleD
6th April 2009, 06:29
With 22 version, it was long to load mpeg-2 streams. In 23/24 it takes even longer. In the newest builds (with EVR CP,dxva) is also a little bit higher cpu usage with vc-1 and much much bigger with mpeg-2. With regular evr, mpeg2 playback back to normal. Also there are two empty lines in shader options.
Leak
6th April 2009, 09:02
Disable Desktop Composition makes my MPC crash. What problem is that setting supposed to address?
Disabling Aero under Vista while MPC is running.
Unless I'm totally wrong it shouldn't do anything under XP - and especially not crash...
fastplayer
6th April 2009, 09:14
hav the same problem with that file but some times the file plays after like 10-15 tries
Edit: works fine if i use ffshow video decoder insted of mpeg video decoder so i think the decoder i broken
My guess is it's the renderer because SVN version works with the internal MPEG-1 decoder and the one from Windows itself.
Mercury_22
6th April 2009, 10:53
WMV 1/2/3 (Windows Media Video 9) it's BROKEN ! (it's playing just the sound with NO video)
EDIT: Strange thing:
If i reset MPC-HC's render settings to default it's playing WMV 1/2/3 BUT after restarting, it's NOT playing WMV 1/2/3 and after another reset of render settings to default it's playing again and so on :(:confused:
No such problem with SVN
EDIT 2: Version 21 it's the last proper working version !
dillee1
6th April 2009, 15:52
mpc video decoder h.264@1080p bug?
card: ATI HD2400 Pro PCI
I got this card hardware accelerated with PDVD8 h.264 decoder fine.
MPCVideoDec.ax (1.1.0.0, 1.2.908.0, 1.2.1010.0, 1.2.1014.0) all giving a blackscreen with h.264@1080p.
Slightly lower res e.g. 1920x816 do works however.
Is this a bug on the mpc video decoder?
neoufo51
6th April 2009, 16:07
edit:
Casshern
6th April 2009, 20:08
Hi,
regarding the new flush gpu options - i have a theory how the ATI 2x00 problems might be related. Lets go back in the pre V18 versions which had the jumping frames when using vmr9 renderless, DXVA under Win XP. Here somehow the buffers where the video gets decoded to were switched before decoding was finished. It takes about 20ms for a regular 1920x1080 high bit rate 23.976 stream per frame with the 2x00 AGP ATI DXVA engine. At a screen refresh of 47.952 - this should be fast enough. But and now here is my theory - the pre V18 versions switched buffers always every vsync. This is critcial when the DXVA engine uses more than approx 20.5 ms which is the 47.952 hz frame time. Whenever that happened you get the stuttering, jumping frames corruption. That's also the reason why on newer cards, the problem was non-existent, they were fast enough to always render within one screen refresh cycle.
Now fast forward to the newest beliyaal build with wait for GPU buffer flush enabled. The renderer waits before switching buffers and the aforementioned problems are gone. But on some titles you get reproducable judder in some scenes. Could it be that if the "wait for gpu flush" takes longer then one screen refresh, beliyaals renderer code gets slightly confused as it expects DXVA frames to always arrive in time for the next screen refresh?
This would explain why newer cards hide the problem, and others can't reproduce on pcx boards which might just be a tic faster? But it also means it is easily solvable by checking if during dxva decoding a vsync occured and just skip buffer changing in this case (if additionally the decoded frame is still in time for its next slot). I could imagine that if wait for gpu flush extends over the next vsync, beliyaals build still executes its normal buffer changing - as it should for software decoding, but not with DXVA
Any ideas?
tetsuo55
6th April 2009, 22:09
Below is a screen of my results, limited testing for now lead to the same results time and time again.
*Default settings
*Optimal settings
*Optimal settings with wait for gpu flush enabled
http://img25.imageshack.us/img25/3605/v24b.th.png (http://img25.imageshack.us/my.php?image=v24b.png)
EDIT:
result worsen as i increase the number of EVR buffers
DeepBeepMeep
7th April 2009, 00:00
I still have an Audio/Video sync problem at 23.976Hz when seeking.
The green line is quite far away from the purple line although there doesn't seem to be any jitter.
My config is XP / EVR / Nvidia 8600 GTS / Reclock / Ffs
http://img24.imageshack.us/img24/4675/shotlep.th.jpg (http://img24.imageshack.us/my.php?image=shotlep.jpg)
I don't have the sync problem neither with VMR9 (although there is a little bit of jitter) nor with EVR at 72Hz.
I would be grateful if could fix that or give me a hint how to make it work.
Thanks
Beliyaal
7th April 2009, 09:56
I still have an Audio/Video sync problem at 23.976Hz when seeking.
The green line is quite far away from the purple line although there doesn't seem to be any jitter.
My config is XP / EVR / Nvidia 8600 GTS / Reclock / Ffs
http://img24.imageshack.us/img24/4675/shotlep.th.jpg (http://img24.imageshack.us/my.php?image=shotlep.jpg)
I don't have the sync problem neither with VMR9 (although there is a little bit of jitter) nor with EVR at 72Hz.
I would be grateful if could fix that or give me a hint how to make it work.
Thanks
You need to increase EVR buffers to at least 4. I think I will change the minimum to 4 instead of 3
DeepBeepMeep
7th April 2009, 12:46
You need to increase EVR buffers to at least 4. I think I will change the minimum to 4 instead of 3
Thanks for your answer, I will check that when I am at home. However, it is a bit strange the stats say that 2 buffers are already free anyway.
Morevoer, I am a bit concerned that this will increase the CPU usage. I had noticed in the past that for instance 10 buffers increase dramatically the CPU usage: e.g: 20% usage for 3 buffers while 70% for 10.
Is that normal?
tetsuo55
7th April 2009, 13:15
Thanks for your answer, I will check that when I am at home. However, it is a bit strange the stats say that 2 buffers are already free anyway.
Morevoer, I am a bit concerned that this will increase the CPU usage. I had noticed in the past that for instance 10 buffers increase dramatically the CPU usage: e.g: 20% usage for 3 buffers while 70% for 10.
Is that normal?
Yeah i too have questions about this.
How does EVR buffering work and what is the effect on CPU and RAM? How does it relate to jitter/judder/dropped frames?
How can i calculate the ideal number of buffers for my hardware?
Do i have to take subtitles into account?
My guess is:
*Cpu speed and Ram = Maximum number of buffers
*Devide buffers evenly(or unevenly) over EVR and Subtitles
tetsuo55
7th April 2009, 13:26
Below is a screen of my results, limited testing for now lead to the same results time and time again.
*Default settings
*Optimal settings
*Optimal settings with wait for gpu flush enabled
http://img25.imageshack.us/img25/3605/v24b.th.png (http://img25.imageshack.us/my.php?image=v24b.png)
EDIT:
result worsen as i increase the number of EVR buffers
More info, Casshern might be on to something.
The result above seems to happen mostly around scene changes and very difficult to render scenes.
Also when this happens i notice the "refresh rate" value slipping away from the actual value. In some cases MPC will lose it completely and display the Ind# error instead
Mark_A_W
7th April 2009, 14:13
Hi,
regarding the new flush gpu options - i have a theory how the ATI 2x00 problems might be related. Lets go back in the pre V18 versions which had the jumping frames when using vmr9 renderless, DXVA under Win XP. Here somehow the buffers where the video gets decoded to were switched before decoding was finished. It takes about 20ms for a regular 1920x1080 high bit rate 23.976 stream per frame with the 2x00 AGP ATI DXVA engine. At a screen refresh of 47.952 - this should be fast enough. But and now here is my theory - the pre V18 versions switched buffers always every vsync. This is critcial when the DXVA engine uses more than approx 20.5 ms which is the 47.952 hz frame time. Whenever that happened you get the stuttering, jumping frames corruption. That's also the reason why on newer cards, the problem was non-existent, they were fast enough to always render within one screen refresh cycle.
Now fast forward to the newest beliyaal build with wait for GPU buffer flush enabled. The renderer waits before switching buffers and the aforementioned problems are gone. But on some titles you get reproducable judder in some scenes. Could it be that if the "wait for gpu flush" takes longer then one screen refresh, beliyaals renderer code gets slightly confused as it expects DXVA frames to always arrive in time for the next screen refresh?
This would explain why newer cards hide the problem, and others can't reproduce on pcx boards which might just be a tic faster? But it also means it is easily solvable by checking if during dxva decoding a vsync occured and just skip buffer changing in this case (if additionally the decoded frame is still in time for its next slot). I could imagine that if wait for gpu flush extends over the next vsync, beliyaals build still executes its normal buffer changing - as it should for software decoding, but not with DXVA
Any ideas?
I have a 2600XT and don't seem to have any problems like this.
I do not use DXVA (why in this day and age? My CPU laughs at all video material).
But it's not 100% perfect, which brings me to my next post...
Mark_A_W
7th April 2009, 14:18
I'm getting 99.9% SMOOTH playback. It's marvelous.
But once or twice a movie I get a glitch where it seems to repeat a second of so of audio, and the screen jumps to resync. It's very noticeable.
I thought it was the Convolver audio filter I am running, but I disabled that and it still happens. I don't think I'm out of CPU either.
My setup:
Reclock (no vsync correction enabled)
MPC internal splitter
MPC internal decoder for VC-1
CoreAVC for AVC
Ffdshow video loaded to perform RGB HQ conversion
Madflac for flac, ffdshow audio for other audio
Convolver filter (removed for testing)
Is it just me getting a very occasional coarse glitch in otherwise perfectly smooth playback?
Repeat of audio? Very strange, never encountered it.
Casshern
7th April 2009, 16:08
I have a 2600XT and don't seem to have any problems like this.
I do not use DXVA (why in this day and age? My CPU laughs at all video material).
But it's not 100% perfect, which brings me to my next post...
The problem is related to DXVA decoding - unfortunatly my machine is not fast enough for software decoding of high bitstream h264 bd material from a bd drive. Not even with core avc.... it's a lowly X2 4600+ overclocked. But still with dxva the judder spikes shouldn't happen. i was just pointing out it could be a bug, which is only showing on the slower ATI boards.
diman1982
7th April 2009, 19:24
i tested this version and found out smth intresting. On vista 32bit, my nvidia 9500gt has modes 23hz and 24hz. i started mkv in this version and enabled monitoring(ctrl+j). And i discovered that 23hz = 23.962hz and 24hz = 24.000hz. That's why with both of this modes every 70-80 seconds i have either 1 double frame or 1 skipped frame. My 9500gt is not working with powerstrip. Nvidia 9 series sucks in 24p mode.
So the question to Ati hd4xxx owners - can you set in your drivers something really close to 23.976(to minimize skipped/doubled frames)? And please run monitoring and post here your real refresh rate in 24p mode.
And what about nvidia gts250 or gtx series. Have they corrected 24p mode or they just don't care?(i love cuda function in nvidia)
Beliyaal
7th April 2009, 19:48
i tested this version and found out smth intresting. On vista 32bit, my nvidia 9500gt has modes 23hz and 24hz. i started mkv in this version and enabled monitoring(ctrl+j). And i discovered that 23hz = 23.962hz and 24hz = 24.000hz. That's why with both of this modes every 70-80 seconds i have either 1 double frame or 1 skipped frame. My 9500gt is not working with powerstrip. Nvidia 9 series sucks in 24p mode.
So the question to Ati hd4xxx owners - can you set in your drivers something really close to 23.976(to minimize skipped/doubled frames)? And please run monitoring and post here your real refresh rate in 24p mode.
And what about nvidia gts250 or gtx series. Have they corrected 24p mode or they just don't care?(i love cuda function in nvidia)
I have a 4870x2 and you can only select 24 Hz in the drivers. Powerstrip works with it however, and I have almost exactly 23.976 Hz realized, with no stuttering during a movie.
diman1982
7th April 2009, 20:35
I have a 4870x2 and you can only select 24 Hz in the drivers. Powerstrip works with it however, and I have almost exactly 23.976 Hz realized, with no stuttering during a movie.
and if you set 24hz in drivers(with no powerstrip) what exact value(23.xxx) monitoring(ctrl+j) shows?
Mark_A_W
7th April 2009, 22:09
The problem is related to DXVA decoding - unfortunatly my machine is not fast enough for software decoding of high bitstream h264 bd material from a bd drive. Not even with core avc.... it's a lowly X2 4600+ overclocked. But still with dxva the judder spikes shouldn't happen. i was just pointing out it could be a bug, which is only showing on the slower ATI boards.
Interesting, I had an Opteron 165 at 2.4ghz (same as X2 4400+) and I just got by in software.
Beliyaal
7th April 2009, 23:21
and if you set 24hz in drivers(with no powerstrip) what exact value(23.xxx) monitoring(ctrl+j) shows?
Between 23.99981 and 24.00020
Basically 24 Hz exactly.
Casshern
7th April 2009, 23:53
Hi did some more testing on the gpu flush settings and found this:
1) The 2x00 AGP Problem is definatly related to "wait for GPU flush". Without this option you get occasional jumping frames, corruption etc. Its more pronounced on some streams (especially vc-1).
2) Without "Flush GPU before Vsync" i get no control over vsync (evr cp, alt vsync, accurate vsync). As soon as this option is enabled (even without wait for GPU flush) i get vsync controll and can move vsync up and down by changing the vsync offset
3) Judder spikes (vmr9 rl, evr cp) - without wait for GPU Flush everything is fine here (but see1). With GPU Flush i get occasional judder (some titles never judder others do every couple of min).
Conclusion: Something "wait for GPU flush" related is not working. The wait could plainly be to long - but turning off shaders does not make a difference, overclocking the card by 20% does not make a difference and also vmr7, overlay, and powerdvd with vmr9 renderless works fine. Going from 47.952 to 23.976 screen refresh also did not solve the problem - here i have to discard the theory from the last post. Either the ATI driver does something strange or the renderer could handle gpu flushing better.
regards,
Casshern
Between 23.99981 and 24.00020
Basically 24 Hz exactly.
yesgrey
8th April 2009, 00:18
My 9500gt is not working with powerstrip. Nvidia 9 series sucks in 24p mode.
Maybe not...;)
Just tell me which resolution you need with 23.976Hz, and maybe I can help you...
As a side note, what you really want is 24.0/1.001Hz, and not 23.976Hz.
Maybe not...;)
Just tell me which resolution you need with 23.976Hz, and maybe I can help you...
As a side note, what you really want is 24.0/1.001Hz, and not 23.976Hz.
Oh yes, such precision! 24/1.001 is higher than 23.976 by whopping 0.0001%. Hint: mkv file itself may not be exact 24/1.001. You can just use timecodes with Assume 23.976 and that works just fine.
diman1982
8th April 2009, 09:09
Maybe not...;)
Just tell me which resolution you need with 23.976Hz, and maybe I can help you...
As a side note, what you really want is 24.0/1.001Hz, and not 23.976Hz.
you intrigued me :)
i need only 1080p(my lcd is fullhd)
so how can i set something really close to 23.976? (may be i'm using powerstrip not properly, every attempt in changing refresh in 24hz zone results in black screen-out of sync)
i think, if it even will be 23.974-23.978 i will be happy(it means one skipped/doubled frame in 10-15 minutes), that would be a complete 24p-problem decision for me.
Leak
8th April 2009, 09:42
so how can i set something really close to 23.976? (may be i'm using powerstrip not properly, every attempt in changing refresh in 24hz zone results in black screen-out of sync)
Well, that's an indication that your TV just can't cope with 23.976 Hz - try using a multiple of it, like 47.952 Hz...
diman1982
8th April 2009, 09:54
Well, that's an indication that your TV just can't cope with 23.976 Hz - try using a multiple of it, like 47.952 Hz...
so, if i connect a brand new bluray player to my brand new panasonic lcd(manual says, it can accept 1080/24p), i will se black screen, right(assuming that bluray outputs 23.976 exactly)?:)
yesgrey
8th April 2009, 09:59
Oh yes, such precision! 24/1.001 is higher than 23.976 by whopping 0.0001%.
It's more easy to get 24/1.001 than 23.976.;)
yesgrey
8th April 2009, 10:08
you intrigued me :)
i need only 1080p(my lcd is fullhd)
so how can i set something really close to 23.976?
Can you please send me the timings for your current 1920x1080@24?
Just open powerstrip and tell me all the values for horizontal and vertical geometries (only the pixel values).
I can't promise anything... since it's for a lcd maybe it will only work with 24.000Hz... Let's see what we can do with it.;)
diman1982
8th April 2009, 10:24
I set my drivers to 23hz mode, opened pstrip and copied timings:
PowerStrip timing parameters:
1920x1080=1920,638,44,148,1080,4,5,36,74129,512
Generic timing details for 1920x1080:
HFP=638 HSW=44 HBP=148 kHz=27 VFP=4 VSW=5 VBP=36 Hz=24
VESA detailed timing:
PClk=74,13 H.Active=1920 H.Blank=830 H.Offset=622 HSW=44 V.Active=1080 V.Blank=45 V.Offset=4 VSW=5
Linux modeline parameters:
"1920x1080" 74,129 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync
and then i switched drivers to 24hz mode:
PowerStrip timing parameters:
1920x1080=1920,638,44,148,1080,4,5,36,74250,512
Generic timing details for 1920x1080:
HFP=638 HSW=44 HBP=148 kHz=27 VFP=4 VSW=5 VBP=36 Hz=24
VESA detailed timing:
PClk=74,25 H.Active=1920 H.Blank=830 H.Offset=622 HSW=44 V.Active=1080 V.Blank=45 V.Offset=4 VSW=5
Linux modeline parameters:
"1920x1080" 74,250 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync
iron2000
8th April 2009, 13:39
Is it that for the jitters and stutters, the ultimate cure is setting the refresh rate to a multiple of the video frame rate?
As for the latest build, I like the addition of the default and optimal renderer mode settings.
Working well so far.
tetsuo55
8th April 2009, 14:03
Is it that for the jitters and stutters, the ultimate cure is setting the refresh rate to a multiple of the video frame rate?
This is true for any moving image (including games and such)
It's more easy to get 24/1.001 than 23.976.;)
In MKV? Not really, as I've told you already even myself in some cases just used AssumeFPS 23.976 in the timecodes file if the content wasn't VFR.
This is true for any moving image (including games and such)
Not exactly. I play online 3D shooters with fps floating around my refresh rate, however it is almost never exactly same (i.e. 100Hz). However due to vsync i dont' have any image artefacts whatsoever.
loretta80
8th April 2009, 19:01
is there a mirror for the binaries? download is broken.
fastplayer
8th April 2009, 19:16
is there a mirror for the binaries? download is broken.
Works fine here.
loretta80
8th April 2009, 19:19
:thanks: now it works
diman1982
8th April 2009, 19:19
is there a mirror for the binaries? download is broken.
take link into flashget and wait 30-40 seconds. it is slow but it works.
loretta80
8th April 2009, 19:32
Known Bug?: No OSD in EVR CP while D3D Fullscreenmode. WinXP 32bit.
Same behavior in mplayer hc 1041
bonanza
8th April 2009, 22:53
links broken :(
yesgrey
8th April 2009, 23:54
In MKV?
No. In the graphics card.
I set my drivers to...
If you want, try the following, but remember that you are doing it at your own risk. I will not be responsible in case any damage occurs to you or to your equipment...
Go to your nvidia drivers control panel and create a custom resolution for 1920x1080@24.
I have created two sets of timings for you to try.
Try this first:
9739
If when you press test your lcd does not work, try this other set:
9740
If none works, let me know so I can try to calculate other sets.;)
If these timings work, you should get an exact refresh rate of 24.0/1.001 Hz.
iron2000
9th April 2009, 05:56
I have an ATI card(HD2600 Pro) and have been using Powerstrip to set custom resolutions.
Anyone knows if theres a way to do it in the CCC?
Found out that optimal renderer setting crashes the player each time on open.
Setting and using default settings is ok.
diman1982
9th April 2009, 17:45
yesgrey3
sory, but none of these works. My Panny lcd is out of sync.
Rectal Prolapse
9th April 2009, 19:12
yesgrey3: Just curious - how did you calculate the alternate timings? I can't quite hit 59.94 on my NVIDIA 8800GT with my Benq W5000 projector. Any pointers would be greatly appreciated!
leeperry
9th April 2009, 19:22
I can't quite hit 59.94 on my NVIDIA 8800GT
like this you mean?
http://www.image-load.eu/out.php/t157160_hr.png (http://www.image-load.eu/out.php/i157160_hr.png)
that's on a GF9600/XP SP3, I've just updated Reclock so the ppm didn't reach 0.17 yet.
well, it takes a good amount of patience mostly :)
yesgrey
9th April 2009, 20:02
yesgrey3
sory, but none of these works. My Panny lcd is out of sync.
I thought that they wouldn't... I will try to get you another timings, but you'll have to wait a little more...
yesgrey3: Just curious - how did you calculate the alternate timings? I can't quite hit 59.94 on my NVIDIA 8800GT with my Benq W5000 projector. Any pointers would be greatly appreciated!
Some time ago I've wrote a little program to find the values that could give exact refresh rates. I put them in powerstrip to get a set of timings, and then it's just copy paste them to a custom resolution in nvidia's drivers. I'm thinking in making my little program available and writing a tutorial on how to do it, but didn't have find the time yet...
Post your current working timings and tell me which resolution you need, maybe I can create a working set for you...
Rectal Prolapse
9th April 2009, 20:21
The best I can get is 59.951 hz (as reported by Reclock) at 1920x1080p. Powerstrip 3.85 actually works for me, while earlier ones didn't, on my NVIDIA 8800GT. It's very finicky though - sometimes clicking on the timing up/down arrows don't work at all, and I have to restart powerstrip to get them to work!
Anyhow, I would be interested in your little program. :) I'll try to get my timings posted later tonight. Do you take the custom timings and enter them in the registry for the NVIDIA drivers?
leeperry: Heh, that's at 1280x768 - which I can hit 59.94 fairly easily! Other resolutions is tougher though hehe.
BTW, I can't wait for Beliyaal SVN 1043 version - 1043 fixes the blu-ray subtitle transparency issue.
yesgrey
9th April 2009, 20:42
I'll try to get my timings posted later tonight. Do you take the custom timings and enter them in the registry for the NVIDIA drivers?
No. The idea is creating a custom resolution in the nvidia drivers... I need your timings to try to find some similar values, because the displays don't sync to all the available combinations that give the exact refresh rates...
Rille
9th April 2009, 20:49
I'm unable to get D3DFS gui to work with 10-bit color. Using Vista x86 SP1, EVR custom, no Aero, catalyst 9.3. It seems it's displayed behind the video as the mousepointer changes to a standard arrow when i move it where the meny should display. Disabling 10-bit solves the problem.
leeperry
9th April 2009, 21:37
No. The idea is creating a custom resolution in the nvidia drivers... I need your timings to try to find some similar values, because the displays don't sync to all the available combinations that give the exact refresh rates...
did you improve it since the last time we tried? because the real world refresh rate also depend on the CPU speed...the timings you gave me did not work at that time.
even pstrip isn't accurate on ATi, for the very same reason. very often you have to input 48.002 to get 48.000 in Reclock :devil:
it's a matter of trial & error on ATi, and it's a lot more complicated on nvidia the further you lower the refresh rate....but w/ a great deal of patience you can reach any freq on either brands :)
Beliyaal
9th April 2009, 21:57
I'm unable to get D3DFS gui to work with 10-bit color. Using Vista x86 SP1, EVR custom, no Aero, catalyst 9.3. It seems it's displayed behind the video as the mousepointer changes to a standard arrow when i move it where the meny should display. Disabling 10-bit solves the problem.
D3DFS gui isn't supported in 10 bit mode. It's a limitation in D3D.
Beliyaal
9th April 2009, 21:58
did you improve it since the last time we tried? because the real world refresh rate also depend on the CPU speed...the timings you gave me did not work at that time.
even pstrip isn't accurate on ATi, for the very same reason. very often you have to input 48.002 to get 48.000 in Reclock :devil:
it's a matter of trial & error on ATi, and it's a lot more complicated on nvidia the further you lower the refresh rate....but w/ a great deal of patience you can reach any freq on either brands :)
Couldn't it be that the clock "QueryPerformanceTimer" is the one in error. It wouldn't matter if you got Reclock to display 48.000 Hz as long as the audio clock was faster as well.
yesgrey
9th April 2009, 21:59
did you improve it since the last time we tried? because the real world refresh rate also depend on the CPU speed...the timings you gave me did not work at that time.
No, but for me they always work... My program gives theoretical values. The real world values will depend on the graphics card crystal temperature... but as I said, for me it always works.:)
If it could help other people, it would be great.
leeperry
9th April 2009, 22:04
The real world values will depend on the graphics card crystal temperature
I've put a huge heatsink on my 27MHz PLL...does it count? :D
well, If I ever so slightly change the CPU/GPU speeds, whatever ATi or nvidia....the real world refresh rates always change :scared:
reason why Seb.26 asked Rik Wang from the pstrip support team to add a search engine into pstrip ;)
DeepBeepMeep
9th April 2009, 22:05
yesgrey3
sory, but none of these works. My Panny lcd is out of sync.
Using trial and error I have managed to get 23.977Hz on my Pany LCD. Here are the settings using the Classic Nvidia Panel:
http://img113.imageshack.us/img113/5760/23976pj.th.jpg (http://img113.imageshack.us/my.php?image=23976pj.jpg)
yesgrey
9th April 2009, 22:21
reason why Seb.26 asked Rik Wang from the pstrip support team to add a search engine into pstrip ;)
My little program works very similar to powerstrip search engine, the only difference is my program outputs a file with all available combinations that allow the exact refrsh rates.
leeperry
9th April 2009, 22:25
My little program works very similar to powerstrip search engine, the only difference is my program outputs a file with all available combinations that allow the exact refrsh rates.
ah well, show us the green then :D
yesgrey
9th April 2009, 23:11
diman1982,
Here are more 4 sets. This time I will not post the images. I will only post the numbers and you only have to change them and try. In all sets the refresh rate should be set to 23.976Hz.
Horizontal - FP / Active / Total / Sync width / Sync pol
Vertical - FP / Active / Total / Sync width / Sync pol
Set 1:
Horizontal - 638 / 1920 / 2750 / 44 / +
Vertical - 4 / 1080 / 1092 / 3 / +
Set 2:
Horizontal - 638 / 1920 / 2750 / 44 / +
Vertical - 4 / 1080 / 1183 / 94 / +
Set 3:
Horizontal - 628 / 1920 / 2730 / 44 / +
Vertical - 4 / 1080 / 1100 / 11 / +
Set 4:
Horizontal - 628 / 1920 / 2730 / 44 / +
Vertical - 4 / 1080 / 1155 / 66 / +
DeepBeepMeep,
If you want, you could also try the timings above. Maybe one of them could work to you...
Remember that you are at your own risk...
Leak
10th April 2009, 10:41
My little program works very similar to powerstrip search engine, the only difference is my program outputs a file with all available combinations that allow the exact refrsh rates.
...while PowerStrip copies that list to the clipboard... :D
Try pasting into a text editor when it's finished, or while it's running... ;)
np: Amorphous Androgynous - Opus Of The Black Sun (The Peppermint Tree & The Seeds Of Superconciousness)
yesgrey
10th April 2009, 11:00
...while PowerStrip copies that list to the clipboard... :D
Try pasting into a text editor when it's finished, or while it's running... ;)
Thanks, didn't know that. The only time I tested it it hasn't worked, probably because I have a GF 8600GT... What's your card?
Leak
10th April 2009, 11:01
Thanks, didn't know that. The only time I tested it it hasn't worked, probably because I have a GF 8600GT... What's your card?
2 ATI Radeon 4850s.
leeperry
10th April 2009, 11:20
Thanks, didn't know that. The only time I tested it it hasn't worked, probably because I have a GF 8600GT... What's your card?
but it's not a search engine to make the DX routines happy(pstrip camera/reclock), it searches for "perfect" theoritical hardware freq....which is a whole different story.
apparently the way Reclock measures the refresh rate is just plain wrong, Kazuya from HCFR posted some screenshots...his LCD screen has a very accurate OSD and when that "perfect theoritical" pstrip computing says 48Hz, the screen says so too...but Reclock gives 48.002 :o
if he gets 48.000 in Reclock, the screen says 47.998(like pstrip regular custom timings), and his Sanyo Z5 pj is only happy w/ theoritical 50Hz(it stutters w/ 50.000Hz in Reclock)
since the beginning Rik Wang has always been clear that measuring the refresh rate through DX will not be accurate(compared to his oscilloscope readings)...so prolly when you're watching a movie at 48.000 in Reclock, it's actually sending 47.998 to your display :sly:
diman1982
10th April 2009, 18:57
yesgrey3
unfortunately, none of these sets synced with my lcd tv. But i managed to get 23.985hz(tried to set 23.976 in manual mode in custom resolutions). BTW, i switched back to winxp. As it turned out, vista gave me nothing in terms of decent 24p mode. The default 24hz mode is actually 23.962hz, so, 23.985 is closer to 23.976. Now i have one doubled frame in 2 minutes. It is a progress :)
It is very strange to me - nvidia made official 24hz mode in their official control panel, but why? for whom? if it doesnt work properly! If you can't set 23.976 in most cases.
i dont know if it is a driver or gpu problem, but it is coming from geforce 8 series. And the most strange thing for me that nvidia is doing NOTHING to fix it!
yesgrey
10th April 2009, 19:14
But i managed to get 23.985hz(tried to set 23.976 in manual mode in custom resolutions).
Can you give me the times for that?
You can also try the sets I gave you with a negative horizontal Sync polarity, instead of the referred positive.
Don't blame nvidia, it should be a problem with the lcd set... it only is able to sync to a very narrow band...
diman1982
10th April 2009, 20:26
Can you give me the times for that?
You can also try the sets I gave you with a negative horizontal Sync polarity, instead of the referred positive.
Don't blame nvidia, it should be a problem with the lcd set... it only is able to sync to a very narrow band...
one strange thing with it. First i switch to manual, then i change desired refresh to 23.976(leaving other settings untoch), press test button, it syncs, and i am back to main custom resolution screen. But when i press edit my new custom res, i see that now the sync mode is DMT and all value boxes are grey(you can't change them). Values:
horizontal - 632, 1920, 2744, 44, +, 27.03(it is scan freq)
vertical - 4, 1080, 1125, 5, +, 74.16
desired freq - 24.000 (grey box)
actual freq - 24.023.
OK, now with this custom freq i run beliyaals mpchc and monitoring(ctrl+j) tells me that refresh is 23.985
Spec-Chum
10th April 2009, 20:44
@Beliyaal
Sorry to be a pain mate, but what sdk versions so you use? I get compile errors trying to build using your patch against SVN. Can't remember error exactly, as I've gone back to SVN version now, but it was in one of the DX*AllocatorPresenter files in src\apps\mplayerc.
regards
yesgrey
10th April 2009, 21:24
But when i press edit my new custom res, i see that now the sync mode is DMT and all value boxes are grey(you can't change them).
It's easy. Just switch the timing mode to "auto" and the correct timing values appear in the boxes. Then, if you just want to edit them, switch to manual.
Yes, I think it's stupid, but that's the way it's working...;)
Please give the values after switching to auto. The others are not correct...
diman1982
10th April 2009, 22:01
It's easy. Just switch the timing mode to "auto" and the correct timing values appear in the boxes. Then, if you just want to edit them, switch to manual.
Yes, I think it's stupid, but that's the way it's working...;)
Please give the values after switching to auto. The others are not correct...
after switching to auto
horiz - 632, 1920, 2744, 44, +, 26.97
vert - 4, 1080, 1125, 5, +, 74.01
desired freq - 24.000
actual freq - 23.974
(but beliyaal monitoring still gives me 23.985 as an actual frequency)
tested all your timing sets(with both + and -) - no good results
yesgrey
10th April 2009, 22:29
Here are a few more sets...:D
Set 1:
Horizontal - 632 / 1920 / 2750 / 44 / +
Vertical - 4 / 1080 / 1092 / 5 / +
Set 2:
Horizontal - 632 / 1920 / 2750 / 44 / +
Vertical - 4 / 1080 / 1183 / 5 / +
Set 3:
Horizontal - 632 / 1920 / 2730 / 44 / +
Vertical - 4 / 1080 / 1100 / 5 / +
Set 4:
Horizontal - 632 / 1920 / 2730 / 44 / +
Vertical - 4 / 1080 / 1155 / 5 / +
Set 5:
Horizontal - 30 / 1920 / 2002 / 44 / +
Vertical - 4 / 1080 / 1125 / 5 / +
Set 6:
Horizontal - 632 / 1920 / 2744 / 44 / +
Vertical - 4 / 1080 / 1816 / 5 / +
yesgrey
10th April 2009, 22:31
actual freq - 23.974
(but beliyaal monitoring still gives me 23.985 as an actual frequency)
What really matters is the actual freq value.;)
kumi
11th April 2009, 07:27
I have to use ffdshow subtitle support, because I also have tearing problems with the internal subtitle renderer. Some observations on .ASS subtitle Vsync issues using the MPC-HC internal renderer on my computer:
I don't get any dropped or skipped frames using ffdshow subtitle renderer.
Vsync tear position moves down when displaying a subtitle line and animation is not disabled. Tear position moves back up to "normal" when subtitle line ends. Happens on all subtitles; with or without effects.
The larger the subtitle texture resolution, the farther down the Vsync tear position moves.
Combining VMRFlushGPUBeforeVSync=1 and VMRFlushGPUWait=1 helps somewhat: the tear position only moves down for a brief period (1 frame) on certain subtitles. Other subtitles aren't affected. Doesn't seem to depend on complexity of karaoke effects or anything else like that.
If subtitle animation is disabled, VSYNC tear position only moves down during one frame (usually when the subtitle line display time ends.)
(WinXPSP3, MPC-HC Beliyaal ver24 (Optimal Renderer Settings), EVR CP, Reclock 1.8.4.2)
DeepBeepMeep
11th April 2009, 11:43
I have noticed as well that using the internal subtitle engine that I have some judder that doens't exist with when I just use the ffdshow subtitle engine (with EVR and VMR9).
I think this is related to the fact that the subtitles of the internal engine are merged using a video card mixer (which allows to have subtitles on DXVA) whereas the ffdshow subtitles are printed directly on the image .
So obviously the mixer creates some interferences with the anti judder algorithm. I would be great if this could be fixed since a big advantage of mpc subtitle engine is that it offers the ability to have both DXVA and subtiles. Most other players don't offer this ability (e.g: zoomplayer).
Jong
11th April 2009, 12:24
A week away and so many changes! Can anyone help?
Am I right nothing has been done that fixes VMR9 stutter due to synchronised frame rate and refresh rate? If I seek a few times with "optimal" settings I still get continuous judder when the timing is wrong.
What do all the new settings do?! I have left all the GPU flush settings at default and when alternate vsync and vsync are off all seems to wrok as before in D3D mode (Reclock can control vsync). I do not know if these settings are ineffective when not using alternate vsync
I also do not know what the "desktop composition" setting does (or at least the words make sense but I do not know how it relates to D3D mode).
I assume it is still best to use Reclock vsync correction with VMR9 D3D (alternate vsync off) to avoid synchronised judder. What should the other settings be when using this? Are they all ineffective or can any of them help to improve smoothness in VMR9 D3D mode.
Thanks for any advice.
Casshern
11th April 2009, 12:36
Jong,
We all are in awe of madhis new renderer and the progress with the gothplayer. The v24 of Beliyaals version still got a lot of problems. It's the most unstable version, but that's also due to the main SVN. F.e. if you play an m2ts file and drag'n'drop another m2ts in the player is often just crashes. I still use the settings which correspond to V20. I assume these are:
1)flush gpu at vblank
2)wait for gpu flush
i do not use any of the vsync options. Reclock then works as before, even though i do not use its vsync correction with mpchc. Gothplayer now does the same thing that reclock does - it manipulates the reference clock. But no sound resampling though, but if screen refresh is a near enough exact multiple many avrs can handle it.... but still audio/video desync probs.
Welcome Back!
A week away and so many changes! Can anyone help?
Am I right nothing has been done that fixes VMR9 stutter due to synchronised frame rate and refresh rate? If I seek a few times with "optimal" settings I still get continuous judder when the timing is wrong.
What do all the new settings do?! I have left all the GPU flush settings at default and when alternate vsync and vsync are off all seems to wrok as before in D3D mode (Reclock can control vsync). I do not know if these settings are ineffective when not using alternate vsync
I also do not know what the "desktop composition" setting does (or at least the words make sense but I do not know how it relates to D3D mode).
I assume it is still best to use Reclock vsync correction with VMR9 D3D (alternate vsync off) to avoid synchronised judder. What should the other settings be when using this? Are they all ineffective or can any of them help to improve smoothness in VMR9 D3D mode.
Thanks for any advice.
Amour
11th April 2009, 16:27
As always: can anybody provide a mirror link? The main one is never available for me.
Ger
11th April 2009, 20:48
Have you tried removing www from the download link (http://olofsson.info/mpchc/MPCHC_x86_svn1040_beliyaal_24.zip)? Some DNS servers seem to work better with just olofsson.info (without the www first).
Rectal Prolapse
11th April 2009, 23:03
yesgrey3:
These are my timing parameters that got me 59.944 as reported by Powerstrip (59.947 reported by Reclock):
59.944 hz:
PowerStrip timing parameters:
1920x1080=1920,88,44,148,1080,4,4,36,148230,512
Generic timing details for 1920x1080:
HFP=88 HSW=44 HBP=148 kHz=67 VFP=4 VSW=4 VBP=36 Hz=60
VESA detailed timing:
PClk=148.23 H.Active=1920 H.Blank=280 H.Offset=72 HSW=44 V.Active=1080 V.Blank=44 V.Offset=4 VSW=4
Linux modeline parameters:
"1920x1080" 148.230 1920 2008 2052 2200 1080 1084 1088 1124 +hsync +vsync
I have to have powerstrip running to get the above to work. But I have to remember to exit Powerstrip when I switch to a different refresh (like 50 hz) using NVIDIA Control Panel. Powerstrip won't let me switch to different refresh rates - it gets locked once I input the above timing parameters!
I cannot get consistent results with the 182.50 NVIDIA drivers - 90% of the time reclock reports 59.921 hz. Only once did I manage to get 59.939 when, for once in a blue moon, my Auto->Manual 59.939 NVIDIA control panel custom timing worked.
yesgrey
12th April 2009, 00:11
yesgrey3:
These are my timing parameters that got me 59.944 as reported by Powerstrip (59.947 reported by Reclock):
Here are some sets of timings for you to try. I hope you have more luck than diman1982...:)
Remember that you are on your own risk. I'm not responsible for any damage.
Use the instructions that I gave previously to diman1982 and create a custom resolution with one of these sets.
Sets 1, 2 and 3 allow you to get exact 48.0/1.001 and 60.0/1.001, you just need to set the vertical refresh rate respectivelly as 47.952Hz or 59.940Hz. Sets 4 and 5, only allow 60.0/1.001.
Set 1:
Horizontal - 34 / 1920 / 2002 / 34 / +
Vertical - 4 / 1080 / 1125 / 4 / +
Set 2:
Horizontal - 88 / 1920 / 2275 / 44 / +
Vertical - 4 / 1080 / 1100 / 4 / +
Set 3:
Horizontal - 88 / 1920 / 2275 / 44 / +
Vertical - 4 / 1080 / 1188 / 4 / +
---
Set 4:
Horizontal - 34 / 1920 / 2005 / 34 / +
Vertical - 4 / 1080 / 1144 / 4 / +
Set 5:
Horizontal - 88 / 1920 / 2200 / 44 / +
Vertical - 4 / 1080 / 1092 / 4 / +
Once again, don't worry too much with the values reported by powerstrip or reclock... with me, I always have to click two times in powerstrip camera so it can give the the correct value...
Bugs with unknown status
* DVD / interlaced playback problems (might be fixed with correction turned off, please check)
* Flash video files (flv) not working correctly (might be fixed with correction turned off, please check)
* Tearing when subtitles are animated in VMR9 (might be fixed, please check)
Seems to be fixed, or I can't reproduce with latest build 24 :)
Klaus_1250
12th April 2009, 17:44
I have noticed as well that using the internal subtitle engine that I have some judder that doens't exist with when I just use the ffdshow subtitle engine (with EVR and VMR9).
Same here, subtitles cause some slight judder :-(
Without the subs, playback is very smooth. (XP SP3, P4 3.2, 2GB, HD3850 AGP, Cat 9.4, VMR9 Renderless)
krbo
12th April 2009, 18:40
Beliyaal, your version suffers from frame dropping after a channel change on HDMI, something I described in MPC HC thread.
My HTPC uses plasma TV as the main and only screen via HDMI and if I change channel and come back (so EDID handshake starts)
your version starts to drop frames like crazy (usually then, reported fps is arround 15-17).
That's with default settings - nothing special switched on.
It's a 780G based PC (onboard Radeon HD3200), Vista 32, catalyst 9.3 (same was with 8.5), EVR custom
regular SVN before 1018 stopped to play after channel change (only audio continues) but that was fixed in later versions
Beliyaal
12th April 2009, 21:08
Beliyaal, your version suffers from frame dropping after a channel change on HDMI, something I described in MPC HC thread.
My HTPC uses plasma TV as the main and only screen via HDMI and if I change channel and come back (so EDID handshake starts)
your version starts to drop frames like crazy (usually then, reported fps is arround 15-17).
That's with default settings - nothing special switched on.
It's a 780G based PC (onboard Radeon HD3200), Vista 32, catalyst 9.3 (same was with 8.5), EVR custom
regular SVN before 1018 stopped to play after channel change (only audio continues) but that was fixed in later versions
I have looked at this now, and this problem cannot be fixed even by recreating the D3D device. The only thing that works is restarting the player. The problem only seems to manifest when desktop composition is enabled, so if you disable it in options you could work around the problem.
Probably the bug is in D3D or graphics card driver.
Kado
12th April 2009, 21:08
@Klaus_1250, DeepBeepMeep
It's known that if you are using no buffering with the internal subtitles renderer that frames are dropped when the subtitles are about to be displayed, the internal subtitle renderer displays the subtitles over the video frame using the cpu to renderer and the gpu to present them while other renderers like vobsub and ffdshow mix them with the frame before presentation. The dropped frames may be related to the fact that they are rendered and presented in real time. Use buffering to reduce/eliminate dropped frames and if you want to keep the effects uncheck "Disable animation".
Klaus_1250
13th April 2009, 00:05
I'm actually using buffers for subtitles. The issue seems to lie in the paint time. Display Stats adds 1-3 ms to the paint time, subs add about 10-13ms, but occasionally, subs add 20-40ms. Using more or less buffers doesn't really change that.
DeepBeepMeep
13th April 2009, 00:38
@Klaus_1250, DeepBeepMeep
It's known that if you are using no buffering with the internal subtitles renderer that frames are dropped when the subtitles are about to be displayed, the internal subtitle renderer displays the subtitles over the video frame using the cpu to renderer and the gpu to present them while other renderers like vobsub and ffdshow mix them with the frame before presentation. The dropped frames may be related to the fact that they are rendered and presented in real time. Use buffering to reduce/eliminate dropped frames and if you want to keep the effects uncheck "Disable animation".
Thanks for the tip but I have tried many values for the buffer and I still have some issues.
My findings are so far that if the internal subtitle engine is enabled:
- one frame is skipped occasionally (although rarely)
- there is some tearing
If I do not enable the internal subtitle engine the two issues go away (it is quite obvious with the tearing).
My config: EVR Custom/XP sp3/NVIDIA GTS86000/Reclock/Coreavc(CUDA)/Ffdshow audio SPDIF
DeepBeepMeep
13th April 2009, 02:08
Here are a few more sets...:D
Set 1:
Horizontal - 632 / 1920 / 2750 / 44 / +
Vertical - 4 / 1080 / 1092 / 5 / +
Set 2:
Horizontal - 632 / 1920 / 2750 / 44 / +
Vertical - 4 / 1080 / 1183 / 5 / +
Set 3:
Horizontal - 632 / 1920 / 2730 / 44 / +
Vertical - 4 / 1080 / 1100 / 5 / +
Set 4:
Horizontal - 632 / 1920 / 2730 / 44 / +
Vertical - 4 / 1080 / 1155 / 5 / +
Set 5:
Horizontal - 30 / 1920 / 2002 / 44 / +
Vertical - 4 / 1080 / 1125 / 5 / +
Set 6:
Horizontal - 632 / 1920 / 2744 / 44 / +
Vertical - 4 / 1080 / 1816 / 5 / +
Thanks for these sets and the others. Unfortunately, none are accepted by my PAE2000.
It would be great if your tool could create a set close to the one I had posted maybe it would increase the chances that this works. Thanks again for your help.
Kaotech
13th April 2009, 08:54
Several times during movie, the frame rate go down to 19 fps, i put the movie in pause 5-6 second, i replay the movie and the frame rate go to the normal FPS (24).
I've you an idea about this ?
http://img13.imageshack.us/img13/9800/300k.png (http://img13.imageshack.us/my.php?image=300k.png)
krbo
13th April 2009, 10:28
I have looked at this now, and this problem cannot be fixed even by recreating the D3D device. The only thing that works is restarting the player. The problem only seems to manifest when desktop composition is enabled, so if you disable it in options you could work around the problem.
Probably the bug is in D3D or graphics card driver.
disabled desktop composition helps only in windowed MPC HC. At full screen it is still dropping frames.
(and there's annoying aero switching on/off)
btw this EDID problem started in regular SVN somewhere above version 900 and stopped after 1018
Casshern
13th April 2009, 10:34
I got the same probs on some movies. It is related to the wait for gpu flush - but without it one gets awful artifacts. At the moment it is unclear whether its a bug in beliyaals version or the catalyst drivers, or if theres a workaround. Also during phases where the movie only displays black - after fade to blacks f.e.. i have a strange decline in frame rate - this is reproducable on the bds of "any given sunday" and "the changeling" during title sequences. Also both bugs might not be in the renderer but already in the DXVA decoder.
Maybe faster cards do not show this behaviour, mine AGP 2600 PRO 512 MB does.
Several times during movie, the frame rate go down to 19 fps, i put the movie in pause 5-6 second, i replay the movie and the frame rate go to the normal FPS (24).
I've you an idea about this ?
http://img13.imageshack.us/img13/9800/300k.png (http://img13.imageshack.us/my.php?image=300k.png)
BatKnight
13th April 2009, 10:46
@Klaus_1250, DeepBeepMeep
It's known that if you are using no buffering with the internal subtitles renderer that frames are dropped when the subtitles are about to be displayed, the internal subtitle renderer displays the subtitles over the video frame using the cpu to renderer and the gpu to present them while other renderers like vobsub and ffdshow mix them with the frame before presentation. The dropped frames may be related to the fact that they are rendered and presented in real time. Use buffering to reduce/eliminate dropped frames and if you want to keep the effects uncheck "Disable animation".
I use buffered subtitles and have animation disabled and also suffer from the same problem.
The line of the graph is always horizontal and it glitches a little when the subtitle is drawed.
I use Vista, Aero On, 60Hz, Vsync off, EVR Custom, NV12 only.
Bat
Kaotech
13th April 2009, 11:04
I got the same probs on some movies. It is related to the wait for gpu flush - but without it one gets awful artifacts. At the moment it is unclear whether its a bug in beliyaals version or the catalyst drivers, or if theres a workaround. Also during phases where the movie only displays black - after fade to blacks f.e.. i have a strange decline in frame rate - this is reproducable on the bds of "any given sunday" and "the changeling" during title sequences. Also both bugs might not be in the renderer but already in the DXVA decoder.
Maybe faster cards do not show this behaviour, mine AGP 2600 PRO 512 MB does.
Ok i've a 4850 and catalyst 9.3, i've this bug also with Coreavc. Did you use shaders ?
Beliyaal
13th April 2009, 11:14
I use buffered subtitles and have animation disabled and also suffer from the same problem.
The line of the graph is always horizontal and it glitches a little when the subtitle is drawed.
I use Vista, Aero On, 60Hz, Vsync off, EVR Custom, NV12 only.
Bat
That is because you have VSync off. If you turn on VSync it will allways start drawing exactly after the last VSync, which will give it as much time as possible to draw the frame before the next VSync.
Is there still a reason for having VSync off for you?
Jong
13th April 2009, 11:16
I got the same probs on some movies. It is related to the wait for gpu flush - but without it one gets awful artifacts. Beliyaal,
Sorry to sound so ignorant! Some more info on these new controls would be very helpful. What exactly do they do? How do they relate to "normal" (current SVN) behaviour? Do they work at all with VMR9?
Beliyaal
13th April 2009, 11:41
Beliyaal,
Sorry to sound so ignorance! Some more info on these new controls would be very helpful. What exactly do they do? How do they relate to "normal" (current SVN) behaviour? Do they work at all with VMR9?
All settings that doesn't work in VMR9 are grayed out when VMR9 is enabled.
Flush GPU before VSync
After all drawing is competed, an event query is queried with flush flag. This will force the driver to start processing it's push buffer and render everything with the GPU. The idea here is that when Present is called to "flip" or present the back buffer to the front buffer everything should already be drawn and ready.
Flush GPU after Present
Same as above, but the idea is to force the flip to occur as soon as possible after the Present call. I'm not sure if this has any effect as Present should already do this, but this is to make sure that the Present is performed at once.
Wait for flushes
This will loop telling the driver to flush repeatedly until the event query is done. This will enable the GPU wait time statistic and make absolutely sure that the GPU has finished drawing before the Present call is made, or absolutely sure that the Present call is preformed immediately in the case of flush GPU after Present.
All these are a replacement for lock backbuffer in the current SVN. It does essentially the same thing as "Flush GPU before VSync", but with the drawback of forcing a lockable backbuffer, which has some performance and compatibly considerations.
BatKnight
13th April 2009, 12:01
That is because you have VSync off. If you turn on VSync it will allways start drawing exactly after the last VSync, which will give it as much time as possible to draw the frame before the next VSync.
Is there still a reason for having VSync off for you?
Yes, I get a more smooth play with vsync off than with on. I test it using the two bars (CTRL+T) and with vsync ON, the bars don't travel smoothly, they skip sometimes. But with vsync OFF, they travel smoothly. I can provide you 2 screenshots late at night. One with vsync ON and other with OFF. Would it be helpful?
Bat
Beliyaal
13th April 2009, 12:32
Yes, I get a more smooth play with vsync off than with on. I test it using the two bars (CTRL+T) and with vsync ON, the bars don't travel smoothly, they skip sometimes. But with vsync OFF, they travel smoothly. I can provide you 2 screenshots late at night. One with vsync ON and other with OFF. Would it be helpful?
Bat
One with VSync on would be helpful, but VSync off doesn't tell me anything as the judder is not visible in the graph with VSync off.
Have you tested this recently? I have fixed the last VSync issues just two weeks ago.
Also it might be the ATI bug that occurs with multi monitor and desktop composition. Does the problem go away if you disable desktop composition in options?
BatKnight
13th April 2009, 12:54
One with VSync on would be helpful, but VSync off doesn't tell me anything as the judder is not visible in the graph with VSync off.
Have you tested this recently? I have fixed the last VSync issues just two weeks ago.
Also it might be the ATI bug that occurs with multi monitor and desktop composition. Does the problem go away if you disable desktop composition in options?
I have the latest 9.4 drivers and your version 24. I don't use multi-monitor, just one LCD via HDMI.
I don't disable desktop composition because in my case Aero OFF gives-me noticeable tearing. Aero ON removes ALL the tearing. This is the reason I don't need your vsync. And yes, Aero OFF and Vsync ON removes the tearing, but as I said, the bars don't moove smoothly all the time.
I will post here a screenshot later.
Bat
Klaus_1250
13th April 2009, 13:24
I have fixed the last VSync issues just two weeks ago.
Haven't had time to properly investigate yet, but with the new beta-builds of the nVidia drivers (185.6x), I've seen VSync/tearing issue's return.
Beliyaal
13th April 2009, 13:31
I have the latest 9.4 drivers and your version 24. I don't use multi-monitor, just one LCD via HDMI.
I don't disable desktop composition because in my case Aero OFF gives-me noticeable tearing. Aero ON removes ALL the tearing. This is the reason I don't need your vsync. And yes, Aero OFF and Vsync ON removes the tearing, but as I said, the bars don't moove smoothly all the time.
I will post here a screenshot later.
Bat
The VSync option doesn't only affect the tearing. All anti-stuttering logic is also disabled when you disable VSync.
For example if you disable VSync and play 23.976 on a 60 Hz display you will get more stuttering.
Looking forward to your screenshot, it will hopefully explain issue!
BatKnight
13th April 2009, 14:45
Here it is:
1080p x264 MKV using internal MPC splitter:
Screen 1: Vsync OFF + FFDShow Subtitler (http://www.apsatanismo.org/images/mpc/vsync_off_ffdshow_sub.jpg)
Screen 2: Vsync OFF + FFDShow Subtitler - example 2 (http://www.apsatanismo.org/images/mpc/2vsync_off_ffdshow_sub.jpg)
Screen 3: Vsync OFF + MPC Internal Subtitler (http://www.apsatanismo.org/images/mpc/vsync_off_mpc_sub.jpg)
Screen 4: Vsync OFF + MPC Internal Subtitler - example 2 (http://www.apsatanismo.org/images/mpc/2vsync_off_mpc_sub.jpg)
Screen 5: Vsync ON + MPC Internal Subtitler (http://www.apsatanismo.org/images/mpc/vsync_on_mpc_sub.jpg)
Screen 6: Vsync ON + MPC Internal Subtitler - example 2 (CTRL+T on) (http://www.apsatanismo.org/images/mpc/2vsync_on_mpc_sub.jpg)
Screen 7: Vsync ON + MPC Internal Subtitler - example 3 (http://www.apsatanismo.org/images/mpc/3vsync_on_mpc_sub.jpg)
I've noticed that the glitch when using the internal subtitler doesn't happen on all videos.
But I've noticed that the glitch on screen 4 is bigger than screen 2 which is almost null. I don't really know if I shoud get what happens on screen 7.
I also have to confess that the straight line that vsync off provides, gives me more confort than the ups and dows that vsync on provides (even though I know it's supposed to be that way)
For example if you disable VSync and play 23.976 on a 60 Hz display you will get more stuttering.
As weird as it could sound, I can watch a whole 1080p x264 MKV movie having the line straight all the time as Screen 1 and 2 shows. I've tested minutes and minutes of non-stop-playing and it never glitches. I also would like to say that I could also get this glitch-free line of Screen 1 with MPC internal subtitler on this movie (go figure). And all this with Vsync OFF. Should this happen? You tell me... :)
With internal subtitler the glitch happens from time to time, but not on a pattern with up to -9.000 ms jitter (like in screen 3 and 4). With the subtitles off or ffdshow subtitler I may get 2, to 3 glitches with -5.000 ms jitter in the whole movie. (like screen 1 and 2)
As I've said this behaviour changes from video to video (don't know why), that's why I captured screens from 3 different 1080p x264's MKV files.
Hope these screens give you the info you need to improve your work. I've tried to provide as much detail as possible so I may have repeated myself.
I am also available to test video samples you provide that would help you even further. If that is the case, just drop the links here.
Glad to help,
Bat
Jong
13th April 2009, 18:08
All settings that doesn't work in VMR9 are grayed out when VMR9 is enabled.Thanks for all the info. What about "Desktop composition"? This is not greyed out when using VMR9.
Beliyaal
13th April 2009, 18:12
Thanks for all the info. What about "Desktop composition"? This is not greyed out when using VMR9.
This is a Vista only option to disable transparent Aero. I will gray this out on XP in future version.
Jong
13th April 2009, 18:12
Yeah. I thought so. Thanks.
Casshern
13th April 2009, 18:42
Hi Beliyaal,
the judder i am experiencing (black phases in any given sunday and the changeling / sporadic judder in casio royal) is displayed in the judder graph even when vsync is off. So the evidence is more and more pointing to GPU Flush maybe taking to long sometimes (sporadic judder in casino royal). And the DXVA decoder having problems with some vc-1 streams during black phases (changeling, any given sunday). I still think the GPU Flush code could be refined somehow to not have the sporadic judder. Without GPU Flush DXVA is totally unusable on my card, so it would be great if there was anything possible to improve the sporadic judder.
When is a new version due? The stability of the latest (maybe also SVN) is not up to par with the older versions. I get:
1) crash if playing m2ts file and drag'n'drop another m2ts file onto the mpc hc window
2) when first audio track is lpcm, audio switching to other tracks (DTS,AC3) only yields static, as if the filter doesn't know the audio is switched and interprets dts as lpcm
3)subtitles sometimes lead to judder
4)player sometimes closes itself without reason
5)seeking a lot can crash the player
Everything except for 2+3 is new to both the svn and the v24 build. V20 was a lot more stable. Also i have the impression (didn't verify yet) that some of the render settings (vsync, gpu flush) are not in effect fully before closing and restarting the video.
regards,
Casshern
One with VSync on would be helpful, but VSync off doesn't tell me anything as the judder is not visible in the graph with VSync off.
Have you tested this recently? I have fixed the last VSync issues just two weeks ago.
Also it might be the ATI bug that occurs with multi monitor and desktop composition. Does the problem go away if you disable desktop composition in options?
Hypernova
13th April 2009, 19:08
I would like to add to BatKnight comments. I also have VSync off because when I turn it on, sometime A/V sync will randomly break down and never go back together again. Sorry I can't explain this well with my English skill. The thing is when I turn VSync on, a little off-sync occur due to subtitle being display (which is kind of reasonable I guess, since I use 2560x1600 texture size) but then, sometimes, the A/V will be completely off. I can see the video is being skip trying to catch up the sound, but it can never do so.
tetsuo55
13th April 2009, 20:17
Below is a screen of my results, limited testing for now lead to the same results time and time again.
*Default settings
*Optimal settings
*Optimal settings with wait for gpu flush enabled
http://img25.imageshack.us/img25/3605/v24b.th.png (http://img25.imageshack.us/my.php?image=v24b.png)
EDIT:
result worsen as i increase the number of EVR buffers
I have made a screenshot of the same scene using SVN 1043
It looks like SVN simply skips some frames to get back in sync, (visably looks like a slight pause)
So it would appear that the new code is not recovering correctly from some problem(probably underpoweredness)
Just to be clear:
Athlon XP 2600+ @ 2ghz
ATI HD2400pro AGP
Catalyt 9.3
i'm going to test with 9.4 hopefully CCC will install this time and i can be 100% sure Vsync is application controled
http://img140.imageshack.us/img140/6260/svn1043.th.png (http://img140.imageshack.us/my.php?image=svn1043.png)
mark0077
13th April 2009, 21:03
Beliyaal,
Maybe this information is in this thread somewhere, but I have a question regarding your 0-255 output setting.
I have been trying the new madVR renderer and madshi isn't interested (yet) in updating it to include audio / video sync, vsync etc. I was hoping you could include something like his 16-bit representation of color values during conversions. My two questions about your renderer would be.
1) Would you be interested in adding this very accurate internal color representation, I suppose with the option of what bit-depth to dither down to, eg. 8bit or 10bit.
2) Does your 0-255 conversion also do colorspace conversion, ie take into account Rec 601 Rec 709 etc.
Thanks,
Mark
andyr2005
13th April 2009, 21:14
Hi,
I am new to using MPC-HC and your build of it too.
Would it be possible to have someone list what the shaders actually do, and under what siuations they are best used, and which are best enabled all the time etc.
Thanks.
ByeByeBluRay
13th April 2009, 21:32
Please keep in mind that drivers often don't do what they're supposed to. The HW companies break the rules in order to get the highest possible scores on benchmark tests, so things that *should* stall the pipeline actually don't. In my daytime life as a games programmer, I've come across this kind of thing a few times, and have had arguments with Nvidia about some of their tricks.
Now, I don't know if the current Catalyst drivers are doing anything odd, I just wanted to make sure you guys are aware of the possibility.
tetsuo55
13th April 2009, 21:53
I just finished installing 9.4
Set Vsync to YES, unless application specifies
Same problem :(
tetsuo55
13th April 2009, 22:10
I also found another thing while testing madVR.
This build uses on average 10% more cpu while rendering the same file (dixv,mp3 in avi container, ffdshow as the decoder) as the SVN
SVN: Average 15%, between 10% and 22%
Beliyaal: Average 25%, Between 19% and 35%
madVR: Stable 35%, almost no fluctuations.
cca
13th April 2009, 22:20
I just finished installing 9.4
Set Vsync to YES, unless application specifies
Same problem :(
The proper setting is NO, unless application specifies, but I suspect something else is your problem.
Klaus_1250
13th April 2009, 22:25
Catalyt 9.3
i'm going to test with 9.4 hopefully CCC will install this time...
Don't hold your breath. CCC won't install on my HD3850AGP. Neither did 9.3. Don't understand why they keep breaking it.
tetsuo55
13th April 2009, 22:28
The proper setting is NO, unless application specifies, but I suspect something else is your problem.
changed, but as expected it makes no difference
tetsuo55
13th April 2009, 22:30
Don't hold your breath. CCC won't install on my HD3850AGP. Neither did 9.3. Don't understand why they keep breaking it.
worked fine for me with the agp hotfix version
http://support.amd.com/us/kbarticles/Pages/CatalystAGPHotfix.aspx
Beliyaal
13th April 2009, 23:16
New version (Link in signature):
* Fixed: Disable desktop composition doesn't crash on XP.
* Fixed: Threading bug in media type renegotiation fixed. Should fix some stability problems.
* Fixed: Predictable output format for mixer. Instead of random, YUV formats are now preferred.
littleD
13th April 2009, 23:36
Regarding to Your bulids Beliyaal, I have to admit that ver.22 is the closest to perfect as far. Tomorrow gonna try the newest build.
Beliyaal
13th April 2009, 23:45
Hope these screens give you the info you need to improve your work. I've tried to provide as much detail as possible so I may have repeated myself.
I am also available to test video samples you provide that would help you even further. If that is the case, just drop the links here.
Glad to help,
Bat
Thanks for the screenshots. I think this is mostly a problem with subtitles. I have an idea to try out here that should eliminate these issues.
So the evidence is more and more pointing to GPU Flush maybe taking to long sometimes (sporadic judder in casino royal). And the DXVA decoder having problems with some vc-1 streams during black phases (changeling, any given sunday). I still think the GPU Flush code could be refined somehow to not have the sporadic judder. Without GPU Flush DXVA is totally unusable on my card, so it would be great if there was anything possible to improve the sporadic judder.
I'm afraid that the GPU flush is either done, or not done. I can't really change anything here. Unfortunately it seems that we either get corruption, or slow video. Could it be that the card isn't fast enough, and the corruption is when the driver tries to catch up? Adding a GPU flush makes the player decode all frames, but the frame rate cannot be maintained?
When is a new version due? The stability of the latest (maybe also SVN) is not up to par with the older versions. I get:
1) crash if playing m2ts file and drag'n'drop another m2ts file onto the mpc hc window
2) when first audio track is lpcm, audio switching to other tracks (DTS,AC3) only yields static, as if the filter doesn't know the audio is switched and interprets dts as lpcm
3)subtitles sometimes lead to judder
4)player sometimes closes itself without reason
5)seeking a lot can crash the player
1) Could be because of threading issue fixed in ver 25.
2) I'm not aware of anything changing here, but as always changing the audio stream with the internal splitter doesn't rerender the graph, so the filter doing the LPCM decoding must decode the changed to tracks as well.
3) I have some ideas about how to fix this.
4) Might be threading issue fixed in ver 25.
5) Not sure what this could be.
I would like to add to BatKnight comments. I also have VSync off because when I turn it on, sometime A/V sync will randomly break down and never go back together again. Sorry I can't explain this well with my English skill. The thing is when I turn VSync on, a little off-sync occur due to subtitle being display (which is kind of reasonable I guess, since I use 2560x1600 texture size) but then, sometimes, the A/V will be completely off. I can see the video is being skip trying to catch up the sound, but it can never do so.
I have only seen this happening with EVR buffers at minimum. Is this your case? Does it work if you raise them slightly? Could also be that you are using too much texture memory. With the screen at 2560x1600 it's eaten up quickly. Try EVR buffers at 5 and the same for subtitle buffers.
Beliyaal,
Maybe this information is in this thread somewhere, but I have a question regarding your 0-255 output setting.
I have been trying the new madVR renderer and madshi isn't interested (yet) in updating it to include audio / video sync, vsync etc. I was hoping you could include something like his 16-bit representation of color values during conversions. My two questions about your renderer would be.
1) Would you be interested in adding this very accurate internal color representation, I suppose with the option of what bit-depth to dither down to, eg. 8bit or 10bit.
2) Does your 0-255 conversion also do colorspace conversion, ie take into account Rec 601 Rec 709 etc.
Thanks,
Mark
I'm going to research if this is possible later, but for now all conversion is done by the EVR, and not in code I have control over. I have half a mind to just ditch EVR and VMR9 and do a renderer without Microsoft code interfering at all!
I also found another thing while testing madVR.
This build uses on average 10% more cpu while rendering the same file (dixv,mp3 in avi container, ffdshow as the decoder) as the SVN
SVN: Average 15%, between 10% and 22%
Beliyaal: Average 25%, Between 19% and 35%
madVR: Stable 35%, almost no fluctuations.
Unfortunately my code has to do some extra work to keep track of VSync that takes some extra CPU. If you want to minimize it:
Disable alternative VSync
Disable accurate VSync
And of course don't have the stats enabled
I will also look at optimizing some things in a future build, but for now I just want to get everything working correctly.
If you have a single CPU this might be a problem, but the renderer code is more multithreaded, so you might not see worse performance as long as you have multiple cores. Power consumption will probably be higher however.
About Radeon 2x000 AGP I think they are simply to slow or have too buggy drivers to work correctly with DXVA. I'm at a loss finding more things to try to fix this.
Beliyaal
13th April 2009, 23:48
Regarding to Your bulids Beliyaal, I have to admit that ver.22 is the closest to perfect as far. Tomorrow gonna try the newest build.
The only thing that changed is that it doesn't wait for GPU flushes by default any longer. So you might want to enable this option.
As it didn't fix the Radeon AGP issues I think I will leave it enabled by default in next version.
noee
14th April 2009, 00:19
Something is wrong with the Menu_IDs (menu handle? or ByPos?) in the Recent File List. Those below the 2nd item are checked relative to the renderer settings and selecting these menu items (from Recent Files) when a file is playing changes renderer settings.
XPSP3, CCC9.4, ATIHD2600XT, build 25.
Hypernova
14th April 2009, 02:38
I have only seen this happening with EVR buffers at minimum. Is this your case? Does it work if you raise them slightly? Could also be that you are using too much texture memory. With the screen at 2560x1600 it's eaten up quickly. Try EVR buffers at 5 and the same for subtitle buffers.
I normally use 5 for both, but recently change subtitle buffer to 20 in trying to reduce the skipping when subtitle being display. I will try 5/5 with your new build and report back later.
Casshern
14th April 2009, 08:41
I'm afraid that the GPU flush is either done, or not done. I can't really change anything here. Unfortunately it seems that we either get corruption, or slow video. Could it be that the card isn't fast enough, and the corruption is when the driver tries to catch up? Adding a GPU flush makes the player decode all frames, but the frame rate cannot be maintained?
About Radeon 2x000 AGP I think they are simply to slow or have too buggy drivers to work correctly with DXVA. I'm at a loss finding more things to try to fix this.
You did a great job already, before your builds it was unusable and now it's pretty decent. Just to put the problem into proportion:
1) The effect during black phases doesn't effect movie watching at all, as you only see a black screen, so judder does not make a difference. Also this is probably not related to GPU Flush but a MPC DXVA decoder bug. You only see it if you turn on the stats and the tearing bar
2) The occasional judder due to GPU Flush is only rarely seen. On some movies there is none! On others you get like every couple of minutes and on some scenes its more pronounced than in others. Movie watching is still fantastic overall. Its only one screen refresh that is repeated instead of showing the next frame.
3) I do not thnik it is due to speed of the card, as overclocking doesn't change it and its gone in VMR7 and Overlay. It must be something in the catalyst drivers or the way they are used. Powerdvd with reclock also does not have this problem (but others). But do not loose to much sweat over this - it works good enough, and other problems effect everybody and are more serious.
Thanks again,
Casshern
P.S.: Arrrggh, how about only flushing every 2nd refresh?
fastplayer
14th April 2009, 10:01
Another bug report:
This MPEG-1 video (http://www.speedyshare.com/410384723.html) doesn't play. Works fine with the SVN builds.
Fixed with version 25. :thanks:
tetsuo55
14th April 2009, 10:14
About Radeon 2x000 AGP I think they are simply to slow or have too buggy drivers to work correctly with DXVA. I'm at a loss finding more things to try to fix this.
I have done some research on the situation:
Hi Beliyaal.
About the HD2x00 problem, here is the short version of what i can find:
-The HD2x00 works fine if it's the PCI-E version
-The problem seems to effect all AGP ATI cards.
-The cards work (almost perfectly) fine with Commercial DXVA decoders and All supported renderers EXCEPT yours
You're basically saying now that your renderer is almost perfect(to the extent of what you know about the subject).
This can only mean 2 things:
-Your renderer is build to work perfectly on PCI-E but has issues with AGP, to find out what is wrong we need to find out what the main differences between AGP and PCI-E are besides the theoretical higher speed(which does not matter because the cards in question use a number of PCI-E lanes equal in speed to AGP).
-There is a bug in the DXVA decoders that is only revealed by your renderer(the other renderers are more friendly to this bug and conceal it)
Some more info:
-Although there are slight variations between driver versions, the results with your renderer seem to always be the same (other renderers show similar problems with some driver versions)
I forgot to test one thing though, anyone else with a AGP card willing to try?
-Display resolution lower than 1600x1000, the bug might only be visable with higher resolutions than that.
--------
AGP vs PCI-E
The difference's i could find are:
-AGP appears to have limited access to system ram, defined in the motherboard settings(appears that PCI has unlimited access to system ram?)
-AGP sideband adressing has to be enabled for it to be truly point-to-point like PCI-E?
-AGP card has a translator, it translates the AGP signal to PCI-E
Casshern
14th April 2009, 10:46
I actually do not know if only AGP boards are affected. It might be that 2x00 PCI-E suffer the same, but as there are many alternatives for PCI-E users they just buy a newer model. The only alternative for AGP is the 3850 and the RV is only marginally different, so it probably shows the same behaviour. I only talk of AGP because that's what i have and i can report on. Also some other AGP user have the same probs. I can't speak for PCI-E boards. Anyhow, without beliyaal we couldn't even use VMR9renderless with DXVA. Now we can use subtitles, DXVA the SHADERS (chroma upsampling, sharpening) -> so it has been a 99.999% improvement from showing corruption, jumping frames or just crashing. For that last 0.00001%, it might be the MPC HC DXVA decoder at fault after all - maybe it needs to intialize the DXVA engine different. Or some trick/workaround which ATI made for Cyberlink which nobody else really knows.
Thanks again Beliyaal!
I have done some research on the situation:
Hi Beliyaal.
About the HD2x00 problem, here is the short version of what i can find:
-The HD2x00 works fine if it's the PCI-E version
-The problem seems to effect all AGP ATI cards.
-The cards work (almost perfectly) fine with Commercial DXVA decoders and All supported renderers EXCEPT yours
You're basically saying now that your renderer is almost perfect(to the extent of what you know about the subject).
This can only mean 2 things:
-Your renderer is build to work perfectly on PCI-E but has issues with AGP, to find out what is wrong we need to find out what the main differences between AGP and PCI-E are besides the theoretical higher speed(which does not matter because the cards in question use a number of PCI-E lanes equal in speed to AGP).
-There is a bug in the DXVA decoders that is only revealed by your renderer(the other renderers are more friendly to this bug and conceal it)
Some more info:
-Although there are slight variations between driver versions, the results with your renderer seem to always be the same (other renderers show similar problems with some driver versions)
I forgot to test one thing though, anyone else with a AGP card willing to try?
-Display resolution lower than 1600x1000, the bug might only be visable with higher resolutions than that.
--------
AGP vs PCI-E
The difference's i could find are:
-AGP appears to have limited access to system ram, defined in the motherboard settings(appears that PCI has unlimited access to system ram?)
-AGP sideband adressing has to be enabled for it to be truly point-to-point like PCI-E?
-AGP card has a translator, it translates the AGP signal to PCI-E
fastplayer
14th April 2009, 10:56
There was - and maybe still is - a SMARTGART component of the Catalyst driver that allows to enable "Fast Write" and other AGP-related settings. For optimal performance, all settings should be enabled.
mark0077
14th April 2009, 12:09
I'm going to research if this is possible later, but for now all conversion is done by the EVR, and not in code I have control over. I have half a mind to just ditch EVR and VMR9 and do a renderer without Microsoft code interfering at all!
This sounds like the holy grail of renderers. I would guess that most of the hard work is already done, maybe you could use some of the existing color conversion work from ffdshow, maybe try and get it upto the standard of the madVR renderer.
All exciting stuff :D
cca
14th April 2009, 12:35
This sounds like the holy grail of renderers. I would guess that most of the hard work is already done, maybe you could use some of the existing color conversion work from ffdshow, maybe try and get it upto the standard of the madVR renderer.
All exciting stuff :D
Only disadvantage would be: NO DxVA, and no DVD / BluRAY playback, because these depend on some DRM crap that only M$ renderers can do.
mark0077
14th April 2009, 12:48
Only disadvantage would be: NO DxVA, and no DVD / BluRAY playback, because these depend on some DRM crap that only M$ renderers can do.
Thats.... bad.... No wonder madVR or Haali can't play my backed up DVD's, strangely though only when ffdshow is in the chain. I get a macrovision protection error.
I guess it would cost $$ to get the licences to be able to play these in any new renderer.
I suppose the existing beliyaal evr-custom presentation renderer could be extended to do its own colorspace and levels conversions like madVR? Best of both worlds... almost.
Mark_A_W
14th April 2009, 13:02
I'm testing build 25, two minor issues I've noticed:
- With Reclock running, I get an audio/video glitch after about an hour. It's a half second repeat of sound/video. Playback is SMOOTH otherwise, as smooth as a hardware Video Processor. Red and green graph lines are rock solid, but unfortunately I haven't caught the glitch in the act with the stats enabled.
I'm now testing with Reclock running, but set to Slave to reference clock, and Media is set to Original speed, therefore disabling reclock. My red and green lines get little peaks in them now, every few seconds, and it's not as smooth, but still very good. I will find out if the glitch is gone, pointing the finger at reclock rather than MPC HC itself.
Edit: no, wait, if I disable all pixel shaders the red and green lines in statistics are back to almost perfectly flat.
- The Renderer Output range controls do not seem to work when ffdshow video is feeding the renderer YUY2. It seems to be always expanding levels....which I don't want to do.
I have to enable the 0-255 -> 16-235 to get my levels back to "retained"...but I fear it is being expanded then compressed again. I will do the RGB conversion in ffdshow for now, retaining the levels.
Keep up the good work Beliyaal, it is appreciated.
Mark
Beliyaal
14th April 2009, 13:10
I'm testing build 25, two minor issues I've noticed:
- With Reclock running, I get an audio/video glitch after about an hour. It's a half second repeat of sound/video. Playback is SMOOTH otherwise, as smooth as a hardware Video Processor. Red and green graph lines are rock solid, but unfortunately I haven't caught the glitch in the act with the stats enabled.
I'm now testing with Reclock running, but set to Slave to reference clock, and Media is set to Original speed, therefore disabling reclock. My red and green lines get little peaks in them now, every few seconds, and it's not as smooth, but still very good. I will find out if the glitch is gone, pointing the finger at reclock rather than MPC HC itself,
- The Renderer Output range controls do not seem to work when ffdshow video is feeding the renderer YUY2. It seems to be always expanding levels....which I don't want to do.
I have to enable the 0-255 -> 16-235 to get my levels back to "retained"...but I fear it is being expanded then compressed again. I will do the RGB conversion in ffdshow for now, retaining the levels.
Keep up the good work Beliyaal, it is appreciated.
Mark
I use reclock myself, and want bit-perfect playback, requiring slave to audio clock and original speed locked. I have the same problem with an unstable audio clock. It will however stabalize after about half a minute. I think reclock could improve here. I have also experienced some glitches on some content. I think this occurs when there is an audio discontinuety in the source stream. I think reclock could handle this better as well. Everytime it happens it takes some time for the clock to stabilize again.
The levels expansion is entierly dependant on the graphics drivers that do the YUV to RGB conversion. On my ATI card YUY2 format gives bad chroma upsampling, so I use NV12 for all content (forced in ffdshow). Is there any content that has YUY2 or other 2:1 chroma format natively?
Mark_A_W
14th April 2009, 13:21
I use reclock myself, and want bit-perfect playback, requiring slave to audio clock and original speed locked. I have the same problem with an unstable audio clock. It will however stabalize after about half a minute. I think reclock could improve here. I have also experienced some glitches on some content. I think this occurs when there is an audio discontinuety in the source stream. I think reclock could handle this better as well. Everytime it happens it takes some time for the clock to stabilize again.
The levels expansion is entierly dependant on the graphics drivers that do the YUV to RGB conversion. On my ATI card YUY2 format gives bad chroma upsampling, so I use NV12 for all content (forced in ffdshow). Is there any content that has YUY2 or other 2:1 chroma format natively?
You may have missed my edit about the Pixel Shaders - when they are disabled I don't get the little bumps in the graph, with Reclock "inactive".
With NV12 the Tearing Test and Stats don't work for me, and the levels still don't seem to change. I think I will stay with ffdshow RGB32 HQ for now. (I have a HD2600XT).
Some info on how you run your setup, which decoders, all the settings, etc, would be much appreciated! If we can stick to your settings as closely as possible, we will probably get the best results.
Mark
Casshern
14th April 2009, 13:29
All settings are on their maximum already. But a while back i tried all smartgart settings, and found no difference!
There was - and maybe still is - a SMARTGART component of the Catalyst driver that allows to enable "Fast Write" and other AGP-related settings. For optimal performance, all settings should be enabled.
fastplayer
14th April 2009, 13:37
All settings are on their maximum already. But a while back i tried all smartgart settings, and found no difference!
And I assume you've set "AGP Aperture Size" to its maximum value?
Some games stutter when the aperture size is set too low. It might have an impact on video rendering too.
BatKnight
14th April 2009, 14:08
On my ATI card YUY2 format gives bad chroma upsampling, so I use NV12 for all content (forced in ffdshow).
Would it be possible for MPC-HC to have an option for one to be able to force NV12 or any other colorspace output, just like ffdshow does?
It would be useful when one wants to use an internal MPC-HC decoder and force output NV12, for example.
Bat
tetsuo55
14th April 2009, 14:19
I actually do not know if only AGP boards are affected. It might be that 2x00 PCI-E suffer the same, but as there are many alternatives for PCI-E users they just buy a newer model.
I have read many reports from 2x00 PCI-E users on many boards, they do not suffer from the problems we AGP users have :(
Casshern
14th April 2009, 17:27
Interesting! But maybe they do not use MPC HC, VMR9 renderless and DXVA. I never had problems with overlay, vmr7 oder powerdvd. Only the first MPC HC with the DXVA decoder showed massive problems under vmr9 renderless and evr. These were mostly fixed by beliyaals version. I would think that non fanatics probably would not notice the remaining problems. It's one repeated field every couple of minutes.
But if the pci-e are definatly not affected, then i am at a loss, because i tried virtually everything - all conceivable settings in catalyst, bios, latency, agp settings, overclock, underclock... you name it. It seems that sometimes for unknown reasons (not related to performance of the card) the wait for gpu flush just takes to long occasionally. If anybody got more ideas.. please forward them. I am leaning to buy one of these new and shiny corei7 machines with some new 4xxxx ATI CARD. Should be passive though. Any suggestions?
Beliyaal: What board do you use? Do you actually use the DXVA engine or do everything by software (as i deducted by you writing that u use ffdshow with NV12)?
I have read many reports from 2x00 PCI-E users on many boards, they do not suffer from the problems we AGP users have :(
tetsuo55
14th April 2009, 17:33
Interesting! But maybe they do not use MPC HC, VMR9 renderless and DXVA. I never had problems with overlay, vmr7 oder powerdvd. Only the first MPC HC with the DXVA decoder showed massive problems under vmr9 renderless and evr. These were mostly fixed by beliyaals version. I would think that non fanatics probably would not notice the remaining problems. It's one repeated field every couple of minutes.
But if the pci-e are definatly not affected, then i am at a loss, because i tried virtually everything - all conceivable settings in catalyst, bios, latency, agp settings, overclock, underclock... you name it. It seems that sometimes for unknown reasons (not related to performance of the card) the wait for gpu flush just takes to long occasionally. If anybody got more ideas.. please forward them. I am leaning to buy one of these new and shiny corei7 machines with some new 4xxxx ATI CARD. Should be passive though. Any suggestions?
Beliyaal: What board do you use? Do you actually use the DXVA engine or do everything by software (as i deducted by you writing that u use ffdshow with NV12)?
These users use MPC-HC with DXVA(i must admit that i have do not remember perfect playback with EVR, VMR9 is a definate yes though), they also had probleemfree playback in PowerDVD before a fix for AGP was found.
The problems i am facing are far worse than you describe.
What are the exact settings you are using?
(For both cases, repeat field and macroblocking errors)
Overclocked and fully silent:
http://www.gigabyte.eu/Products/VGA/Products_Overview.aspx?ProductID=2900
Still too bad ATI has nothing to counter CUDA (DXVA does not work under linux)
Mercury_22
14th April 2009, 17:57
I think v25 it's good enough to be merge SVN so more peoples can take a look to the code (bugs) :thanks::script::rolleyes:
clsid
14th April 2009, 19:53
You said the same thing about a previous version which turned out the be buggy. A longer testing period is needed.
Leak
14th April 2009, 20:53
Still too bad ATI has nothing to counter CUDA (DXVA does not work under linux)
Huh? (http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx)
Of course DXVA wouldn't work under Linux, considering what the DX in DXVA stands for...
np: Jared Emerson-Johnson - Combat Begin!! (Sam & Max Season One OST (Disc 2))
Mercury_22
14th April 2009, 21:09
You said the same thing about a previous version which turned out the be buggy. A longer testing period is needed.
You're probably right ( I haven't said it's BUG FREE !)
But it's not like the SVN it's much "BUG FREE" / better / stable, AFIK (did you find any MAJOR bug in this version ?) so I was thinking more eyes on the code it will speed thigs but if you all don't think so ...
P.S. If it's possible at least some "parts" like the "output range" should be merge, the "new" 9.2->... ATI drivers are killing SVN's EVR CP ! Not a fan of the "shaders" here!:))
tetsuo55
14th April 2009, 21:22
Huh? (http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx)
Of course DXVA wouldn't work under Linux, considering what the DX in DXVA stands for...
np: Jared Emerson-Johnson - Combat Begin!! (Sam & Max Season One OST (Disc 2))
Is there any player that makes use of this?
If so would it work on my HD2400pro?
tetsuo55
14th April 2009, 21:31
@Beliyaal and Casshern
Here i the decoding problems i encounter(results vary with renderer and driver version)
Image corruption:
*Red smearing macroblocking (although i have not seen this for over 6 months)
*Random macroblocking (looks like a ref frame goes missing and the other frames are confused and render randomness)
*Sometimes 1/3rd of the screen will flash an old frame every other second (annoyingly enough often the bottom 1/3rd where the subs are)
General wierdness:
*Sometimes a frame will jump (a frame is repeated and literaly jumps up or down a few pixels)
*Sometimes the movie will become jerky for a second (looks like frameskips)
As i said this happens with any version of MPC-HC with any renderer.
Now here comes my problem with the Beliyaal build:
Depending on the settings all of the above problems seem to dissapear. Only to be replaced by something worse:
*Framerate will suddonly start decreasing, desyncing audio and video (and lagging the player to the point where it refuses to respond for up to 2 minutes) after a while it usually recovers.
Ofcourse all rendered frames appear like a slideshow when this happens.
i can reproduce with at least one of my test files over and over in exactly the same spots. MPC-HC SVN appears to skip 1 frame in exaxtly those spots.
(PowerDVD has none of the above problems)
I really think the problem is in the DXVA decoder filter though
BatKnight
14th April 2009, 23:47
Would it be possible to have someone list what the shaders actually do, and under what siuations they are best used, and which are best enabled all the time etc.
Check here (http://nunnally.ahmygoddess.net/all-the-things-you-may-want-to-know-about-media-player-classic-homecinema/)
Bat
Mark_A_W
15th April 2009, 03:51
I'm still having a minor issue where my monitor turns off and the PC will eventually go into standby while playing. I have to turn off the powersaving features everytime before using MPC-HC. It does it in normal (non Direct3d Fullscreen) playback using EVR custom.
I reported this in the main MPC HC thread, and I thought it was fixed in the SVN. But it's certainly not right in these builds.
Am I the only one?
anon2243
15th April 2009, 06:22
Version 25 working great for me thanks...
Casshern
15th April 2009, 07:52
I use either:
VC-1 EVR CP (8 BUFFERS):
1) VSYNC, ALT VSYNC; ACCURATE VSYNC, VOFFSET -100
2) WAIT FOR GPU FUSH, FLUSH AFTER VSYNC
4) INTERNAL DXVA DECODER + RECLOCK WITHOUT VSYNC CORRECTION, ACCEPT SP-DIF, SP-DIF OVER X-FI TO AVR
5) Refreshrate = 2 * 23.976 (Powerstrip)
6) AC3-Filter for DTS/AC3. Its the only filter at the moment that does not exhibit huge DTS jitter
7) Combined shaders: chroma upsamling, complex sharpen 2 (but i lowered the coefficents to 1.2 and 1.2)
H264 VMR9 (Renderless)
1) ALL VSYNC STUFF OFF
2) the rest stays the same
regards,
Casshern
tried V25 a little. Its more stable, but something changed - sometimes i get corruption again - have to further investigate (V18 works best here).
@Beliyaal and Casshern
Here i the decoding problems i encounter(results vary with renderer and driver version)
Image corruption:
*Red smearing macroblocking (although i have not seen this for over 6 months)
*Random macroblocking (looks like a ref frame goes missing and the other frames are confused and render randomness)
*Sometimes 1/3rd of the screen will flash an old frame every other second (annoyingly enough often the bottom 1/3rd where the subs are)
General wierdness:
*Sometimes a frame will jump (a frame is repeated and literaly jumps up or down a few pixels)
*Sometimes the movie will become jerky for a second (looks like frameskips)
As i said this happens with any version of MPC-HC with any renderer.
Now here comes my problem with the Beliyaal build:
Depending on the settings all of the above problems seem to dissapear. Only to be replaced by something worse:
*Framerate will suddonly start decreasing, desyncing audio and video (and lagging the player to the point where it refuses to respond for up to 2 minutes) after a while it usually recovers.
Ofcourse all rendered frames appear like a slideshow when this happens.
i can reproduce with at least one of my test files over and over in exactly the same spots. MPC-HC SVN appears to skip 1 frame in exaxtly those spots.
(PowerDVD has none of the above problems)
I really think the problem is in the DXVA decoder filter though
tetsuo55
15th April 2009, 09:14
I use either:
VC-1 EVR CP (8 BUFFERS):
1) VSYNC, ALT VSYNC; ACCURATE VSYNC, VOFFSET -100
2) WAIT FOR GPU FUSH, FLUSH AFTER VSYNC
4) INTERNAL DXVA DECODER + RECLOCK WITHOUT VSYNC CORRECTION, ACCEPT SP-DIF, SP-DIF OVER X-FI TO AVR
5) Refreshrate = 2 * 23.976 (Powerstrip)
6) AC3-Filter for DTS/AC3. Its the only filter at the moment that does not exhibit huge DTS jitter
7) Combined shaders: chroma upsamling, complex sharpen 2 (but i lowered the coefficents to 1.2 and 1.2)
H264 VMR9 (Renderless)
1) ALL VSYNC STUFF OFF
2) the rest stays the same
regards,
Casshern
tried V25 a little. Its more stable, but something changed - sometimes i get corruption again - have to further investigate (V18 works best here). Also the bd of "marley and me" totally freaks out the DXVA decoder (on all versions and SVN) - works with core avc
If you remove reclock and powerstrip from the chain is the image still that stable? Or do you get the same issues i reported?
It might be that either reclock or the better refresh rate settings are stopping the problem from appearing on your system
PS, i have an LCD and can only choose 24/50/59/60 (other resolutions are only supported as interlaced)
mark0077
15th April 2009, 09:22
I'm still having a minor issue where my monitor turns off and the PC will eventually go into standby while playing. I have to turn off the powersaving features everytime before using MPC-HC. It does it in normal (non Direct3d Fullscreen) playback using EVR custom.
I reported this in the main MPC HC thread, and I thought it was fixed in the SVN. But it's certainly not right in these builds.
Am I the only one?
You're not the only one. When I come out of fullscreen mode after watching a movie, my display immediately turns off (obviously if the movie was longer than my powersaving setting). Something wrong somewhere. I imagine would be easyish to test by setting power settings to 1 minute and work from there.
Casshern
15th April 2009, 10:26
Reclock and Powerstrip does not make a difference. Here are some things you should look for
1) Bios: AGP Fast Write, AGPx8, side band etc. You can also check these settings in Powerstrip and in catalyst, but i would change them in bios. Make sure they are all at the fastest setting.
2) /usepmtimer in boot.ini
3) try overlay and vmr7 first, they always worked without probs with DXVA
4) be careful with the material, some h264 stuff especially mkv's is not encoded to l4.1 spec - like all bds are. These will give artifacts or newer mpc hc decoders fall back to software decoding (which is also not sable)
6)catalyst settings: some of them do make a difference, even though they should not. you should set hardware deinterlace to weave and no automatic pulldown. Also one of the d3d aliasing settings had an effect. Leave them all at default or reset them to the defaults. I always had wait for vsync set to always on. But recently switched to "on when not specified". Do not know about other settings - both work
5) Disable the second monitor in catalyst - after 8.12 its not enough to set primary to the monitor where you want to watch. But this might also be due to the new reclock, beliyaals code or else
6) Catalyst: try 8.5 this is very stable version for the AGP cards. 8.6. - 9.1 crash when playing back dxva. And 9.2 is ok again but, i did not test this that extensively. 9.4 is worse (slightly).
9) I use a 4600+ X2 Socket 939 AMD and playback bd from a bd drive or from hd.
thats it of the top of my head... see if it helps
Casshern
If you remove reclock and powerstrip from the chain is the image still that stable? Or do you get the same issues i reported?
It might be that either reclock or the better refresh rate settings are stopping the problem from appearing on your system
PS, i have an LCD and can only choose 24/50/59/60 (other resolutions are only supported as interlaced)
tetsuo55
15th April 2009, 10:36
Reclock and Powerstrip does not make a difference. Here are some things you should look for
1) Bios: AGP Fast Write, AGPx8, side band etc. You can also check these settings in Powerstrip and in catalyst, but i would change them in bios. Make sure they are all at the fastest setting.
I will doublecheck my settings (but they should be okay).
One thing i have not done yet is increase the AGP ram size to the maximum size allowed
2) /usepmtimer in boot.iniInteresting setting, did some quick googling, it looks like this won't help (and possibly hurt?) as i have a single core (athlonXP 2600+)
3) try overlay and vmr7 first, they always worked without probs with DXVAThese work at the cost of losing subtitles :(
4) be careful with the material, some h264 stuff especially mkv's is not encoded to l4.1 spec - like all bds are. These will give artifacts or newer mpc hc decoders fall back to software decoding (which is also not sable) I'm testing with remuxes and l4.1 encoded rips (i'm one of the people who pushed the use of l4.1 settings in various encoders)
6)catalyst settings: some of them do make a difference, even though they should not. you should set hardware deinterlace to weave and no automatic pulldown. Also one of the d3d aliasing settings had an effect. Leave them all at default or reset them to the defaults. I always had wait for vsync set to always on. But recently switched to "on when not specified". Do not know about other settings - both work I did not know this, i will change these settings asap
5) Disable the second monitor in catalyst - after 8.12 its not enough to set primary to the monitor where you want to watch. But this might also be due to the new reclock, beliyaals code or else Never though of disabling it, good idea.
6) Catalyst: try 8.5 this is very stable version for the AGP cards. 8.6. - 9.1 crash when playing back dxva. And 9.2 is ok again but, i did not test this that extensively. 9.4 is worse (slightly). I have not tested 9.4 enough, but i use Windows 7 so that would not help (and i had the above problems with any driver version in XP)
9) I use a 4600+ X2 Socket 939 AMD and playback bd from a bd drive or from hd.
thats it of the top of my head... see if it helps
Casshern I play from HD, my cpu is slower and singlecore though
BatKnight
15th April 2009, 10:51
I have not tested 9.4 enough, but i use Windows 7 so that would not help
AMD only started supporting Windows 7 officially from Catalyst 9.3 and up.
Bat
tetsuo55
15th April 2009, 12:15
AMD only started supporting Windows 7 officially from Catalyst 9.3 and up.
Bat
Yes i know, but they started out with a beta driver that is about equal to 9.1
tetsuo55
15th April 2009, 14:02
@ Casshern,
Have you done any trials without DXVA?
AFAIK non-DXVA playback is almost perfect, only DXVA appears to be effected.
Due to my slow processor i cannot test anything beyond very low bitrate 720p though (i will run a bunch of tests tonight)
Casshern
15th April 2009, 15:46
Sure i did.
Without DXVA everything is much less complicated, but even the 4600+ X2 is to slow with certain scenes if the bit rate is high enough. The build in MPC HC software decoder is slower then COREAVC and has more bugs then the WindowsDMO Vc-1 decoder. If you only watch reencoded mkvs cpu speed is no problem - but some BDs (40GB for a 2h movie) are to much for my configuration.
regards,
casshern
@ Casshern,
Have you done any trials without DXVA?
AFAIK non-DXVA playback is almost perfect, only DXVA appears to be effected.
Due to my slow processor i cannot test anything beyond very low bitrate 720p though (i will run a bunch of tests tonight)
tetsuo55
15th April 2009, 19:51
I used all of Casshern's setting(except for powerstrip and reclock, and i use either ffdshow or internal mpc decoders for audio) and then did some testing:
None of the settings influence the (unique to beliyaal build) framerate drop bug reported in my screenshots :(
However messing around with the settings did reveal something interesting:
Problem 1:
*Enabling "Accurate VSync" causes Macroblocking corruption.
Problem 2:
*Enabling "Flush before Vsync" causes macroblocking corruption.
Select either or both and macroblocking corruption will occur
Currently these settings give me the best results:
1) EVR CP (8 BUFFERS):
1) VSYNC, ALT VSYNC;
2) WAIT FOR GPU FUSH, FLUSH AFTER VSYNC
4) INTERNAL DXVA DECODER
----
PS i use 2 files for testing, file 2 seems to no longer suffer from the framerate drop problem.
I'm going to use Beliyaal build as my main player for a few days to expand the number of tested files
----
@Casshern, can you explain more about jitter in audio playback?
You named DTS, but what about the other codecs? (AC3, MP3, Realaudio(cook))
Rectal Prolapse
15th April 2009, 20:21
Hmmm. I just noticed that there is tearing when there are subtitles (using internal subtitle renderer). I may have to go back to the old MPC-HC to verify.
Casshern
16th April 2009, 09:48
The behavior of the ATI 2X00 AGP engine (and when the problems occur) can be explained pretty well in relation to when the vsync occurs. Some of this i already pm'ed beliyaal a while back, some of this are new findings. All of this is with DXVA playback.
I. Pre V18 versions (VMR9 renderless, EVR CP):
a) lock back buffer enabled:
1) no tearing
2) heavy artifacts, jumping frames, corruption on high bitrate 1920 x 1080 streams when played back at a horizontal screen res of larger then 1440-1600. More prominent on VC-1.
3) INTERESTING: As soon as you open the context menu. No corruption while it is on the screen. Explanation see below.
b) lock back buffers disabled
1) tearing no matter what other options are used
2) INTERESTING: If the "tear" is in the visible screen area, no corruption. As soon as it move outside the visible area (play,pause) no more corruption. But as the position is not controllable it will move and lead to unpredictable behaviour (tearing corruption)
II., V18 and later versions
a) VMR9 Renderless, VSYNC STUFF OFF, All GPU Flush settings on
1) No corruption if resolution of display is equal to 1920x1080 or less.
2) On higher res displays, e.g. a friends 2560x1600, you have major problems.
3) INTERESTING: Occasional repeated frame, due to high GPU WAIT time. But this is not due to the overall slowness of the card but to specificy of the FLUSH .- WAIT GPU Cycle. See explanation below.
4) during black phases you also get a wierd drop of frame rate
b) EVR CP, All VSYNC settings ON, GPU FLUSH BEFORE VSYNC ON (without this vsync is not controllable through the offset), Wait for GPU FLUSH OFF.
1) tearing position gets controllable by the offset
2) INTERESTING: if tearing position is in the visible screen no corruption. If tear position is moved outside the visible screen corruption returns.
3) At VOFFSET of -100 corruption is reduced and tear is nearly not visible (a tiny bit at the bottom). But still sometimes repeated frames.
Summary and Expanation: Both the DXVA engine and the presenter code sync itself to the VBLANK period. If the presenter code does not take precautions and f.e. switches buffers while the DXVA engine is doing something on the buffer corruption occurs. If the presenter code is called during the visible screen, you get no corruption but obviously tearing.
They both have to be synchronized somehow. Heres how the FLUSH and WAIT FOR FLUSH cycle works. When entering VBLANK (+- VOFFSET) first the card is flushed and is waited to finish this operation (WAIT FOR FLUSH), this is usually fast and now the presenter code can do its stuff while still in VBLANK. Everybody is happy in this scenario. This also expains
But if the wait for flush takes to long, you get the occasional repeated frame. But why give the card so little time to flush? I would propose this cycle (for clarity on a 1080 display that has an additional 30 lines of VBLANK):
Wait for line 600, do the gpu flush, (and/or lock the gpu), wait for VSYNC(+-OFFSET) then do the presenter code and finally unlock the gpu. And repeat the cycle.
There might be other ways ATI had in mind to communicate to the presenter code (Cyberlink knows). Maybe even a WAIT FOR DECODED FRAME, a BUFFER SAVE FLAG, or even a way to tell the DXVA engine to WAIT for Presenter code- somehow undocumented. As somehow it is strange that if presenter code switches screens during the visible area, no corruption occurs. This is undesirable as tearing is annoying, but it shows that the DXVA engine somehow expects another handshake protocoll.
The above might also explain the frame rate drop during black phases. If the WAIT FOR FLUSH is so fast that it finishes long before line 0, it es reasonable to assume that DXVA engine might render another frame, before the presenter code is finished (after all decoding a black frame is very fast) and also before line 0. Software decoders probably take longer so its never a prob. Thats why i first thought it might be the decoder.
No longer so, i think the whole mess might be fixable.
thanks for listening,
Casshern
P.S: The explanation for the "context menu" effect above is that the menu is put in the VBLANK render pipeline, and therefore changes the timing of the presenter code.
I used all of Casshern's setting(except for powerstrip and reclock, and i use either ffdshow or internal mpc decoders for audio) and then did some testing:
None of the settings influence the (unique to beliyaal build) framerate drop bug reported in my screenshots :(
However messing around with the settings did reveal something interesting:
Problem 1:
*Enabling "Accurate VSync" causes Macroblocking corruption.
Problem 2:
*Enabling "Flush before Vsync" causes macroblocking corruption.
Select either or both and macroblocking corruption will occur
Currently these settings give me the best results:
1) EVR CP (8 BUFFERS):
1) VSYNC, ALT VSYNC;
2) WAIT FOR GPU FUSH, FLUSH AFTER VSYNC
4) INTERNAL DXVA DECODER
----
PS i use 2 files for testing, file 2 seems to no longer suffer from the framerate drop problem.
I'm going to use Beliyaal build as my main player for a few days to expand the number of tested files
----
@Casshern, can you explain more about jitter in audio playback?
You named DTS, but what about the other codecs? (AC3, MP3, Realaudio(cook))
Mark_A_W
16th April 2009, 13:00
You're not the only one. When I come out of fullscreen mode after watching a movie, my display immediately turns off (obviously if the movie was longer than my powersaving setting). Something wrong somewhere. I imagine would be easyish to test by setting power settings to 1 minute and work from there.
On further inspection you are right - the monitor turns off after pressing stop. It's very strange.
mark0077
16th April 2009, 13:05
Yeah I actually laughed when I saw it first. I usually control the PC using the wiimote, and have a button it which maps to "Alt + F4" to close mpc (bringing me back to media center). It was so strange to see the movie finish perfectly, mpc close, then the screen dimming down and turning off...
Mark_A_W
16th April 2009, 13:07
I use reclock myself, and want bit-perfect playback, requiring slave to audio clock and original speed locked. I have the same problem with an unstable audio clock. It will however stabalize after about half a minute. I think reclock could improve here. I have also experienced some glitches on some content. I think this occurs when there is an audio discontinuety in the source stream. I think reclock could handle this better as well. Everytime it happens it takes some time for the clock to stabilize again.
Beliyaal, I just did some more testing (ok, movie watching).
With Reclock set to Slave/Original speed, I still get a glitch, sometimes two after somewhere between 30 mins and 1.5 hours.
Using Waveout instead (Default Directsound device crashes MPC on my system), I also get the same glitches.
I don't think it's Reclock related, not directly at least.
This is with a HD-DVD converted to a MKV with FLAC. I'm 99.9% certain there are no problems in the source.
However, even with Waveout, I did not notice any jumps or judders otherwise.
Reclock in "bypass" mode as a WASAPI renderer is all that is needed with your builds, minor glitch aside. It's smooth as silk...until the half second glitch, which takes a while to occur.
Mark
leeperry
16th April 2009, 14:25
hi Beliyaal, very impressive VMR9 Presenter on XP SP3! :eek:
I wasn't too fund of the regular MPC presenter because it didn't look too stable and would drop frames randomly...but yours looks like the real deal :)
Is there any stat that lets us know whether there's been any dropped frame? like if any of them went for more than one blue "notch" in the jitter thingie?
and you seem to have found a way to enforce the VSYNC on XP, so Reclock never hiccups...great stuff! but I've been traumatized by the regular MPC HC that was randomly dropping frames, so I'm kinda scared :D
anyway, it's great w/ 23.976@48Hz w/ Reclock :
http://www.image-load.eu/out.php/t157958_beli.png (http://www.image-load.eu/out.php/i157958_beli.png)
but 29.97@89.91Hz drops pretty badly(like the regular MPC HC, but HR works just fine) :
http://www.image-load.eu/out.php/t157959_beli2.png (http://www.image-load.eu/out.php/i157959_beli2.png)
:thanks:
leeperry
16th April 2009, 14:44
humm, CoreAVC CUDA on BD's works fine in HR...but hiccups badly in mVR and so does it in your VMR9 Presenter(it goes fine if I disable CUDA in both mVR and your custom VMR9 Presenter).
CUDA :
http://www.image-load.eu/out.php/t157964_cuda.png (http://www.image-load.eu/out.php/i157964_cuda.png)
not CUDA :
http://www.image-load.eu/out.php/t157963_core.png (http://www.image-load.eu/out.php/i157963_core.png)
anyone else tried CoreAVC CUDA on 1080p in Beliyaal's builds? it works fine w/ 720p apparently
also, MPC detected that CoreAVC is using GPU acceleration(DXVA1)
Jong
16th April 2009, 15:30
hi Beliyaal, very impressive VMR9 Presenter on XP SP3! :eek:
I wasn't too fund of the regular MPC presenter because it didn't look too stable and would drop frames randomly...but yours looks like the real deal :)
Is there any stat that lets us know whether there's been any dropped frame? like if any of them went for more than one blue "notch" in the jitter thingie?I agree VMR9 is looking very good now with XP. Works close to perfectly (maybe as perfectly as Windows will allow) when combined with Reclock vsync management (exclusive mode).
Yes, I've asked for a "dropped/repeated frame count" before. Beliyaal it would be great if you could add it to your stats. It means in testing we can just play a movie and come back at the end instead of having to stare at the screen looking for a "blip"!
mariner
16th April 2009, 17:08
Greetings Beliyaal.
Would appreciate if you could kindly look into VMR9/Renderless playback problem with 1920x1080/60P H264/AAC video. Tested on Xp3 with HD3650 AGP.
Best regards.
Link to sample:
http://www.sanyo-dsc.com/products/lineup/dmx_hd2000/img/sample/movie_sample_hd2000_01.zip
STaRGaZeR
17th April 2009, 01:45
It seems the decoder is not the cause, and also there is no audio to be played. Version 23-24 still have the issue. I've uploaded the menu of one of these DVDs here (http://www.megaupload.com/?d=R3JHNSQH) (22MB) so you can take a look. Compare Version 21 against the newer ones to see it clearly.
Seems fixed in Version 25, thanks.
lych_necross
17th April 2009, 07:42
I just tried version 25 and it seems pretty stable for me. I think now is a good time to merge this version with the SVN. FYI, my config is: Vista 32bit w/ SP1, Geforce 9800GTX+ w/ 185.68, and EVR CP with desktop composition enabled.
DeepBeepMeep
17th April 2009, 09:28
Merging with the SVN build would be great ! But please make sure you have fixed first the tearing with internal subtitles since we don't have it this issue with the SVN build.
clsid
17th April 2009, 12:49
All regressions should be fixed before a merge. Period.
tetsuo55
17th April 2009, 15:11
I have tested over 50 movies.
Here are my results:
1. I can reproduce the macroblocking on seek bug in almost every DXVA file, also in some cases it will take very long to get the audio/video back in sync, this looks exactly like the dropped framerate problem.
2. Files that are problematic also show issues in SVN, however SVN recovers immediately while beliyaal build takes a very long time to do so(can take minutes, even crashing MPC when it takes too long).
3. I found some wierd behaviour with my screen set to 24p and using a 24p file, see attached screenshot.
Everytime the 2 lines flatline together the they will jump away from eachother as visable in the screenshot
4. VC1 playback (I only have one) appears to be broken, but this happens in SVN too. Reported here: http://forum.doom9.org/showthread.php?p=1275061#post1275061
5. Good news, beliyaal build is smoother and only shows macroblocking when framerate drops, same file will constantly show random macroblocking in SVN
Here is the screenshot for problem 3.
http://img150.imageshack.us/img150/9708/wierd.th.png (http://img150.imageshack.us/my.php?image=wierd.png)
mark0077
17th April 2009, 17:06
Guys, I am using beliyaals build with reclock ONLY for 25->24 pal speed down.
My question is regarding the "Slave reference clock to audio" and should I leave it on or off in this combination.
I obviously would rather bit exact audio coming from reclock when possible, with it enabled I get bit exact output and notice no problems..... Just wondering should qw enable / disable it if using beliyaal's build for clock / vsync correction.
EDIT: I guess while I am asking you guys about this reclock setting I should also ask do you think the hardware resampling option might be good for my HDAV 1.3 Deluxe versus the software one?
yesgrey
17th April 2009, 17:23
Guys, I am using beliyaals build with reclock ONLY for 25->24 pal speed down.
My question is regarding the "Slave reference clock to audio" and should I leave it on or off in this combination.
Which soundcard do you have?
If you have a RME or Lynx, leave it on and set the soundcard's clock frequency to 46080Hz. If it's not, you have to use reclock in Auto mode and let it resample the sound, or you will loose the sync between audio and video, with lots of dropouts.
Beliyaal
17th April 2009, 17:37
Which soundcard do you have?
If you have a RME or Lynx, leave it on and set the soundcard's clock frequency to 46080Hz. If it's not, you have to use reclock in Auto mode and let it resample the sound, or you will loose the sync between audio and video, with lots of dropouts.
So Reclock doesn't support driving the clock directly from the audio clock? It would be great to have an audio renderer that could do that.
mark0077
17th April 2009, 17:39
Its the HDAV 1.3 Deluxe, only allows me to use 44.1, 48, 96 and 192khz, I guess I will have to let reclock sample the sound. I thought beliyaal's renderer could make up for any out of syncness by speeding up / slowing down frames, no messing with audio. Was hoping for minimal messing with audio if beliyaal's renderer is able to get around this.
Beliyaal
17th April 2009, 17:45
I have tested over 50 movies.
3. I found some wierd behaviour with my screen set to 24p and using a 24p file, see attached screenshot.
Everytime the 2 lines flatline together the they will jump away from eachother as visable in the screenshot
This is just the difference between your 24 Hz display and the 23.976 Hz movie. It's normal for the sync to drift in this case, and once in a while it needs to repeat one frame to get back in sync.
---
The problems with low framerate on AGP cards, CUDA as well as the tearing with subtitles might have the same solution. I will not have time to do anything this weekend, and the translations are still stopping me up from submitting to SVN. Right now it looks like the fastest way is to create a tool that helps me with the translation merging.
Beliyaal
17th April 2009, 17:51
Its the HDAV 1.3 Deluxe, only allows me to use 44.1, 48, 96 and 192khz, I guess I will have to let reclock sample the sound. I thought beliyaal's renderer could make up for any out of syncness by speeding up / slowing down frames, no messing with audio. Was hoping for minimal messing with audio if beliyaal's renderer is able to get around this.
Sorry, there is no way to achieve this without some complicated motion vector detection and interpolation similar to that which 100 Hz TVs use. That is a project for another time :) Maybe when Larrabee is out there will be incentive to try something like that in realtime.
It would be really nice if the next audio/video standard like HDMI would allow any sampling frequency. That would be incentive for the receiver manufacturers to actually create hardware that supports it without resampling.
mark0077
17th April 2009, 17:55
Sorry, there is no way to achieve this without some complicated motion vector detection and interpolation similar to that which 100 Hz TVs use. That is a project for another time :) Maybe when Larrabee is out there will be incentive to try something like that in realtime.
It would be really nice if the next audio/video standard like HDMI would allow any sampling frequency. That would be incentive for the receiver manufacturers to actually create hardware that supports it without resampling.
Hi, Thanks for the reply. I appreciate what you say but what I talk about is the case where reclock will add maybe 3 or 4 hz to the clock, to say 48004 hz, just to keep things in sync I believe.
My question for these types of scenarios is should reclock be set to output bit-perfect 48000 (to stop it resampling) and let your renderer handle the syncing by slightly slowing, speeding up video frames, as its doing a great job.
yesgrey
17th April 2009, 18:17
So Reclock doesn't support driving the clock directly from the audio clock?
No. It will always be based in display's refresh rate. The only thing that it does in that mode is disabling the resampling.
If you want to know all details, see my discussion with James in reclock's main thread.
It would be great to have an audio renderer that could do that.
It already exists, is... the Microsoft Audio Renderer!:D
It works exactly like that. I have played with it using my RME soundcard even with extreme settings, like setting the soundcard's clock to 32000Hz instead of 48000Hz. A PAL movie (25fps) will play at 16.667 fps and the audio and video are completelly in sync (it's like playing in slow motion). The problem is called... kmixer, which degrades the sound quality.:(
Beliyaal
17th April 2009, 18:21
It already exists, is... the Microsoft Audio Renderer!:D
It works exactly like that. I have played with it using my RME soundcard even with extreme settings, like setting the soundcard's clock to 32000Hz instead of 48000Hz. A PAL movie (25fps) will play at 16.667 fps and the audio and video are completelly in sync (it's like playing in slow motion). The problem is called... kmixer, which degrades the sound quality.:(
Ahh, yes what I meant was a WASAPI audio renderer with that feature. I guess that explains why i get cutouts in the audio when I use Reclock for bit-perfect playback. Unless Reclock adds a mode to drive the clock from the Audio I guess I will have to look at creating that audio renderer after all.
mark0077
17th April 2009, 18:29
Ahh, yes what I meant was a WASAPI audio renderer with that feature. I guess that explains why i get cutouts in the audio when I use Reclock for bit-perfect playback. Unless Reclock adds a mode to drive the clock from the Audio I guess I will have to look at creating that audio renderer after all.
* Does a little dance * lol I have a very hard time convincing the reclock guy to improve the interface, making some suggestions now but an audio renderer thats open source with this community improving it through feedback would be a great project for the future.
yesgrey
17th April 2009, 18:54
I guess that explains why i get cutouts in the audio when I use Reclock for bit-perfect playback.
Yes, that's the reason.
Unless Reclock adds a mode to drive the clock from the Audio I guess I will have to look at creating that audio renderer after all.
You better start looking in creating the audio renderer. I've requested that to James and he said that it will never happens, because he would have to rewrote that part of reclock's code and he does not have the time and does not want to.
If you don't want to create the audio renderer, you could think in buying a RME or Lynx soundcard, they will do it.;) but will cost some $$$...:(
tetsuo55
17th April 2009, 19:02
Hi Beliyaal,
Here is a sample from the most problematic file i have
Please note that remuxing the file to make this sample caused a slight change in the behaviour.
I guess the version of mkvmerge used has a large influence on playback (i already knew this, it should only apply to mkvmerge versions of 1 year and older, this file was muxed with a 2 year old version)
In SVN version this file will have macroblocking corruption in one or all of the 3 logo's (the cogs of the first logo), again the remux behaves much better
The real problems start at around 00:01:30
http://www.megaupload.com/?d=0C2GF32C
Jong
17th April 2009, 19:14
4. VC1 playback (I only have one) appears to be broken, but this happens in SVN too.VC-1 working fine here with build 25. It must be something more specific to your setup. Maybe post full specs.
I am using XP SP3 with a 3850 and Cat 9.2. i tried two blu-ray's one fortunately was actually the Corpse Bride. Both were fine using both VMR9(renderless) and EVR, both using built in VC- Decoder in DXVA mode and Haali Splitter.
tetsuo55
17th April 2009, 19:50
VC-1 working fine here with build 25. It must be something more specific to your setup. Maybe post full specs.
I am using XP SP3 with a 3850 and Cat 9.2. i tried two blu-ray's one fortunately was actually the Corpse Bride. Both were fine using both VMR9(renderless) and EVR, both using built in VC- Decoder in DXVA mode and Haali Splitter.
Windows 7, Cat 9.4, EVR-CP, HD2400pro AGP, using build25/latest SVN but i'm not sure which splitter was used, i'm guessing internal?
mark0077
17th April 2009, 20:03
are you using internal decoder, because with ffdshow's decoder I get stuttering with vc-1, but beliyaal let me know this is a bug with the internal splitter I think. His "Frame Time Correction" fixes this problem temporarily.
Klaus_1250
17th April 2009, 21:50
The real problems start at around 00:01:30
http://www.megaupload.com/?d=0C2GF32C
Plays without a problem on v25 on Win XP SP3, HD3850AGP, Cat 9.4, VMR9 Renderless, Haali Splitter, Reclock+Powerstrip (72Hz). Internal splitter for MKV isn't good, e.g. I used to get stuttering with it all the time. Haali splitter is perfect. Does the job, and best of all, you can configure audiotracks/sub preferences and combinations.
tetsuo55
17th April 2009, 23:21
VC-1 working fine here with build 25. It must be something more specific to your setup. Maybe post full specs.
I am using XP SP3 with a 3850 and Cat 9.2. i tried two blu-ray's one fortunately was actually the Corpse Bride. Both were fine using both VMR9(renderless) and EVR, both using built in VC- Decoder in DXVA mode and Haali Splitter.
I did some more testing, the problem only occurs in fullscreen mode, windowed has no problems.
If i open the rightclick menu in fullscreen the corruption also stops, but then the image stutters
Plays without a problem on v25 on Win XP SP3, HD3850AGP, Cat 9.4, VMR9 Renderless, Haali Splitter, Reclock+Powerstrip (72Hz). Internal splitter for MKV isn't good, e.g. I used to get stuttering with it all the time. Haali splitter is perfect. Does the job, and best of all, you can configure audiotracks/sub preferences and combinations.
I disabled all the built in splitters and used haali, the result is indeed much improved, but eventually the sample still starts to drop framerate
Jong
17th April 2009, 23:40
I did some more testing, the problem only occurs in fullscreen mode, windowed has no problems.All my testing was in fullscreen mode, both D3D exclusive and not.
mark0077
18th April 2009, 00:04
Damn, came accross my first major problem with build 25. I was watching an interlaced DVD so it was playing fine at 50hz (de-interlaced by ffdshow). I wanted to check my cpu usage so i did a CTRL-ALT-DEL and was checking the usage when I noticed the video and audio were WAAAAY out of sync. I also notice the fps of the content dropped to EXACTLY 30.0 fps which is odd. It should be 50.0. Disabling de-interlacing should have brought the fps immediately to 25fps, but it stays dead on 30fps. Something in the renderer is definitely wrong as its not calculating the fps right at all. ReClock shows the correct fps, just the final rendering step seems to get it wrong.
http://img25.imageshack.us/img25/6462/wowvak.th.jpg (http://img25.imageshack.us/my.php?image=wowvak.jpg)
I notice the sync offset numbers are growing and growing forever.... nothing can stop them...
leeperry
18th April 2009, 23:01
@Beliyaal : it seems that your VMR9 never misses the VSYNC fliptime in "alternate" VSYNC mode....would that be possible that you improve the HR presenter of MPC in the same way?
HR never drops frames whatsoever on XP(if the jitter <7.5ms), but it constantly misses the VSYNC fliptime when you reseek and never really "sticks" to it....if you could somehow make sure that it "behaves", the jitter would hopefully hardly ever move in 23.976@47.952/48Hz...and that'd be really great as HR seems much more stable than VMR9/EVR :)
:thanks:
Mangix
19th April 2009, 01:24
on XP, enabling alternative VSync gives me very bad tearing. i blame nVidia :)
Klaus_1250
19th April 2009, 02:24
on XP, enabling alternative VSync gives me very bad tearing. i blame nVidia :)
I think Alternative Vsync was meant for ATi cards. But it works on nVidia as well with 185.xx
Mangix
19th April 2009, 03:50
makes sense that it would. with it enabled, i can't get the right amount of fps under VMR9. eg. a 23.976fps video would play below 20fps and still tear. i use 182.47 so that could be why.
neoufo51
19th April 2009, 15:55
Oh wow, Beliyaal's branch already merged with SVN and nobody mentioned it so far.
Barleyman
19th April 2009, 22:24
I had some unrelated grief with DVD menus on MPC/HC (works iffy) so I gave a shot to the latest test build in 1st post.
I didn't fix the menu issue (darn) but introduced crash on changing resolution during playback. Doesn't matter? Well, it does if you've got a HTPC and you want to play videos at panel res (720p) and still get usable windows desktop..
In any case, with nov28 build, resolution change is OK, both automatic (from mpc options) and manual, with Beliyaal's build it crashes either way. I also tried vanilla SVN build from last night and it's got the same problem so probably not a branch issue per se. I wonder if there's a place to report svn bugs..
Just the rundown of setup:
XP SP3
ATI 3850
Usual setup is with VRM9 D3D + reclock
Using haali splitter + PDVD7 DXVA h264 codec or xvid codec + vobsub
Kazuya
20th April 2009, 10:21
@Beliyaal : it seems that your VMR9 never misses the VSYNC fliptime in "alternate" VSYNC mode....would that be possible that you improve the HR presenter of MPC in the same way?
HR never drops frames whatsoever on XP(if the jitter <7.5ms), but it constantly misses the VSYNC fliptime when you reseek and never really "sticks" to it....if you could somehow make sure that it "behaves", the jitter would hopefully hardly ever move in 23.976@47.952/48Hz...and that'd be really great as HR seems much more stable than VMR9/EVR :)
:thanks:
I agree, it would be great if you fix our dear HaaliRenderer ! :cool:
(which is erratic only with mkv@23.976fps)
Thanks a lot for your great work ! :)
Leak
20th April 2009, 10:57
I agree, it would be great if you fix our dear HaaliRenderer ! :cool:
You are aware that the source code for Haali's renderer is not open? So how do you expect Beliyaal to change anything?
Kazuya
20th April 2009, 12:03
EVR/VMR9 are not open source either. Beliyaal made a customer presenter that works just fine with them. if he could do the same for HR, probably all the jitter problems with Reclock would vanish :)
iron2000
20th April 2009, 12:07
I think Alternative Vsync was meant for ATi cards. But it works on nVidia as well with 185.xx
Not on my PC.
Turning on Alternative Vsync gives me tearing on my ATI HD 2600 Pro.
yesgrey
20th April 2009, 13:05
EVR/VMR9 are not open source either. Beliyaal made a customer presenter that works just fine with them.
Yes, but VMR9 and EVR have support for custom presenters, and HR doesn't.
Leak
20th April 2009, 13:11
EVR/VMR9 are not open source either.
Nobody said it was, but they are designed to be extended (http://msdn.microsoft.com/en-us/library/dd407172(VS.85).aspx).
Beliyaal made a customer presenter that works just fine with them. if he could do the same for HR, probably all the jitter problems with Reclock would vanish :)
See, and that's where the problem is - unless I missed a lot of API documentation on Haali's page, there is no way to extend HR like there is with VMR/EVR...
fastplayer
20th April 2009, 13:19
Beliyaal made a customer presenter that works just fine with them.
No, Beliyaal extended resp. improved both presenters, he didn't write them from scratch.
duckyy
20th April 2009, 14:31
@Beliyaal : it seems that your VMR9 never misses the VSYNC fliptime in "alternate" VSYNC mode....would that be possible that you improve the HR presenter of MPC in the same way?
HR never drops frames whatsoever on XP(if the jitter <7.5ms), but it constantly misses the VSYNC fliptime when you reseek and never really "sticks" to it....if you could somehow make sure that it "behaves", the jitter would hopefully hardly ever move in 23.976@47.952/48Hz...and that'd be really great as HR seems much more stable than VMR9/EVR :)
:thanks:
That would be awesome, I'm just sick to have to seek to get a decreasing jitter at the beggining of my movies.
mark0077
20th April 2009, 19:23
Beliyaal, found something you may be interested in.
I was playing around today with some 1080p content at 60fps (originally 23.976fps but want to play at my displays refresh rate, just to see the smoothness and perfect red and green line ;) ). Here is what repeatedly happens on my machine and I thought it would be of interest to you.
The content will play fine, with the red line in the graph remaining perfectly flat. The green line (I assume indicating sync offset) starts a good bit off the red near the top of the graph (mpc-hc info says sync offset is about 60ms). Then over the course of maybe 30 seconds(?) this green line slowly but surely will reach the red line and both flatline.... then
BOOOM
immediately as they merge together perfectly I get a big spike, and the process repeats itself again and again. This gradual syncing of red and green happens again and each time they merge, SPIKE. It takes about 20-30 seconds to merge.
Maybe this might indicate a problem with your renderer. This is with the 1059 mpc-hc build. Below is a shot of the spike and my stats.
http://img25.imageshack.us/img25/7987/weirdproblem.th.jpg (http://img25.imageshack.us/my.php?image=weirdproblem.jpg)
EDIT: I have found that this seems to be caused by reclocks vsync correction (dunno why I had it enabled, DOH!) but still might indicate a problem with the evr-cp renderer. When I disable reclock's vsync correction the green and red line remain flat BUT about 300ms out of sync, the green line being at the extreme top of the graph mostly. Doesn't the evr-cp renderer do any work to get audio and video back in sync, ie shouldn't the red and green line merge together with evr-cp? With reclock's vsync correction the audio slowly becomes in sync with the video but as I say, with evr-cp they never come closer together. I thought your renderer could work to get audio / video in sync? This spike seems to still happen without reclock's vsync correction, but much less often. Its like reclock's efforts to get audio / video back into sync speeds up the onset of the spike, but even with it off the spike still seems to happen when red and line (somehow / sometimes) come close together.
To summarise, my questions are
1) Is evr-cp "supposed" to try and sync video and audio... If so its not working in my situation, 300ms out of sync with no apparant effort to get back to sync.
2) Any idea what might cause this glitch / spike every time audio and video sync seem to come close together. Its like some piece of code activates / deactivates when they come close, which might cause the spike?
leeperry
20th April 2009, 19:32
yeah I was also wondering why the 2 lines come and go depending on how many times I reseek :confused:
http://www.image-load.eu/out.php/t158568_beli.png (http://www.image-load.eu/out.php/i158568_beli.png)
also w/ EVR on XP SP3, when I close MPC the GUI goes away but MPC stays as a process that I have to kill...anyone knows what to do ?
many other ppl on HCFR have this problem, and I've always had it :o
I gave ProcessExplorer logs to Casimir666, but that did not help.
MatMaul
20th April 2009, 19:34
the tiny weird line at the bottom of videos is still here.
http://forum.doom9.org/showpost.php?p=1238622&postcount=5949
up, still here.
now that it is in the trunk it begins to be really annoying...
anyone who can reproduce ?? It is weird that nobody even mention it considering I can reproduce it on 2 completely different computers.
Jong
20th April 2009, 20:03
Beliyaal, found something you may be interested in.
I was playing around today with some 1080p content at 60fps (originally 23.976fps but want to play at my displays refresh rate, just to see the smoothness and perfect red and green line ;) ). Here is what repeatedly happens on my machine and I thought it would be of interest to you.
The content will play fine, with the red line in the graph remaining perfectly flat. The green line (I assume indicating sync offset) starts a good bit off the red near the top of the graph (mpc-hc info says sync offset is about 60ms). Then over the course of maybe 30 seconds(?) this green line slowly but surely will reach the red line and both flatline.... then
BOOOM
immediately as they merge together perfectly I get a big spike, and the process repeats itself again and again. This gradual syncing of red and green happens again and each time they merge, SPIKE. It takes about 20-30 seconds to merge.
Maybe this might indicate a problem with your renderer. This is with the 1059 mpc-hc build. Below is a shot of the spike and my stats.
http://img25.imageshack.us/img25/7987/weirdproblem.th.jpg (http://img25.imageshack.us/my.php?image=weirdproblem.jpg)
EDIT: I have found that this seems to be caused by reclocks vsync correction (dunno why I had it enabled, DOH!) but still might indicate a problem with the evr-cp renderer. When I disable reclock's vsync correction the green and red line remain flat BUT about 300ms out of sync, the green line being at the extreme top of the graph mostly. Doesn't the evr-cp renderer do any work to get audio and video back in sync, ie shouldn't the red and green line merge together with evr-cp? With reclock's vsync correction the audio slowly becomes in sync with the video but as I say, with evr-cp they never come closer together. I thought your renderer could work to get audio / video in sync? This spike seems to still happen without reclock's vsync correction, but much less often. Its like reclock's efforts to get audio / video back into sync speeds up the onset of the spike, but even with it off the spike still seems to happen when red and line (somehow / sometimes) come close together.
To summarise, my questions are
1) Is evr-cp "supposed" to try and sync video and audio... If so its not working in my situation, 300ms out of sync with no apparant effort to get back to sync.
2) Any idea what might cause this glitch / spike every time audio and video sync seem to come close together. Its like some piece of code activates / deactivates when they come close, which might cause the spike?Yeah, you must not enable Reclock vsync when another player is controlling it. We've talked about it here and on the Reclock forum. You have to be careful to be sure Reclcok has control, by putting up the Reclock vsync OSD and watching Reclock pull vsync into its target zone, before you leave it enabled.
What you are seeing with Reclock vsync on and vsync enforced by MPC-HC is the end of frame presentation "lapping" the point of vsync because Reclock is forever speeding up the video ever so slightly trying to fix a vsync it has no control over.
mark0077
20th April 2009, 20:06
Yeah, you must not enable Reclock vsync when another player is controlling it. We've talked about it here and on the Reclock forum. You have to be careful to be sure Reclcok has control, by putting up the Reclock vsync OSD and watching Reclock pull vsync into its target zone, before you leave it enabled.
What you are seeing with Reclock vsync on and vsync enforced by MPC-HC is the end of frame presentation "lapping" the point of vsync because Reclock is forever speeding up the video ever so slightly trying to fix a vsync it has no control over.
Thanks for the explanation. I would actually rather use evr-cp's sync and forgot to disable reclock's vsync setting. My concern is the fact that evr-cp doesn't seem to put any effort into getting my audio / video back into sync when I play some files at 60fps, they are WAAAAAY off audio / video sync.
Jong
20th April 2009, 20:15
Thanks for the explanation. I would actually rather use evr-cp's sync and forgot to disable reclock's vsync setting. My concern is the fact that evr-cp doesn't seem to put any effort into getting my audio / video back into sync when I play some files at 60fps, they are WAAAAAY off audio / video sync.Yeah I do not understand why you are getting 300ms gap.
Jong
20th April 2009, 20:20
also w/ EVR on XP SP3, when I close MPC the GUI goes away but MPC stays as a process that I have to kill...anyone knows what to do ?No. But it doesn't happen here with the same environment. I am using Beliyaal B25 and not the new merged build.
ice25
20th April 2009, 21:18
Indeed when i use EVR i get the same behaviour, green line (the audio) varies between 3ms and 39ms when i start a movie and remains there the whole time. The only way to get it to lower is to enable Reclock Vsync Correction till it arrives around 1ms and then deactivate it. Obviously this isn't how it's supposed to work and i wonder if beliyaal couldn't introduce some sort of mechanism to automate the audio sync to lower to around ~1ms. Or basically put a maximum audio desync which is very close to the red line.
mark0077
20th April 2009, 21:19
Indeed when i use EVR i get the same behaviour, green line (the audio) varies between 3ms and 39ms when i start a movie and remains there the whole time. The only way to get it to lower is to enable Reclock Vsync Correction till it arrives around 1ms and then deactivate it. Obviously this isn't how it's supposed to work and i wonder if beliyaal couldn't introduce some sort of mechanism to automate the audio sync to lower to around ~1ms. Or basically put a maximum audio desync which is very close to the red line.
Oh excellent, I guess we have to wait for beliyaal to see if this is expected behaviour or if he would expect his renderer to attempt to get them into sync over a certain period of seconds maybe.. My speeding up of blu-ray to 60fps just exxagerates this problem but will be my method of testing any changes to the renderer. I'm sure beliyaal has some tricks up his sleeve regarding this ;) I am trying to get less dependent on reclock for this type of thing.
Mark_A_W
20th April 2009, 22:20
Beliyaal, found something you may be interested in.
I was playing around today with some 1080p content at 60fps (originally 23.976fps but want to play at my displays refresh rate, just to see the smoothness and perfect red and green line ;) ).
It can't be smooth at 60hz. From memory you said you had a CRT projector? You could use any refresh rate you like.
Jong
20th April 2009, 22:22
It can't be smooth at 60hz. From memory you said you had a CRT projector? You could use any refresh rate you like.He is using Reclock to speed the video up to 60fps, so it will be smooth.
mark0077
20th April 2009, 22:23
"60fps playing at 60hz can't be smooth"?..... I think your a little mixed up....
I am using a Samsung Series 9 LCD, and happy with the slight judder playing 24fps at 60hz (I prefer the quality of 60hz pc mode compared to 24hz as "pcmode" on this display is like "don't mess with my video" mode, giving much better images). I am surprised however that beliyaals evr-cp doesn't seem to try and keep my audio / video in sync, which playing at 60fps exagerates as a problem somewhere. Reclock seems to get audio / video back to sync when its vsync is enabled, but I want to leave reclock's vsync off and only use it for 25-24 speed down.
I am hoping beliyaal can resolve the lack of audio / video sync which this speedup exxagerates.
Jong
20th April 2009, 22:28
By the way I was rummaging around in the thread and found this:
http://forum.doom9.org/showthread.php?p=1270741#post1270741
What are your EVR buffer settings?
mark0077
20th April 2009, 22:32
By the way I was rummaging around in the thread and found this:
http://forum.doom9.org/showthread.php?p=1270741#post1270741
What are your EVR buffer settings?
Nice find, I had mine at 3. 4 seems to have reduced the out of syncness from 300ms to 27-29ms. Still this 27-29ms delay doesn't reduce, it stays consistently flat on the graph, no attempt seems to be made to get the green line closer to the red one....
Thanks for that, didn't think buffers would effect audio / video sync so much....
What I find strange is, events like maximising my mpc-hc window obviously causes a slight jump in the graph, but wherever the green line ends up after the jump, it stays there. If I maximize window the green line may end up randomly anyhere from 50ms, to 20ms.... and again it doesn't move from here, stays wherever it started after the initial jump. See the jump in this graph after I maximized and the green line will stay wherever it randomly ended up after this jump.
http://img4.imageshack.us/img4/4909/bondc.th.jpg (http://img4.imageshack.us/my.php?image=bondc.jpg)
Forgive my pickyness, just trying to point out problems that may help improve beliyaals already excellent work.
Mark_A_W
20th April 2009, 22:33
I'm sorry, you are doing what Mark? (My mistake about the projector.)
There are no 60fps sources, not really.
And watching a 24fps movie at 60fps means the movie will last about half an hour. That's what 3:2 pulldown is for.
Or there is interpolation.
I'm lost.
mark0077
20th April 2009, 22:41
I'm sorry, you are doing what Mark? (My mistake about the projector.)
There are no 60fps sources, not really.
And watching a 24fps movie at 60fps means the movie will last about half an hour. That's what 3:2 pulldown is for.
Or there is interpolation.
I'm lost.
I'm just playing it at 60fps as a test (of course I would never watch a movie at over twice the normal speed), trying to give the renderer a workout to exxagerate some problems I see when playing at slower rates.
This lack of attempt to get audio / video sync happens for me at normal playback rate also but much easier test / see at higher fps thats all. Don't worry I'm not losing my mind ;)
Here is a blu-ray played at 30fps, which I would expect to easily get flatlines, red and green on my 60hz display, with both lines slowly moving towards eachother if found to be out of sync by the renderer. Here is a screenshot of just after I maximised the window, and you can see the green line randomly jumps up on the graph this time, and will never ever try to move lower... this is what I am asking about, whether this is expected behaviour, or should it attempt to reach perfect sync over time, ie move slowly down on the graph to meet the red line?
http://img22.imageshack.us/img22/6915/bond2.th.jpg (http://img22.imageshack.us/my.php?image=bond2.jpg)
Here is an illustration of what a couple of pause, play's can do to my graph, playing 30fps on 60hz display. See the different jumps each time I unpause, it seems to randomly higher / lower out of sync each time... never to return to perfect sync. This is with 5 buffers.
http://img22.imageshack.us/img22/8666/strangeu.th.jpg (http://img22.imageshack.us/my.php?image=strangeu.jpg)
Hypernova
21st April 2009, 00:53
I have only seen this happening with EVR buffers at minimum. Is this your case? Does it work if you raise them slightly? Could also be that you are using too much texture memory. With the screen at 2560x1600 it's eaten up quickly. Try EVR buffers at 5 and the same for subtitle buffers.
I have tried several buffers size and it does not seem to go away. Your suggestion at 5 is better than 20 that I used to use, but it's still happens sometime. I notice that it only happens when using DXVA. When DXVA is not activated, it seem like I got another weird issue: Sometimes the video suddenly play at a very fast speed. Maybe as fast as my machine can keep up. I'm not sure this is specific to (I guess your) VSync though, since I only notice this after going back to SVN when your branch merge into it.
Another thing I notice is that it is best to keep the subtitle buffer low to get the most smooth playback (with 2560x1600 texture size). Excluding zero and maybe 1 or 2. 3 seems to be optimal. Not sure why that's the case.
ice25
21st April 2009, 11:14
I'm just playing it at 60fps as a test (of course I would never watch a movie at over twice the normal speed), trying to give the renderer a workout to exxagerate some problems I see when playing at slower rates.
This lack of attempt to get audio / video sync happens for me at normal playback rate also but much easier test / see at higher fps thats all. Don't worry I'm not losing my mind ;)
Here is a blu-ray played at 30fps, which I would expect to easily get flatlines, red and green on my 60hz display, with both lines slowly moving towards eachother if found to be out of sync by the renderer. Here is a screenshot of just after I maximised the window, and you can see the green line randomly jumps up on the graph this time, and will never ever try to move lower... this is what I am asking about, whether this is expected behaviour, or should it attempt to reach perfect sync over time, ie move slowly down on the graph to meet the red line?
http://img22.imageshack.us/img22/6915/bond2.th.jpg (http://img22.imageshack.us/my.php?image=bond2.jpg)
Here is an illustration of what a couple of pause, play's can do to my graph, playing 30fps on 60hz display. See the different jumps each time I unpause, it seems to randomly higher / lower out of sync each time... never to return to perfect sync. This is with 5 buffers.
http://img22.imageshack.us/img22/8666/strangeu.th.jpg (http://img22.imageshack.us/my.php?image=strangeu.jpg)
The problem is probably that every time you start a movie your vsync starts at a different location, giving a varying degree of ms latency vs the audio. No idea on how to make the vsync behave though..
mark0077
21st April 2009, 11:19
The problem is probably that every time you start a movie your vsync starts at a different location, giving a varying degree of ms latency vs the audio. No idea on how to make the vsync behave though..
Ah thats understandable. I think the renderer should accomodate for this though, the average user won't know about vsync location etc... looking forward to Beliyaal's input on this problem I am seeing.
THX-UltraII
21st April 2009, 11:19
I ve been away for a few weeks and howly cow, things go fast these days :)
I have a questions about Beliyaals MPC-HC version:
Is reclock still needed? I ask this because I see in the history version of Beliyaals version (on page 1)
* Fixed: Refresh rate now detected in VMR9 as well.
* Fixed: Refresh rate detection should now be more accurate.
I use Reclock for the build-in PAL-speeddown function to play my 25fps PAL movies at the original 23,976fps rate. Can MPC-HC do this on its own nowdays?
Would be great because I keep having lipsync issues with ReClock
mark0077
21st April 2009, 11:23
I ve been away for a few weeks and howly cow, things go fast these days :)
I have a questions about Beliyaals MPC-HC version:
Is reclock still needed? I ask this because I see in the history version of Beliyaals version (on page 1)
* Fixed: Refresh rate now detected in VMR9 as well.
* Fixed: Refresh rate detection should now be more accurate.
I use Reclock for the build-in PAL-speeddown function to play my 25fps PAL movies at the original 23,976fps rate. Can MPC-HC do this on its own nowdays?
Would be great because I keep having lipsync issues with ReClock
I'm in the same situation as you, using reclock only for pal speed down. Hoping to see these sync problems ironed out in mpc-hc fully so I can completely get rid of reclock for anything other than 25->24 speed down.
Beliyaal's build doesn't have a pal speed down function yet.
Jong
21st April 2009, 12:16
I ve been away for a few weeks and howly cow, things go fast these days :)
I have a questions about Beliyaals MPC-HC version:
Is reclock still needed? I ask this because I see in the history version of Beliyaals version (on page 1)
* Fixed: Refresh rate now detected in VMR9 as well.
* Fixed: Refresh rate detection should now be more accurate.
I use Reclock for the build-in PAL-speeddown function to play my 25fps PAL movies at the original 23,976fps rate. Can MPC-HC do this on its own nowdays?
Would be great because I keep having lipsync issues with ReClockI'd be interested in Beliyaal's comments on the VMR9 state of play. There are now so many permutations of presentation/renderer/output settings it is hard to be sure (;)) but on XP SP3 I have not found a VMR9 combination that works. All still seem vulnerable to synchronised judder at start/after seek.
So I am still using Reclock for both frame rate adaptation and vsync correction using VMR9 D3D mode, vsync "off", alternate vsync "disabled", D3D GUI "off". Beliyaal's fixes help to tighten up presentation but do nothing to avoid synchronised judder with VMR9 in any of the combinations I have tried!
If there is a way to get reliable vsync control under XP with VMR9 using MPC-HC alone I'd like to know.
Also, if there is a way to get frame rate adaptation (although I don't think that is there).
plaus
21st April 2009, 12:59
DVD menus are buggy using your build.When I try to play a DVD I get a flashing black square in my picture and I also cannot click/navigate through the menus. It's an issue I don't have with the normal MPC-HC. The flashing square goes away when I manually open the right .vobs and then I have normal playback.
I'm using Vista SP1. I'm using EVR custom pres with a Radeon HD3870x2 GPU drivers 8.512. I don't use Aero.
Can't post screenshot as it won't cap the flashing square.
ice25
21st April 2009, 15:49
Ah thats understandable. I think the renderer should accomodate for this though, the average user won't know about vsync location etc... looking forward to Beliyaal's input on this problem I am seeing.
If i remember correctly beliyaal mentioned a while ago, that you couldn't manipulate the vsync position, but instead had to manipulate the audio or refresh rate to make it drift in a sync'd location. The easiest method would be to pause the audio till it reached a good sync position, or set a max value of audio desync (1ms) where the audio would be dropped to get in sync again.
mark0077
21st April 2009, 15:54
If i remember correctly beliyaal mentioned a while ago, that you couldn't manipulate the vsync position, but instead had to manipulate the audio or refresh rate to make it drift in a sync'd location. The easiest method would be to pause the audio till it reached a good sync position, or set a max value of audio desync (1ms) where the audio would be dropped to get in sync again.
Ah ok and I also remember beliyaal telling me he had implemented what you talk about here but I think it was removed because users complained..... ugh....
I think audio has to be dropped to get audio / video back to sync, or maybe beliyaal has other ideas on speeding up / slowing down video to get back to sync (and maybe in future builds if beliyaal builds in the ability to speed up / slow down audio for us pal users he could use this ability to more seemlessly get audio / video back to sync without anyone hearing any blips, I think this may be what reclock does).
anyone23
21st April 2009, 21:32
Hi,
starting with build ~20 MPC-HC gets crazy sometimes and seems to decode the video as fast as possible.
When I look at the stats with Strg + J the Refreshrate field shows some very strange letters (instead of 55-65 hz).
It happens randomly on my files every ~20-60 minutes (PAL DVB-C/DVD MPEG2).
Is there already a fix for this (maybe by forcing the refreshrate)?
PC:
WinVista SP1
ATI HD 2400 Xt Mobility
Catalyst 9.4
Laptop TFT @ 60 hz
newest MPC-HC/ffdshow from xvidvideo.ru
EVR custum
build 18 works
DigitalDeviant
23rd April 2009, 04:43
Hi,
starting with build ~20 MPC-HC gets crazy sometimes and seems to decode the video as fast as possible.
When I look at the stats with Strg + J the Refreshrate field shows some very strange letters (instead of 55-65 hz).
It happens randomly on my files every ~20-60 minutes (PAL DVB-C/DVD MPEG2).
Is there already a fix for this (maybe by forcing the refreshrate)?
PC:
WinVista SP1
ATI HD 2400 Xt Mobility
Catalyst 9.4
Laptop TFT @ 60 hz
newest MPC-HC/ffdshow from xvidvideo.ru
EVR custum
build 18 works
This seems similar to something I'm getting, though I'm only seeing it in .mkv w/ AVC in certain situations. It seems limited to CoreAVC and Haali's splitter. Removing either by using the internal component seems to work OK. MPEG2 in .mkv also seems to work fine with Haali's. Also, enabling "Disable Desktop Composition" seems to fix the issue but causes tearing in the first few seconds of the file and after seeking.
http://img16.imageshack.us/img16/742/error2ahq.png
System specs:
Vista Basic SP1
Nvidia Geforce 9600GT
60hz LCD
Hypernova
23rd April 2009, 06:14
I posted about it before that I'm getting the "decode as fast as possible" too but I don't think it limited to CoreAVC or HR. I don't even have CoreAVC and I generally don't use HR.
Ger
23rd April 2009, 18:47
I have seen this (or a very similar) issue with no CoreAVC as well. I know I've seen it with mkv, 720p H.264, Haali splitter + internal H.264 DXVA decoder. The few times I've seen it, the refresh rate always looks like DigitalDeviant's screenshot (with the #IND). When everything works fine the (CTRL-J stats) refresh rate is displayed as 59.95-ish on my LCD.
I've been planning to take/post a similar screenshot for a while, but In my case this issue happens very rarely (I've probably used MPC-HC several hundred times without seeing this since the last time it happened), and I've found no way to reproduce it at will. So I certainly don't have this problem every 20-60 mins like anyone23. So maybe they are diffrent issues after all.
Settings:
Vista SP-1
Nvidia 8800GT
EVR CP with 5 EVR buffers. Alternative Vsync off (at least I think it was). Otherwise everything relevant I can think of is default.
STaRGaZeR
23rd April 2009, 20:53
In some programs I coded some time ago I got the "-1.#IND0" result when a variable was divided by zero and the result was directly writen into a text file. Maybe that's what is causing the problem here?
Hypernova
24th April 2009, 04:42
More report on -1.#IND0 issue. It seem to happen a lot when audio and video is constantly out of sync. For example, in my case, if I allow desktop resolution for subtitle texture size, which cause the green and red line deviate from each other a bit every time subtitle is displayed, this issue will happen a lot. If I reduce the texture size such that the two line always stay together (save for the up and down due to monitor/video refresh rate is not integer), this issue rarely happen.
Ger
26th April 2009, 16:21
In case more screenshots could be useful in finding the cause of this problem:
Just had this issue again for the first time in probably 2-3 weeks. This time with a run of the mill xvid avi, using internal avi splitter and internal xvid and mp3 decoders. So no Haali splitter or H.264/DXVA this time. No subtitles.
When the problem occurs the refresh rate is as previously mentioned displayed as -1,#IND0 and the frame rate is increased from around 23.976 to around 59.954 (which is just about what my Dell 2709W refresh rate is in the stats when everything is working fine). The video obviously outruns the audio at this frame rate, and sync is never achieved. The audio sounds normal for a while (while the video keeps speeding ahead) until it just stops playing.
The screenshots are both taken during fullscreen playback. Not of the same frame, but hopefully that isn't needed.
Problem:
http://img99.imageshack.us/img99/4836/superspeedvideo.th.png (http://img99.imageshack.us/img99/4836/superspeedvideo.png)
OK (after MPC-HC restart):
http://img99.imageshack.us/img99/2826/normalspeedvideo.th.png (http://img99.imageshack.us/img99/2826/normalspeedvideo.png)
System:
MPC-HC SVN build 1060
Vista32 SP1 with desktop composition enabled
Nvidia 8800GT
Beliyaal
27th April 2009, 01:30
I have submitted a possible fix for the refresh rate being -1,#IND0. Will be in SVN build 1071
Ashed
27th April 2009, 07:26
I just tried the Beliyaal build and found that it fixed the audio sync problem I had with the regular Homecinema build when playing 1080p x264 MKV files @ 24 Hz. However, I don't understand what the three Vsyncs options actually do but apparently, I get the best results with the Vsyncs off. I get up to -30 ms audio sync when I turn on Vsync, why is this?
Beliyaal
27th April 2009, 08:14
I just tried the Beliyaal build and found that it fixed the audio sync problem I had with the regular Homecinema build when playing 1080p x264 MKV files @ 24 Hz. However, I don't understand what the three Vsyncs options actually do but apparently, I get the best results with the Vsyncs off. I get up to -30 ms audio sync when I turn on Vsync, why is this?
With VSync off the audio sync stats are meaningless, just use the default settings, or optionally the optimal settings.
mark0077
27th April 2009, 10:18
Beliyaal, do you think you would get a chance to look into improving audio / video sync for an upcoming build. You might have seen my posts earlier describing the fact that when audio / video go out of sync for whatever reason, without reclock the current builds don't attempt to get back to sync at all, they stay the same value out of sync for the rest of the movie.... and I managed to exxagerate this playing a clip faster than normal, giving me hundreds of ms out of sync sometimes.
Would be great to see audio / video coming back to sync over the space of a couple of seconds, or even better than nothing would be to have an abrupt change in video / audio speed to get back to 0ms off.
Nothing worse than an otherwise impressive HT setup, when the gf says "their mouth's arn't moving with their voices", or "they look like they are miming" ;).. and this seems to happen to me at least a few times a week now.. sometimes if I come accross a scratched disk from the video store especially.. I would need to get up and reseek to get audio / video back... of course with reclock it will speedup / slowdown the audio to get back to sync but I don't want to become too dependent on reclock.
Beliyaal
27th April 2009, 13:04
Beliyaal, do you think you would get a chance to look into improving audio / video sync for an upcoming build. You might have seen my posts earlier describing the fact that when audio / video go out of sync for whatever reason, without reclock the current builds don't attempt to get back to sync at all, they stay the same value out of sync for the rest of the movie.... and I managed to exxagerate this playing a clip faster than normal, giving me hundreds of ms out of sync sometimes.
This must be with EVR buffers at 3. I have now limited the buffers to 4 minumum.
Would be great to see audio / video coming back to sync over the space of a couple of seconds, or even better than nothing would be to have an abrupt change in video / audio speed to get back to 0ms off.
Just pausing the graph to get in sync isn't an option that I find appealing, so nothing I can do other than resampling the audio or changing the display refresh rate. And I do plan to add support for this.
Nothing worse than an otherwise impressive HT setup, when the gf says "their mouth's arn't moving with their voices", or "they look like they are miming" ;).. and this seems to happen to me at least a few times a week now.. sometimes if I come accross a scratched disk from the video store especially.. I would need to get up and reseek to get audio / video back... of course with reclock it will speedup / slowdown the audio to get back to sync but I don't want to become too dependent on reclock.
The maximum sync difference is the minimum time of one frame or one screen refresh, whichever is the smallest value. This translates to 16 ms maximum in your case. Really it's not that important until I have added audio/video sync calibration support, because you never know the delay for the processing in the receiver or TV. Probably the error will be larger there.
mark0077
27th April 2009, 13:10
This must be with EVR buffers at 3. I have now limited the buffers to 4 minumum.
Just pausing the graph to get in sync isn't an option that I find appealing, so nothing I can do other than resampling the audio or changing the display refresh rate. And I do plan to add support for this.
The maximum sync difference is the minimum time of one frame or one screen refresh, whichever is the smallest value. This translates to 16 ms maximum in your case. Really it's not that important until I have added audio/video sync calibration support, because you never know the delay for the processing in the receiver or TV. Probably the error will be larger there.
Your right, using 4 buffers does improve it ALOT but still getting out of sync by quite a bit sometimes, like 30ms... Definitely looking forward to your future work on this. I know my TV has about 20ms delay but ffdshow gets rid of this for me by adding the audio delays but of course only when a player outputs in sync. Cheers for the feedback.
Ashed
27th April 2009, 14:02
With VSync off the audio sync stats are meaningless, just use the default settings, or optionally the optimal settings.
That's the thing, I get around -30 ms audio sync with the default and optimal settings. :confused:
mark0077
27th April 2009, 14:08
That's the thing, I get around -30 ms audio sync with the default and optimal settings. :confused:
What is your display refresh rate? I am seeing similar higher than beliyaal expected, audio video sync problems using 60hz display, playing 24fps material. In my setup I am told I should see 16ms max...
Ashed
27th April 2009, 14:36
What is your display refresh rate? I am seeing similar higher than beliyaal expected, audio video sync problems using 60hz display, playing 24fps material. In my setup I am told I should see 16ms max...
24 Hz playing 24 fps material.
ice25
27th April 2009, 14:57
Well at least now we know beliyaal will add audio/video sync calibration support in the near future. Good thing.
Beliyaal
27th April 2009, 18:24
24 FPS at 24 Hz is up to 41.6 ms AV-sync difference, as the frame time is 41.6 ms
@mark0077:
I think your -30 ms sync is because of your sped up clock. The code doesn't correct for the 250% clock speed. Will add that correction.
mariner
27th April 2009, 18:37
Greetings Beliyaal.
H264 DXVA playback has been broken since ver 1056. Black screen with only audio. XP3 with HD 3650 AGP graphics card.
VC1 is fine.
Here's a sample:
http://www.sanyo-dsc.com/products/lineup/dmx_hd2000/img/sample/movie_sample_hd2000_01.zip
mark0077
27th April 2009, 18:51
24 FPS at 24 Hz is up to 41.6 ms AV-sync difference, as the frame time is 41.6 ms
@mark0077:
I think your -30 ms sync is because of your sped up clock. The code doesn't correct for the 250% clock speed. Will add that correction.
Thanks, just trying to really push an already great renderer to its limits as it currently stands, cheers for that.
Ashed
28th April 2009, 04:13
24 FPS at 24 Hz is up to 41.6 ms AV-sync difference, as the frame time is 41.6 ms
How can I fix this? Surely, there has to be a way to get video and audio to be perfectly in sync?
Beliyaal
28th April 2009, 09:29
How can I fix this? Surely, there has to be a way to get video and audio to be perfectly in sync?
Sorry right now the only way to do it is to switch between 23.976 and 24 Hz to get the sync in the desired location.
The problem is that the relation between the time for the VSync and the audio time is fixed, nothing can be done about it other than resampling the audio or changing the refresh rate for a while to get relation to change. This is what I'm adding next featurewise.
ikarad
1st May 2009, 20:35
Sorry right now the only way to do it is to switch between 23.976 and 24 Hz to get the sync in the desired location.
The problem is that the relation between the time for the VSync and the audio time is fixed, nothing can be done about it other than resampling the audio or changing the refresh rate for a while to get relation to change. This is what I'm adding next featurewise.
Excuse me but I have any problem with subtitle and dvds. Maybe you can fix this problem.
This problem is related here
https://sourceforge.net/tracker/?func=detail&aid=2466321&group_id=170561&atid=854651
Would it be possible to get a higher res out of the thumbnails size?
It is currently limited by 2048!
I would prefer sth like 10000...
KornX
shaolin95
2nd May 2009, 22:37
I am not sure when it started but I got version 15 and at least from 22 and up or so the player is slower now.
I notice it right away when playing a rip of Training Day. With version 15 an older it runs perfectly smooth but with 22 and up it plays slow.
What changed?
Regards
BTW, does MPC benefit of having 4GB vs 2GB under Vista 64?
I decided to use the regular EVR as my renderer for now since I can't get 24 fps videos to play without having audio syncing issues. :(
anybody
9th May 2009, 11:18
NOTE: All my changes are currently integrated into SVN
I will use this thread in the future for testing of experimental new features.
Where can I get these SVN versions or daily MPC-HC Builds ?
I've searched a lot but not found anything :-(
They are posted almost daily in the huge Media Player Classic Homecinema topic. How could you have missed them?
You can find them at http://xvidcodec.ru
anybody
9th May 2009, 12:18
They are posted almost daily in the huge Media Player Classic Homecinema topic. How could you have missed them?
You can find them at http://xvidcodec.ru
Thanks! I missed them by searching using google für "media player classic svn" or media player classic daily build" and not reading a thread, sorry :-)
PS: I now read the thread, it's http://www.xvidvideo.ru/ actually :-)
Thanks again!
Kaotech
18th May 2009, 23:28
With "alternative Vsync" what's the best way to avoid tearing, i'm using VMR9, with vsync, accurate vsync, flush Gpu before vsync and flush gpu after present.
With offset -2 or less , i've no tearing but during playback, my refresh rate is not fixe, with offset +3, my refresh rate is fix but i've tearing at the top.
Can you help to resolve that ?
I have asked Beliyaal a few times to clear up the status of VMR9. But, as far as I can see Synchronised frame rate/refresh rate judder is NOT fixed with VMR9 only with EVR. If you want true judder-less playback of VMR9 you need to use:
- VMR9(renderless) D3D
- alternate vsync UNTICKED
- vsync UNTICKED
- D3D GUI support OFF
- Reclock with vsync correction ON
The Beliyaal enhancements still do good things to tighten up presentation, but Reclock is needed to avoid synchronised judder and for it to work it needs to be able to control vsync without tearing. The above settings acheive that.
mark0077
19th May 2009, 18:17
Beliyaal, have you any idea why the output from your builds might sometimes play at the wrong speed. Sometimes loading a file, its framerate can be output completely wrong by mpc-hc. I reported this before when a 24fps file was being output at 30fps or something. Today I played a blu-ray from disk, and it was output by evr-cp at exactly 11.988 fps. Both ffdshow and reclock indicated this fps aswell as the mpc-hc interface. Reloading the disk stopped this as is always the case.
Definitely some quirks with the new changes you have implemented but very hard to reproduce consistently. Maybe if you had an idea what might be the cause you could come up with a way to reproduce / test / fix.
tetsuo55
19th May 2009, 19:32
Beliyaal, have you any idea why the output from your builds might sometimes play at the wrong speed. Sometimes loading a file, its framerate can be output completely wrong by mpc-hc. I reported this before when a 24fps file was being output at 30fps or something. Today I played a blu-ray from disk, and it was output by evr-cp at exactly 11.988 fps. Both ffdshow and reclock indicated this fps aswell as the mpc-hc interface. Reloading the disk stopped this as is always the case.
Definitely some quirks with the new changes you have implemented but very hard to reproduce consistently. Maybe if you had an idea what might be the cause you could come up with a way to reproduce / test / fix.
this might be a ffdshow bug (i found the same problem with dvd's) can you try another decoder?
mark0077
19th May 2009, 20:46
Well its so hard to reproduce, it might be another week or two until I might see it again.
I don't think its ffdshow because I have seen it with DVD's with ffdshow's libmpeg2 decoder AND when using mpc-hc's software vc-1 decoder (happened today). I hate bugs like this. I have a feeling its evr-cp though, never ever saw this with the older evr-cp pre beliyaal. Someone might know where the problem lies when mpc-hc AND ffdshow AND reclock all said movie fps was 11.988fps instead of 23.976. This was today as I say using mpc-hc vc-1 software decoder but happened before with DVD in ffdshow decoders.
EDIT: Actually reproduced it again just now with a m2ts file using internal mpc-hc vc-1 decoder. reclock and ffdshow said the movie fps was 23.976 BUT mpc-hc was showing 60fps, the video was going really really fast obviously. Horrible when it happens.
Ashed
1st June 2009, 05:56
Sorry right now the only way to do it is to switch between 23.976 and 24 Hz to get the sync in the desired location.
The problem is that the relation between the time for the VSync and the audio time is fixed, nothing can be done about it other than resampling the audio or changing the refresh rate for a while to get relation to change. This is what I'm adding next featurewise.
So I've been playing with the regular Homecinema build from http://mpc-hc.sourceforge.net/ and it seems like the sync issue is only present when I select EVR Custom Presenter as the renderer. Video and audio are perfectly in sync with EVR... This also only occurs when I set my TV's refresh rate to 23 Hz (23.976 Hz).
leeperry
25th June 2009, 15:35
any news on the "dropped frames" stat? :thanks:
Kazuya
25th June 2009, 17:05
One month without any post !?
What happened ?
All people is satisfied ???:p
nurbs
25th June 2009, 17:35
Changes got merged with MPC-HC. Discussion continues in that thread.
anybody
25th June 2009, 18:45
By the way, is there an archive available somewhere of all the old Beliyaal builds?
I've recently found a bug that was introduced in SVN during the Beliyaal merge.
If the old builds were available somewhere I could test them to specify more exactly on what day the problem was introduced in my bug report @ SF...
headrat
11th July 2009, 12:40
Sorry if I'm being thick but where can I download, I don't see any dowload links?
tetsuo55
11th July 2009, 12:41
look at my signature
smok3
20th July 2009, 08:27
q: are utf-8 subtitles supported?
stpdrgstr
30th July 2009, 16:32
Guys, I've been testing and, since r1120, automatic aspect ratio detection seems to be ignored in EVR Custom and videos stay at 1:1. I can't see anything in the changelog that could affect it.
I'm using Windows XP. Am I doing something wrong?
me7
11th December 2009, 16:27
I got here because this post (http://forum.doom9.org/showpost.php?p=1269168&postcount=3) says that MPC-HC can play Blu-Ray discs but I can't get it to work.
Opening a bdmv file does not work, opening an mpls doesn't do it, neither does opening the folder as a dvd...
rack04
11th December 2009, 16:37
I got here because this post (http://forum.doom9.org/showpost.php?p=1269168&postcount=3) says that MPC-HC can play Blu-Ray discs but I can't get it to work.
Opening a bdmv file does not work, opening an mpls doesn't do it, neither does opening the folder as a dvd...
Use File->Open DVD and select the folder.
DMD
6th January 2010, 16:10
Or directly use keyboard commands Ctrl + D + Enter
One thing missing is the autoplay for DVD or Blu-ray
Bye
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.