Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 609199" data-attributes="member: 10858">Thanks for joining the discussion <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /> Just going to give a quick answer, not to all point you made.Actually raster offset is pretty close the point of presentation, just a bit different &quot;name&quot;. Raster offset is nothing more than the current v-sync point / line. And presentation time can be either &quot;free&quot; (MP's current code doesn't try to target the presentation position of 1:1 material to anything special place) or targeted to some specific raster offset (like MP does for 1:2 to reduce the risk of presenting frame on a wrong v-sync).Too bad that ReClock is closed source, so it will make really hard to know what it is exactly doing. For example if we would know that ReClock is not going to re-adjust the reference clock rate when the presentation happens on lets say 1/4 th of the screen area it would make things much more easy. If both MP and ReClock tries to adjust video presentation spot and audio / reference clock those both are feeding back into each others Also one issue that ReClock creates is that the direct show samples aren't going to reflect the real duration (so code needs to have some ugly tolerance for the real and told fps).In short, we would need to have really detailed description of the ReClock's algorithm to be able to write a EVR presenter code that works nicely with it. Unfortunately I'm sure that Slysoft wont give even than much out and we are just left in cold to guess what happens.</blockquote>

[QUOTE="tourettes, post: 609199, member: 10858"] Thanks for joining the discussion :) Just going to give a quick answer, not to all point you made. Actually raster offset is pretty close the point of presentation, just a bit different "name". Raster offset is nothing more than the current v-sync point / line. And presentation time can be either "free" (MP's current code doesn't try to target the presentation position of 1:1 material to anything special place) or targeted to some specific raster offset (like MP does for 1:2 to reduce the risk of presenting frame on a wrong v-sync). Too bad that ReClock is closed source, so it will make really hard to know what it is exactly doing. For example if we would know that ReClock is not going to re-adjust the reference clock rate when the presentation happens on lets say 1/4 th of the screen area it would make things much more easy. If both MP and ReClock tries to adjust video presentation spot and audio / reference clock those both are feeding back into each others Also one issue that ReClock creates is that the direct show samples aren't going to reflect the real duration (so code needs to have some ugly tolerance for the real and told fps). In short, we would need to have really detailed description of the ReClock's algorithm to be able to write a EVR presenter code that works nicely with it. Unfortunately I'm sure that Slysoft wont give even than much out and we are just left in cold to guess what happens. [/QUOTE]

Verification