MPC-HC GothSync tryouts

[tetsuo55]

This is what I think happened: You managed to find a file / decoder combination just like Jong's, which doesn't report its frame-rate in the videoinfo header. Thus the 0 on the second row. With such a large (apparent) rate difference, the "snap" function won't kick in and you get judder when passing vsync.

I just fixed (hopefully) exactly this issue in VMR9. I will do the same with EVR if the fix seems to work well. -Asounds plausible.
Let me know as soon as you have ported that fix, i will test it asap.

[Jong]

I think it is remarkable how smooth we are now managing to make things given this background, helped significantly by throwing ridiculously large amounts of processing power at the problem compared to what should be needed.I thought I'd elaborate a little on this comment, for discussion!

Reclock alters the frame rate to match it to the refresh rate; In vsync mode it even alters it continually to keep frame presentation in the "right" place relative to vsync. To be able to do this it has to resample up to 8 channels of potentially high definition, up to 96khz/24-bit, audio in real time; To keep HD audio HD it has to do this to an exceptionally high quality. This simply would not have been possible a few year ago. It was not really possible when Reclock was written, hence Ogo's recommendations that lower quality resampling be used. This may have been OK (ish!) for SD audio, but would certainly have been unacceptable in today's HD world. Only recent advances in processing power and GPUs has allowed better resampling to be incorporated into Reclock in the last year, and for most of us, with state-of-the-art HTPCs, to use it.

Gothsyncs methods are (and you know I do not mean this in a derogatory way at all!) "simpler" and "lighter" but it does mean for a perfect result you need a better match of frame-rate and refresh rate. Even then only options 1 and 2 offer the "perfect" video playback we are all seeking. However, even they (and Reclock) rely on the fact that a modern PC is able to render and paint a frame in a tiny fraction of the time available between vsyncs. There is plenty of space available to avoid frames being presented @vsync and plenty of spare CPU (mostly!) for Windows to do whatever it wants/needs/must do even when playing time critical video :rolleyes: and still deliver the frame on time. It would be possible to build a stand-alone player using technology from many years ago that takes most of the time between refreshes to render the frame, but a PC using that technology would be completely unreliable in delivering frames on time. The methods we are using to retro-fit vsync correction would also be unreliable on such hardware.

Along with the sad fact that 90% of the market just do not know or care about smooth video playback(!), the other reason why the "main players" have not yet fixed the problem (I guess) is any of the techniques available would not work on the full spectrum of PCs that they would be expected to run on. In another few years that may change, but it will, again, be using the brute force of incredible processing power to overcome a fundamental design flaw.

[THX-UltraII]

did some more and more testing last night:

No matter what combination I tried (with VSync settings d3d etc etc) there was always troubles.

Eventually I applied a 'back-to-basics' method:

I installed the latest regular MPC-HC version and put EVERYTHING off (vsync options, etc) and now everything works as smooth as hell

[Jong]

If you don't have a problem don't look for one and don't try to fix it! It will only drive you mad. Glad you have found something you are happy with. It would help others if you listed your full settings - OS, renderer, renderer options, renderer settings, display refresh rate.

[ar-jar]

sounds plausible.
Let me know as soon as you have ported that fix, i will test it asap.

There's a new private build. I've now also addressed the case when the video frame-rate is higher than the display refresh rate. I realized it wouldn't have worked with the Present at Nearest as it was implemented before. It also exclusively gets the frame rate from the sample timestamps now, both in VMR and EVR. It seems to be the only reliable method to actually get the number. And the previous method also had some serious issues as Jong found out. It was the same code as in the regular build so I wouldn't be surprised if the same issue pops up there too sooner or later. I don't have time to fix any major bugs again for a week or so, so be patient :-) Cheers! -A

[Jong]

ar-jar. Thanks for the new build. I will test tomorrow.

Something occured to me about "option 3". Does audio/video sync change as your offset correction grows or do you fix this somehow? If it grows it might still be OK for 60Hz/50Hz but it could be quite noticeable @24Hz (42ms cycle time). Of course option 3 is only the fallback anyway.

[Jong]

So although it's still 9012 it's new, right? Changed from last night's new build?

[ar-jar]

ar-jar. Thanks for the new build. I will test tomorrow.

Something occured to me about "option 3". Does audio/video sync change as your offset correction grows or do you fix this somehow? If it grows it might still be OK for 60Hz/50Hz but it could be quite noticeable @24Hz (42ms cycle time). Of course option 3 is only the fallback anyway.

Audio and video will get slightly out of sync yes (one frame cycle at the most). But this is a tricky issue in general if you don't insist on GPU flushes and what have you. The gfx board for instance has according to DirectX docs the option to store up to 2 frames in an inaccessible buffer if it so chooses which will give you some 80 ms diff to start with. It is definitely possible to improve the performance but it's not my priority right now. A stable renderer is :-) -A

[Jong]

Yes of course I understand!

But most can calibrate for a fixed offset. 42ms of variable sync @24Hz will be very noticeable and may influence whether it can/should be the default setting for 24p?

Do you think your build with all your sync settings OFF has a different AV sync to the trunk build with default GPU flush settings? I haven't spent long with it but I think there is about 40ms of difference, which I need to adjust for.

[ar-jar]

Yes of course I understand!

But most can calibrate for a fixed offset. 42ms of variable sync @24Hz will be very noticeable and may influence whether it can/should be the default setting for 24p?

Do you think your build with all your sync settings OFF has a different AV sync to the trunk build with default GPU flush settings? I haven't spent long with it but I think there is about 40ms of difference, which I need to adjust for.

Depending on the gfx board, all players using DirectX may end up with 2 frames worth of audio lead, if not compensated for. This probably varies between boards. GPU flush flushes the GPU pipeline clean and so should cause immediate presentation. (It also thus disables any threading advantages of having a pipeline in the GPU.) Not sure if there is a way to actually know exactly when a new frame is flipped into the front buffer by gfx driver. Maybe one can query the GPU but I haven't checked. -A

[Jong]

In my experience the most important thing is for it to be consistent. Probably up to 20ms of variability @50Hz will not be noticed, especially if av sync is set so audio is slightly behind video at all times, but 42ms of variability I think would be distracting (for me anyway!).

[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.

Greetings ar-jar. Did you get a chance to look into these issues?

Best regards.

[Casshern]

Hi,

i just switched to win7 and already posted some interesting findings in the main MPC HC thread. I came around testing the MPC GOTHSync tryouts under win 7 and want to present some of my observations. Let me first briefly sum up my findings of the regular build (x86), win7 (x64), my trusty old ATI 2600 PRO AGP, reclock (no vsync control), and powerstrip (e.g. 47.952 display refresh), movie frame rate 23.976, EVR CP:

Through trial and error i came up with two working (no tearing, judder free, dxva + YV12 upsampling + complex sharpen 2, bicubic resizing) settings:
1) All Vsync options off, all gpu options off, desktop composition enabled (= uncheck the option to disable the desktop composition).
tearing free + judder free: but after starting play might be stuck with permanent judder which one has to eliminate by hitting pause/play a couple of times. Once judder free it will stay that way - i tested it with about 3 full movies.

2) Even better: Vsync on, all other options off, desktop composition disabled.
tearing free + judder free: after start i get tearing judder for maybe 1-2 seconds after which beliyaals code settles and gives perfect playback. But this is extremely sensitive to the time it takes the gfx card to finish all DXVA+Shader+ resizing operations. If the card takes to long, you get tearing. If went back to bilinear scaling or desabled one of the shaders i used (e.g. complex sharpen) it worked fine. Luckily i found out that I had to compile all shaders with shader model 3.0 which gave enough of a speed up to have everything working without disabling any shader or going back to bilinear resizing.

Additional observations: resizing is currently ALWAYS applied, even if source resolution equals display resolution. Also it seems like the shaders are also applied at screen refresh and NOT on the decoded frames. Here is a lot of room to improve especially for older/slower/onboard gfx cards. It would be best to decouple the shaders+resizing from screen refresh.

Speculation: this decoupling sort of happens if you use aero (enable desktop compositon) or use the flush gpu, wait for gpu settings: Here the code waits for all GFX operations to finish. If this takes longer then one screen refresh, beliyaals code recovers here (i don't know whether by design or accidental) as the previous skipped display frame is only a repeat of the previous.

Gothsync tryouts:
Under XP: i did not get it to work without tearing, no matter what GPU settings and i highly suspect it was indeed because of the speculation above, only that the goth code does not recover that well
Under Win7: Everything turned off, except for the present at nearest sync option, and desktop compositon disabled it behaved much like method two above. Judderfree + tearing free, if and only if i disable one of the shaders and/or go back to simpler resizing. It seems like the goth code is even move timing sensitiv or maybe just takes up more vsync time of its own. But if i disable a shader it works pretty solidly - but at the moment i would obviously prefer the beliyaal code as it permits to use all of my shaders and bicubic resizing.

All this explains some of the probs people with slow gfx cards and/or Vista versions without aero have. Without aero you cannot use option1 and with a very slow gfx dxva engine even option two without any shaders and simple resizing might be plaged with tearing.

i hope this sheds some light on some issues and helps to improve....

[ar-jar]

Greetings ar-jar. Did you get a chance to look into these issues?

Best regards.

Hi, I think I gave you a partial answer earlier. I could never access the screenshot as it was pending approval for a long time.

Not sure what you mean by "target refresh rate". The refresh rate should stay approx. constant with that sync option. The refresh rate is estimated when streaming starts and then from the estimated vsync times. The vsync detection may be less exact now than in previous builds but should be sufficiently exact for its purposes.

About tearing: the only pretty universal antidote seems to be exclusive fullscreen ("D3D"). Many boards including the ones I have at home are pretty tearing-proof as long as you give them enough time to do the rendering (keep the green line far enough above the red line in the graph). But other boards seem to require all kinds of tricks. I would be great if we could, once we have a couple of stable builds, collect some data on what configs work well and what configs to avoid when building a new HTPC. -A

[Jong]

New private build does seem to have fixed the hanging problem. However, when it exits it does not seem to cause a full screen refresh :confused: (using VMR9 D3D)

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

[tetsuo55]

New private build does seem to have fixed the hanging problem. However, when it exits it does not seem to cause a full screen refresh :confused:it's probably better and faster if you use an externalhosting like imageshack.us

[tetsuo55]

There's a new private build. I've now also addressed the case when the video frame-rate is higher than the display refresh rate. I realized it wouldn't have worked with the Present at Nearest as it was implemented before. It also exclusively gets the frame rate from the sample timestamps now, both in VMR and EVR. It seems to be the only reliable method to actually get the number. And the previous method also had some serious issues as Jong found out. It was the same code as in the regular build so I wouldn't be surprised if the same issue pops up there too sooner or later. I don't have time to fix any major bugs again for a week or so, so be patient :-) Cheers! -AHere is the result for dvd playback on my htpchttp://img245.imageshack.us/img245/7019/dvd2.th.png (http://img245.imageshack.us/i/dvd2.png/)

[ar-jar]

Here is the result for dvd playback on my htpchttp://img245.imageshack.us/img245/7019/dvd2.th.png (http://img245.imageshack.us/i/dvd2.png/)

Looking good huh? -A

[tetsuo55]

Looking good huh? -AYeah, however on the "sample paint time correction" roll over from 16 to 0 it still looks like this: http://forum.doom9.org/showthread.php?p=1324878#post1324878

[THX-UltraII]

if you guys had to pick an OS from a full reinstallation of a HTPC. Which is the best to pick (with keeping in mind the best for MPC-HC and no-tearing).

XP
Vista
or
Windows7 (which version is the current one?)

[pirlouy]

In the latest build (Tentative patch 9012), seek function is quite broken: when you seek, image freezes (not always, but often).

Not present in an older build. Someone to confirm ?

[ar-jar]

In the latest build (Tentative patch 9012), seek function is quite broken: when you seek, image freezes (not always, but often).

Not present in an older build. Someone to confirm ?

I'm working on it :-) -A

[ar-jar]

In the latest build (Tentative patch 9012), seek function is quite broken: when you seek, image freezes (not always, but often).

Not present in an older build. Someone to confirm ?

The new version should be a little better but it's not perfect. To be continued... -A

[buzzqw]

Hi

i dumb question: my plasma support 23.976, 24p, 25p,50p,60i,60p mode and my nvidia (9400m) too

i tryed your mpc build, but don't seems that framerate of display changes (even if i checked the options) (tested with varius sources)

for sure i am doing something stupid.. any help ?

BHH

[webs0r]

I'll post what I found useful in getting perfect sync:

Setup
Intel E7300 @ 3.4 Ghz
ATI 4550
Windows Home Server (comparable to XP)

I found EVR+Gothsync patch version gives me the most consistent perfect sync.

Typical filterchain:
Source (haali splitter mostly)
Decoder (usually ffdshow or coreavc)
ffdshow (Spline resize + colour conversion)
Reclock
EVR/gothsync renderer

My TV supports basically 50/60 Hz only afaik, at least I don't know other timings for it (48?).

So I use reclock to automatically switch refresh rate to 50 or 60 Hz and adjust media speed to 25 or 30 fps exact, depending on the source.

Then I have gothsync set to present at nearest vsync.

With target sync offset set to 9ms:
- I found it would tear when I set MPC resize to Bicubic. Tearing would be fixed if I set it to bilinear, in which case playback was perfect.
- This is even though MPC doesn't need to resize when ffdshow is resizing to 1080 already and I am watching at 1080. So I'm keen to get latest MPC code merged.

With target sync offset set to 14ms:
- It does not tear when I set MPC resize to Bicubic & there is perfect playback.

Although I don't understand the detail it seems that moving this offset up has given the system more time to ..? All I know is it avoids tearing when the graphics system has (slightly) more load. Knowing this & the resize issue might help some out there.

Other notes:
- Monitoring the MPC load on the GPU shows that there is only a small difference in bilinear vs bicubic, both well below 100% (20-30%)
- Can frames be prepared & buffered ahead of time so that variation in cpu/gpu load become irrelevant?
- It is interesting to test with 50/60 fps content as the window is much smaller. I get perfect sync on this too, but on my gaming/encoding rig which is much more powerful (q9550/8800gt etc).
- Argh I overwrote my copy with seek working! :( Ar-jar can the version numbers be incremented, and maybe older versions kept? :)

Cheers & good luck!

[ar-jar]

Hi

i dumb question: my plasma support 23.976, 24p, 25p,50p,60i,60p mode and my nvidia (9400m) too

i tryed your mpc build, but don't seems that framerate of display changes (even if i checked the options) (tested with varius sources)

for sure i am doing something stupid.. any help ?

BHH

Which sync option are you testing? The refresh rate of the display (if that's what you mean) only changes with the Sync Display option and it probably won't work with your new-ish nvidia board. You have to check if it is supported by PowerStrip. More documentation on my site. -A

[ar-jar]

With target sync offset set to 9ms:
- I found it would tear when I set MPC resize to Bicubic. Tearing would be fixed if I set it to bilinear, in which case playback was perfect.
- This is even though MPC doesn't need to resize when ffdshow is resizing to 1080 already and I am watching at 1080. So I'm keen to get latest MPC code merged.

With target sync offset set to 14ms:
- It does not tear when I set MPC resize to Bicubic & there is perfect playback.

Although I don't understand the detail it seems that moving this offset up has given the system more time to ..? All I know is it avoids tearing when the graphics system has (slightly) more load. Knowing this & the resize issue might help some out there.

Other notes:
- Monitoring the MPC load on the GPU shows that there is only a small difference in bilinear vs bicubic, both well below 100% (20-30%)
- Can frames be prepared & buffered ahead of time so that variation in cpu/gpu load become irrelevant?
- It is interesting to test with 50/60 fps content as the window is much smaller. I get perfect sync on this too, but on my gaming/encoding rig which is much more powerful (q9550/8800gt etc).
- Argh I overwrote my copy with seek working! :( Ar-jar can the version numbers be incremented, and maybe older versions kept? :)

Cheers & good luck!

Some answers:

- A larger sync offset indeed gives the GPU more time for processing. I haven't been eager to pull it back too far as one may perhaps "slip" to the previous vsync period if you are too close to the previous vsync. But people say it doesn't easily happen so it's probably safe to pull it back to say 3/4 of a vsync cycle (15 ms @ 50 Hz).
- Merge will come in due time :-)
- Frames are already buffered (> 4 when running EVR) but the GPU can only take one frame at the time anyway.
- 50/60 fps shouldn't make much difference to 25/30 as I already only use one vsync period at the most for processing (easier algorithms).
- I will have numbering on the more "official" builds but I've been churning out "private builds" for a few people to test. Now these have become more or less "official"... The thing is that to insert a new patch label I need to recompile for maybe 5 minutes which is a lot sometimes.
Cheers! -A

[tetsuo55]

The new version should be a little better but it's not perfect. To be continued... -ADoes this mean you uploaded a new private build last minute?

[buzzqw]

Which sync option are you testing? The refresh rate of the display (if that's what you mean) only changes with the Sync Display option and it probably won't work with your new-ish nvidia board. You have to check if it is supported by PowerStrip. More documentation on my site. -A

thanks for the answer

i have checked "synch display to video"

could you please link me the power strip on your site ?
i have tryed the search .. but don't seems to works well (too much results)

or i must search on power strip application site ?

thanks again

BHH

[ar-jar]

Does this mean you uploaded a new private build last minute?

I'll try to number the private builds too in the future. Try this one for a fresh start of that numbering :-) -A

[ar-jar]

thanks for the answer

i have checked "synch display to video"

could you please link me the power strip on your site ?
i have tryed the search .. but don't seems to works well (too much results)

or i must search on power strip application site ?

thanks again

BHH

See this page http://www.ostrogothia.com/?page_id=1216 under "Alternative 2". -A

[pirlouy]

Does this mean you uploaded a new private build last minute?
Yes, and this build improved seek function.
And with the new one (9013), it looks like there isn't seek problem anymore.

Thanks ar-jar for your work and your spontaneity !

[Jong]

ar-jar, can you explain to everyone the difference between "glitches" and "frames dropped" in the OSD of your latest private builds?

Is it the difference between frames which are "consciously" never displayed because they are ready too late vs those that are skipped/repeated due to successive frames being presented too close to vsync?

[webs0r]

Awesome, seek problem mostly fixed:

Ar-jar I noticed that on my 60 fps test scenario on HTPC (60 Hz/60 fps source):
- if I have too much processing that can't pump out the frames fast enough (CPU saturated), the video just "freezes" similar to the seek problem before (i.e. sound continues, picture is still). Not sure what the best option is in the scenario as the video would technically be unwatchable anyway, but should it just skip frames, perhaps just display the last frame actually ready at the vsync?
- if I reduce the processing (basically take off spline resize), it works flawlessly <edit: actually it doesn't i just noticed it is dropping every 2nd frame need to test more and get a screenshot>

[tetsuo55]

Awesome, seek problem mostly fixed:

Ar-jar I noticed that on my 60 fps test scenario on HTPC (60 Hz/60 fps source):
- if I have too much processing that can't pump out the frames fast enough (CPU saturated), the video just "freezes" similar to the seek problem before (i.e. sound continues, picture is still). Not sure what the best option is in the scenario as the video would technically be unwatchable anyway, but should it just skip frames, perhaps just display the last frame actually ready at the vsync?
- if I reduce the processing (basically take off spline resize), it works flawlesslyimho it should start dropping frames, and only display frames it has on time for paint

[ar-jar]

Awesome, seek problem mostly fixed:

Ar-jar I noticed that on my 60 fps test scenario on HTPC (60 Hz/60 fps source):
- if I have too much processing that can't pump out the frames fast enough (CPU saturated), the video just "freezes" similar to the seek problem before (i.e. sound continues, picture is still). Not sure what the best option is in the scenario as the video would technically be unwatchable anyway, but should it just skip frames, perhaps just display the last frame actually ready at the vsync?
- if I reduce the processing (basically take off spline resize), it works flawlessly <edit: actually it doesn't i just noticed it is dropping every 2nd frame need to test more and get a screenshot>

Hi, in my notes on my download page I wrote a couple of words about this scenario. It does at least not work too well with Present at nearest option in the 50/50 or 60/60 scenario. Dropping every other frame might be correct if they arrive too late. When it goes black it *might* be because every frame arrives late and the system is choked up basically. But I haven't tested these scenarios too well yet. -A

[webs0r]

Hi ar-jar

Actually upon doing some more testing, I have a feeling it is just an OSD issue..... because it *seems* quite smooth. I know, its subjective but I think it is showing me 60 fps but telling me its only doing 30. Actually I can't really definitively tell, if its dropping every second frame exactly its hard.

http://sharonj81.customer.netspace.net.au/example.jpg
- Please refer to the number of frames dropped - those 160 were from the last few seconds after reset stats, increase at about 30 per second I think
- But the playback is butter smooth
- The sync is fine
- I have cpu/gpu to spare in this test case

[Jong]

The player seems to exit properly with this latest private build. No remnants of the last frame left on the screen, as in my earlier screenshot. Thanks.

[ar-jar]

Actually upon doing some more testing, I have a feeling it is just an OSD issue..... because it *seems* quite smooth. I know, its subjective but I think it is showing me 60 fps but telling me its only doing 30. Actually I can't really definitively tell, if its dropping every second frame exactly its hard.

- Please refer to the number of frames dropped - those 160 were from the last few seconds after reset stats, increase at about 30 per second I think
- But the playback is butter smooth
- The sync is fine
- I have cpu/gpu to spare in this test case

It *is* probably dropping every other frame but since the contents is interlaced you probably don't get more than 30 unique frames anyway so you won't notice losing every other frame. As I said, I haven't managed to put the last bits of the algorithm in place so it doesn't handle the 50/50 or 60/60 case very well. It's a bit of a challenge actually. But I'll get there... -A

[webs0r]

OK. Ready to test whenever :)

Question: When reclock changes playback from 23.9 to 25 fps, how come the OSD still reports 23.9 as the frame rate?

[Jong]

Question: When reclock changes playback from 23.9 to 25 fps, how come the OSD still reports 23.9 as the frame rate?Yes, I'm intrigued by this too.

What is also interesting is the "Actual Frame Rate" reported in Gothsync DOES change when Reclock is making the, much smaller, adjustments to frame rate needed for vsync correction. I had thought that Reclock would simply take the two factors and use them to make one adjustment to the master clock, but it seems frame rate/refresh rate matching and vsync correction are made in different places.

[starla_]

Yes, I'm intrigued by this too.

What is also interesting is the "Actual Frame Rate" reported in Gothsync DOES change when Reclock is making the, much smaller, adjustments to frame rate needed for vsync correction. I had thought that Reclock would simply take the two factors and use them to make one adjustment to the master clock, but it seems frame rate/refresh rate matching and vsync correction are made in different places.

Actual frame rate is calculated based in the rendering stats and the frame rate is most likely read from the media file / samples itself.

[Jong]

Actual frame rate is calculated based in the rendering stats and the frame rate is most likely read from the media file / samples itself.That doesn't match what we are seeing.

[ar-jar]

OK. Ready to test whenever :)

Question: When reclock changes playback from 23.9 to 25 fps, how come the OSD still reports 23.9 as the frame rate?

Please take the 9014 version for a spin. Haven't had much time for testing unfortunately but the older versions are there as a fall-back. Search might still be a bit of an issue.

The frame rate has to do with the fact that Reclock doesn't change the time stamps on the frames (of natural reasons since it's just an audio renderer) and the Frame cycle number is based on those time stamps. Reclock also adjusts the reference clock which I use to measure the Actual frame cycle. So both numbers are off. I could use another clock to measure the actual frame rate of course but haven't got around to it.

Cheers! -A

[webs0r]

9014 is working well for me for up to 30 fps content I haven't yet had a seek issue.
I had one instance where it displayed weird behaviour (dropping frames) before fixing itself, but I'm unable to replicate it now.

Here is a shot of playback of 60 fps content now:
http://sharonj81.customer.netspace.net.au/example2.jpg

- Now it is not dropping every second frame, it is dropping less (good)
- But "randomly" so you do notice constant stutter (bad)
- This does experience the seek issue (but not all the time) where the video will freeze
- When testing on the overloaded cpu scenario the video will freeze as well

[ar-jar]

9014 is working well for me for up to 30 fps content I haven't yet had a seek issue.
I had one instance where it displayed weird behaviour (dropping frames) before fixing itself, but I'm unable to replicate it now.

- Now it is not dropping every second frame, it is dropping less (good)
- But "randomly" so you do notice constant stutter (bad)
- This does experience the seek issue (but not all the time) where the video will freeze
- When testing on the overloaded cpu scenario the video will freeze as well

Thanks for testing! What's our CPU-load when running 60 fps w/o DXVA. I have only been able to test 50 fps @ 50 Hz from a Cyberlink Video/SP decoder that delivers 50 fps in DXVA mode. Do you have any links to true 60 Hz material that I can decode with the internal decoders. Would be useful for further testing. (One of my "problems" is that I have a very powerful computer for compilation purposes and it conceals many timing issues.) -A

[Jong]

The frame rate has to do with the fact that Reclock doesn't change the time stamps on the frames (of natural reasons since it's just an audio renderer) and the Frame cycle number is based on those time stamps.Makes sense, but how come the frame cycle and actual frame rate DO change when Reclock is correction vsync (see those two posts off the Reclock forum I PM'd you)?

[mariner]

Greetings ar-jar.

9014 is quite a disaster, massive number of dropped frames.

Tested with MS decoder, currently the only one that offers FGT.

[STaRGaZeR]

Hi Arto, I've been testing your branch for weeks but didn't have time to properly report these issues. Well, let's get it started because your chenges have lots of potential. I'm using a Samsung 2233RZ, which has a refresh rate of 120Hz. Real 120Hz. Private build 9013 from your site, fresh installations of Vista and Seven x64.

- Issue 1:

I get this glitches every time the device is restarted, by opening a new file, changing the refresh rate when playing videos, etc. They were introduced when beliyaal changed EVR, so they're not caused by your changes, but if you can look into it, it'd be fantastic. I can always reproduce this behaviour. They happen every 2 seconds or so, for 30 seconds or so, then they disappear and playback is perfect.

http://thumbnails3.imagebam.com/4943/4e053d49421905.gif (http://www.imagebam.com/image/4e053d49421905)

When using 60Hz instead of 120Hz, I can't determine the frequency because it changes each time the device is restarted: 6, 20 seconds, whatever. Frame rate or options don't matter.

http://thumbnails19.imagebam.com/4943/cdbced49422976.gif (http://www.imagebam.com/image/cdbced49422976)

You can't see the next one because it comes 20 seconds after this one.

- Issue 2:

With your builds I get random lockups, the video just freezes while the audio continues for 5 seconds, then it stops too. I can track this one. I think it's the same issue other people are reporting. Happens with any of your sync options.

- Issue 3:

When "Sync video to display" is enabled, weird behaviour when using 120Hz and close frame rates like 23,976 or 29,97, glitches all over the place. Both should be flat lines. Red and green lines are parallel for some time, then an adjustment happens and the green line goes down until it passes the red line, after that, see the screenshot.

http://thumbnails15.imagebam.com/4943/c22a6e49423863.gif (http://www.imagebam.com/image/c22a6e49423863)

- Issue 4:

When "Sync video to display" is enabled, noise and audio glitches can be heard sometimes. Is this normal?


That's all for now, thanks for your hard work :)

[ar-jar]

- Issue 1:

I get this glitches every time the device is restarted, by opening a new file, changing the refresh rate when playing videos, etc. They were introduced when beliyaal changed EVR, so they're not caused by your changes, but if you can look into it, it'd be fantastic. I can always reproduce this behaviour. They happen every 2 seconds or so, for 30 seconds or so, then they disappear and playback is perfect.

When using 60Hz instead of 120Hz, I can't determine the frequency because it changes each time the device is restarted: 6, 20 seconds, whatever. Frame rate or options don't matter.

You can't see the next one because it comes 20 seconds after this one.

- Issue 2:

With your builds I get random lockups, the video just freezes while the audio continues for 5 seconds, then it stops too. I can track this one. I think it's the same issue other people are reporting. Happens with any of your sync options.

- Issue 3:

When "Sync video to display" is enabled, weird behaviour when using 120Hz and close frame rates like 23,976 or 29,97, glitches all over the place. Both should be flat lines. Red and green lines are parallel for some time, then an adjustment happens and the green line goes down until it passes the red line, after that, see the screenshot.

- Issue 4:

When "Sync video to display" is enabled, noise and audio glitches can be heard sometimes. Is this normal?

That's all for now, thanks for your hard work :)

Hi, thanks for your testing efforts! I don't have much time to look into these in a week or two unfortunately. A couple of comments and questions though:

In issue 1 you say "each time the device is restarted". What do you mean by that?

Issue 2: i will look into the lock-ups. Do they happen with all sync options turned off too or just with certain sync options?

Issue 3: The Sync video option can only bridge small frequency differences and is not recommended for a change that requires a "bias" (like from 23.976 to 24 or a multiple). The slope in the green line indicates that the frequency adjustment is not big enough. It actually looks like your frequency diff is 0.2%. The default frequency adjustment is only 0.12% (in the Options), i.e. too small. You could try Frequency adjustment = 0.0022 or something just as a test. But it's really not intended to be used that way.

Issue 4: No, no glitches should be heard. All my audio renderer have handled the small speed adjustments gracefully. Are you using SPDIF? Could you try with a different audio renderer and see what happens?

Thanks! -A