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

[red5goahead]

Not a good way, but you could query PowerStrip for such information (bad since requires 3rd party application and wont work with Nvidia > 7xxxx series). Reading from HW would be the best way, but I guess you wont want to develop another PowerStrip (and not to be able to read from newer Nvidia GPUs).

A good solution could be a reclock exposed com on .net library to query the exactly refresh used by reclock itself.
I'll try to ask this to Jong or James (reclock devs team). (better if reclock is not necessary indeed)

 

[tourettes]

Not a good way, but you could query PowerStrip for such information (bad since requires 3rd party application and wont work with Nvidia > 7xxxx series). Reading from HW would be the best way, but I guess you wont want to develop another PowerStrip (and not to be able to read from newer Nvidia GPUs).

A good solution could be a reclock exposed com on .net library to query the exactly refresh used by reclock itself.
I'll try to ask this to Jong or James (reclock devs team). (better if reclock is not necessary indeed)

Preferably a C++ based library, since dshowhelper.dll is not a NET component I guess ReClock is just asking from the DirectDraw / DirectX about the refresh rate (and neither of those are as accurate as PowerStrip)

 

[tourettes]

I was just following the technique that was already in use (but with calculated sleep times rather than looping with a 1ms sleep each iteration). I don't want to use anything that wastes CPU time e.g. polling for vsync, given that this is running at 'critical' thread priority.

It's only trying to push the 'paint' start time approx in the middle of the low/high limit period.

If thread context switch happens during a sleep (most likely it will since sleep is telling system that it is allowed to do it ) it could be as high as 10 ms that the sleep will take. And that is already almost the whole frame with 60hz display that the v-sync can "travel" during that time.

Causing high CPU usage in that part of code is not a sin, it won't be causing any playback issues like it would be if done in some other places. Also since the v-sync is most likely already in the place the high CPU spike wont be a long one. After all, that part of the code should be doing only a small fine tuning to the paint position.

I think the Sleep(1) was a relic, and shouldn't be there in the first place. Also I think I didn't see any CPU usage rise when busy polling in that part of the code.

 

[Owlsroost]

Not a good way, but you could query PowerStrip for such information (bad since requires 3rd party application and wont work with Nvidia > 7xxxx series). Reading from HW would be the best way, but I guess you wont want to develop another PowerStrip (and not to be able to read from newer Nvidia GPUs).

A good solution could be a reclock exposed com on .net library to query the exactly refresh used by reclock itself.
I'll try to ask this to Jong or James (reclock devs team). (better if reclock is not necessary indeed)

Preferably a C++ based library, since dshowhelper.dll is not a NET component I guess ReClock is just asking from the DirectDraw / DirectX about the refresh rate (and neither of those are as accurate as PowerStrip)

AFAIK, if it's not in it's timings database, it measures the refresh rate (this is the red/green flashing icon period - quite a long time period sometimes). Once it's got the display timing stored, it then just recalls the values each time (to speed things up at start of play).

Tony

I was just following the technique that was already in use (but with calculated sleep times rather than looping with a 1ms sleep each iteration). I don't want to use anything that wastes CPU time e.g. polling for vsync, given that this is running at 'critical' thread priority.

It's only trying to push the 'paint' start time approx in the middle of the low/high limit period.

If thread context switch happens during a sleep (most likely it will since sleep is telling system that it is allowed to do it ) it could be as high as 10 ms that the sleep will take. And that is already almost the whole frame with 60hz display that the v-sync can "travel" during that time.

Causing high CPU usage in that part of code is not a sin, it won't be causing any playback issues like it would be if done in some other places. Also since the v-sync is most likely already in the place the high CPU spike wont be a long one. After all, that part of the code should be doing only a small fine tuning to the paint position.

I think the Sleep(1) was a relic, and shouldn't be there in the first place. Also I think I didn't see any CPU usage rise when busy polling in that part of the code.

What about the timer + callback technique used in scheduler.cpp ? (but I don't have enough windows programming knowledge to understand how that really works.....)

Tony

 

[mrmojo666]

OK - time to put the tin hat on

Attached is my version of the dshowhelper.dll - it works OK on my system (Vista32, nVidia 9500GT with 195.62 drivers) but has to be regarded as VERY EXPERIMENTAL so tread carefully !

Please disable vsync correction in ReClock - the dshowhelper does it's own vsync correction internally.

It only attempts vsync correction if the (measured) display refresh rate is within 2% of 1x or 2x the (measured) video frames-per-second rate.

Tony

GOOD JOB!

I don't know what you exactly did but it work like a charm on my htpc this almost fix my hard stuttering problem https://forum.team-mediaportal.com/606737-post21.html.
Finally i get all working as it must work, playing pal 50i tv hd and sd is Ok at 50hz just get few framedrops, but they are not visible during play, no more stuttering

I think you found the right way to fix this annoying problem.

i don't use reclock , all is perfectly sync witout that.

Thank you i'll keep your directshowhelper as my treasssssure

 

[Owlsroost]

OK, good - and you are using Win 7 with an ATi 4670 video card too (I can only test it on Vista with nVidia 9500GT)

It doesn't need/assume ReClock, but it tries to accomdate the timing changes ReClock can perform....

Tony

 

[mrmojo666]

OK, good - and you are using Win 7 with an ATi 4670 video card too (I can only test it on Vista with nVidia 9500GT)

It doesn't need/assume ReClock, but it tries to accomdate the timing changes ReClock can perform....

Tony

Would be nice if us will keep in contact, to fine tuning.............. now , as i told , is stutter free....... would be GREAT if you can reach total stutter free with no framedrops at all


I'm really happy to help you in testing this customization, seems no one of the team is interested in get for ALL mp users stutter free experience

 

[tourettes]

What about the timer + callback technique used in scheduler.cpp ? (but I don't have enough windows programming knowledge to understand how that really works.....)

I'm not sure how reliable those are, but in any case CPU polling is most accurate so I would suggest you to do some testing if it has any affect on CPU usage (if I remember correct I didn't see any increase in CPU usage with my low end dev pc).

 

[Owlsroost]

What about the timer + callback technique used in scheduler.cpp ? (but I don't have enough windows programming knowledge to understand how that really works.....)

I'm not sure how reliable those are, but in any case CPU polling is most accurate so I would suggest you to do some testing if it has any affect on CPU usage (if I remember correct I didn't see any increase in CPU usage with my low end dev pc).

OK, I'll give it a try (but I'll incorporate the latest 'crash to the desktop' fixes from SVN 25556 first - I've had those crashes happen a few times...)

I take your point about sleep() allowing Windows to steal to much time sometimes

Tony

 

[tourettes]

What about the timer + callback technique used in scheduler.cpp ? (but I don't have enough windows programming knowledge to understand how that really works.....)

I'm not sure how reliable those are, but in any case CPU polling is most accurate so I would suggest you to do some testing if it has any affect on CPU usage (if I remember correct I didn't see any increase in CPU usage with my low end dev pc).

OK, I'll give it a try (but I'll incorporate the latest 'crash to the desktop' fixes from SVN 25556 first - I've had those crashes happen a few times...)

Just do a SVN update and the merging should be automatic (unless there are conflicts with the local changes you have made).