[gst-devel] addition of a buffer flag

[Thomas Vander Stichele]

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 ?

> > > (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.

Ok, so in the ideal world, how would this be made human-readable ? It's
always just going to be a binary blob that only the codec can read. 
While we all can read width and height.
 
> > 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?

If you intentionally try to break something then of course it's going to
break.  If you make filesrc read from the middle of the file then the
decoder won't understand it either.

What is interesting is that it can be made to work easily by having
identity automatically always send the buffers marked as streamheaders
to each new pad, and then your use case would work with very little
extra code.

> 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".

With the drawback that the large blob is meaningless, not used for
negotation (but rather as a way to tell a downstream element something
about the stream but in a different format), and contains duplicate data
already exposed in the caps.

> Personally, I feel that the large the blob of bits, the less you
> can call it a "stream", but apparently codec writers disagree.

Heh, I'm more of the "the larger the blob of bits, the less you can call
it a caps property" school.

But really, if you guys only consider the caps solution as viable,
that's how I'll do it.

I'll outline some of the issues in a separate mail.

Thomas



Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Get a fella's motor running, let the tension
marinate a couple of days, then BAM !
You crown yourself the ice queen.
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/