<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [AMD Fusion E-350] HDMI refresh rates doesn't match expectations" href="https://bugs.freedesktop.org/show_bug.cgi?id=76564#c57">Comment # 57</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [AMD Fusion E-350] HDMI refresh rates doesn't match expectations" href="https://bugs.freedesktop.org/show_bug.cgi?id=76564">bug 76564</a> from <a class="email" href="mailto:fernetmenta@online.de" title="Rainer Hochecker <fernetmenta@online.de>"> Rainer Hochecker</a> <pre>(In reply to <a href="show_bug.cgi?id=76564#c50">comment #50</a>) > If the 'sync to display' option is on in XBMC the video pixels clock is > master and I guess it then uses the vblank interrupt generated by the OSS > driver. These interrupts are generated using the same clock settings that > were used to set the PLL parameters. Why are there then ever skips reported, > because the renderer cannot be late as it is the master and just puts a > frame out for each vblank interrupt? or do I misunderstand something? > Are missed vblanks reported by the OSS driver to XBMC or does XBMC keep some > shadow adminstration to see if vblank interrupts arrive at the expected time? > Almost correct. At the application level we don't see interrupts. We just render the frames. We only can render one frame per vblank interval. Decoding should be fasted than rendering, hence the queue of ready frames fills and frames wait for being picked up. At this point (when the render thread comes by) we check the timestamp attached to the frame. If the time has already passed and there is more than a single frame in the queue, the next frame is skipped. Means the render thread is late by minimum frametime 41ms when running at 23.976. So even if we run at wrong speed, the render thread should not get that late.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>