On Sunday 10 July 2011 01:45:13 Dan Dennedy wrote:
(...)
> > The bug is that sometimes in "mlt_playlist_resize_clip", the blank
> > producer seems to be disconnected from the playlist's blank
> > (self->blank). Disconnected means that they have a different length
> > property.
> >
> > So, in "mlt_playlist_resize_clip", when we have a blank producer, we get
> > the following for example:
> >
> > mlt_producer_get_length( &self->blank ) returns 38000
> > and
> > mlt_producer_get_length( producer ) returns 15000
> >
> > and I made sure they are the same producer using:
> > mlt_producer_cut_parent( producer ) == &self->blank
> >
> > My guess is that for some reason the properties for "producer" and "self-
> >
> >>blank" producer are not in sync, but maybe you have a better idea.
>
> Blanks are cuts of the self->blank producer (cut parent). if one blank
> is resized over 15000, then resizing a subsequent over 15000 does not
> complete because the test against its parent fails (it is already long
> enough). It really is a simple matter of parent and cut both
> potentially need to be increased, but the test is only made against
> the parent.
>
> > Then in "mlt_playlist_resize_clip", if we try to resize the producer to a
> > length of 17000. It only checks for the length of &self->blank, so
> > setting the out of producer to 17000 fails and we get an out of 15000
> > (the producer length).
> >
> > This results in playlist corruption since consolidate_blanks then changes
> > the duration of in between blanks.
> >
> > Below is a patch that fixes the issue, but it would probably be better to
> > understand why the producer can give a length different than the
> > playlist's blank.
>
> You are on the right track, but I think this patch more elegantly
> illustrates the problem and solution:
Hello Dan.
Ok for me, your patch fixes the issue. To reproduce the bug, I opened the
before.kdenlive project file from bug report and selected all clips on the
upper tracks from 0 to 10 minutes. The deletion triggered the bug about 50%
of the time.
(When moving groups, Kdenlive first deletes the clips before re-inserting them
in the right place, that's why I think it is the issue that caused the
reported bug).
Can you also check in "mlt_playlist_virtual_append", line 237 we have a very
similar code that probably needs to be fixed too:
// Make sure the blank is long enough to accomodate the length
specified
if ( out - in + 1 > mlt_producer_get_length( &self->blank ) )
{
mlt_properties blank_props = MLT_PRODUCER_PROPERTIES(
&self->blank );
mlt_events_block( blank_props, blank_props );
mlt_producer_set_in_and_out( &self->blank, in, out );
mlt_events_unblock( blank_props, blank_props );
}
Thanks
jb
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
