It is not disabled in 50Hz mode (1:2). It is just EVR presenter from MP that overrides the raster position in the :
aint().
MP1 EVR Presenter/dshowhelper community development (4 Viewers)
- Thread starter Owlsroost
- Start date
It is not disabled in 50Hz mode (1:2). It is just EVR presenter from MP that overrides the raster position in the :
aint().
United Kingdom
- Thread starter
- #72
Thanks for all the explanations
I'm not trying to fix the 'ReClock vsync correction not working' problem (I don't use ReClock vsync correction myself because I've never managed to find a vsync 'sweet spot' that works for all material and codecs - e.g. if I find a good setting for 1:2 H.264 it messes up 1:1 HD MPEG-2 - and vv).
I set out to try and fix/alleviate some of the 'bursts of judder' problems I was seeing, and also make sure (as a side issue) that the code accomodated the 'render clock' changes that ReClock makes e.g. the +/-4% PAL speedup/speedown - without breaking any vsync correction the dshowhelper tries to do internally.
I've worked in the video/audio hardware design field for years, so I fully appreciate that video/audio synchronisation and vsync alignment in Windows is a much bigger mess than the MP dshowhelper can hope to fix
Tony
Hi tourettes,
before you told me you don't need the HPET because Mp have to manage to work with two video and audio clocks......... now you wrote the EVR is using Pc clock as reference clock.....
in addiction to that, you wrote: Windows is not a real time OS, so the timers aren't always firing on the exact moment when they should ........ reading Hpet definition seems that very very precise in firing at the exact moment...... as you can read there :
http://www.microsoft.com/whdc/system/sysinternals/mm-timer.mspx
"To get tolerable multimedia performance on a system with current timing hardware, developers have had to develop tricks and techniques, such as large playback buffers and busy waiting, which sacrifice performance and quality to hide the shortcomings of the timing hardware. Because of these tricks and techniques, multimedia applications on a general purpose system with the current timing hardware will never be able to achieve the high quality performance and high level of responsiveness that consumers demand from dedicated units."
So please would you take a look to this article and think about it ?
As i told you i'm not an expert, but when i read those kind of articles they seem talking about our sync problems.
bye
HPET will be used automatically by MP / EVR presenter if you are running Vista / Windows 7 and have HPET support in HW + enabled in bios.
Thanks for all the explanations
Thanks for reading (I didn't even proof read the content yet, so there might be even some big brain farts included...).
That issue would be solved the my "future proposal", where video renderer is able to guide the reference clock.
Those bursts might be coming form the wrong real fps detection code. One easy way to trigger such burst is to play DVD at 32x speed. At first it is smooth,but after maybe 5 seconds it goes havec (most likely the history data in the fps detection gets filled with the skipped frames etc which completely throws off the MPC-HC code that I borrowed. I guess it now just fires back that we haven't implemented custom EVR mixer that would allow the real fps to be gathered).
I've worked in the video/audio hardware design field for years, so I fully appreciate that video/audio synchronisation and vsync alignment in Windows is a much bigger mess than the MP dshowhelper can hope to fix
It is completely fixable if we either have a reference clock that we can adjust from renderer side or when GPU manufacturers provide HW that has single clock chip.
Now, with your merits I would even propose a team member status
After all you would be the only one in our team that really has been working with A/V industry... I would be interested into hear about some more info from your background.Note to users/testers:
ReClock is not compatible with the MP1.1.0 RC2 when it comes to 1:2 material playback. Also it is not perfect when 1:1 or other types are considered, both these are fixable if someone has time...
Owlsroost's DLL is even less compatible with the ReClock. So, when testing his DLL, it would be nice to test without ReClock, since otherwise there is just two algorithms that are going to fight with each other (in some cases it will work, in some it wont).
Absolutely correct, you're on the right way for the purpose and the solution even.
The reclock vsynch correction must become useless also in PAL speedup/speedown situation.
Absolutely correct, you're on the right way for the purpose and the solution even.
The reclock vsynch correction must become useless also in PAL speedup/speedown situation.
About the "future proposal", it might be already not required to have any modifications in ReClock (the external interface for advicing...). If ReClock is able to resample audio correctly, based on the frame rate that it monitors it should be already working after Owlsroost provides the rester offset correction (for 1:1 as well).
Yes, I agree terminology can be confusing!!Now, I don't know what ReClock expects, does it expect the paint to be started on the spot that it is monitoring (and how it is even monitoring the raster position when paint happens, since all that should be visible outside the EVR presenter is the v-sync when the frame is drawn... only James knows...
To try to answer your question on Reclock, the position of the Reclock vsync marker appears to correspond with the end of paint (plus presumably a scheduling delay). In MPC-HC EVR sync, for example, it is quite noticeable that the Reclock vsync marker is a few ms further down the frame than the green line on the OSD (start paint). It is also noticeable that as you reduce the work the OSD has to do (each press of <ctrl-J> gives a different OSD, some with minimal info) the difference between the EVR sync green line and the Reclock marker closes. Also, if you use a "normal renderer" which double-buffers the Reclock vsync marker is "pinned" just below the start of the frame. In my discussions with ar-jar we understand this to be because when double-buffering "end paint" does not return until after the flip. It is this that stops Reclock controlling what it terms "vsync", i.e. raster offset of "end paint" relative to vsync, with conventional EVR and VMR9. D3D mode introduces additional buffering that means Reclock sees end of paint as soon as the frame is ready to be flipped. Aero seems to do the same (assuming of course there is no "clever" vsync code in the renderer itself), making rendering, from the player perspective, asynchronous to actual vsync, as with Overlay, and allowing Reclock vsync correction to work.
As you have probably figured, Reclock does not have tight control over the point paint starts, it measures the average point it finished over recent frames and if that falls outside of its target it starts to play with the reference clock to pull things back in line. So Reclock does not really know about "Y" or target it specifically, it just makes sure that on average paint completes well away from any danger.
You are right, of course, this is not foolproof. But I am not sure that anything Reclock would trip up on would be fixable with the EVR Presenter. Reclock is not actively triggering the start of paint and finding execution happens too late for vsync. It merely makes sure the previous frame is close to its target, let's things happen as fast as they can, and hopes the next one will be ready in time. Maybe this sounds worse!! But I think, in reality, it means that any delay which leads to the next frame not being presented until too late would equally affect the EVR Presenter, but maybe I have missed something? Maybe there are rare occasions when this might be true.
In practice, if the Reclock vsync marker is set to complete paint around half way through a frame (making sure it is not started until after vsync, or judder occurs) this leaves quite a lot of time for any delayed execution. With XP I used to see spike downward in the green line in EVR sync of as much as 6 or 7ms (C2D 2.7Ghz). However, on W7 I can honestly say I have never seen the green line spike down (although not to say it does not happen). Either way, a Reclock vsync target around 40% of the screen height, with a green line @about 16.5ms @50Hz leaves plenty of headroom (~7ms on XP). It does seem some presenters are much more sensitive to timing than others. I found it took a bit of work to get the right position for TMT3. It seems to need frames presented in a pretty narrow window (maybe 25% of the screen) for smooth playback. Fortunately, this position is compatible with other players that are less sensitive.
I agree with these points. I am still trying to get James to improve the first. It cannot be eliminated completely but it could be better. Audio resampling has become much better though recently with improved code and faster PCs, allowing higher quality modes to be practical. I honestly think for the vast majority it is inaudible. For purists though it will never be bit perfect. Of course if you are using Reclock for 24p->25p, 25p->24p or even 29.97->30fps that is not possible anyway. It is also worth noting that unless the player is bitstreaming or supports WASAPI Windows Mixer messes with and resamples the audio anyway. Reclock does have the advantage it can bypass Windows Mixer completely and ensure only one, high quality resampling takes place .
This is a good idea. It may be worth trying to open a discussion with James. Even better if you could get ar-jar to join you. It would be better if it were a wider open community request, rather than just a MP one. Also, James is probably trying to crack just the same issue for the mythical(!) "Slyplayer". He may have already done something similar (then I don't know if he would want to open it up) or you may have thought of something he has not. Of course if you do this make sure that you do not turn off Reclock's correction until you are in the middle of your presentation window, or better at the opposite extreme if you can predict the direction of drift. Reclock currently still stops correction as soon as the edges of its target zone are hit. In practice this means correction is continual after a while as drift is normally in one direction. It keeps drifting just out of the target to get nudged only just back into it. It then falls out of it again pretty quickly.
Off-topic question for tourettes!
Have you considered trying to implement EVR onto an overlay surface as seems to be done my commercial Blu-ray players in disc mode. TMT3 also uses it for DVD playback. It does nothing for this judder problem (except Reclock vsync works fine with it), but it does mean that YCbCr is passed over HDMI unmolested - no conversion to/from RGB. Tests over at AVS Forum show the YCbCr values to be almost perfectly to spec (as measured at the other end of the HDMI cable). A significant improvement in colour quality over current solutions.
I guess you are talking about the new Windows 7 "overlay" more (not the same as in XP / Vista). Hardware Overlay Support (Windows)
Looks like it is having quite many restrictions and limitations even from driver support -> Exploring hardware overlay support in Windows 7 - virtualdub.org
As long as there is some juddering I consider it much bigger issue, much more annoying than slight color space issue. Especially when I don't have enough free money to buy proper tv and beamer