On Tue, Oct 25, 2011 at 2:56 AM, jb <j...@kdenlive.org> wrote:
> On Sunday 23 October 2011 20:58:51 Dan Dennedy wrote:
>> On Sun, Oct 23, 2011 at 3:38 PM, jb <j...@kdenlive.org> wrote:
>> > Using MLT in debug mode, I discovered several cases where FFmpeg did
>> > show a warning about insufficient thread locking around avcodec open /
>> > close.
>> I have seen these messages before as well, but there are global mutex
>> locks around all calls to avcodec_open/close.
>>
>> > After several of this warnings, the avformat producer became corrupted
>> > and unable to load any clip, or simply crashed, which might be the
>> > reason for those clips becoming invalid.
>> >
>> > These problems were caused by concurrent uses of producers in Kdenlive,
>> > and also by a "weakness" in the sdl preview consumer that caused such
>> > corruption when doing the following steps very fast several times:
>> >
>> > stop the consumer
>> > delete the producer
>> > connect a new producer to the consumer
>> > start the consumer
>> >
>> > Looks like when looping, sometimes the consumer was stopped while
>> > starting,
>> 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.
>
> The way I currently solved it is to do this just after the call to refresh:
>
> Mlt::Event *ev = consumer->setup_wait_for("consumer-frame-show");
> consumer->wait_for(ev);
> delete ev;
>
> After that, we can stop the consumer, delete the producer and start a new one
> safely.
>
> Somehow, it seems to me that when stopping the consumer (or when purging), all
> frames should be closed (including those in the events). Maybe there is a way
> in MLT to make this happen that I do not know?
No, that would be very bad because it breaks the semantics of
reference. Then, a variable that holds a reference to a frame could
legitimately try to use a frame that was destroyed. Also, frames are
independent of the consumer.
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.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Kdenlive-devel mailing list
Kdenlive-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
