[gst-devel] GstFileSrc vs. GstAudioSrc

[Tim Müller]

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