On Thu, Jan 19, 2012 at 9:54 PM, Dan Dennedy <[email protected]> wrote: > On Fri, Jan 6, 2012 at 4:59 AM, j-b-m <[email protected]> wrote: >> Hello. >> >> 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. -- +-DRD-+ ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
