MP1 EVR Presenter/dshowhelper community development (4 Viewers)

[mrmojo666]

[
Good news is that there is a API in Windows 7 that you can use to track down the v-sync number (not suitable for MP1, but only for debugging purposes since we need to remain XP compatible).

Direct3D 9Ex Improvements (Windows) / D3DPRESENTSTATS Structure (Windows)

I just wondering......
In not possible implementing two different code: one for Xp and one for win7 ?

Maybe during installation the installer automatically install the right files following the kind of SO ?

That could help the TeamMP in respecting promises to XP users and don;t loose any new user coming with win7..... i have many friends who want to try MP but they are all with new pcs with win7 aboard

 

[Owlsroost]

Maybe it is other things causing the judder in this case, as you have hinted?

I'm beginning to think so - I suspect that the presenter code is dropping samples sometimes, somehow - this would (I think) produce the symptoms I'm seeing with the 'average time between samples' number changing but the reported sample durations being correct.

Sample durations from where? The real duration or the one reported by DS / EVR mixer? Such horrible judder would be (in my opinion) result from a wrong v-sync that is used to be presented (that throws of the stat lines exactly in the fashion you have seen... zig-zag pattern ).

Reported from inside the CorrectSampleTime() function i.e. comparing the values of 'SetDuration' (which is always correct) and 'm_DetectedFrameTime' - or 'Average' - (which is 3/2 times the correct duration when the problem occurs). These are the 'm_SDur' and 'm_DetFrT' values in my version of the render stats. This function is called by the input side of the presenter code.

Tony

 

[tourettes]

[
Good news is that there is a API in Windows 7 that you can use to track down the v-sync number (not suitable for MP1, but only for debugging purposes since we need to remain XP compatible).

Direct3D 9Ex Improvements (Windows) / D3DPRESENTSTATS Structure (Windows)

I just wondering......
In not possible implementing two different code: one for Xp and one for win7 ?

Maybe during installation the installer automatically install the right files following the kind of SO ?

That could help the TeamMP in respecting promises to XP users and don;t loose any new user coming with win7..... i have many friends who want to try MP but they are all with new pcs with win7 aboard

Yes, it would be possible, but causes too much work -> with current man power it wont happen.

 

[tourettes]

I'm beginning to think so - I suspect that the presenter code is dropping samples sometimes, somehow - this would (I think) produce the symptoms I'm seeing with the 'average time between samples' number changing but the reported sample durations being correct.

Sample durations from where? The real duration or the one reported by DS / EVR mixer? Such horrible judder would be (in my opinion) result from a wrong v-sync that is used to be presented (that throws of the stat lines exactly in the fashion you have seen... zig-zag pattern ).

Reported from inside the CorrectSampleTime() function i.e. comparing the values of 'SetDuration' (which is always correct) and 'm_DetectedFrameTime' - or 'Average' - (which is 3/2 times the correct duration when the problem occurs). These are the 'm_SDur' and 'm_DetFrT' values in my version of the render stats. This function is called by the input side of the presenter code.

So the data (samples) from EVR mixer are coming in wrong speed? Sounds like it could be deinterlace switching between on and off (at least ATI GPUs are pretty keen to do that when they are running out of processing power. Nvidia most likely does the same).

 

[Owlsroost]

I'm going to put some counters into the code so I can check if 'samples in = samples popped' when the problem happens - that should prove if the MP code is mis-behaving or if the incoming sample data is incorrect/jittery.

BTW, this is happening with SD MPEG-2 (live SD TV, no ReClock) on a system with more than enough CPU/GPU power to cope with it.

Tony

 

[tourettes]

BTW, this is happening with SD MPEG-2 (live SD TV, no ReClock) on a system with more than enough CPU/GPU power to cope with it.

Does it happen for example with ffdshow in software mode with bob deinterlace (and forcing the double "speed"?)).

 

[Owlsroost]

BTW, this is happening with SD MPEG-2 (live SD TV, no ReClock) on a system with more than enough CPU/GPU power to cope with it.

Does it happen for example with ffdshow in software mode with bob deinterlace (and forcing the double "speed"?)).

No idea - and I'm not about to waste time trying it (it's hardware deinterlacing or HTPC in the trash, as far as I'm concerned )

Tony

 

[tourettes]

BTW, this is happening with SD MPEG-2 (live SD TV, no ReClock) on a system with more than enough CPU/GPU power to cope with it.

Does it happen for example with ffdshow in software mode with bob deinterlace (and forcing the double "speed"?)).

No idea - and I'm not about to waste time trying it (it's hardware deinterlacing or HTPC in the trash, as far as I'm concerned )

with ffdshow test it could be only GPU into the trash Also it would be worth to try if it is TsReader issue by using haali splitter (rename ts to mkv).

 

[mrmojo666]

I'm not about to waste time trying it (it's hardware deinterlacing or HTPC in the trash, as far as I'm concerned )

Tony

I totally agreee with you Tony.... finally i bit of fresh air


we are in the 2010...the time is good to trash xp, ffdshow, all other paleolitic stuffs

 

[tourettes]

Anyway . Do you talk about the target windows or the vSynch dots painted during playback?
If you choose a value 88 for vysnc target position (the slide on the right or the HCU\software\reclock\VsyncTarget value) the target window will be at the bottom of the screen (in my case and my system the correct position is 22).

Actually I was talking about the fact that Reclock is unable to draw those stats on my system for some reason.