[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