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.
--
+-DRD-+
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
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-d2d
_______________________________________________
Mlt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mlt-devel
