I'm not sure why we need to take renderer delay into account at all. The
render queue is by design implemented so it incures zero delay. Ie if you
request to present a frame now, it will be presented close to now by
dropping any frames ahead in the queue.


On Sat, May 17, 2014 at 6:08 PM, Rainer Hochecker
<notifications@github.com>wrote:

> In xbmc/cores/dvdplayer/DVDPlayerVideo.cpp:
>
> > +  // get render stats
> > +  g_renderManager.GetStats(iSleepTime, iRenderPts, iBufferLevel);
> > +
> > +  if (iBufferLevel < 0)
> > +    result |= EOS_BUFFER_LEVEL;
> > +  else if (iBufferLevel < 2)
> > +  {
> > +    result |= EOS_BUFFER_LEVEL;
> > +    CLog::Log(LOGDEBUG,"CDVDPlayerVideo::CalcDropRequirement - hurry: %d", iBufferLevel);
> > +  }
> > +
> > +  bNewFrame = iDecoderPts != m_droppingStats.m_lastDecoderPts;
> > +
> > +  iInterval = 1/m_fFrameRate*(double)DVD_TIME_BASE;
> > +
> > +  m_FlipTimeStamp = m_pClock->GetAbsoluteClock() + max(0.0, iSleepTime) + iInterval;
>
> I should have renamed this member because I change the meaning. Here is is
> the timestamp renderer flips, not the requested time. only used for
> calculation of delay on GENERAL_RESYNC
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/xbmc/xbmc/pull/4639/files#r12769304>
> .
>