MP1 EVR Presenter/dshowhelper community development (7 Viewers)

[emphatic]

Too bad that ReClock is closed source, so it will make really hard to know what it is exactly doing.

XBMC is open source, right? That player features an option similar to ReClock (sync to display with audio resample).

Emph

 

[te3hpurp]

Hi.

This so technical discussion, that i dont have much to say about it, but just of interest, i tried v4 dll and noticed
a interesing thing. If somebody knows channel named bloomberg, which is economy new channel and it has this
scrolling text at the bottom of the screen.

Before using this experimental dll the scrolling text has allways seemed to be, so that it's not deinterlaced properly. Every other parts of the image is good. Only Cyberlink codec has been able to produce this text nicely so far. Other channels that have similar scrolling text has been good with my M$ codec setup(win 7).

Well by this dll the scrolling text starts fine with my M$ codec, but after about 10 seconds it starts to look like it's allways been
with my codec setup.

I have PAL tv 50Hz, Nvidia 8400 GS, DVI->HDMI, Custom Resolution 1196 x 699


Br,

 

[red5goahead]

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.

Jong. Probably if reclock allow the player use it to query some kind of information such as video hw/refresh rate or what kind of adaptation is in use the player , in this case MP, could use that data . for example in cinema adaptation 24@->25@ or 25@->24@ Mp could disable the vsynch correction to let reclock do its job with its internal method.
The problem is the two modules in the filter graph don't know how the other works , I guess .

 

[tourettes]

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

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?

Yes, with some additional code it would be possible but:

1) 2x GPU memory bandwidth is required (not good)
2) I consider such only a workaround / ugly hack
3) It would require 100% working 1:2 material detection (writing EVR mixer most likely, since the EVR presenter cannot get the information - current MPC-HC loaned code is just making educated guess on the real fps).

 

[tourettes]

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.

Jong. Probably if reclock allow the player use it to query some kind of information such as video hw/refresh rate or what kind of adaptation is in use the player , in this case MP, could use that data . for example in cinema adaptation 24@->25@ or 25@->24@ Mp could disable the vsynch correction to let reclock do its job with its internal method.
The problem is the two modules in the filter graph don't know how the other works , I guess .

I'm quite sure that information is not must to have on the EVR presenter side. After all reference clock is the way for EVR presenter to obtain the time to present a frame.

 

[tourettes]

Too bad that ReClock is closed source, so it will make really hard to know what it is exactly doing.

XBMC is open source, right? That player features an option similar to ReClock (sync to display with audio resample).

Basicly it would mean that someone would have to write a directshow filter that does pretty much what ReClock does. I have been thinking starting such project, but it would eat more free time than I have at my hand. Good side would be that I would know exactly what it (at least tries) to do and the EVR presenter code would be much easier to write.

(not to be taken into part of this thread: I have been playing with two different ways to sync the video (both are loaned from the ar-jar's renderer / scheduling code.) 1) Directshows own audio renderer is also capable of resampling audio when you provide a custom reference clock - wouldn't work with bitstreaming / SPDIF 2) powerstrip modifying the video refresh rate - not good since wont work with Nvidia GPUs that I have now - last ones are 7xxx series.)

 

[Jong]

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.

Jong. Probably if reclock allow the player use it to query some kind of information such as video hw/refresh rate or what kind of adaptation is in use the player , in this case MP, could use that data . for example in cinema adaptation 24@->25@ or 25@->24@ Mp could disable the vsynch correction to let reclock do its job with its internal method.
The problem is the two modules in the filter graph don't know how the other works , I guess .

Possibly, but it seems there are already two options available:

- Use EVR Sync "present at nearest" which works even with Reclock. And because Reclock is adapting playback speeds (assuming they are not so far out that is not possible of course) there should be very little drift and maybe (depending on the method for targeting vsync) no dropped frames in a typical movie. This assumes that a full frame of drift would be needed to cause a dropped/repeated frame regardless of the initial raster offset, but that should be possible. One thing I am not sure of is how well this works when using non-exact multiple adaptation, e.g Reclock automatically recognises 24fps@60Hz, 23.976Hz@59.94Hz and allows 3:2 pulldown. It will even speed up 23.976fps to 24fps for display @60Hz. It will also automatically display 29.97 or 30fps material @50Hz (the former sped up to 30fps), which also has a regular if slightly unusual cadence (better than slowing down or speeding up, or running 29.97fps at its original speed, which leads to irregular cadence and more irritating judder). Reclock vsync control can still achieve and then hold its target with these, not sure if "present at nearest" will cope (just never tested).

- Allow an advanced option to turn off all vsync correction as per EVR Sync, which would allow people using Reclock to let Reclock do everything, including vsync (with Aero ON), as it seems was possible until recently.

 

[tourettes]

Re: AW: MP1 EVR Presenter/dshowhelper community development

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

Wont help. The issue we have is two different hardware clocks. GPU and audio hardware. Both running "freely".

 

[petrovice]

Allow an advanced option to turn off all vsync correction as per EVR Sync, which would allow people using Reclock to let Reclock do everything, including vsync (with Aero ON), as it seems was possible until recently.

+1

 

[tourettes]

Allow an advanced option to turn off all vsync correction as per EVR Sync, which would allow people using Reclock to let Reclock do everything, including vsync (with Aero ON), as it seems was possible until recently.

+1

For 1:1 material there is no v-sync / raster offset correction in the EVR presenter code. Only for the 1:2 material. So I decided to test the 1:2 material with ReClock and removing the raster offset correction. Not good, ReClock is not able to detect the refresh rate on my dev PC and it wont try the v-sync correction at all As a result the 1:2 playback is worser with ReClock than it is without it.