On Thu, Jul 29, 2010 at 1:29 PM, jb <j...@kdenlive.org> 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. > > jb > > > backtrace: > > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xabb86b70 (LWP 10659)] > __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:1248 > 1248 ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S: No such file or > directory. > in ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S > (gdb) thread apply all bt > > Thread 19 (Thread 0xabb86b70 (LWP 10659)): > #0 __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:1248 > #1 0xabb85ea8 in ?? () > #2 0x00143f56 in mlt_consumer_frame_show (listener=0xacf8afc8, > owner=0x88c7fe0, this=0x88c8560, > args=0xabb85ff4) at mlt_consumer.c:276 > #3 0x0013ce2c in mlt_events_fire (this=0x88c8d78, id=0x609c084 "consumer- > frame-show") at mlt_events.c:215 > #4 0x06098dfd in consumer_frame_show_cb (sdl=0x88d5258, parent=0x88c8d78, > frame=0x8babb68) > at consumer_sdl_preview.c:118 > #5 0x00143f56 in mlt_consumer_frame_show (listener=0xacf8afc8, > owner=0x88d5258, this=0x88c8d78, > args=0xabb86144) at mlt_consumer.c:276 > #6 0x0013ce2c in mlt_events_fire (this=0x88cace8, id=0x609c084 "consumer- > frame-show") at mlt_events.c:215 > #7 0x06096715 in consumer_play_video (arg=0x88cace8) at consumer_sdl.c:465 > #8 video_thread (arg=0x88cace8) at consumer_sdl.c:698 > #9 0x0097696e in start_thread (arg=0xabb86b70) at pthread_create.c:300 > #10 0x02181a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 > > > > > > ------------------------------------------------------------------------------ > 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 > Kdenlive-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > -- +-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 Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
