MP1 EVR Presenter/dshowhelper community development (24 Viewers)

[mironicus]

AW: MP1 EVR Presenter/dshowhelper community development

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.

It won't affect the CPU in any case, only the GPU is used. The effect doubles the framerate and it is "for free".

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.

NV12 gives you the best deinterlacing possible on ATI-cards (vector adaptive) and it works well with lowerend gpus like Radeon 3200. NV12 is also used by codecs like PowerDVD. The only problem is that there is no DXVA-enabled decoder yet that supports forcing deinterlacing, that would reduce the CPU usage additionally.

That workaround does help but it does not cure the main problem that Mediaportal have and therefore I will test the dll in this thread even though I can live good with this workaround. The workaround does also double the framerate of the gui while playing videos. The Mediaportal gui runs normally with 50 fps and only with 25 fps if you play a 25 fps-movie. Speeding up the gui while playing videos gives Mediaportal a tremendously better look and feeling - everything is smooth in all situations - I really like it.

 

[tourettes]

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!

Thanks for joining the discussion Just going to give a quick answer, not to all point you made.

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.

Actually raster offset is pretty close the point of presentation, just a bit different "name". Raster offset is nothing more than the current v-sync point / line. And presentation time can be either "free" (MP's current code doesn't try to target the presentation position of 1:1 material to anything special place) or targeted to some specific raster offset (like MP does for 1:2 to reduce the risk of presenting frame on a wrong v-sync).

Too bad that ReClock is closed source, so it will make really hard to know what it is exactly doing. For example if we would know that ReClock is not going to re-adjust the reference clock rate when the presentation happens on lets say 1/4 th of the screen area it would make things much more easy. If both MP and ReClock tries to adjust video presentation spot and audio / reference clock those both are feeding back into each others

Also one issue that ReClock creates is that the direct show samples aren't going to reflect the real duration (so code needs to have some ugly tolerance for the real and told fps).

In short, we would need to have really detailed description of the ReClock's algorithm to be able to write a EVR presenter code that works nicely with it. Unfortunately I'm sure that Slysoft wont give even than much out and we are just left in cold to guess what happens.

 

[tourettes]

Re: AW: MP1 EVR Presenter/dshowhelper community development

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.

It won't affect the CPU in any case, only the GPU is used. The effect doubles the framerate and it is "for free".

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.

NV12 gives you the best deinterlacing possible on ATI-cards (vector adaptive) and it works well with lowerend gpus like Radeon 3200. NV12 is also used by codecs like PowerDVD. The only problem is that there is no DXVA-enabled decoder yet that supports forcing deinterlacing, that would reduce the CPU usage additionally.

That workaround does help but it does not cure the main problem that Mediaportal have and therefore I will test the dll in this thread even though I can live good with this workaround. The workaround does also double the framerate of the gui while playing videos. The Mediaportal gui runs normally with 50 fps and only with 25 fps if you play a 25 fps-movie. Speeding up the gui while playing videos gives Mediaportal a tremendously better look and feeling - everything is smooth in all situations - I really like it.

Not all 1:2 material is possible to be de-interlaced into 50/60hz content. Just think about those progressive DVDs

 

[robyf]

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.

I suspect this vsync code has been added some time just before RC1, because I used reclock with vsyne enabled to fix the stuttering, but as I said, I was not able to use it anymore from some SVN before RC1, because it leads to stuttering after some minute.

I will try to use relock with vsync correction enabled and let you know.

 

[WebKnight]

Regarding vsync, what about the settings in the GPU control panel, having Nvidia myself. Does this have any effect on the result, should it be enabled/disabled or set to auto..?

 

[tourettes]

Jong, do you know the logic that ReClock uses when the "correct v-sync" option is enabled? I personally don't use ReClock since #1 I have been blessed with two PCs that have such small drift between audio and GPU clocks that they cause only one or two out of time presented frames for a full length movie #2 ReClock goes havoc if it is used with live tv when changing channels.

My assumption would be that ReClock is trying to use the reference clock (by resampling the audio) to "drive" the v-sync to the sweet position. I see no benefit from it when the renderer itself is able to do the same (present video frame on the correct v-sync, before the time when directx is going to flip the backbuffer. DirectX itself will handle the). I think the v-sync correction in ReClock is something from the past, where it was required to be used to prevent the tearing (that is not an issue anymore).

To get perfect video playback following would already work:

1) video renderer makes sure that every single frame is presented on correct v-sync
2) audio renderer generates the reference clock based on the video v-sync

I see no benefit when the audio renderer tries to adjust the v-sync position. All that it should do is to make sure that reference clock runs on the same speed as the GPUs clock is running (by monitoring the v-sync, would be enough that the v-blank period is monitored, as the fine tuning of video frame presentation is done by the video renderer).

 

[tourettes]

Regarding vsync, what about the settings in the GPU control panel, having Nvidia myself. Does this have any effect on the result, should it be enabled/disabled or set to auto..?

MP enables it always on application level, so unless drivers are broken there is no real difference if it is enabled or not.

 

[mironicus]

AW: MP1 EVR Presenter/dshowhelper community development

Not all 1:2 material is possible to be de-interlaced into 50/60hz content. Just think about those progressive DVDs

Yes, but the frame rate is doubled in every case (24->48 fps) and speeding up the frame rate alone seems to be a good way to reduce the stutter problem.

Would it be difficult to let Mediaportal itself double the framerate based on the video fps and refreshrate? So if you are running 50 Hz and play a 25 fps-movie, Mediaportal could display every frame twice?

 

[Jong]

Actually raster offset is pretty close the point of presentation, just a bit different "name". Raster offset is nothing more than the current v-sync point / line. And presentation time can be either "free" (MP's current code doesn't try to target the presentation position of 1:1 material to anything special place) or targeted to some specific raster offset (like MP does for 1:2 to reduce the risk of presenting frame on a wrong v-sync)

.........

.... we would need to have really detailed description of the ReClock's algorithm to be able to write a EVR presenter code that works nicely with it. Unfortunately I'm sure that Slysoft wont give even than much out and we are just left in cold to guess what happens.

So, correct me if I am wrong, when it is "free" the two are almost the same, but otherwise (in your normal code and more so with the owlsroost mod?) there is an offset applied which depends on how the "raster offset" compares with the targeted location?

My point was that this offset will change over time, very slowly if the rates are "compatible" (depending on the GPU/reference clock drift), much faster eg. if playing 23.976fps @24.000hz or 60Hz. But in either case they will drift. Only Reclock in "vsync correction" mode can use its feedback loop to fix this in all cases (although EVR Sync renderer can fix it using a similar method when the rates are "compatible"). Also, if it is left "free", this free position will drift.

On your last point, EVR Sync renderer in "Present at nearest" mode is compatible with Reclock, when vsync is not enabled, without any special "hooks". Is there a reason why this cannot just be "lifted"?

Jong, do you know the logic that ReClock uses when the "correct v-sync" option is enabled? I personally don't use ReClock since #1 I have been blessed with two PCs that have such small drift between audio and GPU clocks that they cause only one or two out of time presented frames for a full length movie #2 ReClock goes havoc if it is used with live tv when changing channels.

My assumption would be that ReClock is trying to use the reference clock (by resampling the audio) to "drive" the v-sync to the sweet position. I see no benefit from it when the renderer itself is able to do the same (present video frame on the correct v-sync, before the time when directx is going to flip the backbuffer. DirectX itself will handle the). I think the v-sync correction in ReClock is something from the past, where it was required to be used to prevent the tearing (that is not an issue anymore).

To get perfect video playback following would already work:

1) video renderer makes sure that every single frame is presented on correct v-sync
2) audio renderer generates the reference clock based on the video v-sync

I see no benefit when the audio renderer tries to adjust the v-sync position. All that it should do is to make sure that reference clock runs on the same speed as the GPUs clock is running (by monitoring the v-sync, would be enough that the v-blank period is monitored, as the fine tuning of video frame presentation is done by the video renderer).

Yes, Reclock makes very small adjustments to the reference clock to pull the "raster offset" to a targeted position, user selectable. The size of the adjustment depends on how far away from the target it is. It slows down as it gets close to avoid overshoot. EVR Sync's "Sync video to display" does similar, but does not slow down it's offset as it approaches the target.

You are wrong about the goal of Reclocks' vsync correction. It was always about eliminating synchronised frame rate/refresh rate judder. Ogo realised that when he had a really accurate reference clock there would be times when the point of presentation would be so close to the vsync that sometimes it would fall one side of the line and sometimes the other, causing judder, (Video Frame Display Synchronization - Intel® Software Network, figure 5) and that with an accurate clock this state could go on and on and on. Indeed, on my system, with Reclock on and vsync correction off, synchronised judder after a seek can go on for >45mins!!

I personally do not find Reclock vsync correction outdated firstly because its feedback loop does eliminate any chance of drift, second because it works with commercial Blu-ray players (and, as it happens, TMT in DVD disc mode), which we still need to play Blu-ray discs, rather than .m2ts or mkv rips, third it works when changing playback speed (24p@25p or 25p@24p). But I get your point, if 1) and 2) above are in place, as they kind of are when using Reclock (which improves the reference clock) and "present at nearest" (similar to owlsroost mod?), things should be close to perfect. It still will not be quite as robust though as:

- without the "feedback loop" there can still be drift.
- I am not sure it is possible to use the GPU clock "raw" as the reference clock as I am not sure it will be accurate enough for audio especially, although I accept the GPU clock is probably a lot better now than when Ogo first conceived Reclock.
- in any case, this solution only works when rates are "compatible". it does not work for 24p@25p or even 24p(23.976fps) @24Hz or 60Hz.

Also or course, there is no alternate reference clock without Reclock, although one could of course be written.

 

[mrmojo666]

Re: AW: MP1 EVR Presenter/dshowhelper community development

Not all 1:2 material is possible to be de-interlaced into 50/60hz content. Just think about those progressive DVDs

Quote 100% and in general is not good deinterlace progressive sources......

almost all the xvid and divx rips at 25 fps are yet progressive ( i never find one interlaced) , i think duplicating frames is a workaround just used because the 25hz is not generally supported by HDMI televisions but just 24p 50i 50p 60i and 60p
as like 24p sources must be at 24hz, 25p should be played at 25 hz, 50i and 50p 50 hz etc etc
I think the best way is display one fps every 2 hz at 50 hz

IMHO

I'm not an expert, but does anyone know about the HPET system clock ? Could be use in this bugfixing ?

High Precision Event Timer - Wikipedia, the free encyclopedia


bye

thank you all , i really appreciate