[mythtv] [patch] Fix for sluggish pause

David Engel gigem at comcast.net
Mon Dec 6 02:51:31 UTC 2004


On Sun, Dec 05, 2004 at 06:00:26PM -0500, Isaac Richards wrote:
> forwards a few times quickly.  I'm just grumbling because CVS has been 
> slightly broken for a bit now, so really, please don't mind me. =)

I figured you were just having a bad day.

> > > How about reverting Pause() to the state it was before all the speed
> > > change stuff got tacked on to it, and move just _that_ part of it into
> > > the decoder loop?  Same with Play()...
> >
> > Sure, and reintroduce all of the race conditions I've been trying to
> > get rid of?  Yes, my first attempt using the decoder_lock was a stupid
> > way of doing it given Linux/Qt/pthread's lack of real-time semantics,
> > but I've kept working to correct that, and believe I have.
> 
> Right - as I said, I missed the fact that Pause() looks good now.

I relooked at this.  All I really care about is syncronizing the speed
changes.  I only moved the other stuff because it seemed logical to
due so.  Since the video/audio/ringbuffer stuff shouldn't have any
effect on the speed changes, I moved it back in this patch.

The other change in this patch is to re-fix ff/rew for the
ivtvdecoder.  It's a little closer to the software decoders now
regarding framesPlayed.

> > No, for several reasons.  Reading every frame, even if most of them
> > are dropeed, will put too high of a load on the systems and network.
> > Reading only keyframes without reducing the frame rate will also
> > create too high of a load.  Not reducing the frame rate will make it
> > too hard to recognize what is flying by on the screen.  Not adjusting
> > the frame rate after choosing a skip interval will restrict the actual
> > speeds to multiples of the keyframe interval.
> 
> Right, but the framerate's locked to a max of what the actual refresh rate of 
> the display is.

I'm open to other suggestions.

> > unpauseaudio should be safe too.  It's only set and used when the lock
> > is held.  It's possible someone with very quick fingers could rechange
> > the speed before the previous change takes effect, but that's always
> > been the case and shouldn't matter -- last change wins anyway.
> 
> Not speed change - say, change channel + then seek immediately.  That was safe 
> before, and I don't think it's guaranteed to be now..

I don't see why, but I'll take your word for it because I tried
channel change + seek and was able to produce odd results sometimes.
Please answer me this, if unpauseaudio == false when changing channels
or inputs, when does the audio get unpaused?  Does the move of some
stuff back to NVP::Play handle the problem?

David
-- 
David Engel
gigem at comcast.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: speed3.patch.gz
Type: application/octet-stream
Size: 5293 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20041205/6281d2dd/speed3.patch.obj


More information about the mythtv-dev mailing list