[mythtv] [patch] Fix for sluggish pause

[Isaac Richards]

On Sunday 05 December 2004 03:29 am, David Engel wrote:
> On Sun, Dec 05, 2004 at 01:23:55AM -0500, Isaac Richards wrote:
> > I'm also not really liking how complicated this whole thing is becoming.
> > =(
>
> I'm sorry you feel that way.  If anything, I think the logic is
> getting simpler, and more importantly, works in a more controlled
> manner.
>
> Furthermore, I feel the feature changes which lead to the, hopefully
> temporary, and near ending, chaos have been worth the pain.  The new
> ff/rew is much better, IMO, for the software decoders and is finally
> somewhat useful for the ivtvdecoder.  Getting the framesPlayed from
> the VideoOutput instead of from the decoders is just the right thing
> to do instead of hacking around it as was done previously.

Yeah, but I don't use ff/rew at all - I don't see the point when I can skip 
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. =)

> > 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.

> > Also, wouldn't it be simpler to not adjust the frame display interval
> > ever, and simply either add or drop frames as required for the current
> > speed?  That would lead to smoother non-1.0 video playback, and simplify
> > a lot of this code.

> 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.

> On Sun, Dec 05, 2004 at 01:46:14AM -0500, Isaac Richards wrote:
> > > There's also no protection for
> > > next_waitvideo/next_unpauseaudio, and I can see those values getting
> > > overwritten.
> >
> > And waitvideo's safe (because of the wait condition), but unpauseaudio
> > isn't..
>
> 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..

Isaac