[mythtv] [patch] Fix for sluggish pause

[David Engel]

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.

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

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

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.

David
-- 
David Engel
gigem at comcast.net