[gst-devel] Re: [gst-cvs] CVS: gstreamer/libs/bytestream

[Erik Walthinsen]

On Sun, 16 Sep 2001, Wim Taymans wrote:

> Log Message:
> Removed the _bytes_ from the methods because we don't return raw bytes.

My thought for the bytestream implementation is that it would have both
buffer and byte routines.  The peek/flush sequence is what allows that.
The API would be:

GstByteStream *gst_bytestream_new(GstPad *sinkpad);
GstBuffer *gst_bytestream_peek(GstByteStream *bs,guint64 len);
guint8 *gst_bytestream_peek_bytes(GstByteStream *bs,guint64 len);
void gst_bytestream_flush_bytes(GstByteStream *bs,guint64 len);
GstBuffer *gst_bytestream_read(GstByteStream *bs,guint64 len);

The idea is that the data returned by the peek_bytes routine cannot be
freed until the flush pointer passes them.  This means the plugin has to
make sure it doesn't flush past data it needs.  Also, the question is
whether we want to have a separate read and flush pointer, and if so, how
to keep track of that.  Not having separate pointers means that reading
far ahead of the flush pointer will cause copies in many cases, because
each peek() would start from the flush pointer, so you have to read
successively larger and larger buffers to get what you're after.

Having separate pointers means that the plugin has to make sure there's no
chance of totally losing track of things (which could cause a leak if the
flush pointer lags further and further behind the read pointer, or a
potential fault if the flush pointer jumps past the read pointer).

The reason for having byte-pointer operations is that they're faster.
Having to create a new buffer is annoying, because it costs a fair bit (a
mutex and alloc, atm, which might be fixed with some kind of lock-free
free-list).

Not sure what _fill and _shrink are all about, they shoudln't be necessary
I don't think.

The implementation I'm thinking of would make use of _is_span_fast() to
merge buffers as necessary, but also keep a (short, hopefully) list of
live buffers, enough to cover the flush and read pointers if the incoming
buffers aren't spannable.  As buffers come in, they're merged into the
latest buffer if _is_span_fast(), else pushed on the top.  A peek() would
then go ahead and use _span() to construct the buffer if necessary, in
case _span() for some reason has some 'semi-fast' mechanism in the future,
like an architecturally optimized copy.

I'll write up a new prototype bytestream impl to test this out, and we can
hash out the API issues soon.

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_