gnonlin memory leak?

[Mathis Hofer]

hi

I'm using gstreamer 0.10.18 and gnonlin 0.10.9 on ubuntu hardy (the same
happens on gutsy) and I have a problem with this simple gnonlin program:
http://pastebin.org/27154

either I am doing something wrong here, or there is a pretty serious
memory leak. it looks like the audio files don't get freed after they
have been played.

the effect with this equivalent python script:
http://pastebin.org/27157

I've searched the bugzilla database, but did not found anything like this...

I'd be very glad, if somebody could reproduce this or give me a hint
what I'm doing wrong.

regards,
mathis

--
DreamLab Technologies AG
Monbijoustrasse 36
3011 Bern
Switzerland

Tel: [phone]
Fax: [phone]

PGP Key ID: 2462240B


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey-2]

Hi,

On Thu, 2008-04-03 at 15:14 +0200, Mathis Hofer wrote:

> hi
>
> I'm using gstreamer 0.10.18 and gnonlin 0.10.9 on ubuntu hardy (the same
> happens on gutsy) and I have a problem with this simple gnonlin program:
> http://pastebin.org/27154
>
> either I am doing something wrong here, or there is a pretty serious
> memory leak. it looks like the audio files don't get freed after they
> have been played.
>
> the effect with this equivalent python script:
> http://pastebin.org/27157
>
> I've searched the bugzilla database, but did not found anything like this...
>
> I'd be very glad, if somebody could reproduce this or give me a hint
> what I'm doing wrong.

  The GnlSource you add to a composition will not be freed after they've
been played (else you wouldn't be able to seek back). Although that
shouldn't result in a big leak.

  You might want to run your C program under Valgrind to find what
exactly is leaking. You will find some good information about how to
debug gst-based applications here :
  http://www.buzztard.org/index.php/Debugging#Valgrind


   Edward

>
> regards,
> mathis
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
Edward Hervey
Lead Platforms Engineer / Director
Collabora Multimedia


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Phil Pellouchoud]

Okay, I need some help. :-)

Here's my situation - I want to create a filter with no sink pads and
exactly one source pad -- essentially a source filter?

It looks like a file source filter in the sense that it has a "location"
property associated with it, but it spits out PCM instead of actual file
data (i.e. there's a decompressor built in).

What should I base this filter on?  I started using GstAudioSrc because
it seemed like the documentation was leading me that way.  But now that
I'm having all these problems, I'm wondering if I should have used the
GstFileSrc...

It seems like what I want to do is pretty simple - a source filter,
takes a 'location' as a property and spews out PCM on the "source" pad
so that I could hook it up to a autoaudiosink and play audio....

Any suggestions?

-phil

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Fri, 2008-04-04 at 16:21 -0700, Phil Pellouchoud wrote:

Hi,

please don't 'hijack' existing mailing list threads by replying to an
existing mailing list post when you want to start a new thread with a
new topic.

> Here's my situation - I want to create a filter with no sink pads and
> exactly one source pad -- essentially a source filter?
>
> It looks like a file source filter in the sense that it has a "location"
> property associated with it, but it spits out PCM instead of actual file
> data (i.e. there's a decompressor built in).

Why not write this as a normal decoder/demuxer/parser element then and
let filesrc do the file reading?

> What should I base this filter on?  I started using GstAudioSrc because
> it seemed like the documentation was leading me that way.  But now that
> I'm having all these problems, I'm wondering if I should have used the
> GstFileSrc...

GstAudioSrc is meant for live capture, where producing one second worth
of data will take about one second. In your case this is probably not
the case.

When reading from file, the source and all other elements produce
buffers as quickly as possible, and the audio sink then syncs to the
clock based on the timestamps on the buffers and newsegment events.

> It seems like what I want to do is pretty simple - a source filter,
> takes a 'location' as a property and spews out PCM on the "source" pad
> so that I could hook it up to a autoaudiosink and play audio....

If you really want to go down this route instead of writing a separate
parser element, then you should probably derive from GstPushSrc and/or
GstBaseSrc. (You can't derive from GstFileSrc, since its headers are not
public; you don't need to either though, you can do anything you can do
at the source by writing a pull-mode based parser).

Cheers
 -Tim



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel