home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Support
Codecs, External Players
A guide to stutter free playback with Reclock
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="tourettes" data-source="post: 608493" data-attributes="member: 10858"><p>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).</p><p></p><p>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.</p><p></p><p>The reason why it is not accurate:</p><p></p><p>1) Even running on time critical priority kernel / drivers (and some system processes) are allowed to steal time from the application. </p><p>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 </p><p></p><p>Also delaying the video playback start up time with 1 second is not suitable.</p><p></p><p>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)</p><p></p><p></p><p></p><p>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.</p><p></p><p></p><p></p><p>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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" />) that can be used.</p></blockquote><p></p>
[QUOTE="tourettes, post: 608493, member: 10858"] 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) 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. 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Support
Codecs, External Players
A guide to stutter free playback with Reclock
Contact us
RSS
Top
Bottom
