[gst-devel] code review & commiting

[vishnu at pobox.com]

On Thu, Oct 11, 2001 at 08:14:57PM +0200, Wim Taymans wrote:
> > The bytestream stuff probably needs a closer look.  Sort of thing we
> > really need a test suite to stress test any changes to it.  Who should
> > review and comment on or commit it?  Apparently no one else cares to
> > deal with the code but when someone does it would be nice to get any
> > beneficial changes into cvs in a timely manner.
> 
> As said before, make us understand how things work and in what way they
> are beneficial. The usual way to do this is by explaining things on IRC
> or by sending out e-mails on -devel.

IIRC, here are the changes vs. the old bytestream code:

* In the old code, _peek_bytes just leaked.  There was no code to keep
track of the memory returned by _peek_bytes.  i added "GstBuffer *peek"
to GstByteStream to keep track of this memory.  This buffer is freed
whenever there is a flush or a new _peek_bytes.

* i changed headbufavail into flushed.  Now there is an inline function
to calculate the headbufavail (GST_BUFFER_SIZE (_headbuf(bs)) - bs->flushed).
i made this change because i felt it was easier to think this way.
It also allowed me to make the update logic more centralized.

* i added event handling code in _get_next_buf.  It's probably wrong,
but it's better than nothing.

* i split _flush into two parts: _flush & _flush_fast.  This is a
minor optimization.  Often you know that you can just _flush_fast,
so you can avoid some extra checks.

* i added code to check all the return codes and fail gracefully.

-- 
Victory to the Divine Mother!!
  http://sahajayoga.org