MPC-HC GothSync tryouts

[Jong]

Hi, I just ran a full movie with Reclock w/o vsync correction and Present at nearest and got 2 ms of drift during 6800 seconds of movie. So there *is* drift, but not much. In this particular case I had zero sync glitches as the drift entirely fit into one refresh period. In the worst case I would have got one glitch. With vsync correction I get sync offsets all over the place. With VMR9 in the regular build MPC (and my build) I get severe judder with Reclock w/ vsync correction turned on no matter how I set the vsync ruler. I'll look more into this. -AMaybe tell me what you see or you post a screenshot and I might be able to help. If there is one thing I have spent a lot of time with it is fixing judder with Reclock!

As I mentioned you must use D3D mode with Reclock vsync correction. Then the graph should look like this and stay this way forever:

http://jong.pwp.blueyonder.co.uk/images/mpcgs_003.jpg

With D3D mode OFF this is the "rolling sync" you normally see due to Reclock continually running at a slightly too fast/slow refresh rate (watch the green line!):

http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_2.jpg
http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_3.jpg
http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_4.jpg
http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_5.jpg

Obviously you cannot see this graphically with the beliyaal build but you can see it by watching the "present wait" figure, with vsync set "off" (not actuall off!), or "VBlank Wait", with vsync set "ON".

If you turn off DXVA and turn on the Reclock vsync markers you can also see if there is a problem. In the above example the vsync marker will be "pinned" at the top of the screen and will never approach the target zone (Marked by the other two white lines).

[FoLLgoTT]

@ar-jar
Great work! :)

But I have a strange problem. The sync graph is not painted on my HTPC with your tryout and private build. On my other PC with nearly the same configuration everything is correct. I attached a screenshot of the display stats. Do you have any idea?

http://img142.imageshack.us/img142/2360/unbenanntfc.th.jpg (http://img142.imageshack.us/i/unbenanntfc.jpg/)

Configuration:

Windows Vista, ATI 3850, EVR Custom Presenter, Sync video to display

And by the way, should the tearing test work?

[Jong]

Hi,

the way i understand ar-jays method it might have the potential to circumvent the judder due to the slow drift. In essence instead of going into a long period of judder it should just drop or repeat one frame and then be fine again for the next lets say 45 minutes.... this would be reasonable, and perfectly fine for movie playback.

We discussed this way back with james from slysoft and beliyaal and the consensus was that perfection can only be achieved if the vsync handler could actually talk to reclock (which in turn uses the reference clock to adjust the speed of video). But ar-jays code could do without that, trading absolute perfection for one occasional dropped or repeated frame. I think it would be a worthwhile compromise.If you cannot put up with D3D mode I agree. If you can then Reclock vsync is better, or ar-jar's option 1 if you refresh rates are near identical.

On the other hand, ar-jar, it is the buffering in D3D mode that seems to allow Reclock's vsync to work. PowerDVD seems to use [triple?] buffering that allows Reclock vsync to work in VMR9 WITHOUT D3D. If you could implement a renderer like this for MPC-HC it would make Reclock usable by many more people.

[tetsuo55]

@ar-jar
Great work! :)

But I have a strange problem. The sync graph is not painted on my HTPC with your tryout and private build. On my other PC with nearly the same configuration everything is correct. I attached a screenshot of the display stats. Do you have any idea?

http://img142.imageshack.us/img142/2360/unbenanntfc.th.jpg (http://img142.imageshack.us/i/unbenanntfc.jpg/)

Configuration:

Windows Vista, ATI 3850, EVR Custom Presenter, Sync video to display

And by the way, should the tearing test work?did you install the latest directx redist? (link in my signature)

[ar-jar]

@ar-Jar
The lastest private build(downloaded 5 minutes ago) breaks syncnearest on my laptop. This is the worst its ever looked.

Both the green and red look like hearbeat monitors, and i get glitches every second.

I noticed you enabled vsync again, no difference however with it on or off

Pls try the new one. I'm off for a few days though so make a note of your bugs and report them to me later when I'm on-line (or on my blog). Thanks! -A

[FoLLgoTT]

did you install the latest directx redist? (link in my signature)

Thanks! After an upgrade to the newest DirectX I can see the sync graph. :)

[tetsuo55]

Pls try the new one. I'm off for a few days though so make a note of your bugs and report them to me later when I'm on-line (or on my blog). Thanks! -ANo difference for the private build i downloaded just now.

[ar-jar]

No difference for the private build i downloaded just now.

Does the last regular build work better? -A

[tetsuo55]

Regular MPC and last stable mpc-hc gothsync are behaving as good as we've got it so far

[ADude]

I assume that when beliyaal replaced the microsoft vsync handler with his own this sort of broke VMR9 for me and introduced the tearing

and

Beliyaal's code allows you to turn off vsync in VMR9, but that just seems to mean you flip buffers as soon as a frame is complete, so it tears.

So, evidently in this thread, everyone knows that Beliyaal's code tears.

But if you say so in the MPC-HC thread, then it is heresy and you are kicked out ??

If the concept is to have intelligent technical discussion in this thread, and leave the MPC-HC thread to children who think that a two year old video card is "old and outdated", then someone should have at least said so in a PM, and a lot of trouble would have been avoided...

[Casshern]

Please do not disinform through quoting out of context. I said that beliyaal's "GPU Flush" options fixed the tearing for me with VMR9. Before beliyaal's code VMR9 and DXVA was completely useless on my video card due to severe frame stuttering (wrong buffers being displayed). With "GPU Flush" and VMR9 on everythings works nicely here with beliyaals code - my remark was directed at very early beliyaal builds where he didn't include the gpu flush stuff. I only brought it up here because ar-jay removed some of this code in his experimental builds, so the tearing is back in those builds as the "gpu flush" options have no effect anymore.

Please do never quote me again, as i do not want to waste time answering your troll attempts.


and



So, evidently in this thread, everyone knows that Beliyaal's code tears.

But if you say so in the MPC-HC thread, then it is heresy and you are kicked out ??

If the concept is to have intelligent technical discussion in this thread, and leave the MPC-HC thread to children who think that a two year old video card is "old and outdated", then someone should have at least said so in a PM, and a lot of trouble would have been avoided...

[ADude]

Please do not disinform through quoting out of context. I said that beliyaal's "GPU Flush" options fixed the tearing for me with VMR9. ...

Please do never quote me again, as i do not want to waste time answering your troll attempts.

Oops, sorry for taking you out of context.

Such as the context of other posts where you state that GPU Flush options have caused judder problems, and where Tetsuo55 states they have caused macroblocking problems.

I only brought it up here because ar-jay removed some of this code in his experimental builds, so the tearing is back in those builds as the "gpu flush" options have no effect anymore.

Amazingly parallel to my own statement of " Belliyaal removed some of the code in his experimental builds (that were merged with main version), so the tearing is back in the main version, because he removed the code that parallels ar-jar's ' present at next vsync' ".

So, you want me to respect your statement, but when I say the same thing, it is "trolling".

And I mistakenly thought that perhaps there was some place we could talk just about technical issues, but never mind...

[foxyshadis]

Struck for rule 16. The issue of Baliyaal's vsync code is closed. Any further derailings will be a suspension.

[ar-jar]

If you cannot put up with D3D mode I agree. If you can then Reclock vsync is better, or ar-jar's option 1 if you refresh rates are near identical.

On the other hand, ar-jar, it is the buffering in D3D mode that seems to allow Reclock's vsync to work. PowerDVD seems to use [triple?] buffering that allows Reclock vsync to work in VMR9 WITHOUT D3D. If you could implement a renderer like this for MPC-HC it would make Reclock usable by many more people.

I use triple buffering in my old player in both windowed and exclusive mode. So it's definitely doable but it doesn't work immediately in MPC (did a very quick test). MPC currently uses one backbuffer in windowed mode. If I change that to three (simultaneously doing some other necessary chances that with a single buffer work fine), I won't get any video output. THe reason for this should be relatively easy to find since I have a "correct answer" to look at. The main difference between my old renderer and the MPC renderer is that I render a texture on a "virtual moviescreen" (a 3d object) whereas MPC uses a "strechrect" which I believe is a blt. I'll add this to my todo-list. -A

[mariner]

Greetings ar-jar. Thanks for the kind reply.

1. If you look at the attached capture, it shows that your new vsync option does not produce as clean a result as Casimir's latest build.

2. You may have overlooked my other post 9005 vs 9012. If vsync is set to synchronized video, 9005 will quickly settle on the target refresh rate, but not 9012. So which one is reporting the frame rate correctly?

3. Tearing is still an issue and seems to occur most frequently when playing 24fps content with 24Hz refresh rate. In my case, it appeared near the bottom of the screen, and the position is the same for both your build and Casimir's. Enabling D3DFullScreen is the only way to eliminate it.

Best regards.

[Jong]

Hi, I just ran a full movie with Reclock w/o vsync correction and Present at nearest and got 2 ms of drift during 6800 seconds of movie. So there *is* drift, but not much.Seems your system is a bit better than mine!:)

Just did my own similar test and I get 1ms of drift about every 20mins. It happens this drift is always in the same direction on my system (at least today) but I'm sure it could go either way, maybe even on my system another time. Normal variability in presentation is about +/- 1-2ms. So if I use option3 instead of Reclock vsync correction or your option 1 and set the starting offset @10ms (in the middle). It should be about 2 1/2 hours before I get one single dropped frame. Not bad. Trouble is, on my system at least, I very occasionally (once or twice a movie) get presentation shifting out up to 7.5ms. So if it is kept nice and tight on 10ms (as with option 1) I get no glitches. With option 3 I would get maybe a couple. Still at least they would be single frames, not long periods of judder and at least the starting offset is fixed, not random, as without any vsync correction. A huge improvement!

I guess what it shows though is that the drift can vary from system to system and I am sure the peaks will vary depending on on "tied down" the system is. So with anything but option1/option2/Reclock vsync correction some skips are likely. Option 3 is a very good second best, but how good will depends on the speed of drift and the general stability of presentation.

I would recommend this player even to to anyone planning on using Reclock vsync correction.The min/max/av. offset display let's you position the Reclock vsync marker with precision, instead of with educated guesswork!

[Jong]

I use triple buffering in my old player in both windowed and exclusive mode. So it's definitely doable but it doesn't work immediately in MPC (did a very quick test). MPC currently uses one backbuffer in windowed mode. If I change that to three (simultaneously doing some other necessary chances that with a single buffer work fine), I won't get any video output. THe reason for this should be relatively easy to find since I have a "correct answer" to look at. The main difference between my old renderer and the MPC renderer is that I render a texture on a "virtual moviescreen" (a 3d object) whereas MPC uses a "strechrect" which I believe is a blt. I'll add this to my todo-list. -AThis sounds exciting! Great.

[tetsuo55]

Greetings ar-jar. Thanks for the kind reply.

1. If you look at the attached capture, it shows that your new vsync option does not produce as clean a result as Casimir's latest build.

2. You may have overlooked my other post 9005 vs 9012. If vsync is set to synchronized video, 9005 will quickly settle on the target refresh rate, but not 9012. So which one is reporting the frame rate correctly?

3. Tearing is still an issue and seems to occur most frequently when playing 24fps content with 24Hz refresh rate. In my case, it appeared near the bottom of the screen, and the position is the same for both your build and Casimir's. Enabling D3DFullScreen is the only way to eliminate it.

Best regards.Your picture has not been approved yet, can you upload it to imageshack.us or something?

You cannot compare the graph to casimir because the gothsync graph is more revealing.

[Jong]

ar-jar, one, hopefully small, request for your to-do list!

Can you either change to using percentages for the target offset - so 50% would mean 10ms @50Hz and 8ms @60Hz - or allow several figures to be set for different common refresh rates. Quite a lot are using different refresh rates for different media. The first sounds a lot easier and I cannot see the downside, but you may know different!

[Jong]

ar-jar,

could your renderer (VMR9 specifically) have problems with DVD playback (i.e when using DVD Navigator)? I know MAD-VR had/still has issues to do I think with menu transitions etc.

I am getting frequent "lock-ups" trying to play full discs with your player that I do not get with the current trunk build.

[Jong]

ar-jar,

could your renderer (VMR9 specifically) have problems with DVD playback (i.e when using DVD Navigator)? I know MAD-VR had/still has issues to do I think with menu transitions etc.

I am getting frequent "lock-ups" trying to play full discs with your player that I do not get with the current trunk build.It may be just D3D mode. Trying to play a disc in this mode is guaranteed to lock-up either at first play, or the main menu, or before the movie starts. yet to get a movie (in DVD structure) playing. A quick test in non-D3D mode worked despite a fair bit of menu navigation and chapter jumping in the movie.

The trunk is rock solid.

[Jong]

Hi again ar-jar!

Small point but I think your stats get confused if there is a refresh rate change, especially if it is done by Pstrip (using a Reclock script). Looks like your refresh rate calculation is a one time deal? If it is not too resource intensive it might be sensible to check the refresh rate every few seconds or so and reset the OSD if it has changed.

[THX-UltraII]

I ve been using Reclock for ages now and all it gave me all these years was loooooots of discusions with James and many headaches. Because I live in PAL-land I need something like ReClock. Is this the player I m looking for? If not, what is the purpose of this player compared to MPC-HC 'regular'?

[Jong]

No, this does not speed up 24p for display @50Hz or slow down PAL to 24Hz. Reclock works very well with it though. :)

It offers the benefits of vsync correction (part of Reclock) but without all the confusing options and renderer restrictions - turn it on and go.

It seems really solid, except it really does seem to have a problem with DVD playback in D3D mode (quite a big "but"!), but I am waiting for ar-jar to come back on that one. That said, if you don't need to use Reclock, you don't need Reclock vsync correction and if you don't need that you don't need D3D mode, so for many this will be just fine. Sadly, it sounds like you do still need Reclock.

[Jong]

ar-jar,

Something else from my testing. It seems pretty clear to me, on several system, that whilst "normal", "background" variability in presentation is roughly symmetric, the bigger spikes in variability that can lead to glitches are all one way - towards -0ms. I have never seen a big spike towards -20ms.

So my testing with your excellent OSD has confirmed what I had assumed/guessed but never been able to truly verify before, that you do not really want to set the target offset "in the middle" but as close to -20ms (for 50Hz) as you can without risking "normal" variability taking you over. I would guess this might vary from system to system, but is easy to see using your "check the sync" test. On the systems I have tried a figure of say 15ms @50Hz seems good. For 60Hz maybe 12ms would be good. (Or 75% for both if you change the way of defining the offset).

Thoughts?

[ar-jar]

ar-jar,

Something else from my testing. It seems pretty clear to me, on several system, that whilst "normal", "background" variability in presentation is roughly symetric, the bigger spikes in variability that can lead to glitches are all one way - towards -0ms. I have never seen a big spike towards -20ms.

So my testing with your excellent OSD has confirmed what I had assumed/guessed but never been able to truly verify before, that you do not really want to set the target offset "in the middle" but as close to -20ms (for 50Hz) as you can without risking "normal" variability taking you over. I would guess this might vary from system to system, but is easy to see using your "check the sync" test. On the systems I have tried a figure of say 15ms seems good.

Thoughts?

Thanks for your analysis Jong. I suspected it could be like this but as I've not had any issues myself with the middle ground value, I've stuck with it. I shall run a few tests on my own when I get the time. Talking of which, I will try to answer you all during the weekend but I'm rather busy at work currently. The DVD in exclusive mode should not be a big issue, I might be able to look into this also during the weekend. Other than that, progress will unfortunately be slow the next month or so... -A

[Jong]

This brings up an interesting question for "option3". What offset figure should be targetted?

It seems to me (do you agree?) that "drift" could be in either direction. Can't think why it should not be.

If drift is towards -0ms you would want to set offset as suggested above for Reclock and your option 1. As time goes on the drift will increase the chance of a random spike causing a glitch, but at least it will be clean.

If drift is towards -20ms we have a trickier decision. If we set at -15ms we will get much more frequent glitches due to drift. If we set @-5ms we will be much more vulnerable to random spikes causing a glitch early on. Probably best to stick to "in the middle" for this mode unless testing shows drift is always towards -0ms.

[THX-UltraII]

No, this does not speed up 24p for display @50Hz or slow down PAL to 24Hz. Reclock works very well with it though. :)

It offers the benefits of vsync correction (part of Reclock) but without all the confusing options and renderer restrictions - turn it on and go.

It seems really solid, except it really does seem to have a problem with DVD playback in D3D mode (quite a big "but"!), but I am waiting for ar-jar to come back on that one. That said, if you don't need to use Reclock, you don't need Reclock vsync correction and if you don't need that you don't need D3D mode, so for many this will be just fine. Sadly, it sounds like you do still need Reclock.


and how do I find out if I need this version? In other words, how do I find out if I have V-Sync problems?

btw. Is it still not possible with Reclock to PAL-speeddown when you SPDIF passthrough?

[Jong]

What renderer and renderer settings are you using? what OS? But generally (other than maybe EVR with Aero ON) if you have matched frame rates and refresh rates (e.g. using Reclock) you need it. But if you don't notice the problems no need to make life difficult for yourself!

Basically:

- if you notice repeating judder (not one skipped frame but judder that goes on and on for many seconds or even minutes) sometimes when you start playback, or after pausing/seeking
- if you notice repeating judder that starts after a period of playback varying randomly from minutes to an hour or more
- if you suffer from odd random frame drops that Reclock does not fix

Try the Gothsync version of MPC-HC (it is just an exe, it does not install anything else or mess with the registry), with all ar-jars synchronisation options "off". Bring up the OSD with <cntrl-j> and play a movie. Try seeking and pausing/un-pausing. Does the "sync offset" (the gap between the green and red lines) vary from one seek to the next? Does the green line sometimes come very close to the red line and then cause big spikes on both (judder). Does the sync offset drift over time (green line drifts towards the red line)?

You can speeddown and use s/pdif provided you are prepared to decode the audio on your PC and then use Reclock (or your soundcard/motherboard) to re-encode to AC3 (or, with some soundcards/MBs, DTS). In my experience this works fine. The re-encoding is done @640kb/s - higher than DVD, which is a max of 448kb/s. Compared to the damage done by the timeshifting dll itself I'd say the effects are negligible.

Edit: Sorry, of course when doing PAL speeddown the timestretch dll is not used, so it does not affect quality. Still, my main point stands: The damage (lossy re-encoding technically always degrades the sound) done by re-encoding the a DVD track (originally 448kb/s or 384kb/s) @640kb/s, after resampling, has an inaudible effect on sound quality.

[tetsuo55]

Try seeking and pausing/un-pausing. Does the "sync offset" (the gap between the green and red lines) vary from one seek to the next? Does the green line sometimes come very close to the red line and then cause big spikes on both (judder). Isnt this behaviour inherent of the "seek" function, the splitter has to recover causing a few spikes.
Also the action of opening the menu (in full screen mode) will cause spikes.

I think this is expected and logical behaviour, but it would be cool to add some form of robustness to remove these spikes.

[ar-jar]

Isnt this behaviour inherent of the "seek" function, the splitter has to recover causing a few spikes.
Also the action of opening the menu (in full screen mode) will cause spikes.

I think this is expected and logical behaviour, but it would be cool to add some form of robustness to remove these spikes.

Without any vsync-related correction, either in the renderer or in Reclock, the green line (indicating the time when the actual rendering code is called) will settle pretty randomly between vsyncs (having settled after streaming is started after a pause - not referring to those few initial spikes). With some luck it ends up several ms before vsync but on occasion it may end up very close to vsync which doesn't leave enough time for the rendering code and you end up with judder. With drift, the lines will sooner or later meet too, causing a spike or judder. The closer the rates are to each other, the longer the judder period. A

[Jong]

Isnt this behaviour inherent of the "seek" function, the splitter has to recover causing a few spikes.
Also the action of opening the menu (in full screen mode) will cause spikes.

I think this is expected and logical behaviour, but it would be cool to add some form of robustness to remove these spikes.A few spikes, yes. No I was talking of after those spikes have gone. If there is no vsync correction the final sync offset is essentially random after a seek/pause. Sometimes it may be only 0-2ms one side or other from vsync in which case you get synchronised frame rate/refresh rate judder from then until drift takes it out of the danger zone. Especially with Reclock stabilising things, but more generally if refresh rate and frame rate are well matched, this may not be for up to an hour or so!

edit: oops.. sorry. didn't realise you had already replied to this ar-jar!

[Jong]

With drift, the lines will sooner or later meet too, causing a spike or judder. The closer the rates are to each other, the longer the judder period. A Maybe a small point but I would change this to read "With drift, the lines will sooner or later meet too, causing a period of spikes and judder. The closer the rates are to each other, the longer the judder period, from seconds to many minutes, even an hour or more", just so its clear we are not nitpicking over the odd very rare single dropped frame!

[THX-UltraII]

You can speeddown and use s/pdif provided you are prepared to decode the audio on your PC and then use Reclock (or your soundcard/motherboard) to re-encode to AC3 (or, with some soundcards/MBs, DTS). In my experience this works fine. The re-encoding is done @640kb/s - higher than DVD, which is a max of 448kb/s. Compared to the damage done by the timeshifting dll itself I'd say the effects are negligible.


So if I per se want my receiver do the decoding and live in PAL-land (use both 24 and 25fps material) Reclock is useless?

[webs0r]

Hi all, good to see progress on this great initiative.
I noticed the latest version of mpc-hc does not resize the output when it does not need to. This is great for me as I use ffdshow spline resizing instead, but then MPC resizes again unnecessarily, causing me to have to select Bilinear in MPC to avoid occasional tearing on my htpc setup.

Can I request an updated Gothsync build?

Cheers :)

[Jong]

So if I per se want my receiver do the decoding and live in PAL-land (use both 24 and 25fps material) Reclock is useless?If you want your receiver to decode and you want 25p DVDs played back @24p, Reclock cannot help and there is no other tool to help either, nor is there ever likely to be.

If you are happy that your PC does the decoding Reclock can help. Audio can then be passed over analogue, as PCM over HDMI or, with lossy compression, as s/pdif to your receiver.

If you are happy to playback at 24p or 25p depending on the disc and your TV properly supports 24p and 50Hz then either Reclock or "MPC-HC-gothsync" can help.

But we are OT. I suggest a thread in the Reclock forum if you want to discuss further.

[ar-jar]

It may be just D3D mode. Trying to play a disc in this mode is guaranteed to lock-up either at first play, or the main menu, or before the movie starts. yet to get a movie (in DVD structure) playing. A quick test in non-D3D mode worked despite a fair bit of menu navigation and chapter jumping in the movie.

The trunk is rock solid.

I'm unable to reproduce your problems on my XP system, sorry. I'm running my latest "private build". That build and the trunk behave the same here playing DVDs with VMR9 exclusive mode. Both work so-so (the menus are rather unresponsive in both cases). Can't remember what OS you're running but perhaps it's W7. I have just got my new hardware from the post office and will put together a new HTPC over the weekend. It will run W7 (whenever it becomes available, I just missed the window for the beta as my h/w was delayed). This will give me one more machine to test on. I'm not really keen on "upgrading" though; XP has over the years become rock-solid. But I guess one needs to go with the flow... -A

[Jong]

I'm unable to reproduce your problems on my XP system, sorry. I'm running my latest "private build". That build and the trunk behave the same here playing DVDs with VMR9 exclusive mode. Both work so-so (the menus are rather unresponsive in both cases). Can't remember what OS you're running but perhaps it's W7. I have just got my new hardware from the post office and will put together a new HTPC over the weekend. It will run W7 (whenever it becomes available, I just missed the window for the beta as my h/w was delayed). This will give me one more machine to test on. I'm not really keen on "upgrading" though; XP has over the years become rock-solid. But I guess one needs to go with the flow... -ANo. I'm using XP SP3 :confused: Any more testing I can do? In all other ways your player is great, but in VMR9 D3D mode (with VMR mixer and YUV mixing, if that makes a difference) as soon as I try to play a DVD it crashes, either on the first play, or the menu or, at least, before the movie starts.

[ar-jar]

Just tested this. With your latest private build i get tearing in vmr9 no matter what. The GPU Flush settings do not make any difference here - in contrast to the regular build. It looks like undr VMR9 it still use its own vsync handler, only that it is empty and does not contain any code.

I have removed the GPU flush code. That's why there's no difference. I wanted to start from something that I understood. I will probably put stuff back as I understand why it's there and if it is still needed with the rest of my code. I realize that GPU flushes removes tearing with some gfx boards. To me it's a bit black magic and probably a fix for a bad driver. When using PresentationInterval = D3DPRESENT_INTERVAL_ONE for the DirectX device "The driver will wait for the vertical retrace period (the runtime will "beam follow" to prevent tearing)." says the docs. It seems that I've been lucky with my gfx boards that indeed behave according to the MS docs; there's no tearing (unless I force the presentation time very close to vsync). Other people around here don't seem as lucky. -A

[ar-jar]

No. I'm using XP SP3 :confused: Any more testing I can do? In all other ways your player is great, but in VMR9 D3D mode (with VMR mixer and YUV mixing, if that makes a difference) as soon as I try to play a DVD it crashes, either on the first play, or the menu or, at least, before the movie starts.

I've tried it with a few more DVDs. I do get freezes. On Sade's Lovers Life concert DVD i can't for instance navigate to a certain song. But, the behavior is exactly the same with the trunk build and my branch build. It also consistently fails with both windowed mode and exclusive mode fs.

When I use the NVidia Purevideo MPEG2 decoder instead of the internal one, everything works fine. There is a video format change from 4:3 to 16:9 between the menus and the actual video in the Sade case (that could be a clue). Another DVD that I've used for testing for some time works fine every time. Have you tried several DVDs? Any format changes? -A

[Jong]

Thanks. I'll do some more testing and come back. I never, ever get crashes playing DVDs with the trunk. I am using Cyberlink's MPEG-2 decoder with DXVA on. Should have mentioned that, sorry.

[Jong]

Still hangs with the built in decoder :confused: It does seem to affect some discs wore than others, although it is a bit random/inconsistent so not totally sure. There is no visble aspect ratio change on the discs I am trying, but the way DVD menus work there could be things happening invisibly.

Did you test with VMR Mixer on, YUV mixing on? I must admit I haven't tested with it off yet. (everytime it hangs I have had no put the PC to sleep and bring it out to get rid of the black screen , but now I have a hotkey to kill your process so that should speed up testing! :))

I am using 1269 trunk. Also using your buikd 1259.9012. No problem with 1269 (and not with any build for a long long time).

[Leak]

Did you test with VMR Mixer on, YUV mixing on? I must admit I haven't tested with it off yet. (everytime it hangs I have had no put the PC to sleep and bring it out to get rid of the black screen , but now I have a hotkey to kill your process so that should speed up testing! :))
Have you considered hitting Ctrl-Alt-Del?

(Unless you're using one of those Microsoftian Toy-OS-versions where said combination brings up the task manager instead of the Windows Security dialog/screen...)

np: Reinhard Voigt - Am Limit (Various - Kompakt Total 10 (Disc 2))

[tetsuo55]

Can you reproduce with internal decoder?

We think non matching navigator/decoder will always be problematic in one way or another.

[Jong]

On second thoughts it may be the Cyberlink decoder that is tripping up your renderer. I did get one hang when I switched to the internal decoder, but I have not been able to reproduce it. But the problems with Cyberlink are serious. It will crash sometimes a few seconds after successfully starting to play the first play video. Video playback just locks up with a forzen frame on screen.

It may be DXVA related. I'll test the decoder with DXVA off in a little while.

[Jong]

Have you considered hitting Ctrl-Alt-Del?Doesn't work in D3D mode. Task manager opens but it is hidden behind the fullscree D3D window. However a hotkey which runs a "taskkill" batch file works great.

[Jong]

Can you reproduce with internal decoder?

We think non matching navigator/decoder will always be problematic in one way or another.That doesn't really make sense, or all DVD playback would be problematic on XP! There is no MS decoder. Directshow playback always involves the MS Navigator and a 3rd party decoder. All the decoders must be validated with the MS Navigator as it is standard practice for WMP to play DVDs once a 3rd party player/decoder is installed.

There is certainly no problem at all with using the Cyberlink decoder (7 or 8) with the trunk build.

[tetsuo55]

That doesn't really make sense, or all DVD playback would be problematic on XP! There is no MS decoder. Directshow playback always involves the MS Navigator and a 3rd party decoder. All the decoders must be validated with the MS Navigator as it is standard practice for WMP to play DVDs once a 3rd party player/decoder is installed.

There is certainly no problem at all with using the Cyberlink decoder (7 or 8) with the trunk build.Every decoder has its own navigator if you use the original program it was intended for.

Also the navigator was only meant to be used in WMP.
We're 99% sure its a combined problem of MPC+MS navigator+random renderer

[Jong]

In brief testing the problem goes away when I turn off DXVA in the Cyberlink decoder. It does now seem the crashes are not menu related. It will crash just playing a video if you leave it long enough (normally just a few seconds). It does not affect .mpg playback, so it does seem related to using DVD Navigator as a splitter. But it definitely does not affect the trunk. Since using an external decoder is the only way to get decent hardware assisted de-interlacing of DVDs in MPC-HC I think its pretty vital to get this fixed. IMHO :)

[ar-jar]

In brief testing the problem goes away when I turn off DXVA in the Cyberlink decoder. It does now seem the crashes are not menu related. It will crash just playing a video if you leave it long enough (normally just a few seconds). It does not affect .mpg playback, so it does seem related to using DVD Navigator as a splitter. But it definitely does not affect the trunk. Since using an external decoder is the only way to get decent hardware assisted de-interlacing of DVDs in MPC-HC I think its pretty vital to get this fixed. IMHO :)

Thanks, I'm looking into it. The thing is that it works pretty well on my dev machine with CyberLink SP/Video Decoder (PDVD8) w/ DXVA so debugging is a bit slow. -A