home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MP1 EVR Presenter/dshowhelper community development
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="tourettes" data-source="post: 609517" data-attributes="member: 10858"><p><span style="font-size: 15px">Preamble / definitions</span></p><p></p><p>Unfortunately this is quite hard topic to discuss with, especially when one small difference in a definition of a word can turn the whole scheme upside down. Also it doesn't make it any easier when you have non-real time communication with the other persons so that it would be much easier to correct other persons view / facts (and looks like this post wont be a short one as well <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" />)</p><p></p><p>Here are some definitions for few common words that need to be exactly defined when they are used in the video rendering context. Thanks in advance for reading!</p><p></p><ul> <li data-xf-list-type="ul"> <strong>presentation window</strong> - this is the time window that EVR presenter has time to start and end the frame drawing so that the frame will be displayed during next v-sync (after next VBLANK time is over). To make it easy for the algorithm discussion let's just assume that this is the first 1/4 of frame duration (time when raster offset is in the first 25% of the screen height)</li> <li data-xf-list-type="ul"> <strong>raster offset</strong> - this is the scan line that video HW is currently drawing</li> <li data-xf-list-type="ul"> <strong>v-sync position</strong> - same as raster offset</li> <li data-xf-list-type="ul"> <strong>1:1</strong> - When source material's fps and target device's refresh rate have an exact match (for example 50fps on 50Hz TV)</li> <li data-xf-list-type="ul"> <strong>1:2</strong> - When source material's fps and target device's refresh rate have an integer multiplied match of 2 (for example 25fps on 50Hz TV)</li> </ul><p></p><p>Next I'll try my best to try to explain the interesting parts of the ecosystem of video / audio rendering that are related to video rendering / accuracy and ReClock in general... I'm not sure how well I manage in it, but let's try anyway <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p><span style="font-size: 15px">To ride shotgun (current design)</span></p><p></p><p>Current design with the ReClock in graph is a bit odd ball, I guess this is the result that Ogg didn't want to write a custom video presenter for few reasons:</p><p></p><ul> <li data-xf-list-type="ul"> ReClock was designed at the time when mostly overlay was used as the video renderer. Overlay doesn't give possibility to build a custom presenter (not 100% sure).</li> <li data-xf-list-type="ul"> By using a custom renderer approach all video playback applications would have required to be modified to support the renderer (this is a big no-no for few obvious reasons: 1) you cannot change implementation of 3rd party applications 2) some applications that mix GUI and video, like for example MediaPortal does, </li> </ul><p></p><p>What I mean with the odd ball design? ReClock itself does it's job really nicely, but it is not the best way to do the frame scheduling synchronization. It's a bit like blind and mute person (EVR presenter) would be instructed by guy in the passenger seat (ReClock / reference clock) about the steering and speed. That wouldn't matter that much if there wouldn't be one random variable (let's call it X this time) that ReClock cannot know.</p><p></p><p><span style="font-size: 15px">X?</span></p><p></p><p>Usually X marks the spot and this is partly true in our case as well. So, what is the mysterious variable X? Hard to describe without a flip board or anything that you could draw on (too lazy to open paint since it would be just impossible to draw with...) </p><p></p><p>EVR presenter schedules the frame to be presented at time Y and this is got from the information that EVR mixer tells the frame presentation time to be and then EVR presenter queries the reference clock when such "imaginary" time is on the wall time (the PC clock in this case). </p><p></p><p>After the Y (targeted frame presentation time) is received, EVR presenter schedules a timer to wake up the rendering thread in such way that we will be "early enough" in the :<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite7" alt=":p" title="Stick Out Tongue :p" loading="lazy" data-shortname=":p" />aint() / frame presentation that we can draw the frame in correct v-sync period (presentation window). Since the timer is not 100% accurate we have the Mr. X appearing in our equation.</p><p></p><p>So, ReClock thinks that we will be presenting at time Y and it modifies the reference clock / audio playback rate (pushes speed pedal and/or brakes) where as in reality the presentation will happen on Y + X spot. </p><p></p><p><span style="font-size: 15px">Pitfalls of the current design</span></p><p></p><p><strong>not as glitch resistant as possible</strong></p><p></p><p>X is result of two things 1) Windows is not a real time OS, so the timers aren't always firing on the exact moment when they should 2) some extra work on CPU / HD could delay code execution after timer has fired. Since we have the Mr. X modifying our results (ReClock doesn't see the X, but EVR presenter will see it) it might rarely happen that we aren't presenting the frame on correct v-sync even when the EVR presenter could fix that.</p><p></p><p><strong>Slow to recover from seeking / channel changes</strong> </p><p></p><p>Since ReClock is working only based on the "feedback loop", it is taking a lot of time for it to recover from a seek or channel changes. Users can see this by multiple second that are juddering after seeking / changing channel (live tv has also one general issue, solving it would require a time machine... but lets talk about that in some other thread or universe since having a slight buffer will sort it out.)</p><p></p><p><strong>Not optimal audio quality because of constant resampling</strong> </p><p></p><p>First, it wont ever be possible to get bit perfect audio playback when you are targeting to a judder free video (unless GPU manufacturers start to provide GPUs that have one crystal to rule them all... meaning that there would be only one time source for the video and audio clocks).</p><p></p><p>But... it would be possible to reduce the need for audio resampling when the driver would see how close we are to the border of presentation window. Driver would instruct the passanger to speed up or slow down only when we are to close to the border.</p><p></p><p><span style="font-size: 15px">Optimal way for the future?</span></p><p></p><p><strong>If the driver would just able to tell where the car is going it would help the passanger to give better driving instructions for the driver himself!</strong></p><p></p><p>ar-jar (<a href="http://www.ostrogothia.com/video/" target="_blank">vertical sync</a>) has been experimenting with video renderer instructing the reference clock. This would be the ultimate solution for rendering. Now, if we only had a change to </p><p></p><p>1) do the fine tuning of the frame presentation in EVR presenter (making sure that presentation window is hit)</p><p>2) tell reference clock to speed up or slow down when presentation window limits are reached</p><p></p><p>This would require only small change from ReClock. It should implement a IReClock interface that has two methods:</p><p></p><p><strong>SetVSyncMode(enum mode)</strong> - toggling between current behavior of ReClock and advice mode, where ReClock would listen to the EVR presenter's (or any other presenter's) advices should the clock run faster / slower / or at 1.0 speed</p><p><strong>Advice(double)</strong> - this would tell ReClock to modify the reference clock to run at different speed (1.01x for example). </p><p></p><p>That way the Mr. X can be killed and video rendering is a bit more close to the perfect.</p><p></p><p><span style="font-size: 15px">To Owlsroost</span></p><p></p><p>I think you aren't currently running in the opposite direction that you should be if you are trying to fix the ReClock incompatibility issue we are seeing. Your current approach is to ignore the steering commands that the passanger tells and then the passager gets confused when it sees the results (with a delay) where the car is heading into.</p><p></p><p>The raster offset that you are working now is not compatible with ReClock's philosophy but it is most likely a good way to make the non-ReClock situations a bit more robust (as some users have already reported). </p><p></p><p>How to make ReClock work with the MP / EVR presenter? Best way would be to as James to allow us to tell ReClock some info (Optimal way for the future? part in the post). Next, almost perfect, way would be to ignore the raster offset position completely in the :<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite7" alt=":p" title="Stick Out Tongue :p" loading="lazy" data-shortname=":p" />aint() and make :<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite7" alt=":p" title="Stick Out Tongue :p" loading="lazy" data-shortname=":p" />aint() to only try to target to the exact spot in the wall time that was calculated earlier (busy loop until Y is reached). 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... <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" />) or is it the end position (or even something in between <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" />).</p><p></p><p>...hopefully this did make some sense <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p></blockquote><p></p>
[QUOTE="tourettes, post: 609517, member: 10858"] [SIZE="4"]Preamble / definitions[/SIZE] Unfortunately this is quite hard topic to discuss with, especially when one small difference in a definition of a word can turn the whole scheme upside down. Also it doesn't make it any easier when you have non-real time communication with the other persons so that it would be much easier to correct other persons view / facts (and looks like this post wont be a short one as well :)) Here are some definitions for few common words that need to be exactly defined when they are used in the video rendering context. Thanks in advance for reading! [list] [*] [b]presentation window[/b] - this is the time window that EVR presenter has time to start and end the frame drawing so that the frame will be displayed during next v-sync (after next VBLANK time is over). To make it easy for the algorithm discussion let's just assume that this is the first 1/4 of frame duration (time when raster offset is in the first 25% of the screen height) [*] [b]raster offset[/b] - this is the scan line that video HW is currently drawing [*] [b]v-sync position[/b] - same as raster offset [*] [b]1:1[/b] - When source material's fps and target device's refresh rate have an exact match (for example 50fps on 50Hz TV) [*] [b]1:2[/b] - When source material's fps and target device's refresh rate have an integer multiplied match of 2 (for example 25fps on 50Hz TV) [/list] Next I'll try my best to try to explain the interesting parts of the ecosystem of video / audio rendering that are related to video rendering / accuracy and ReClock in general... I'm not sure how well I manage in it, but let's try anyway :) [SIZE="4"]To ride shotgun (current design)[/SIZE] Current design with the ReClock in graph is a bit odd ball, I guess this is the result that Ogg didn't want to write a custom video presenter for few reasons: [list] [*] ReClock was designed at the time when mostly overlay was used as the video renderer. Overlay doesn't give possibility to build a custom presenter (not 100% sure). [*] By using a custom renderer approach all video playback applications would have required to be modified to support the renderer (this is a big no-no for few obvious reasons: 1) you cannot change implementation of 3rd party applications 2) some applications that mix GUI and video, like for example MediaPortal does, [/list] What I mean with the odd ball design? ReClock itself does it's job really nicely, but it is not the best way to do the frame scheduling synchronization. It's a bit like blind and mute person (EVR presenter) would be instructed by guy in the passenger seat (ReClock / reference clock) about the steering and speed. That wouldn't matter that much if there wouldn't be one random variable (let's call it X this time) that ReClock cannot know. [SIZE="4"]X?[/SIZE] Usually X marks the spot and this is partly true in our case as well. So, what is the mysterious variable X? Hard to describe without a flip board or anything that you could draw on (too lazy to open paint since it would be just impossible to draw with...) EVR presenter schedules the frame to be presented at time Y and this is got from the information that EVR mixer tells the frame presentation time to be and then EVR presenter queries the reference clock when such "imaginary" time is on the wall time (the PC clock in this case). After the Y (targeted frame presentation time) is received, EVR presenter schedules a timer to wake up the rendering thread in such way that we will be "early enough" in the ::Paint() / frame presentation that we can draw the frame in correct v-sync period (presentation window). Since the timer is not 100% accurate we have the Mr. X appearing in our equation. So, ReClock thinks that we will be presenting at time Y and it modifies the reference clock / audio playback rate (pushes speed pedal and/or brakes) where as in reality the presentation will happen on Y + X spot. [SIZE="4"]Pitfalls of the current design[/SIZE] [b]not as glitch resistant as possible[/b] X is result of two things 1) Windows is not a real time OS, so the timers aren't always firing on the exact moment when they should 2) some extra work on CPU / HD could delay code execution after timer has fired. Since we have the Mr. X modifying our results (ReClock doesn't see the X, but EVR presenter will see it) it might rarely happen that we aren't presenting the frame on correct v-sync even when the EVR presenter could fix that. [b]Slow to recover from seeking / channel changes[/b] Since ReClock is working only based on the "feedback loop", it is taking a lot of time for it to recover from a seek or channel changes. Users can see this by multiple second that are juddering after seeking / changing channel (live tv has also one general issue, solving it would require a time machine... but lets talk about that in some other thread or universe since having a slight buffer will sort it out.) [b]Not optimal audio quality because of constant resampling[/b] First, it wont ever be possible to get bit perfect audio playback when you are targeting to a judder free video (unless GPU manufacturers start to provide GPUs that have one crystal to rule them all... meaning that there would be only one time source for the video and audio clocks). But... it would be possible to reduce the need for audio resampling when the driver would see how close we are to the border of presentation window. Driver would instruct the passanger to speed up or slow down only when we are to close to the border. [SIZE="4"]Optimal way for the future?[/SIZE] [b]If the driver would just able to tell where the car is going it would help the passanger to give better driving instructions for the driver himself![/b] ar-jar ([url=http://www.ostrogothia.com/video/]vertical sync[/url]) has been experimenting with video renderer instructing the reference clock. This would be the ultimate solution for rendering. Now, if we only had a change to 1) do the fine tuning of the frame presentation in EVR presenter (making sure that presentation window is hit) 2) tell reference clock to speed up or slow down when presentation window limits are reached This would require only small change from ReClock. It should implement a IReClock interface that has two methods: [B]SetVSyncMode(enum mode)[/B] - toggling between current behavior of ReClock and advice mode, where ReClock would listen to the EVR presenter's (or any other presenter's) advices should the clock run faster / slower / or at 1.0 speed [B]Advice(double)[/B] - this would tell ReClock to modify the reference clock to run at different speed (1.01x for example). That way the Mr. X can be killed and video rendering is a bit more close to the perfect. [SIZE="4"]To Owlsroost[/SIZE] I think you aren't currently running in the opposite direction that you should be if you are trying to fix the ReClock incompatibility issue we are seeing. Your current approach is to ignore the steering commands that the passanger tells and then the passager gets confused when it sees the results (with a delay) where the car is heading into. The raster offset that you are working now is not compatible with ReClock's philosophy but it is most likely a good way to make the non-ReClock situations a bit more robust (as some users have already reported). How to make ReClock work with the MP / EVR presenter? Best way would be to as James to allow us to tell ReClock some info (Optimal way for the future? part in the post). Next, almost perfect, way would be to ignore the raster offset position completely in the ::Paint() and make ::Paint() to only try to target to the exact spot in the wall time that was calculated earlier (busy loop until Y is reached). 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... :)) or is it the end position (or even something in between :)). ...hopefully this did make some sense :) [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MP1 EVR Presenter/dshowhelper community development
Contact us
RSS
Top
Bottom
