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