[Kdenlive-devel] Color correction tools: How and where to implement them?

Dan Dennedy dan at dennedy.org
Thu Aug 5 05:47:43 UTC 2010


On Fri, Jul 30, 2010 at 10:34 AM, Dan Dennedy <dan at dennedy.org> wrote:
> On Thu, Jul 29, 2010 at 1:29 PM, jb <jb at 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.

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




More information about the Kdenlive mailing list