A guide to stutter free playback with Reclock (1 Viewer)

[tourettes]

e. For Windows 7 we already have OS based API to tell, but XP and Vista users are left in cold.

that doesn't seem a sin to me..... xp in not yet sold and vista too....all new HW is sold with win7, why still supporting xp ? I know many user that are happy with the 1.0.2 version and Xp. Go ahead and make MP ok just on the ACTUAL windows 7.

Getting completely off topic... We have promised that 1.1.0 supports XP / Vista. Would be quite nasty move now to tell users than XP is not supported So, it is not an option with MP1. ...now back to the topic.

 

[tourettes]

btw. I think it would be better to utilise the development sub forum to continue this experimenting. After all it doesn't match the topic of this thread.

 

[robyf]

btw. I think it would be better to utilise the development sub forum to continue this experimenting. After all it doesn't match the topic of this thread.

I think you both are doing a great job here... this is the right way to go to solve the problems.

For Owlsroost: I've tried your modded version. Works great with TV, HD and SD (slighty better than RC2 release where I had some occasional framedrop). Had not time to try it with 1:2 content for a long time (my problem was that after 30 minutes I got stuttering), but I will try as soon as possible and let you know.

I can confirm that with stats enabled xvid horribly stutters (it doesn't happen with TV and HDTV or MKV, don't know why).

 

[Owlsroost]

Owlsroost, any good ideas how to replace the display cycle detection code with something working? That current way is much too inaccurate (and cannot be used in at any MP release as such). After all, over a 10% deviation is simply just too much (23.xxx ms vs. 20.000ms). Error should be less than 0.5% to be acceptable. For Windows 7 we already have OS based API to tell, but XP and Vista users are left in cold. Maybe James could tell how ReClock does it (it has a setting for DirectX / DirectDraw, but I'm not sure what API calls it is using... and too lazy to try to spy those with anything )

Given the problems it's creating, I might revert to using the Windows reported value for now (but I'd love to know why the calculated values are so inaccuarate on your system - the timing polling loop runs at 'critical' thread priority, so is Win7 taking bigger chunks of time away from the thread so it misses a vsync sometimes ?)

Concerning the stats jitter etc - I've found that positioning the 'start of paint' time relative to display vsync can be critical - on my system (1080p display) it targets approx scanline 250 for start-of-paint, and paint finishes at approx line 500. Sometimes the end-of-paint point will change to just after line 0 i.e. something is delaying the return from PresentImage() until after the next vsync. I've no idea why this happens, but I assume there's more raster related synchronisation happening further down the render pipeline....

If you want to move this discussion to a more suitable place that's OK with me, but it would be nice to move the recent dshowhelper discussion posts as well so it's all in one thread.

Tony

 

[tourettes]

Given the problems it's creating, I might revert to using the Windows reported value for now (but I'd love to know why the calculated values are so inaccuarate on your system - the timing polling loop runs at 'critical' thread priority, so is Win7 taking bigger chunks of time away from the thread so it misses a vsync sometimes ?)

Yes, I think it is better to use the OS provided values (even when they cause nasty issues on XP / Vista as they are whole integer, also for Windows 7 they might be off since we don't know if the driver reports those correctly on 0.xxx ms area).

But the reason why that display cycle value cannot contain any errors is quite simple. If it will randomly be off (no matter what reason it is) it will "corrupt" the whole 2 hour movie experience since it causes quite periodic stuttering to be introduced. Its much more severe damage than normal hick ups that happen only sometimes / randomly are causing.

The reason why it is not accurate:

1) Even running on time critical priority kernel / drivers (and some system processes) are allowed to steal time from the application.
2) Polling and calculating some durations is always not 1:1 exact way to collect any information (especially when the point #1 is valid). With real time OS and high enough sampling rate the polling would be good enough, but not on Windows / Linux or any other desktop OS where kernel etc can

Also delaying the video playback start up time with 1 second is not suitable.

What comes to my dev PC, I dont think it is Windows 7 specific in any way. Just bad luck that something interrupts the polling loop for a few ms and causes the incorrect results / missed v-sync (five loops -> one missed v-sync -> pretty much the 20 to 23.9...ms jump. Again, Windows 7 has an API that can be used to track down the v-sync counts... but it is not suitable for MP1)

Concerning the stats jitter etc - I've found that positioning the 'start of paint' time relative to display vsync can be critical - on my system (1080p display) it targets approx scanline 250 for start-of-paint, and paint finishes at approx line 500. Sometimes the end-of-paint point will change to just after line 0 i.e. something is delaying the return from PresentImage() until after the next vsync. I've no idea why this happens, but I assume there's more raster related synchronisation happening further down the render pipeline....

PresentImage() is always waiting the v-sync. Sounds like the code did present too close to the next v-sync and DirectX / drivers are skipping over the v-sync since it is too late to present anything at that time.

If you want to move this discussion to a more suitable place that's OK with me, but it would be nice to move the recent dshowhelper discussion posts as well so it's all in one thread.

I think it would be good to discuss the technical details in the correct forum part. Please create a new thread (with a good opening post ) that can be used.

 

[red5goahead]

From the render stats it looks like you are using ReClock to play 24fps material at 25/50fps (I do this too), so I think the problem is that the frame rate ratio detection is deciding to turn off the vsync correction sometimes.

Yes. Pal Speedup and Pal Speeddown (don't forget about it) should be supported in the new dynamic vsync correction .

 

[Owlsroost]

As requested, new thread created for dshowhelper related discussions here - https://forum.team-mediaportal.com/general-development-no-feature-request-here-48/mp1-evr-presenter-dshowhelper-community-development-81148/#post608526 - please post any new comments in that thread.

Tony

Yes. Pal Speedup and Pal Speeddown (don't forget about it) should be supported in the new dynamic vsync correction .

It already does try to support it.

Tony

 

[Jay_UK]

Ignore me...Answered my own question

J.

 

[Ragnarok666]

One issue that Scythe noticed in MP1 EVR presenter code is that the sample queue is not tried to fill, unless it is almost empty. This could cause some dropped frames on busy, lower end systems. Worth to check / change for the next DLL that is build for testing:

In ReturnSample()

if (tryNotify && m_iFreeSamples == 1 && m_bInputAvailable)

Should be:

if (tryNotify && m_iFreeSamples < NUM_SURFACES && m_bInputAvailable)

I think that is causing some major stutters even on higher end systems like mine, makes DXVA stop for a few seconds before resuming with an unmodified mp 1.1.0 dshowhelper.dll, it's very annoying!!

 

[tourettes]

One issue that Scythe noticed in MP1 EVR presenter code is that the sample queue is not tried to fill, unless it is almost empty. This could cause some dropped frames on busy, lower end systems. Worth to check / change for the next DLL that is build for testing:

In ReturnSample()

if (tryNotify && m_iFreeSamples == 1 && m_bInputAvailable)

Should be:

if (tryNotify && m_iFreeSamples < NUM_SURFACES && m_bInputAvailable)

I think that is causing some major stutters even on higher end systems like mine, makes DXVA stop for a few seconds before resuming with an unmodified mp 1.1.0 dshowhelper.dll, it's very annoying!!

Which one? The old or proposed implementation? Also have you tested the actual change (with no other changes done)?