Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 510690" data-attributes="member: 10858">Hopefully that drifting is caused by the inaccuracy of the current query performance counter code (I'll provide the fixed GetCurrentTimestamp() method as soon as I have done my own testing...).Yep, testing on the different hardware might show some issues (hopefully not). But it is a good to test those before going into public test mode.There are few known oddities that could be need to taken care:1) our TsReader is not able to report the fps rate of the played file (old EVR code is assuming every thing is 40.000 ms per frame if no rate is provided). This might break NTSC videos... Fixing f the TsReader is on the way, but I'm not sure if we can push that change into 1.1.0 (depends how busy djblu and gemx are <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite7" alt=":p" title="Stick Out Tongue&nbsp; &nbsp; :p" loading="lazy" data-shortname=":p" />)2) Some other files might as well sometimes report no frame duration / fps. I guess we need to build some detection to workaround the possible issues.codec might be responsible for sending the frame too late. maybe we could adjust that by having for example 40 ms (adjusted based on the source content) &quot;buffer&quot; for the arriving frames. Not sure if it works in practice, but at least it should be possible in theory.I'll test that.</blockquote>

[QUOTE="tourettes, post: 510690, member: 10858"] Hopefully that drifting is caused by the inaccuracy of the current query performance counter code (I'll provide the fixed GetCurrentTimestamp() method as soon as I have done my own testing...). Yep, testing on the different hardware might show some issues (hopefully not). But it is a good to test those before going into public test mode. There are few known oddities that could be need to taken care: 1) our TsReader is not able to report the fps rate of the played file (old EVR code is assuming every thing is 40.000 ms per frame if no rate is provided). This might break NTSC videos... Fixing f the TsReader is on the way, but I'm not sure if we can push that change into 1.1.0 (depends how busy djblu and gemx are :P) 2) Some other files might as well sometimes report no frame duration / fps. I guess we need to build some detection to workaround the possible issues. codec might be responsible for sending the frame too late. maybe we could adjust that by having for example 40 ms (adjusted based on the source content) "buffer" for the arriving frames. Not sure if it works in practice, but at least it should be possible in theory. I'll test that. [/QUOTE]

Verification