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 [EMAIL PROTECTED]
speed3.patch.gz
Description: Binary data
_______________________________________________ mythtv-dev mailing list [EMAIL PROTECTED] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
