[gst-devel] Docs/RFC: GstData

[Benjamin Otte]

On 18 Apr 2002, Ronald Bultje wrote:

> * why is  GstBuffer a GstInstream thing? Wouldn't GstBuffer better be a
> special type of GstData on its own? Buffers and events are very
> different...

If you look closely, you will find out that buffers and events are indeed
not different at all. They are used with the same functions, they share a
big bunch of code. A buffer really is a "data event". It's the base class
appended by a "size" and a "data" field.
This is not very visible in the current code, because buffers support all
kinds of stuff that doesn't belong there like eg parents or timestamps.

> * why the separation between in and out stream events? The naming isn't
> very obvious and most events can come both instream and outstream (I can
> request for a new file to filesink using GstEventNewMedia and I can do
> seek/flush events in avimux at the end of the input stream internally
> without a notice from outside. In short, maybe it;d be better to not try
> to separate them. Or is this short-sighted?
>
They are indeed very different. Instream data is the current way we handle
data. (well, actually we only handle buffers and EOS.)
Out of stream data is data like seeking requests, flush requests and so on
(most of them being requests) that are send upstream. They need a
completely different way for handling them, even their own scheduling.
They are the reason why I'm going over all this stuff after all ;)


> > Subbuffers
> > ----------
> > Subbuffers have been replaced by a special kind of GstBufferClass.
>
> I don't see any reason to let subbuffers *not* be a GstBuffer.... (?) in
> order to push/pull them, they'd better be gstbuffers, right?
>
Subbuffers are buffers. I tried to explain this concept in the other mail
I send just minutes ago.
You might want to read it there.