MPC-HC GothSync tryouts

[THX-UltraII]

The same result I had yesterday when I tried Sync renderer, I thought it was my projector problem:mad::mad::mad:

Try EVR Custom with 'alternative v-sync' enabled and see if that solves your problem.

maybe Ar-Jar know more about this....

[pirlouy]

If you read the change log (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=1517) you'll find it actually was added by Aleksoid, so you might have more success asking in the "regular" MPC HC thread...
In fact, Aleksoid just added patches from X-Dron (who is posting in MPC-HC regular thread indeed).

[aymeric106]

Now that you have merged with the offical build, is there some way to enable your sync method with VMR9 ? (just like your old custom build)

For some reason, Fullscreen D3D with EVR never worked on my secondary display ...

Thanks

aymeric106

[ar-jar]

Hi ar-jar, thanks for your great work, now I can see it's integrated to MPC-HC with auto display refresh rate changing feature, amazing.
I have a question, what is the advised value of target sync offset and control for 24P playback on 23.976HZ display? The default value is 12ms, and I assume it only works for 25P playback on 50HZ device right?
Thanks!

If you're output is really 24p you can use anything up to the cycle time minus a few ms which should be like 35 ms or so. That would give you ample time for using complex shaders and still get tearing-free playback. -A

[ar-jar]

Hi Ar-Jar,

I just bought a new ATI 5670 card and have some tearing issues when selecting sync output as renderer. The problem is at the bottom of the screen. So no problems with 2:35:1 movies but you can see tearing at very bottom of the screen with 1:85 (full 16:9) content. It can also be seen when doing a tearing test (ctrl+t) because the two red bars are broken at the bottom of the screen. I also have this problem with EVR custom but found out that I can solve it by CHECKING 'alternative v-sync' (that s NOT the 'accurate v-sync option which is ENABLED by default in EVR custom).

I hope you can do something with this information because I m not using your output now because of this rendering issue. If you need more info let me know!

I assume you refer to fullscreen playback(?) Try this:
- Use bilinear resizer (it's light-weight)
- Set target sync output to your display cycle time minus say 3 ms (e.g. 17 ms for a 50 Hz display refresh rate)
- Use "present at nearest vsync"

Try both regular fullscreen and D3D fullscreen. If both work, then you can try more complex resizers and shaders with the regular fullscreen. Depending on the processing power of your GPU, you may or may not get tearing when adding more processing to the rendering cycle.

Generally D3D fullscreen should be tearing-free with almost any parameters. The drawback is that if you use the fullscreen gui-support you lose all benefits of D3D fullscreen wrt tearing so I have disabled fullscreen gui support for the time being.

Hope this helps!

Arto

[ar-jar]

Now that you have merged with the offical build, is there some way to enable your sync method with VMR9 ? (just like your old custom build)

For some reason, Fullscreen D3D with EVR never worked on my secondary display ...

Thanks

aymeric106

I'm sorry but I don't have any plans for this as of now. I will focus on the EVR for some time. Hopefully your problems will be solved along the way too. What's your gfx board? -A

[THX-UltraII]

I assume you refer to fullscreen playback(?) Try this:
- Use bilinear resizer (it's light-weight)
- Set target sync output to your display cycle time minus say 3 ms (e.g. 17 ms for a 50 Hz display refresh rate)
- Use "present at nearest vsync"

Try both regular fullscreen and D3D fullscreen. If both work, then you can try more complex resizers and shaders with the regular fullscreen. Depending on the processing power of your GPU, you may or may not get tearing when adding more processing to the rendering cycle.

Generally D3D fullscreen should be tearing-free with almost any parameters. The drawback is that if you use the fullscreen gui-support you lose all benefits of D3D fullscreen wrt tearing so I have disabled fullscreen gui support for the time being.

Hope this helps!

Arto

thxz for your reply Ar-Jar.
I will try some suggestions tonight and report back to you.
I still don t understand the calculation to set the 'Taget Sync offset'. Can you help me with this? => I have a JVC RS20 projector that supports 24p playback and have set my ATI5670 to 1920x1080@23,976Hz.

ps. When you want to give me the correct value for this setting you have to keep in mind that I live in PAL-land and that I also play 25fps material. My JVC projector DOES NOT support 25Hz so I use the 'autochange' options in fullscreen options of MPC-HC as follow:
* 23.50 - 24.00Hz => 1920x1080 32bpp 23Hz (that is 23,976 for ATI)
* 24.50 - 25.00Hz => 1920x1080 32bpp 50Hz
* 29.50 - 30.00Hz => 1920x1080 32bpp 60Hz

And now that you know what hardware and settings I use, can you also give me the best values to use for the frequency of 'sync video to display' which standard is 0.0012 and the setting 'Control Limits' which standard is set to 2ms.

thanks again Ar-Jar

[ar-jar]

ps. When you want to give me the correct value for this setting you have to keep in mind that I live in PAL-land and that I also play 25fps material. My JVC projector DOES NOT support 25Hz so I use the 'autochange' options in fullscreen options of MPC-HC as follow:
* 23.50 - 24.00Hz => 1920x1080 32bpp 23Hz (that is 23,976 for ATI)
* 24.50 - 25.00Hz => 1920x1080 32bpp 50Hz
* 29.50 - 30.00Hz => 1920x1080 32bpp 60Hz

And now that you know what hardware and settings I use, can you also give me the best values to use for the frequency of 'sync video to display' which standard is 0.0012 and the setting 'Control Limits' which standard is set to 2ms.

thanks again Ar-Jar

If you aren't using any advanced shaders or complex resizers (or if you have a potent gfx board) you could choose about 12 ms for the target sync offset for all resolutions and refresh rates).

To really optimize things I would recommend sync offset = display refresh cycle - 3 ms. For 25 Hz (40 ms) this would mean 37 ms. For 50 Hz (20 ms) 17 ms and so on.

The default values should be ok for the other parameters.

This reminds me that I should calculate the default value based on current refresh rate. I'll add that to my to-do list.

Tell me if it works!

-Arto

PS. See my blog for more details about this.

[mark0077]

Hi arjar. Can settings like this be set to an auto setting. Ie use the formula you give above.

Just or kore question. Does evr sync detect media speed changes during playback yet. It seemed to be an issue for me with early versions so I must use evr-cp.

Thank you.

[pirlouy]

If it can help people...
50 Hz: 1/50 = 0,020 s = 20 ms ; -3ms = 17 ms
25 Hz: 1/25 = 0.040 s = 40 ms ; -3ms = 37 ms
23,976 Hz: 1 / 23.976 ~ 41 ms ; -3ms = 38 ms
60 Hz: 1/60 ~ 16 ms ; -3ms = 13 ms

[Peuj]

Hi arjar. Can settings like this be set to an auto setting. Ie use the formula you give above.

Thank you.

Or at least as an option like "Auto sync offset". So users can have the choice.

[mark0077]

Yeah sounds good. Anything that can be automated within reason should be as much as possible.

[THX-UltraII]

If it can help people...
50 Hz: 1/50 = 0,020 s = 20 ms ; -3ms = 17 ms
25 Hz: 1/25 = 0.040 s = 40 ms ; -3ms = 37 ms
23,976 Hz: 1 / 23.976 ~ 41 ms ; -3ms = 38 ms
60 Hz: 1/60 ~ 16 ms ; -3ms = 13 ms

but that's the 'problem' I have. My projector can handle 23,976Hz but I also play 25fps (PAL) material. My projector cannot display at 25Hz so I play the 25fps material @50Hz.

So this means that everytime I switch between NTSC and PAL material I have to manually change the sync offset value from 38 to 17ms and so on.....

[pirlouy]

That's why mark0077 asks for something automatic. :D

[Jong]

Personally I would go with -4ms, not -3ms. I have not seen sync glitches @-3ms but it is close enough that I do sometimes see the red line wavering in sync with the green line. @-4ms the red line is flat. A sign we are cutting things a bit fine @-3ms I think (at least here).

Automatic is definitely good, but things are not as bad as they seem. The most important thing is to have a reasonable margin from vsync. For most peoples systems I would imagine that the -12ms or -13ms you would get setting for 60Hz would be perfectly fine. If you use this same setting for 50Hz, 24Hz etc. you are not taking advantage of the extra margin available to you at those refresh rates, but if -12ms works then it works(!) and the extra margin is really not needed or particularly useful.

When automatic really is needed is if people what to use 96Hz or 120Hz. Then -12ms (or, even worse, -13ms) really would not work.

[pirlouy]

@ar-jar:
When I use EVR Sync, I have some little tearing at bottom (5% of screen) (Aero disabled, and when I don't use D3D fullscreen).
This strip is always present, I mean it's not due to CPU, GPU, RAM limitations; for example, if I use another way to resize (bicubic instead of bilinear), there's the same strip.

This tearing is present with madVR too (a lot more for that matter), but I've noticed that with Beliyaal EVR custom, if I choose V-Sync + Alternative Sync (only these two), there's is no tearing anymore.

Do you know what these options do, or you haven't studied it ?

[ar-jar]

@ar-jar:
When I use EVR Sync, I have some little tearing at bottom (5% of screen) (Aero disabled, and when I don't use D3D fullscreen).
This strip is always present, I mean it's not due to CPU, GPU, RAM limitations; for example, if I use another way to resize (bicubic instead of bilinear), there's the same strip.

This tearing is present with madVR too (a lot more for that matter), but I've noticed that with Beliyaal EVR custom, if I choose V-Sync + Alternative Sync (only these two), there's is no tearing anymore.

Do you know what these options do, or you haven't studied it ?

What happens when you gradually change target sync offset (use CTRL+ALT+up or down arrow)? Test both increasing it and decreasing it. In my experience the tearing should disappear when you have a large enough target sync offset. I don't think the tearing issue can be explained with anything in the DirectX library. It's probably depends on the driver and / or the hardware. My desktop ATI card causes tearing while my laptop ATI card is impossible to force to tear. Go figure.

I'll try to understand the complex algorithms of EVR custom eventually but not quite yet. -Arto

[pirlouy]

No, changing "target sync offset" does not prevent this little strip of tearing (less than 5% of screen in fact).

I didn't remember, but after some tries, I've noticed Tearing is present in VMR9, EVR, madVR but not in VMR7 or Overlay Mixer. This Overlay Mixer may look old, but in fact, it works well regarding tearing or audio lag.

[canuckerfan]

forgive me if I've missed something but I get this error when I try to watch a video:

http://i50.tinypic.com/dgjko2.png

any thoughts?

[pirlouy]

I think it could help if you give information on MPC-HC Build, GPU, OS for example.

[mark0077]

Hi, just wondering how high up the todo list, is getting audio and video in sync.

As said before I always get 20-40ms out of sync with evr-cp and synch renderer. With vsync disabled, and reclock vsync enabled instead, this drops immediately to 0-2ms, and I get noticible back into sync.

[ar-jar]

forgive me if I've missed something but I get this error when I try to watch a video:

http://i50.tinypic.com/dgjko2.png

any thoughts?

This means that you probably have a rather basic gfx board that doesn't have any information about what scan line of the video frame it is currently showing. It should really only be an issue if you use the "synchronize display to video" option. I'll look into the code to see if I issue this warning for other modes as well. That would be a bug. -A

[canuckerfan]

I think it could help if you give information on MPC-HC Build, GPU, OS for example.
build 1.3.1588.0
radeon 9250 pro
windows xp sp3

[FDisk80]

Sorry, double post. ignore this :)

[FDisk80]

What happens when you gradually change target sync offset (use CTRL+ALT+up or down arrow)? Test both increasing it and decreasing it. In my experience the tearing should disappear when you have a large enough target sync offset. I don't think the tearing issue can be explained with anything in the DirectX library. It's probably depends on the driver and / or the hardware. My desktop ATI card causes tearing while my laptop ATI card is impossible to force to tear. Go figure.

I'll try to understand the complex algorithms of EVR custom eventually but not quite yet. -Arto


This is a bug.
I have the same problem when in sync with 24Hz while playing 1080p content.
The solution is very strange. Turn ON Aero and the tearing at the bottom goes away.

But this starts another strange problem
With Aero ON the video starts with insane frame skip. (When starting playback directly in fullscreen)
And the solution for this bug is to open any menu.
Click "O" for example for options then close the options window and the frame skipping stops.
Very strange.

Some Details of the system:
i5 750, HD5770 (DXVA), Win 7 64bit, MPC-HC 64bit v1.3.1594.0

[pirlouy]

@canuckerfan: I don't know if you missed ar-jar post (just before your last post), but the answer is here: you have an old GPU card (6 year old) and it was not an advanced GPU at that time so it may be linked. What options are you using in EVR Sync settings ?

[canuckerfan]

^I was following the guide here: http://www.ostrogothia.com/?page_id=1216

beginning with alternative 1: "using sync video to display"

[pirlouy]

What about if you use option "Present at nearest" ? Have you this error ?

[canuckerfan]

What about if you use option "Present at nearest" ? Have you this error ?
I still get the error. it's weird because in both cases (with or w/o the option ticked) the file plays in the background fullscreen while mpc stays in the foreground. but I can't seem to control anything and I have to close mpc-hc just to get out of the fullscreen mode. is my video card just too old for this?

[ar-jar]

I still get the error. it's weird because in both cases (with or w/o the option ticked) the file plays in the background fullscreen while mpc stays in the foreground. but I can't seem to control anything and I have to close mpc-hc just to get out of the fullscreen mode. is my video card just too old for this?

Sorry, I checked the code and realized that the checking of the graphics board capabilities is a little too conservative, i.e. it will rule out your card whatever sync option you use. I'll fix that in a future build. -A

[ADude]

pirlouy -

The sync option for EVR CP are not sufficiently documented, either in the code or elsewhere. The developer of that specific part of the code, left the project right after finishing the options, and right before some questions were asked to clarify - in a technical way - what the options do. So, all you can do is experiment.

[ADude]

ar-jar -

I recently was playing a video - which turned out to have some encoding problems. But, in an effort to see if the visual problems were due to EVR Sync, I tried going back to EVR CP (and, as implied, there was no difference).

Later, I was playing other videos, and encountered the sort of tearing that is usually fixed by "Present At Nearest" with my setup. I remembered that I had changed to EVR CP, and so, I went into options, selected "EVR Sync" again, and exited.

When I played the video again, the EVR CP options were grayed out and in Options, "EVR Sync" was indeed selected. BUT, the tearing was still there AND Filters said "EVR CP" was in use.

I then rebooted my PC (vista 32bit, no Aero, as stated in my sig), and played the video again immediately after reboot, and this time, there was no tearing and Filters said "EVR Sync".

This seems to be the same bug that I reported a few weeks ago, where changing from EVR CP to EVR Sync does not take effect without rebooting.

[pirlouy]

pirlouy -
The developer of that specific part of the code, left the project right after finishing the options,
Maybe there is not a lot of documentation, but Beliyaal's algorithms are (I think) very interesting to study.
It's one of the first here to have modified EVR in order to avoid judder. And a lot of people use its renderer and it works well.

Options are documented, and Beliyaal has not left; he's less active, but he has committed some changes not so long ago.

[ADude]

Options are documented, and Beliyaal has not left; he's less active, but he has committed some changes not so long ago.

There is very sketchy documentation. The technical questions about the options have never been answered and no other developer has been able to answer them.

[edigee]

I post here , because your sync renderer options was implemented in the main MPC-HC project ,but I guess I can find out more here.
Here's my set up:
HD3650 ,Cat 10.1 ,Vista 32 bit, HD Audio (ALC662 Audio Codec) built in device, MPC_HC build 1623 with: EVR sync ,Sync video to display, audio renderer-system default, display at 60Hz, no reclock, aero enable.
Here's my broblem:
When I play H264 files(mkv or mp4) with 23.976 with DXVA (don't know if it matters) the video is pretty much OK in terms of smooth movement but the audio gives some strange hisses or more like small scratches from time to time as if it was an old vinyl disk.
No matter I switch between AC3 filter or ffdshow audio ,the issue is still on. When I check the sound device tab there are some erors (i guess sync ones) displayed there. When I choose a different audio renderer the problem is still on or the audio goes out of sync.
With EVR Custom those problems dissapear ,but I have small isues in terms of smooth movement of the video.

[pirlouy]

S/PDIF or analog ?
Which option do you use for synchronization (EVR Sync options) ?

[edigee]

S/PDIF or analog ?
Which option do you use for synchronization (EVR Sync options) ?

I'm on analog( stereo output to a stereo amplifier).
EVR Sync -sync video to display-freq. adjust.:0.0012

[swp]

No, changing "target sync offset" does not prevent this little strip of tearing (less than 5% of screen in fact).

I didn't remember, but after some tries, I've noticed Tearing is present in VMR9, EVR, madVR but not in VMR7 or Overlay Mixer. This Overlay Mixer may look old, but in fact, it works well regarding tearing or audio lag.
I can also confirm this. I have constant tearing at the bottom as well with an ati 5850.
- Aero removes tearing but screws up frame rate.
- d3d also removes it but then I get frequent freezes especially if using autochange of fullscreen freq.

[ikarad]

http://forum.doom9.org/showpost.php?p=1376500&postcount=12003

[ADude]

ar-jar -

I recently was playing a video - which turned out to have some encoding problems. But, in an effort to see if the visual problems were due to EVR Sync, I tried going back to EVR CP (and, as implied, there was no difference).

Later, I was playing other videos, and encountered the sort of tearing that is usually fixed by "Present At Nearest" with my setup. I remembered that I had changed to EVR CP, and so, I went into options, selected "EVR Sync" again, and exited.

When I played the video again, the EVR CP options were grayed out and in Options, "EVR Sync" was indeed selected. BUT, the tearing was still there AND Filters said "EVR CP" was in use.

I then rebooted my PC (vista 32bit, no Aero, as stated in my sig), and played the video again immediately after reboot, and this time, there was no tearing and Filters said "EVR Sync".

This seems to be the same bug that I reported a few weeks ago, where changing from EVR CP to EVR Sync does not take effect without rebooting.

[ar-jar]

ar-jar -

I recently was playing a video - which turned out to have some encoding problems. But, in an effort to see if the visual problems were due to EVR Sync, I tried going back to EVR CP (and, as implied, there was no difference).

Later, I was playing other videos, and encountered the sort of tearing that is usually fixed by "Present At Nearest" with my setup. I remembered that I had changed to EVR CP, and so, I went into options, selected "EVR Sync" again, and exited.

When I played the video again, the EVR CP options were grayed out and in Options, "EVR Sync" was indeed selected. BUT, the tearing was still there AND Filters said "EVR CP" was in use.

I then rebooted my PC (vista 32bit, no Aero, as stated in my sig), and played the video again immediately after reboot, and this time, there was no tearing and Filters said "EVR Sync".

This seems to be the same bug that I reported a few weeks ago, where changing from EVR CP to EVR Sync does not take effect without rebooting.

I have added a bookmark to this report in my private "mpc-hc bugs" folder. I'm in the middle of some major restructuring right now so it will be some time before i can look at it. -A

[THX-UltraII]

I can also confirm this. I have constant tearing at the bottom as well with an ati 5850.
- Aero removes tearing but screws up frame rate.
- d3d also removes it but then I get frequent freezes especially if using autochange of fullscreen freq.

+1 for this problem. Still having tearing at the bottom of the screen with Ar-Jar renderer as output. Using EVR Custom for the time-beeing now :(

[ADude]

Ar-jar:

Since you are currently working on full-screen and monitor issues, perhaps you know the answer to this MPC-HC question:

Back when I was using Build 1043 (the last MPC-HC build prior to he-who-I-am-not-allowed-to-mention), I used to use RealVNC to connect to my HT-PC (which otherwise only has my HD TV as its display) from my laptop. That was convenient when someone was using another source to watch that HD TV, and so I could use RealVNC to do various maintenance on the HT-PC at the same time.

Sometimes I would just use RealVNC from the laptop to start a file playing in MPC-HC on the HD TV. This worked fine, although the RealVNC display on the laptop only showed occasional frames and in a lower color depth, but that was irrelevant, since we were watching the video on the HD TV.

Nowadays, using recent MPC-HC versions with EVR Sync, I find that if RealVNC is running at the same time on the laptop from the HT-PC, I get terrible jerky playback on the HT-PC until such time as I stop the RealVNC viewer altogether. Doing that causes the HD TV to go blank for a fraction of a second, and then playback resumes and is entirely smooth from then on.

So, out of curiosity, do you have any idea what changed in MPC-HC (that caused this) ?

[THX-UltraII]

Ar-Jar, any progress in solving the 'bottom-tearing' issue with EVR SYNC?

[ar-jar]

Ar-jar:

Since you are currently working on full-screen and monitor issues, perhaps you know the answer to this MPC-HC question:

Back when I was using Build 1043 (the last MPC-HC build prior to he-who-I-am-not-allowed-to-mention), I used to use RealVNC to connect to my HT-PC (which otherwise only has my HD TV as its display) from my laptop. That was convenient when someone was using another source to watch that HD TV, and so I could use RealVNC to do various maintenance on the HT-PC at the same time.

Sometimes I would just use RealVNC from the laptop to start a file playing in MPC-HC on the HD TV. This worked fine, although the RealVNC display on the laptop only showed occasional frames and in a lower color depth, but that was irrelevant, since we were watching the video on the HD TV.

Nowadays, using recent MPC-HC versions with EVR Sync, I find that if RealVNC is running at the same time on the laptop from the HT-PC, I get terrible jerky playback on the HT-PC until such time as I stop the RealVNC viewer altogether. Doing that causes the HD TV to go blank for a fraction of a second, and then playback resumes and is entirely smooth from then on.

So, out of curiosity, do you have any idea what changed in MPC-HC (that caused this) ?

The short answer is no, sorry. Does this also happen with the other DirectX-based renderers? Have you experimented with Disabling Desktop Composition (just guessing a bit here)? -A

[ar-jar]

Ar-Jar, any progress in solving the 'bottom-tearing' issue with EVR SYNC?

No, sorry. I'm not really able to repeat it. I am instead focusing on making exclusive mode (D3D mode) full-screen more convenient to use. It is my gut feeling (backed up with some facts) that it will always be the most robust mode tearing-wise and timing-wise as it doesn't share the graphics device with any other processes (except perhaps DXVA). -A

[tetsuo55]

You guys should consider EVR-Sync a work in progress, thus highly unstable in some cases.

You should consider it a complete rewrite, and things are likely to break in that process

[THX-UltraII]

So you recommend to stick with ECR Custom for now?

[tetsuo55]

I suggest try EVR-Sync and if it works for you then keep using it.

If however you have problems right now, i suggest comming back later.
Do report the issue you found here, that way we can contact you and check if the final code still has the bug

Work is still being done on the core basics, and that means that bugs could be fixed, reintroduced or added by accident continually

[Jong]

Ar-Jar, any progress in solving the 'bottom-tearing' issue with EVR SYNC?I assume you have tried moving the sync target?

What synchronisation settings are you using? What refresh rate? can you post a screenshot with the OSD displayed when you have the tearing (so we can see what is ahppening to the red and green lines)?

In my experience this can happen if you have the sync target too close to either the start or end of the frame, eg. @50Hz too close to 0ms or -20ms

Or, as ar-jar says, try D3D mode. Even with its current restrictions that is what I use all the time other than when testing.