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. 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... 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