[gst-devel] addition of a buffer flag

[Wim Taymans]

On Wed, 2004-05-12 at 14:06 -0700, 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.
> 

Is it stored as a buffer or as a string in the caps structure?

> > > (e.g. caps: video/x-theora,width=(int)384,height=(int)288,
> > > codec_data=(buffer)fe56ba3c810c).
> > 
> > Ok, so I can read and interpret those caps, *except* for the
> > codec_data.  What does it tell me ?
> 
> It tells you that we'd love to provide that as human-readable data,
> but in the interest of expediency in 0.8, we don't.
> 
We could ask a plugin, one that can handle the caps, to transform the
caps into a readable format if you want.

> 
> > > Of course,I'm open to suggestions from others if they see different
> > > (better) solutions to the problem drawn above.
> > 
> > Tell me how the buffer flag approach fails for you.
> 
>   ... ! oggdemux ! identity ! blah ...
> 
> Play for 10 seconds, then disconnect identity and blah, and connect
> identity to vorbisdec.  How does vorbisdec get the header packets?

And how does oggdemux know what packets are codec data so that it can
put these as blobs in the caps? Or is de codec responsible for updating
the caps blob? Your identity example would still fail.. Maybe we can
assume that as long as the granule pos in the ogg page header remains
constant, we are dealing with headers?

Not that the blob data is a bad idea per se.. it somehow describes the
buffer format you are sending through the pads.

> 
> We've always known that out-of-band data is required to properly
> parse a format.  For some streams, it's called "height" and "width".
> For others, it's a large blob of bits that we call "codec_data".
> 
> Personally, I feel that the large the blob of bits, the less you
> can call it a "stream", but apparently codec writers disagree.
> 
> 
> 
> dave...
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
> higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>