On Thu, Jan 19, 2012 at 9:54 PM, Dan Dennedy <dan@...> wrote:
> On Fri, Jan 6, 2012 at 4:59 AM, j-b-m <j-b-m@...> wrote:
>> Investigating Kdenlive bug http://kdenlive.org/mantis/view.php?id=2468, I
>> discovered that several filters break the playlist position when attached to a
>> track. For example, when trying to play frames 50 to 100:
>> melt broken.mlt in=50 out=100
>> It will play the first frame (50), then rewind to the first frame and play
>> frames 0-49.
>> This can be reproduced with melt. For my example, I used the pango producer
>> but the bug can be reproduced using any producer on the track.
>> 1 - Working case:
>> melt -track -attach sepia -producer pango text="Broken" in=0 out=50 pango
>> text="OK" in=0 out=50 -consumer xml:test.mlt
>> This will create a test.mlt playlist with text "Broken" in the first 50 frames
>> and "Ok" in the frames 50-100.
>> Now try:
>> melt test.mlt in=60 out=70
>> It will display frames 60-70 (showing "Ok"), good.
>> 2 - Same playlist with the dust effect reveals the bug:
>> melt -track -attach dust -producer pango text="Broken" in=0 out=50 pango
>> text="OK" in=0 out=50 -consumer xml:test2.mlt
>> melt test2.mlt in=60 out=70
>> It will display "Ok" for the first frame, then "Broken", because the playlist
>> position was somehow reset to 0 by the filter!
>> This bug can be reproduced with effects dust, lines, watermark and volume and
>> maybe others.
>> Looking at the dust filter (in oldfilm/filter_dust.c), I noticed that the bug
>> can be solved by commenting out lines 143 to 145 that are:
>> mlt_properties_set_data ( properties , savename , savepic , sizeof(uint8_t*) ,
>> mlt_pool_release, NULL );
>> mlt_properties_set_data ( properties , savename1 , savealpha ,
>> sizeof(uint8_t*) , mlt_pool_release, NULL );
>> mlt_properties_set_int ( properties , cachedy , luma_height );
>> Uncommenting any of them makes the bug re-appear. So my guess is that somehow,
>> when a filter is attached to a track, trying to change one of its property
>> corrupts the track...
>> Hope it helps solving the problem
> I started looking into this problem, and I found that this event
> listener in mlt_multitrack_connect() is the source of the problem:
> self->list[ track ]->event = mlt_events_listen(
> MLT_PRODUCER_PROPERTIES( producer ), self,
> "producer-changed", (
> mlt_listener )mlt_multitrack_listener );
> Changing the event name to something bogus makes the problem go away.
> This is an area of code I do not visit a lot. So still working on it.
This was just fixed in commit "fix property-changed becoming a
service-changed event." A service-changed on a producer is converted
into a producer-changed, which was triggering the above. However,
service-changed and producer-changed should be more specific than a
very broad property-changed event. So, I improved the docs for these
events as well.