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
Development
General Development (no feature request here!)
MP1 EVR Presenter/dshowhelper community development
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="Jong" data-source="post: 609191" data-attributes="member: 104040"><p>Hi all! Especially owlsroost and tourettes, a few comments from a diehard member of the Reclock community for your consideration! Do with them what you will!</p><p></p><p>As discussed with owlsroost over @Slysoft forums Reclock changes the playback speed, e.g. 24p -> 25p by replacing the player's clock with one that runs too fast. It basically fools the player into thinking time is running faster than it is, so playback is faster. It also attempts to improve the synchronisation of the system, GPU and audio clocks, replacing the reference clock with its new improved version, which, even if on the face of it there is no need to adapt the playback speed eg. 24p @23.976Hz reduces any disagreement on what 23.976 really is between GPU and the player (normally the audio clock) that can and does lead to drift and ultimately to judder, when presentation passes through vsync. It is this drift that causes, as well as playback starting with judder, judder that starts after some time of playback, 1s - 90 mins, depending on the starting point of presentation and clock accuracy.</p><p></p><p>Reclock, without vsync correction enabled, goes a considerable way to eliminating this drift, but even with Reclock playback might start only just outside of the danger zone and then drift into it quite quickly during a movie.</p><p></p><p>AFAIK the only sure fire way of eliminating judder for sure, for ever (after the first few secs when it can never be guaranteed) is using Reclock WITH <em><strong>Reclock </strong></em>vsync correction. This is because, with vsync correction enabled, Reclock sets up a feedback loop that is constantly monitoring I think what you call the "raster offset" and by making additional minor adjustments to the reference clock, in addition to any needed to adapt the playback speed (as mentioned above), it keeps the <strong><em>raster offset </em></strong>, not just the point of presentation, in a fixed range. When it does this, even if the GPU and reference clocks do not quite agree on what 23.976 (for example) is, Reclock will spot this when the "Raster offset" drifts outside of its target zone and it will then make tiny adjustments to the playback speed to correct it. As I say, AFAIK, only this will guarantee you never have to drop a frame because of clock drift. </p><p></p><p>ar-jar's "sync video to display" kind of does the same, but because it cannot re-sample audio it can only be used if the frame rate and refresh rates are very close to being compatible, or audio will fall out of sync with video. It cannot even cope with a 23.976 -> 24.000 speedup.</p><p></p><p>I think what you are doing is similar to ar-jar's "Present at nearest" option, which will minimise judder by moving the point of presentation but cannot avoid it completely when speed difference, or just reference/GPU clock drift, leads to frames and vsync "lapping each other".</p><p></p><p>So, assuming you do not want to completely duplicate Reclock's intricate code for clock synchronisation and audio resampling (which I can understand) I think it is worth offering the advanced option to turn off all vsync code, as the MPC-HC EVR CP and EVR Sync renderers offer so people using Reclock e.g. to speed 24p ->25p can also use it to <em>really </em>fix vsync. This will only work with Aero ON, as I don't think you offer a D3D option for EVR, but for most now that should be fine.</p><p></p><p>Offering this will also help people who use a commercial Blu-ray player and need to use Reclock vsync correction to avoid this problem in those players. otherwise they need to turn off vsync correction when MediaPortal's player is used and turn it on again eg. for TMT or PDVD. This is possible by changing the registry prior to loading the player software, but that is a clumsy hack at best!</p><p></p><p>You could also offer an equivalent of "sync video to display" to properly fix vsync when rates are very close, but that is completely incompatible with Reclock and I realise that makes configuration rather unfriendly and support trickier.</p><p></p><p>Any way, as I said, just a few thoughts, for what they are worth. it is good to see another player fixing this issue. It still amazes me that the big commercial players still do nothing to address it. I assume they think their more mass market are mostly ignorant and either using mismatched rates anyway (so judder is unavoidable) or they just won't notice!</p><p></p><p>Jon</p></blockquote><p></p>
[QUOTE="Jong, post: 609191, member: 104040"] Hi all! Especially owlsroost and tourettes, a few comments from a diehard member of the Reclock community for your consideration! Do with them what you will! As discussed with owlsroost over @Slysoft forums Reclock changes the playback speed, e.g. 24p -> 25p by replacing the player's clock with one that runs too fast. It basically fools the player into thinking time is running faster than it is, so playback is faster. It also attempts to improve the synchronisation of the system, GPU and audio clocks, replacing the reference clock with its new improved version, which, even if on the face of it there is no need to adapt the playback speed eg. 24p @23.976Hz reduces any disagreement on what 23.976 really is between GPU and the player (normally the audio clock) that can and does lead to drift and ultimately to judder, when presentation passes through vsync. It is this drift that causes, as well as playback starting with judder, judder that starts after some time of playback, 1s - 90 mins, depending on the starting point of presentation and clock accuracy. Reclock, without vsync correction enabled, goes a considerable way to eliminating this drift, but even with Reclock playback might start only just outside of the danger zone and then drift into it quite quickly during a movie. AFAIK the only sure fire way of eliminating judder for sure, for ever (after the first few secs when it can never be guaranteed) is using Reclock WITH [I][B]Reclock [/B][/I]vsync correction. This is because, with vsync correction enabled, Reclock sets up a feedback loop that is constantly monitoring I think what you call the "raster offset" and by making additional minor adjustments to the reference clock, in addition to any needed to adapt the playback speed (as mentioned above), it keeps the [B][I]raster offset [/I][/B], not just the point of presentation, in a fixed range. When it does this, even if the GPU and reference clocks do not quite agree on what 23.976 (for example) is, Reclock will spot this when the "Raster offset" drifts outside of its target zone and it will then make tiny adjustments to the playback speed to correct it. As I say, AFAIK, only this will guarantee you never have to drop a frame because of clock drift. ar-jar's "sync video to display" kind of does the same, but because it cannot re-sample audio it can only be used if the frame rate and refresh rates are very close to being compatible, or audio will fall out of sync with video. It cannot even cope with a 23.976 -> 24.000 speedup. I think what you are doing is similar to ar-jar's "Present at nearest" option, which will minimise judder by moving the point of presentation but cannot avoid it completely when speed difference, or just reference/GPU clock drift, leads to frames and vsync "lapping each other". So, assuming you do not want to completely duplicate Reclock's intricate code for clock synchronisation and audio resampling (which I can understand) I think it is worth offering the advanced option to turn off all vsync code, as the MPC-HC EVR CP and EVR Sync renderers offer so people using Reclock e.g. to speed 24p ->25p can also use it to [I]really [/I]fix vsync. This will only work with Aero ON, as I don't think you offer a D3D option for EVR, but for most now that should be fine. Offering this will also help people who use a commercial Blu-ray player and need to use Reclock vsync correction to avoid this problem in those players. otherwise they need to turn off vsync correction when MediaPortal's player is used and turn it on again eg. for TMT or PDVD. This is possible by changing the registry prior to loading the player software, but that is a clumsy hack at best! You could also offer an equivalent of "sync video to display" to properly fix vsync when rates are very close, but that is completely incompatible with Reclock and I realise that makes configuration rather unfriendly and support trickier. Any way, as I said, just a few thoughts, for what they are worth. it is good to see another player fixing this issue. It still amazes me that the big commercial players still do nothing to address it. I assume they think their more mass market are mostly ignorant and either using mismatched rates anyway (so judder is unavoidable) or they just won't notice! Jon [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MP1 EVR Presenter/dshowhelper community development
Contact us
RSS
Top
Bottom