On Thu, Jul 22, 2010 at 7:50 AM, Simon Eugster <simon.eu at gmail.com> wrote: > 2010/7/22 jb <jb at 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. 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. -- +-DRD-+