Thanks for looking into this. I will run some more tests.
What do you mean by "when the playlist is deleted"? Because setting it to nil
was not affecting anything on my side.
You say that Mlt::Producer.new is the preferred form. Is that also true with
Mlt::Factory.consumer? Why? I see in your source that a lot of properties are
being set on .new and it looks like the defaults on Factory.x are maybe
different (I can't find exactly where they are).
BTW, if you want to play with this stuff in Ruby and get some great info, there
is an irb replacement called pry. It has great stuff like calling 'ls' on
classes or objects to get all the class/instance methods/variables up the call
list. It is how I discovered most of the mlt library before I could read C. You
can even cd into classes or instances to look around. You can also view the
ruby and C source code for classes/methods
https://github.com/pry/pry/wiki/Source-browsing
Here is a little sample
https://gist.github.com/pferdefleisch/635ea97b169546a04dd0
Sorry for the aside :)
On May 7, 2013, at 6:35 PM, Dan Dennedy wrote:
> On Tue, May 7, 2013 at 4:02 AM, Aaron Cruz <aa...@aaroncruz.com> wrote:
>> No, it isn't open source (ATM). I would like to release part of it at some
>> point.
>>
>> The project is basically a simple RESTful web server wrapping the ruby swig
>> bindings that takes in API calls and consumes and produces JSON. It is
>> pretty much a ruby http version of melted that speaks JSON. If necessary I
>> could write up a dumbed down version for you to test.
>>
>> But I can't even get the garbage collection to work correctly with the
>> sample script I showed you. Once I got that to work I could use that
>> solution to see what I can do to fix my memory issues in my project.
>>
>> If you haven't run the script, I highly recommend it.
>> I am running mlt 0.8.2 and ruby 1.9.3p327 on OSX 10.7.5
>> I have also tested mlt 0.8.2 with ruby 1.8.7p358 on ubuntu precise64 with
>> the same results. With this version, it seems to be releasing about 2MB RAM
>> after the nils and GC.
>
> I did a little testing last night with your script. I put printfs in
> the Producer and Playlist destructors, and I noticed that they were
> not being called. When I changed Mlt::Factory.producer to
> Mlt::Producer.new (the preferred form), I saw the producer destructors
> being called. (By that time I was not using the exact same script as
> you, so you may not necessarily see the exact same results.)
> Nonetheless, for some strange reason, I never saw the Playlist
> destructor called, and the playlist holds a reference to every
> producer added to it, which it eventually releases when either the
> producer is removed, when autoclose=1 and the producer has played out,
> or when the playlist is deleted.
>
>> Both of these i have tried w/ and w/o %trackobjects;
>
> I believe it is a swig definition problem, but I do not think
> %trackobjects will solve it. In fact, it might make the problem worse
> as it seems like it is more suited towards C++ classes that do not use
> reference counting. I am not sure how much more effort I will put into
> it. The effort I put forth now is based purely on curiosity, but I do
> have other pressing concerns.
>
>> --
>> aaron
>>
>> On May 6, 2013, at 6:46 PM, Dan Dennedy wrote:
>>
>> This has worked in the past. I need to know more about your
>> application before I offer to debug these things for you. Is it an
>> open source project?
>>
>> On Mon, May 6, 2013 at 8:46 AM, Aaron Cruz <aa...@aaroncruz.com> wrote:
>>
>> Hi Dan,
>>
>> What you suggested (setting to nil) has never worked for me in the past.
>>
>>
>> I just created a little test to showcase this here
>>
>> https://gist.github.com/pferdefleisch/1e448e3257837ebeb2b3
>>
>> My memory is never released. It stayed in my test with 100 short .movs right
>>
>> around 200MB with 0.0% CPU.
>>
>> I also tried something that I found on the SWIG page with the mlt.i file
>>
>> (you can see in the gist).
>>
>>
>> Since there seems to be no garbage collected playlist factory, I tried the
>>
>> same test above but with just connecting the consumer to a non-playlist
>>
>> producer with the same results, no memory released.
>>
>>
>> I have also seen strange things happen like when I set 'autoclose' to 1, as
>>
>> mlt plays my list, clips are removed, but memory is only released, and only
>>
>> a tiny bit, when I append new videos. Maybe this is a separate bug.
>>
>> --
>>
>> thanks for your time,
>>
>> aaron
>>
>>
>> On May 5, 2013, at 8:24 PM, Dan Dennedy wrote:
>>
>>
>> On Sun, May 5, 2013 at 4:14 AM, Aaron Cruz <aa...@aaroncruz.com> wrote:
>>
>>
>> I am trying to create a reset functionality in my Ruby code that will clean
>>
>> up my consumer and playlist (Mlt::Factory.consumer and Mlt::Playlist
>>
>> respectively).
>>
>>
>> It seems like both the mlt_playlist_close and mlt_consumer_close functions
>>
>> were made for this but they are not included in the SWIG bindings.
>>
>>
>> Is there a reason they were left out?
>>
>>
>> Is there a better way to to this with the already provided interface?
>>
>>
>>
>> I would like my server to handle the reset instead of having to reset my
>>
>> server. I am also still having memory leak issues and I would like to tweak
>>
>> some things like this for some experiments.
>>
>>
>> --
>>
>>
>> Thank you,
>>
>>
>> Aaron
>>
>>
>>
>>
>> The C++ destructors call the C close functions. When you release
>>
>> references in a scripting language and garbage collection occurs, then
>>
>> the C++ destructors are called. If you want to make cleanup more
>>
>> immediate in the scripting language runtime, then set the vars holding
>>
>> reference to nil and force processing the garbage collection. If you
>>
>> call the C close functions directly, then the C++ destructors will
>>
>> (eventually) call close on invalid pointers.
>>
>>
>> --
>>
>> +-DRD-+
>>
>>
>>
>>
>>
>>
>> --
>> +-DRD-+
>>
>>
>
>
>
> --
> +-DRD-+
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
