2010/7/22 Dan Dennedy <d...@dennedy.org>: > On Thu, Jul 22, 2010 at 7:50 AM, Simon Eugster <simon...@gmail.com> wrote: >> 2010/7/22 jb <j...@kdenlive.org>: >>> On Wednesday 21 July 2010 15.49:47 Simon Eugster wrote: >>> >>>> What does not work yet is updating the scopes when e.g. adjusting >>>> effect parameters. For example color temperature. There are very >>>> interesting effects on the vectorscope when changing the temperature >>>> btw :) >>>> If someone could give me a hint which signal to use, I've been >>>> searching for this event for half an hour or so but couldn't find one >>>> yet. >>> >>> After thinking a bit about it, I just added a new signal to renderer.cpp, >>> called: >>> >>> void frameUpdated(int) >>> >>> That signal is emitted every time the frame is updated without a seek event. >>> Currently, the frame is updated not only when an effect is added, but also >>> every time the monitor needs a refresh (for example when another window >>> moves >>> above it), so you will get a few extra calls, but that's also an occasion to >>> track unneeded refreshes :) >> >> Thank you! Works now. >> >> Something else: >> When activating realtime and auto-refresh in one of the scopes, the >> speed when playing clips changes. I'm not sure, but perhaps this is >> because of: >>> m_activeRender->extractFrame(m_activeRender->seekFramePosition()) >> which I use for retrieving the current frame (perhaps there's a better >> way?). Any idea? (I'd disable realtime for the release otherwise.) >> > > Yeah, this is bad. First of all, the mlt consumer-frame-show event > supplies a frame reference, which gets lost in the Kdenlive > rendererPosition signal that its frame-show event handler emits. It > appears that kdenlive signal was intended purely for position-oriented > thing like updating a timecode label, but now you could say it is > being abused. Interestingly, when I trace your logic for updating the > vectorscope, that frame position is not used. Instead it is a trigger > to get the position of the mlt producer for the active monitor. Using > the producer's position is the second bad thing.
I just tried to change it. When pressing play, it kept on jumping back in the monitor. The current version may work better because I'm getting the most up-to-date position and not one that may have been delayed for one or two seconds (for whatever reason). > It is not the same > position as that in the monitor (the mlt consumer). The producer may > read ahead for some parallelism. While we currently keep this low for > better latency handling, it is going to go up a little when additional > parallelism is introduced. The third bad thing is that to get a frame > object, it asks the producer to seek backwards when it may have > already moved ahead! This might not be too bad right now due to some > frame caching in MLT, but again, with increased parallelism coming, it > may become worse. In summary, the scopes should be using the frame > object from the mlt frame-show event and avoid jumping through so many > hoops. I see ... So if we'd pass the frame directly, we would a) gain performance and b) be able to make use of the «original» (i.e. last used) color space? Simon ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
