MPC-HC GothSync tryouts [Archive] - Page 10

Leak

13th October 2009, 08:44

http://msdn.microsoft.com/en-us/library/ms698989(VS.85).aspx Might be helpful.
Helpful in determining how the chroma is oriented vs. the luma - yes. (If the values are to be trusted, see interlaced vs. progressive in MPEG2 streams...)

Helpful in getting the renderer to not do point upscaling of the chroma - not so much, I'm afraid...

madshi

13th October 2009, 13:31

I briefly tried triple buffering but it didn't make much difference. See an earlier post on this thread. What makes a huge difference is exclusive mode full-screen ("D3D") w/o GUI support.
From my experience it seems that triple buffering is next to useless in windowed mode (regardless of whether it's "full screen" or not) because the "Present" call actually blocks until the next VSync occurs. Which means that as soon as you call "Present", you can't do any more rendering. Which means that the additional two background render buffers have no chance to even fill up.

In fullscreen *exclusive* mode I think "Present" does not block (haven't tried yet, though). Which should give you a HUGE performance advantage. Of course the whole presentation logic (which frame is shown when) must be able to cope with the non-blocking "Present" call for this all to make sense. Fullscreen exclusive mode with triple buffering should be the best option for performance.

ar-jar

13th October 2009, 17:56

From my experience it seems that triple buffering is next to useless in windowed mode (regardless of whether it's "full screen" or not) because the "Present" call actually blocks until the next VSync occurs. Which means that as soon as you call "Present", you can't do any more rendering. Which means that the additional two background render buffers have no chance to even fill up.

In fullscreen *exclusive* mode I think "Present" does not block (haven't tried yet, though). Which should give you a HUGE performance advantage. Of course the whole presentation logic (which frame is shown when) must be able to cope with the non-blocking "Present" call for this all to make sense. Fullscreen exclusive mode with triple buffering should be the best option for performance.

Thanks! This rhymes with my experience also. I remember back when I started working with this that I was a bit surprised that Present didn't always block. Most of the time it looks like it blocks but that's when you are up to speed and feed the swap-chain with a new frame every screen refresh cycle which I do most of the time (I know this is not always optimal but I wanted to be able to handle 50/60 fps anyway since some decoders actually deliver this number of unique frames, e.g. the CyberLink AVCHD decoder). Conclusion: use either exclusive mode full-screen or a large sync offset value. -A

THX-UltraII

14th October 2009, 08:12

I had to do a fresh installation of my HTPC last night. So of course time for new bugs after this :D

The problem:
When I use ffdshow as video decoder I get the result you see in picture 1 (I m not @home so I made a home-made picture with paint :)). The thing I notice is that when I press CTRL+J I see that the Actual Frame Rate information shows strange behaviour: Is goes up to approx. 24,002 and back to approx. 23,961 and this goes in cycles. (off course this is why the green line is not constantly horizontal).

When I don t use ffdshow (internal MPC-HC filters) I get a perfect constant info @Actual Frame Rate of 23,976 and picture 2 @CRTL+J.

''Why not use the internal filter than'' I hear you think. Cause I need ffdshow for RGB HQ output.

What could this be?

My settings: latest .9018 GothSync MPC-HC, EVR Custom output, ATI HD4350 with 9.10 beta driver, Sync Video to Display option, all other Vsync option in MPC-HC OFF.

Picture 1:
http://img395.imageshack.us/img395/4433/ffdshow.th.jpg (http://img395.imageshack.us/i/ffdshow.jpg/)

Picture 2:
http://img63.imageshack.us/img63/1964/withoutffdshow.th.jpg (http://img63.imageshack.us/i/withoutffdshow.jpg/)

madshi

14th October 2009, 08:26

I remember back when I started working with this that I was a bit surprised that Present didn't always block.
That was with fullscreen exclusive mode, I guess?

ar-jar

14th October 2009, 12:29

That was with fullscreen exclusive mode, I guess?

Yes, I believe it was as I focused entirely on getting this to work in exclusive mode. When I started a few years ago, there were severe tearing issues with non-exclusive mode (there still are but they are more controllable now it seems).

I'm among those who use the HTPC with a remote control in a real home cinema setting and I couldn't care less about menus and windowed mode :-)

-A

Jong

14th October 2009, 12:37

I'm among those who use the HTPC with a remote control in a real home cinema setting and I couldn't care less about menus and windowed mode :-)Me too!

THX-UltraII

14th October 2009, 12:48

any thought on the issue I have Ar-Jar or Jong?

Jong

14th October 2009, 13:07

My main thought is that if you are not upscaling in ffdshow you do not need to use ffdshow to convert to RGB. I understand in another thread leeperry is suggesting you use it as a reference to compare with other options, but that should just be for testing. There should be no reason why you cannot use MPC-HC with EVR/VMR9 Gothsync and get the correct colours. If they are wrong, somehow MPC or your filters are misconfigured or there is something wrong with the file you were using for testing (hence the suggestion you use AVS-HD test patterns).

On what you are observing, first are you actually using ffdshow to DECODE or are you using it just as a post-processor? ar-jar may need to comment on why the frame-rate is constantly varying, but the main thing is provided your number of glitches/dropped frames is not going up this makes no difference at all to your viewing pleasure. What you are seeing is a slight variation in when the frames are presented, but the frames are displayed on a precise "beat" controlled by the GPU and slight variations like this that do not cause glitches make no difference at all to your viewing pleasure!

Jong

14th October 2009, 13:11

My main thought is that if you are not upscaling in ffdshow you do not need to use ffdshow to convert to RGB. Actually there is one exception to this that leeperry has mentioned. That is 2.35:1 or 2.4:1 video encoded @720p without the black bars. Then the vertical resolution that most renderers use to decide the colorspace is <720p and they make the wrong choice. However, since your video is 1080p this would not apply even if encoded withoutthe black bars (all professional BR discs are encoded WITH the black bars, so at the full 1920x1080 resolution). Personally I live with the errors in these rare situations (normally trailers).

THX-UltraII

14th October 2009, 13:29

thxz for all info (again!) Jong. The link to the testfile Leeperry wrote, how does this work? Do I just need to see all equal sqaures and is it then ok? If so, I m going to do some tests tonight and report back to you asap

Jong

14th October 2009, 13:32

I don't know I haven't looked at it. Ask leeperry or follow the suggested diagnostic method I proposed using AVS-HD.

THX-UltraII

14th October 2009, 13:49

I don't know I haven't looked at it. Ask leeperry or follow the suggested diagnostic method I proposed using AVS-HD.

ok, so just grab the mp4 version from http://www.avsforum.com/avs-vb/showthread.php?t=948496.

Is there a manual with it so I know how it works?

Jong

14th October 2009, 15:12

Didn't you grab the .pdf file, that is right next to the download link in the first post?

ar-jar

14th October 2009, 20:30

The problem:
When I use ffdshow as video decoder I get the result you see in picture 1 (I m not @home so I made a home-made picture with paint :)). The thing I notice is that when I press CTRL+J I see that the Actual Frame Rate information shows strange behaviour: Is goes up to approx. 24,002 and back to approx. 23,961 and this goes in cycles. (off course this is why the green line is not constantly horizontal).

When I don t use ffdshow (internal MPC-HC filters) I get a perfect constant info @Actual Frame Rate of 23,976 and picture 2 @CRTL+J.

''Why not use the internal filter than'' I hear you think. Cause I need ffdshow for RGB HQ output.

What could this be?

The strange thing is why you get straight lines in the second case (the first one is kind of normal although you could experiment with the control limit a bit too to narrow down the oscillations). You say the image is done with paint? So are the lines exactly straight in the second case? If they are, I don't have any explanation currently. I've never seen lines w/o the tiniest wiggle. Have to think about what it is that could have happened. Are you sure you are doing sync video in both cases?

And btw, are you also trying to illustrate that the scaling is wrong so that the actual video only covers the upper left corner of the screen?

-A

tdoll

16th October 2009, 16:56

I am sorry for my simple question but I am using mpc-hc for a while now and I have not jet been able to use gothsync tryouts. I always take the latest version of mpc-hc and I thought gothsync is embedded in the player. Am I wrong here. Is there any thread where I could read about how to use the gothsync tryouts with mpc-hc. I just neet some hints to get started. I am very interested in this project. I used to use reclock but I like the idea to have everything integrated in the player.

Thanks for your help!

Thomas

Jong

16th October 2009, 17:04

Just follow the link in the first post of this thread for the special Gothsync versions of MPC-HC. It is not in the standard builds yet.

Casshern

21st October 2009, 18:20

Hi ar-jay,

just read on your site that you will move your code to your own renderer! Good call! This will make everybody happy. People can still use beliyaals code or yours, whatever works best for them. Awesome!

pirlouy

21st October 2009, 19:39

Is this "new" renderer going to be based on EVR ?

ar-jar

21st October 2009, 20:59

Is this "new" renderer going to be based on EVR ?

Yes, that would be my first bet as EVR gives better access to controlling the timing etc. -A

honai

21st October 2009, 21:12

I hope you are aware that with EVR you get all sorts of transparent driver tweaks that nVidia, ATI and Intel apply behind the scenes, e.g. VSYNC fiddling, color correction (applying both Windows color-management and certain enhancements, e.g. for skin tones), implicit color-space conversions, color clipping, etc.

With EVR there's no way around that. That's why madshi decided to base his renderer *not* on EVR.

tetsuo55

21st October 2009, 21:21

The renderer isnt new from scratch like madvr, but rather the newest evolution of custom-EVR.

honai

21st October 2009, 21:28

Still, the relevant parts of this project - reducing tear/judder and faithful rescaling - are out of the control of the dev/user as long as you use EVR. Even with a custom EVR renderer you get transparent driver tweaks, hence the bunch of options that Beliyaal had to include in his version. And still, behavior of his custom EVR varies vastly from platform to platform, GPU to GPU - simply because, no matter how nicely you talk to the EVR API, the driver determines the actual behavior, i.e. the part of the EVR renderer code that is invisible to you.

tetsuo55

21st October 2009, 21:36

pirlouy

21st October 2009, 21:57

Maybe honai is right, but I think it's very hard to write your own renderer all by yourself. Since Madshi has some plans, I guess it's not a bad idea to improve a renderer which is now a reference (EVR) with its pros and cons.

Anyway, one thing which works well for sync in my case in Beliyaal build, it's the ability to stop Aero (even if stopping Aero causes tearing)... I hope Ar-jar's renderer will keep this option.

PaJaSoft

22nd October 2009, 08:16

Anyway, one thing which works well for sync in my case in Beliyaal build, it's the ability to stop Aero (even if stopping Aero causes tearing)... I hope Ar-jar's renderer will keep this option.

I thought the same thing, but practical test - ar-jar graph during play - says something else... I didn't disable Aero in whole Windows 7, only disable Desktop composition for this binary .exe, but the result is much more jitter/judder and synchonization adjustment every second or less - red line spike... (HDMI out is 50Hz, source off-line played signal is recording from SAT 1080i 25fps DVB) - I'm using sync to nearest as the best method - without PowerStrip.

Leave Aero ON is much better for me (NVidia 250GTX, 191.07WHQL, Windows 7 Prof. 64-bit Prof) in this program... - althought in DVBViewer is the situation on EVR surface exactly inverse... strange:-( (using latest build of GothSync)

Jong

22nd October 2009, 11:43

Yes, that would be my first bet as EVR gives better access to controlling the timing etc. -APlease try to keep a VMR9 renderer too, for XP users. I have totally got used to using Gothsync now. I would hate to have to "regress" :)

pirlouy

22nd October 2009, 12:12

I thought the same thing, but practical test - ar-jar graph during play - says something else...
In my case, Ar-jar graph suffers from judder when Aero is enabled. graph is correct thought, but it has judders.
In fact, I think it's due to dual screen. One screen in 60Hz, other in 50Hz.
But when Aero is enabled, and when I use 24Hz, UI is very slow (which is not the case when Aero disabled).

Aero is pretty, fights again tearing, but unfortunately it does not manage to do it the right way. It does not worth GothSync + D3D. Madshi renderer is not really usable for now.

tetsuo55

22nd October 2009, 12:21

Please try to keep a VMR9 renderer too, for XP users. I have totally got used to using Gothsync now. I would hate to have to "regress" :)You only need VMR9 for DXVA, otherwise ar-jar's EVR is better even for XP.

Eventually changes will be backported to VMR9

mark0077

22nd October 2009, 14:05

Looking forward to seeing it integrated into mpc-hc. When I play 24hz content on my 60hz display, I am used the usual spiky graph, but I notice a difference between beliyaals graph and gothsync's graph.

With the normal mpc-hc graph, the audio sync line spikes up and down, I assume to show the audio is out of sync with the video?
With gothsync, my audio sync line stays almost perfectly straight, but the video line in the graph spikes as usual.

Are they representing different things?

tetsuo55

22nd October 2009, 15:00

mark0077

22nd October 2009, 15:00

OK cheers.

THX-UltraII

22nd October 2009, 15:01

tetsuo55

22nd October 2009, 17:32

Here a stupid question:

What happens when Gothsync gets integrated in MPC-HC as renderer? With the current version posted by Ar-Jar you already have the 'syncronisation' option in the options menu of MPC-HC. What will become different then?the difference is, that Ar-Jar can work freely on the renderer, without having to worry about syncing with trunk.

webs0r

3rd November 2009, 01:06

Hey ar-jar how is it going? It has been quiet for a bit. Anything new to test? :)

pirlouy

3rd November 2009, 08:49

As he said on his blog (http://www.ostrogothia.com/video/), he is occupied to rewrite his current renderer in order to be "MPC independent" in fact.

ar-jar

4th November 2009, 19:51

As he said on his blog (http://www.ostrogothia.com/video/), he is occupied to rewrite his current renderer in order to be "MPC independent" in fact.

Well, I don't think I wrote "MPC-independent". I didn't mean it in any case. I have been rather ambivalent as to whether I should again integrate my features with the Beliyaal track and I talked with him about that. Eventually I will probably do that but he is doing some work on the renderer for the moment so it's a bit of a moving target. I will therefore, time permitting, work on a parallel track for yet some time. Unfortunately I've been extremely busy at work lately so progress has been slow. That *must* change eventually :-) -A

pirlouy

4th November 2009, 21:41

Ok, but I think you should try to make the renderer independent of MPC-HC. You can support some MPC API like subtitle renderer, but I think it could be better if it was not dependent on MPC.

ar-jar

4th November 2009, 21:57

Ok, but I think you should try to make the renderer independent of MPC-HC. You can support some MPC API like subtitle renderer, but I think it could be better if it was not dependent on MPC.

My first renderer (non-MPC) was in fact almost independent of the player. At that time there was one challenge that I couldn't find a good solution for: to switch between exclusive mode full-screen and windowed mode only using the standard renderer interfaces. Also at that time all players used the IVideoWindow interface which was a real pain to implement. So I ended up specifying a proprietary interface that only my own player used. I think that many of these things have changed with EVR so I might give it another try. Thanks for the encouragement! -A

SundaY82

15th November 2009, 13:44

My first renderer (non-MPC) was in fact almost independent of the player. At that time there was one challenge that I couldn't find a good solution for: to switch between exclusive mode full-screen and windowed mode only using the standard renderer interfaces. Also at that time all players used the IVideoWindow interface which was a real pain to implement. So I ended up specifying a proprietary interface that only my own player used. I think that many of these things have changed with EVR so I might give it another try. Thanks for the encouragement! -A
I would also love a version free from mpc so I can use gothsync with zoom player :)

aymeric106

16th November 2009, 22:43

I spent years trying to find the perfect player ... and now, i've got it, thanks to your work
It was almost perfect until i saw your post about resizing and shaders http://www.ostrogothia.com/?p=1444, and now it is perfect.

bye bye reclock, powerstrip, mad renderer, haali ... I can stop buying nvidia card, then ati, then nividia ...
The only thing i'm missing is the script that was launched by reclock to set the proper frequency on my second monitor (24,50 or 60 Hz depending on the video source rate), but i'm not sure it's the media player role to change display frequency.

Anyway, thanks, and keep it up !!

aymeric

THX-UltraII

24th November 2009, 09:26

any news on MPC-HC intergration?

pirlouy

24th November 2009, 12:54

I think you missed another point ! :P http://www.ostrogothia.com/?p=1460

But maybe we can ask the development state of this kinda new renderer... Does it progress or are there more and more difficulties ? :-)

THX-UltraII

24th November 2009, 13:01

ar-jar

25th November 2009, 22:47

any news on MPC-HC intergration?

Sorry, progress is really slow now due to too much work (for a living). That *will* change, I just don't know exactly when. I'm happy to receive any feedback on the existing version in the mean time. -A

SundaY82

22nd December 2009, 00:03

Anyone have a dl link to latest version of gothsync?
Reinstalled my computer with windows 7 but now when I was to redownload gothsync the links are dead.

Progress update by the way?

THX-UltraII

22nd December 2009, 08:42

Let s hope it s not dead!

ar-jar

24th December 2009, 09:07

Let s hope it s not dead!

Thanks for letting me know. My ISP has been messing with my ftp site. I can't access it myself anymore. The support folks are probably home for Christmas so give it a few days. Hopefully I will get a couple of days off myself during the holidays to try to remember what my project was all about :-) -A

ar-jar

24th December 2009, 09:17

The download links should work again! -A

SundaY82

25th December 2009, 21:57

Thanks for letting me know. My ISP has been messing with my ftp site. I can't access it myself anymore. The support folks are probably home for Christmas so give it a few days. Hopefully I will get a couple of days off myself during the holidays to try to remember what my project was all about :-) -A
Sounds great, would really hate if this work you have done goes dead.

Did you plan on making some sort of version free from mpc that could be used in other players like zoom player?