MP1 EVR Presenter/dshowhelper community development (1 Viewer)

[Owlsroost]

Owlsroost, in the next patch version, could you enable the tearing test bar? Just because it will make detecting the judder much easier (tearing is not an issue in any case if EARO is enabled since v-sync / present() is handled by it).

See first post

I've had a few ideas about handling the vsync correction differently (and the display timing estimation), so there will be a pause in new version development while I try a few things.....

Tony

 

[red5goahead]

Owlsroost, in the next patch version, could you enable the tearing test bar? Just because it will make detecting the judder much easier (tearing is not an issue in any case if EARO is enabled since v-sync / present() is handled by it).

See first post

I've had a few ideas about handling the vsync correction differently (and the display timing estimation), so there will be a pause in new version development while I try a few things.....

Tony

yet another ideas.. If it was possible to record in a XML file the whole set of values visibile in the graphs from different system do you think could be usefull to check and understand the renderer behavior?

 

[robyf]

I've tried dll number 02. For me everything plays fine except for xvid 25fps played at 50hz. After 20/25 minutes I get heavy stuttering. Here's my screenshot.

I have to say this DLL is slightly better than the one of RC2 for me, since I really got 0 frame dropped (for instance 0 frame dropped in HDTV in two hours of vision).

I will try DLL number 3 tomorrow.

Does it make sense to enable vsync correction in reclock with this DLL? I used to use it to correct this kind of stuttering before RC1.

 

[Owlsroost]

I've tried dll number 02. For me everything plays fine except for xvid 25fps played at 50hz. After 20/25 minutes I get heavy stuttering. Here's my screenshot.

I have to say this DLL is slightly better than the one of RC2 for me, since I really got 0 frame dropped (for instance 0 frame dropped in HDTV in two hours of vision).

I will try DLL number 3 tomorrow.

Does it make sense to enable vsync correction in reclock with this DLL? I used to use it to correct this kind of stuttering before RC1.

Well, you can try it but it shouldn't be necessary. I'd also try dll v004 (see first post in thread).

Tony

 

[red5goahead]

Please note:

1) Reclock vSynch doesn't work . It's ok. Will be unnecessary (its vsynch correction not Reclock itself )

2) when stuttering appear Sdev value raise over value 12-13 or more. When the play is smooth normally is under 0.4-0.5. Most of times pause and play is enough to solve the stuttering.

3) when stuttering appear FrRat switch quickly from value 2 to value 1 a so on. (yes, value FrRat with 004 now is correct to value 2)

 

[cecet23]

Re: AW: MP1 EVR Presenter/dshowhelper community development

The render stats look OK - the evr.log has one dropped frame during playback (ignoring the drops at the start). If it's happening every 7/8 minutes (but not with DXVA codec) then I suspect there's something else stealing CPU time periodically.

Tony

I have my doubt....that happen only with xvid (25 fps) at 50hz...

 

[mrmojo666]

HI, Tony

i've tested the n#4 dll.

that is very similar to the n#1 in smoothness, but still remains some few stutters


please notice that the OSD is working almost ok with hdtv an sd PAL TV (50i) @50hz, but slowing all others kind of videos . When the OSD is going slower it starts with wrong FPS values, it starts from 0 fps and they raise slow to the correct fps , as you can see in my screenshots below, in the hdtv and sd tv sometimes i can notice spikes.
Obviously the results are suffering with OSB opened.

thank you for your work

 

[Owlsroost]

Quick update - I've managed to provoke a 'burst of stuttering with no frame drops' problem with live TV on my system.

I looks like (from the render stats numbers) that something - maybe in the incoming stream timing data - is triggering a bug in the dshowhelper code i.e. it's not a vsync alignment problem in this case.

(For those familar with the code, 'm_DetectedFrameTime' is way off the correct value when this happens, which - I think - is causing incorrect sample duration correction)

Tony

 

[tourettes]

(For those familar with the code, 'm_DetectedFrameTime' is way off the correct value when this happens, which - I think - is causing incorrect sample duration correction)

That is a hack to allow 1:2 material to be detected (no other good way to solve it). The code itself is from MPC-HC and I feared it might have some side effect in some specific cases (detection is thrown off). Unfortunately EVR presenter doesn't see the real frame rate and to fix that we would need to implement a custom EVR mixer component...

 

[Owlsroost]

(For those familar with the code, 'm_DetectedFrameTime' is way off the correct value when this happens, which - I think - is causing incorrect sample duration correction)

That is a hack to allow 1:2 material to be detected (no other good way to solve it). The code itself is from MPC-HC and I feared it might have some side effect in some specific cases (detection is thrown off). Unfortunately EVR presenter doesn't see the real frame rate and to fix that we would need to implement a custom EVR mixer component...

OK, thanks - could you quickly explain what the purpose of the CorrectSampleTime() function is i.e. why do the sample durations need correction ?

Tony