On Fri, Jul 30, 2010 at 10:34 AM, Dan Dennedy <[email protected]> wrote: > On Thu, Jul 29, 2010 at 1:29 PM, jb <[email protected]> wrote: >> On Thursday 22 July 2010 19:06:22 Dan Dennedy wrote: >> >>> >>> 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. >> >> Hi all. >> >> I had a look at this stuff and tried to use the frame object from the mlt- >> frame-show event, using exactly the same code that is used to get a QImage >> to display on the QGLWidget. >> >> Added code in the consumer_frame_show event looks like this: >> >> mlt_image_format format = mlt_image_rgb24a; >> int width = 0; >> int height = 0; >> const uchar* image = frame.get_image(format, width, height); >> QImage qimage(width, height, QImage::Format_ARGB32); >> memcpy(qimage.bits(), image, width * height * 4); >> self->gotFrame(qimage); // send the image for analysis >> >> It works fine when seeking, but if I try to play the clip, it crashes with >> the >> backtrace copied at the end of the mail. > > I will take a closer look this weekend. > >> So I am wondering if it is possible to use the frame from the consumer event >> or if something in MLT's design makes it impossible... > > I am thinking of 2 possible things. One is that a reference needs to > be added to prevent a premature free on the mlt_frame object. Another > thing is that this callback is initiated from a separate thread and > sometimes painting from a separate thread does not play well with a > toolkit's main thread. > >> Any hints welcome.
I have this change working good in my local copy, but I had to move the location of the consumer-frame-show event in the MLT sdl consumer to occur _after_ the consumer was finished with the frame's image. Then, basically, I made the event handler in Kdenlive emit a signal with a QImage, which the Qt signals-slots system takes care of queuing between the threads. The slot in the AbstractScopeWidget then updates a private QImage, which is then sent into the renderScope methods. I can update Kdenlive svn a few days after I commit the MLT change. -- +-DRD-+ ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Kdenlive-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
