Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 609585" data-attributes="member: 10858">Thanks for reading (I didn't even proof read the content yet, so there might be even some big brain farts included...).That issue would be solved the my &quot;future proposal&quot;, where video renderer is able to guide the reference clock.Those bursts might be coming form the wrong real fps detection code. One easy way to trigger such burst is to play DVD at 32x speed. At first it is smooth,but after maybe 5 seconds it goes havec (most likely the history data in the fps detection gets filled with the skipped frames etc which completely throws off the MPC-HC code that I borrowed. I guess it now just fires back that we haven't implemented custom EVR mixer that would allow the real fps to be gathered).It is completely fixable if we either have a reference clock that we can adjust from renderer side or when GPU manufacturers provide HW that has single clock chip. Now, with your merits I would even propose a team member status <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" /> After all you would be the only one in our team that really has been working with A/V industry... I would be interested into hear about some more info from your background.Note to users/testers:ReClock is not compatible with the MP1.1.0 RC2 when it comes to 1:2 material playback. Also it is not perfect when 1:1 or other types are considered, both these are fixable if someone has time...Owlsroost's DLL is even less compatible with the ReClock. So, when testing his DLL, it would be nice to test without ReClock, since otherwise there is just two algorithms that are going to fight with each other (in some cases it will work, in some it wont).</blockquote>

[QUOTE="tourettes, post: 609585, member: 10858"] Thanks for reading (I didn't even proof read the content yet, so there might be even some big brain farts included...). That issue would be solved the my "future proposal", where video renderer is able to guide the reference clock. Those bursts might be coming form the wrong real fps detection code. One easy way to trigger such burst is to play DVD at 32x speed. At first it is smooth,but after maybe 5 seconds it goes havec (most likely the history data in the fps detection gets filled with the skipped frames etc which completely throws off the MPC-HC code that I borrowed. I guess it now just fires back that we haven't implemented custom EVR mixer that would allow the real fps to be gathered). It is completely fixable if we either have a reference clock that we can adjust from renderer side or when GPU manufacturers provide HW that has single clock chip. Now, with your merits I would even propose a team member status :) After all you would be the only one in our team that really has been working with A/V industry... I would be interested into hear about some more info from your background. [SIZE="4"]Note to users/testers:[/SIZE] ReClock is not compatible with the MP1.1.0 RC2 when it comes to 1:2 material playback. Also it is not perfect when 1:1 or other types are considered, both these are fixable if someone has time... Owlsroost's DLL is even less compatible with the ReClock. So, when testing his DLL, it would be nice to test without ReClock, since otherwise there is just two algorithms that are going to fight with each other (in some cases it will work, in some it wont). [/QUOTE]

Verification