[gst-devel] Synchronizing between "disconnected" sink and source

Steve Fink sphink at gmail.com
Thu Jun 7 00:47:43 CEST 2007


On 6/6/07, David Schleef <ds at schleef.org> wrote:
> On Wed, Jun 06, 2007 at 02:56:30PM -0700, Steve Fink wrote:
> > I am trying to write a plugin element that keeps a copy of all data
> > received on its sink, and at a later time produces on one or more
> > sources. Currently, I am basing it off of GstBaseAudioSink, because it
> > seems like I fit its requirements: I have exactly one sink pad, and as
> > far as I know I don't need to get involved in capabilities
> > negotiation. I'm not sure if the latter is correct, though. I don't
> > think I ever will need to even look at the data that I copy from the
> > sink; only the metadata (timestamps).
>
> See http://bugzilla.gnome.org/show_bug.cgi?id=114973

Excellent, thanks! Err... now how can I get the source code? I don't
see it in current CVS of gst-plugins-bad.

I have mine at least running and capturing buffers, at least, which
turned out to be trivially easy once I switched to using GstBaseSink
instead of the GstBaseAudioSink. But that's the easy part.

The eventual plugin I want is slightly different from yours, though:
 - I don't care about seeking
 - I want to always buffer to memory (if I get too much data, I'd
rather drop some of it and restart my input to start again. But I
don't really need that.)
 - I want N source pads, dynamically created based on events
 - I also want to dynamically destroy source pads

So it sounds like it could be a fairly simple modification of yours --
mostly a slight simplification, with the addition of the dynamic
source pads. And hey, if that ends up allowing seeking across the
source pads, I have no complaints! (It may not make any sense, since
they would all seek together.)




More information about the gstreamer-devel mailing list