MP1 EVR Presenter/dshowhelper community development (1 Viewer)
- Thread starter Owlsroost
- Start date
Italy
for digging deep in this EVR debugging EVR mixer provides sample durations that doesn't match the real ones. If I remember correctly it was the 40 ms duration that should have been reported for the 25fps material is reported incorrectly in many cases.
If I remember correctly EVR.log should contain the EVR mixer / ds graph's frame rate information logged (in the start up phase). Play different files and see when that gets a different value than the real fps is. Wouldn't be a bad idea to add stat screen to display both of those real (estimated) and the one reported with the DS / EVR mixer. I'm not sure if the analyzed / estimated refresh rate is shown and I'm quite sure that the EVR mixer / DS rate is not shown.
Do you use DXVA for TV? Because I'm only able to reproduce the problem without DXVA (es. xvid 25fps 50hz). With DXVA enabled all works fine.
Maybe it has something to do with DXVA.
For instance an mkv 25fps at 50hz works without stutter since I'm using MPC-HC with DXVA enabled to reproduce it.
Those bursts don't most likely have anything to do with the DXVA. Only think that causes those is the 1:2 fps to Hz ratio.
AW: MP1 EVR Presenter/dshowhelper community development
v2 works really good for me. I have some anime videos that change the frame rate between 29,97 and 23,97 fps sometimes (displayed on the monitor with 60 Hz). This videos now don't stutter anymore. The stutter mainly existed in the parts with 29,97 fps.
On 25fps movies displayed on 50 Hz the stutter is greatly reduced, even if you skip wildly through the video. The standard directshowhelper.dll produced stutter mainly after one or two skips within the video, sometimes also after resuming a video. The stutter usually goes away if you do an additional skip.
However, stutter is no issue if the video framerate matches the refresh rate of the monitor. You can do this if you force bob deinterlacing on all output using FFDSHow as decoder with NV12-output. That works very well with 25fps material.
With v3 and v4 the gui seems to be slowed down. You really see a difference if you display 24fps movies on 60 Hz, pressing Y and let the displayed window go up and down with the cursor keys (B3Wide).
v2 works really good for me. I have some anime videos that change the frame rate between 29,97 and 23,97 fps sometimes (displayed on the monitor with 60 Hz). This videos now don't stutter anymore. The stutter mainly existed in the parts with 29,97 fps.
On 25fps movies displayed on 50 Hz the stutter is greatly reduced, even if you skip wildly through the video. The standard directshowhelper.dll produced stutter mainly after one or two skips within the video, sometimes also after resuming a video. The stutter usually goes away if you do an additional skip.
However, stutter is no issue if the video framerate matches the refresh rate of the monitor. You can do this if you force bob deinterlacing on all output using FFDSHow as decoder with NV12-output. That works very well with 25fps material.
With v3 and v4 the gui seems to be slowed down. You really see a difference if you display 24fps movies on 60 Hz, pressing Y and let the displayed window go up and down with the cursor keys (B3Wide).
Re: AW: MP1 EVR Presenter/dshowhelper community development
Sorry mironicus,
but this looks like deprecable workaround to solve 1:2 video problems, i don't think is correct to deinterlace a progressive source and change the color space to a unusual kind , these two operations add more unnecessary load to CPU and may introduce more artifacts and erroneous colors.
IMHO
Sorry mironicus,
but this looks like deprecable workaround to solve 1:2 video problems, i don't think is correct to deinterlace a progressive source and change the color space to a unusual kind , these two operations add more unnecessary load to CPU and may introduce more artifacts and erroneous colors.
IMHO
- Thread starter
- #37
I'm seeing the issue using DXVA (PDVD10 codec) at 50fps (hardware de-interlaced live TV) on a 50fps TV - i.e. a 1:1 fps ratio.
There may well be other problems that can produce bursts of stuttering - all we can do is try and fix them one-by-one....
Tony
Re: AW: MP1 EVR Presenter/dshowhelper community development
I do not think is necessary to change the color space. I use RGB for instance and forcing deinterlacing works as a workaround for me.
Roby
OK but I don't have them with H.264 DXVA 25fps videos played at 50hz, only with xvid... mah...
I do not think is necessary to change the color space. I use RGB for instance and forcing deinterlacing works as a workaround for me.
Roby
OK but I don't have them with H.264 DXVA 25fps videos played at 50hz, only with xvid... mah...
- Thread starter
- #39
Re: AW: MP1 EVR Presenter/dshowhelper community development
v002 only enables the vsync correction for 2:1 or 1:1 (display:video) FPS ratios - which feels to me to be the right thing to do, but (as Tourettes implies) it's hard to get a good estimate of the actual FPS of the video - to make the vsync correction on/off decision....
Tony
v002 only enables the vsync correction for 2:1 or 1:1 (display:video) FPS ratios - which feels to me to be the right thing to do, but (as Tourettes implies) it's hard to get a good estimate of the actual FPS of the video - to make the vsync correction on/off decision....
Tony
Hi all! Especially owlsroost and tourettes, a few comments from a diehard member of the Reclock community for your consideration! Do with them what you will!
As discussed with owlsroost over @Slysoft forums Reclock changes the playback speed, e.g. 24p -> 25p by replacing the player's clock with one that runs too fast. It basically fools the player into thinking time is running faster than it is, so playback is faster. It also attempts to improve the synchronisation of the system, GPU and audio clocks, replacing the reference clock with its new improved version, which, even if on the face of it there is no need to adapt the playback speed eg. 24p @23.976Hz reduces any disagreement on what 23.976 really is between GPU and the player (normally the audio clock) that can and does lead to drift and ultimately to judder, when presentation passes through vsync. It is this drift that causes, as well as playback starting with judder, judder that starts after some time of playback, 1s - 90 mins, depending on the starting point of presentation and clock accuracy.
Reclock, without vsync correction enabled, goes a considerable way to eliminating this drift, but even with Reclock playback might start only just outside of the danger zone and then drift into it quite quickly during a movie.
AFAIK the only sure fire way of eliminating judder for sure, for ever (after the first few secs when it can never be guaranteed) is using Reclock WITH Reclock vsync correction. This is because, with vsync correction enabled, Reclock sets up a feedback loop that is constantly monitoring I think what you call the "raster offset" and by making additional minor adjustments to the reference clock, in addition to any needed to adapt the playback speed (as mentioned above), it keeps the raster offset , not just the point of presentation, in a fixed range. When it does this, even if the GPU and reference clocks do not quite agree on what 23.976 (for example) is, Reclock will spot this when the "Raster offset" drifts outside of its target zone and it will then make tiny adjustments to the playback speed to correct it. As I say, AFAIK, only this will guarantee you never have to drop a frame because of clock drift.
ar-jar's "sync video to display" kind of does the same, but because it cannot re-sample audio it can only be used if the frame rate and refresh rates are very close to being compatible, or audio will fall out of sync with video. It cannot even cope with a 23.976 -> 24.000 speedup.
I think what you are doing is similar to ar-jar's "Present at nearest" option, which will minimise judder by moving the point of presentation but cannot avoid it completely when speed difference, or just reference/GPU clock drift, leads to frames and vsync "lapping each other".
So, assuming you do not want to completely duplicate Reclock's intricate code for clock synchronisation and audio resampling (which I can understand) I think it is worth offering the advanced option to turn off all vsync code, as the MPC-HC EVR CP and EVR Sync renderers offer so people using Reclock e.g. to speed 24p ->25p can also use it to really fix vsync. This will only work with Aero ON, as I don't think you offer a D3D option for EVR, but for most now that should be fine.
Offering this will also help people who use a commercial Blu-ray player and need to use Reclock vsync correction to avoid this problem in those players. otherwise they need to turn off vsync correction when MediaPortal's player is used and turn it on again eg. for TMT or PDVD. This is possible by changing the registry prior to loading the player software, but that is a clumsy hack at best!
You could also offer an equivalent of "sync video to display" to properly fix vsync when rates are very close, but that is completely incompatible with Reclock and I realise that makes configuration rather unfriendly and support trickier.
Any way, as I said, just a few thoughts, for what they are worth. it is good to see another player fixing this issue. It still amazes me that the big commercial players still do nothing to address it. I assume they think their more mass market are mostly ignorant and either using mismatched rates anyway (so judder is unavoidable) or they just won't notice!
Jon
As discussed with owlsroost over @Slysoft forums Reclock changes the playback speed, e.g. 24p -> 25p by replacing the player's clock with one that runs too fast. It basically fools the player into thinking time is running faster than it is, so playback is faster. It also attempts to improve the synchronisation of the system, GPU and audio clocks, replacing the reference clock with its new improved version, which, even if on the face of it there is no need to adapt the playback speed eg. 24p @23.976Hz reduces any disagreement on what 23.976 really is between GPU and the player (normally the audio clock) that can and does lead to drift and ultimately to judder, when presentation passes through vsync. It is this drift that causes, as well as playback starting with judder, judder that starts after some time of playback, 1s - 90 mins, depending on the starting point of presentation and clock accuracy.
Reclock, without vsync correction enabled, goes a considerable way to eliminating this drift, but even with Reclock playback might start only just outside of the danger zone and then drift into it quite quickly during a movie.
AFAIK the only sure fire way of eliminating judder for sure, for ever (after the first few secs when it can never be guaranteed) is using Reclock WITH Reclock vsync correction. This is because, with vsync correction enabled, Reclock sets up a feedback loop that is constantly monitoring I think what you call the "raster offset" and by making additional minor adjustments to the reference clock, in addition to any needed to adapt the playback speed (as mentioned above), it keeps the raster offset , not just the point of presentation, in a fixed range. When it does this, even if the GPU and reference clocks do not quite agree on what 23.976 (for example) is, Reclock will spot this when the "Raster offset" drifts outside of its target zone and it will then make tiny adjustments to the playback speed to correct it. As I say, AFAIK, only this will guarantee you never have to drop a frame because of clock drift.
ar-jar's "sync video to display" kind of does the same, but because it cannot re-sample audio it can only be used if the frame rate and refresh rates are very close to being compatible, or audio will fall out of sync with video. It cannot even cope with a 23.976 -> 24.000 speedup.
I think what you are doing is similar to ar-jar's "Present at nearest" option, which will minimise judder by moving the point of presentation but cannot avoid it completely when speed difference, or just reference/GPU clock drift, leads to frames and vsync "lapping each other".
So, assuming you do not want to completely duplicate Reclock's intricate code for clock synchronisation and audio resampling (which I can understand) I think it is worth offering the advanced option to turn off all vsync code, as the MPC-HC EVR CP and EVR Sync renderers offer so people using Reclock e.g. to speed 24p ->25p can also use it to really fix vsync. This will only work with Aero ON, as I don't think you offer a D3D option for EVR, but for most now that should be fine.
Offering this will also help people who use a commercial Blu-ray player and need to use Reclock vsync correction to avoid this problem in those players. otherwise they need to turn off vsync correction when MediaPortal's player is used and turn it on again eg. for TMT or PDVD. This is possible by changing the registry prior to loading the player software, but that is a clumsy hack at best!
You could also offer an equivalent of "sync video to display" to properly fix vsync when rates are very close, but that is completely incompatible with Reclock and I realise that makes configuration rather unfriendly and support trickier.
Any way, as I said, just a few thoughts, for what they are worth. it is good to see another player fixing this issue. It still amazes me that the big commercial players still do nothing to address it. I assume they think their more mass market are mostly ignorant and either using mismatched rates anyway (so judder is unavoidable) or they just won't notice!
Jon