[Kdenlive-devel] kthumb crash? (was Re: [PATCH mlt] Clear audio and video context to NULL)

jb jb at kdenlive.org
Tue Oct 25 17:13:15 UTC 2011


On Tuesday 25 October 2011 09:19:02 Dan Dennedy wrote:
> >> Were you calling consumer.is_stopped() before trying to start it? I do
> >> not criticize you if you were not; it is not exactly obvious you
> >> should need to, but I am wondering if that would help.
> > 
> > Making sure that the consumer is stopped before starting it does not
> > change anything. In fact, the problem is the following:
> > 
> > After starting the consumer, I do:
> > consumer->set("refresh", 1);
> > 
> > To trigger an update of the display. The avformat corruption happens
> > because of the "consumer-frame-show" event. After refreshing, the sdl
> > consumer triggers the event like this:
> > 
> > mlt_events_fire( properties, "consumer-frame-show", frame, NULL );
> > 
> > It sends a frame, but sometimes, when stopping the consumer (and purging
> > it), that frame is still "alive" somewhere in this event. Then, when we
> > delete its producer, it causes some of the corruptions I noticed.
> 
> were you using the frame pointer beyond the scope of the event
> handler? That is not supported without incrementing reference count
> and later closing the frame when needed. The frame holds a reference
> to the avformat producer to prevent it from being totally flushed from
> cache. It sounds like the frame pointer is being used after it has
> been destroyed, or the consumer stop/flush is too agressive at
> decrementing reference count causing premature destruction. This then
> allows the avformat producer to be removed from cache.

In fact, the problem showed up even when not using the event. It showed up 
even if Kdenlive was not listening for any MLT events. So on second thought, 
maybe I was wrong in my interpretation of the issue.

Maybe the problem comes when we try to stop the SDL consumer at a very special 
moment in its startup, and my workaround (wait for the event to be emited) 
simply makes sure that we don't stop the consumer before it has fully 
processed it's first frame.

I tried to review the sdl consumer code but couldn't find any hint on where 
this would be possible.


> This is rather difficult for me to debug further since I did not
> directly experience the problem and develop the workaround. And you
> are good about trying to get things fixed in MLT where needed. So, I
> leave it to your judgement based on the information you have from this
> experience and my feedback.

Anyhow, I am happy with the current situation, and have to concentrate on some 
other small issues for now to make the next Kdenlive release happen.

regards
jb







More information about the Kdenlive mailing list