GNOME Bugzilla – Bug 308523
buffersink and buffersrc
Last modified: 2006-01-27 14:46:58 UTC
I've made a pair of plugins, buffersink and buffersrc. They work a lot like filesink and filesrc, with the difference that they use GstBuffers instead of files. Also, they try to preserve the capabilities of streams. I'd like to see them as a part of GStreamer proper. They're available at http://users.utu.fi/kaolpa/gst/ From the README of the package: Buffersink is a sink that stores a stream to a GstBuffer. Buffersrc is a source that uses as the source a GstBuffer. These are meant to be used together. Typically you'd use them with something like: GstBuffer *buf; GstCaps *caps; GstElement *bufsink, *bufsrc; ... // Run a pipeline that uses bufsink as a sink g_object_get (bufsink, "buffer", &buf, NULL); g_object_set (bufsrc, "buffer", buf, NULL); g_object_get (bufsink, "caps", &caps, NULL); g_object_set (bufsrc, "caps", caps, NULL); gst_element_link (bufsrc, sink);
Hi! I've looked at your elements today, seems cool :) Some random thoughts: - they seem to work only for audio, right? - gst-inspect-0.8 buffersink gives an error while displaying properties - Is seeking while playing supported? - Is it ok to send only a very big buffer? (first buffer == whole stream, if i have understood properly). Why you don't pass the list created in buffersrc to buffersink and make buffersink push all buffers? Maybe this is a work for a different element.. - Can you please explain a use case for this element? To cache already decoded data? anyway, good work!
I like the elements. However, I have doubts about insertion. Their functionality comes very close to fakesrc/sink, and I would like to have distinct functionality for elements with no huge overlap.
I've considered the elements for use with audio only so far, but I guess there shouldn't be that much trouble with other types of data too, as long as the caps are set properly. I'll upload 0.1.3 shortly, it should be more robust and not give errors with gst-inspect-0.8. Seeking is supported but untested. I've opted to merge the incoming stream to a single GstBuffer since I thought that passing that around is simpler than passing a GSList of GstBuffers. Maybe there's reason to not merge the buffers, or maybe it would make sense to have both functionalities in. I haven't thought about that point that much. Are there sinks around that set a maximum size for the GstBuffers it receives? I'm thinking of using buffersrc/buffersink to play sound effects in a game. Usually I'd have to create a filesrc and find a decoder for that and then play the sound. Decoding at that time takes CPU time when the game is running and it has to be done every time the sound is played, too. Having it buffered in memory allows to do that only once when initialising the game data. I guess this all could be done with fakesink and fakesrc, with handoff signals AIUI. But their usage is warned against when using threads.
If you know what you're doing, handoff is fine. The thing is that some people want to 'decoder data using gstreamer' (i.e. as alternative to libmpeg2 or such) and don't really get the concept. The warning is there to prevent this kind of, well, abuse. It's just not the right way and will get you into trouble. If you knwow hat you're doing, up to some amount, you're fine.
Another possibility is buffer probes, which you can use without a sink element to collect the buffers. Then you can just push them manually into your playback pipeline without a source element. That's pretty ghetto though. I don't think this element is appropriate for inclusion in GStreamer, though. This is not really a supported usage pattern. Will close as a NOTABUG or some such if there's no activity on this for a few days.