From: Steve F. <sp...@gm...> - 2007-06-06 22:47:48
|
On 6/6/07, David Schleef <ds...@sc...> 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.) |