Back from Fosdem

The FOSDEM weekend went down great as usual. Met the usual folks, and many more new people. Alway refreshing to put a face and personality behind a IRC nick :)

The talk I gave on “GStreamer: What’s New?” was well received. I had a hard time in fact both reducing the talk to fit in the limit of 45 mins and keeping it not too technical, but it seems to have paid off. The slides are available here in OOo format.

As I mentioned during my talk, we’ve been working hard on making GStreamer work on other platforms, including Windows and MacOSX. We’d love to receive more feedback on their usage, especially from MacOSX users/developers. If you want to give a ride, install fink and either use the available package (although they’re a bit old now) or compile your own GStreamer from releases or cvs. BTW, if a fink maintainer sees this post, updates to the existing GStreamer packages would be nice :)

The native MacOSX video sink is coming on nicely… but sometimes you hit some wall, like NSAutoReleasePool (objective C explicit garbage collector) not being able to work across multiple threads, which makes it impossible to avoid some warnings about objects leaking. In GStreamer plugins your entry points (pad functions, element methods, …) can be called from different threads, and you shouldn’t have to care about which thread it is (well you need to protect data that can be called by different threads with locks, but you get the drill), but with ObjectiveC you apparently need to create one of those pools for each new thread… tricky since I’m not the creator of those threads, they’re created outside of the scope of my plugin. If an ObjectiveC guru knows the trick, I’m dying to know it.

4 Responses to “Back from Fosdem”

  1. Hub says:

    It is splitting hair: it is not an Objective-C feature but a FoundationKit feature. I had to insist on this.

    Also it is a bit unsafe:

    http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html

    Unless you do what they say in the first “Note:”.

    See also:

    http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/AutoreleasePools.html#//apple_ref/doc/uid/20000047

  2. Edward Hervey says:

    Hub, I am creating a dummy NSThread (which exits straight away), but I still get the same issues. Will still try looking deeper.
    Also, I can’t use ‘local’ NSAutoReleasePool, since some objects might be allocated in one thread, but released in another.
    Sorry for the confusion between ObjectiveC and FoundationKit.

  3. Randall Wood says:

    Instead of Fink, try Macports (http://www.macports.org) The project trys to keep abreast of the latest stable version of most GNOME packages including gstreamer.

  4. Helge Heß says:

    For a general introduction to ObjC retain counting use this:

    http://www.stepwise.com/Articles/Technical/HoldMe.html

    I don’t know what exactly you want to do, but can’t you just wrap all calls to your entry points in pools?
    You can use a local NSAutoreleasePool, it doesn’t matter in which pool actually deallocates the object (autorelease pools do not deallocate objects, they just call -release, which may or may not deallocate an object).

    (and no, NSThread doesn’t create pools [why would it?], but it might be required to initiate a dummy thread to put the ObjC runtime into multithreading mode).