> I do not know what you are talking about (properties are being set) > and what you mean by ".new". If you refer to the properties that are > set in the various C init functions, then it does not matter. That is what I meant.
> I was using swig v2.0.4. And I v2.0.7 If you get interested in scratching your itch, I look forward to what you come up with. Otherwise I will continue to try to debug this as problems arise and I will keep you updated if I find the bug. -- aaron On May 7, 2013, at 7:24 PM, Dan Dennedy wrote: > On Tue, May 7, 2013 at 9:58 AM, Aaron Cruz <aa...@aaroncruz.com> wrote: >> 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. > > I mean when you work in C++ and delete the playlist or when you work > in C and call mlt_playlist_close(). > >> You say that Mlt::Producer.new is the preferred form. Is that also true with >> Mlt::Factory.consumer? Why? > > yes, the C++ constructors for Producer, Consumer, Transition, and > Filter use mlt_factory. The reason it is preferred is simply because > it is the cleanest and most obvious thing to use in the high level > languages. Playlist does not go through a factory because it is not > extensible at the C level - same goes for Multitrack and Tractor. > >> 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). > > I do not know what you are talking about (properties are being set) > and what you mean by ".new". If you refer to the properties that are > set in the various C init functions, then it does not matter. > Technically there is no difference between using Mlt::Factory.producer > and Mlt::Producer.new because the Factory methods simply invoke the > appropriate constructor! The fact that I am seeing different behavior > in ruby when making that change says something about the swig > definition - at least for ruby - even though it has declared the > Factory methods as %newobject. However, the biggest surprise is the > failure to destroy a playlist (after nil and GC) even though > Mlt::Playlist.new is a plain old constructor and not needing a > %newobject! That is a total head scratcher. I was using swig v2.0.4. > >> 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-+ >> >> > > > > -- > +-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
