[gst-devel] [gstreamer] Problem with pulling data from a sink pad

[iain]

On Tue, 2003-12-23 at 16:12 +0100, Thomas Vander Stichele wrote:
> > Why?
> > This is what Marlin does, well, a more sophisticated version of it.
> > 
> > MarlinSampleSrc and MarlinSampleSink are the two elements marlin uses to
> > get data into and out of GStreamer pipelines. People have said its a bad
> > idea before, but I disagree and feel that it is essential in certain
> > cases (NLE being one of them).
> 
> Name things that you can do with this approach but GStreamer doesn't
> allow you to do by design.
> 
> If there are valid things, we should consider these problems.  If there
> aren't, all functionality that currently accesses raw audio data should
> be rewritten as gst plug-ins.

Caching/peak levels
mmapping huge data to disk so that I can jump around it at will
without having to send a seek event, run the pipeline to get 2 frames of
data, send another seek event, run pipeline again...

GStreamer is good for streaming data around a pipeline.
A pipeline is not the way all data should be handled/manipulated.
Just like a hashtable is good for certain things
And bad for others.

> The bottom line is that any code you're writing to process audio outside
> of GStreamer is only useful for marlin.  While any code you write using
> a plug-in is useful for any gstreamer app.

Yes. It only needs to be.
I don't see that this is a problem.

iain
--