[gst-devel] addition of a buffer flag

[David Schleef]

On Thu, May 13, 2004 at 05:03:09PM +0200, Thomas Vander Stichele wrote:
> On Wed, 2004-05-12 at 23:06, David Schleef wrote:
> > On Wed, May 12, 2004 at 07:17:02PM +0200, Thomas Vander Stichele wrote:
> > > Seriously, this is not what caps are supposed to be used for.
> > 
> > Actually, it is.  The caps rewrite had this specifically as one
> > of its goals.
> 
> Heh :) I guess that's not written down somewhere as one of the goals ?
> What exactly was the goal on this particular subject ?

"Goal" in the sense that the old caps system was limited to 5
simple types, and it was well-known at the time that we needed
more than that for negotiation.  Being limited to that system
led us to thinking a certain way about what data could be put
into caps, and that anything outside those 5 types would have
to be transmitted in another way, such as in events or
out-of-band buffers.  Thankfully, we're no longer limited in
that way, and elements toss around complex caps that serialize
to 3000-byte strings without concern.  For that reason, I have
no problem with elements putting buffers in caps, or even
inventing new types to put in caps, such as what Ronald is
doing for multi-channel audio.  Moreover, plugin writers should
not hesitate to put things in caps if it's the correct solution.

With the current caps and negotiation system, we still have a
lingering issue about the difference between normative and
informative parts of caps.  The normative parts are the fields
that are actually used in negotiation (such as height and width
in video/x-raw-int), and informative are fields that merely
convey information from an upstream element to downstream.
Often, these are optional, such as pixel_height and pixel_width
in video/x-raw-int.  "codec_data" is informative.  Of course,
if the informative part gets large, there's the tendency to
want to put it in a buffer and push it.



dave...