[mythtv] Playback too fast

[Isaac Richards]

On Friday 31 March 2006 17:46, Greg Stark wrote:
> Isaac Richards <ijr at case.edu> writes:
> > On Friday 31 March 2006 15:29, Greg Stark wrote:
> > > Isaac Richards <ijr at case.edu> writes:
> > > > > Or perhaps the usleep should be happening before the videosync
> > > > > method is even called from NuppelVideo itself.
> > > >
> > > > A usleep isn't accurate enough for that.
> > >
> > > It seems to work fine with the usleep+busywait sync method.
> > >
> > > usleep (actually the syscall on linux is nanosleep) on most platforms
> > > has a resolution of 10ms. Even if it goes over by 1 or two iterations
> > > that's only 10-20ms which is still less than the frame interval for a
> > > 30fps NTSC video.
> >
> > Who's limited to 30fps NTSC?  Use the bob, and you're at 60 fps.  720p at 60
> > HD video..  10-20ms resolution simply doesn't cut it.
>
> Sure, so it wouldn't normally call the usleep unless it got at least a full
> frame ahead. My point is you have to at least check where you are and not
> just use dead reckoning.

What do you think VideoSync::CalcDelay() is for?  Notice the gettimeofday, 
comparing directly to the next desired display time.  Granted, that only 
cares if it didn't wait long enough, and the video getting too far 
ahead/behind is dealt with in the main loop (where it can drop or double a 
frame if need be).

> > Yes, it trusts that the ioctls are doing what they're supposed to be
> > doing. If they're not, they shouldn't be advertised as working in the
> > first place.
>
> Well there's two problems here. A) They might not, as they weren't in this
> case. and B) all they promise is that they'll sync with the retrace, not
> that they'll wait for a specific amount of time. Mythtv makes assumptions
> about the timing based on the refresh rate it calculates from GetModeLIne.

If a driver is _lying_ to an application about what it can do, then it should 
be fixed, not the application.

> If it gets it wrong then mythtv never corrects based on gettimeofday at all
> and gets completely confused.

VideoSync::CalcDelay(), again.

> Incidentally I'm a bit surprised at all the effort expended to sync with
> retrace. AFAIK mplayer makes no effort to sync with the retrace and just
> uses the RTC to sync to the audio and I've never noticed any page tearing.
> Are you sure the X server doesn't use page flipping to avoid tearing
> automatically?

The point of all this code isn't to avoid tearing, it's to have video playback 
be as smooth as possible.  Delivery is an order of magnitude or two smoother 
when it can use the hardware for this, instead of just trusting to the 
vagaries of a usleep.

Maybe just don't use a broken driver?

Isaac