[gst-devel] ogg and friends

[Thomas Vander Stichele]

Hi,

> On Wed, 19 May 2004, Thomas Vander Stichele wrote:
> > Others have in this thread said that the following should also work:
> > - having identity after oggmux
> >   ... oggmux ! identity ! filesink
> > - having oggmux ! fakesink, and at some point replace fakesink with
> > filesink
> 
> Actually, that was for rawvorbisenc ! fakesink and then replace
> fakesink with oggmux.

Ah, ok.  Well, for me it's still basically the same problem - I
understand why you make the distinction between codecs and muxers, but I
prefer trying to generalize the concept so that it works on both.

Ie, for me, trying to get rawvorbisenc ! fakesink to work is the same
technical problem as trying to get oggmux ! fakesink to work, so it'd be
nice to figure out a solution common to the two cases.

> > Suppose we use caps the way Ronald suggested.  Here's what will happen.
> > - vorbisenc will create three packets.  These three packets are put into
> > one caps value, as a GList of buffers (the packets really need to be
> > separate).
> 
> I'd put them in three separate properties: codec_data_bos,
> codec_data_setup and codec_data_comment. GList is not serializeable
> (yet?).

IIRC it's automatically serializable - lists of GValues Just Work.  I
don't think we have special code in the caps stuff for lists of
ints/floats/doubles either.  I'll try however to make sure.

The reason I want to avoid codec-specific ones is two-fold;
- I want to keep as much as possible codec-specific stuff out of oggmux
when it doesn't bring any real benefit
- I want to make the mechanism to solve this issue as similar as
possible for vorbisenc/theoraenc as oggmux, since it's basically the
same problem: "these buffers should go first for a new consumer".


> Can you explain the clarity and consistency. 

Like I said, for me it makes more sense that the general problem of "how
could an element export the fact that some strings of bytes ought to be
sent first before the data makes sense" is solved in a generic way,
irrespective of the fact that the element is a muxer or codec.

So, I would find it more consistent to use buffers-in-caps in a generic
way (even though I'm not particularly fond of the idea of using
buffers-in-caps, but I'm following your lead), both for muxers and
codecs, than to use "technique A" for codecs and "technique B" for
muxers.


> Proposal mostly looks good; when can I try out tcpserversink? :).

Now that the data protocol is in, I can move it to gst-plugins, together
with the old tcp plugins.  So, hopefully today.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
One day we will live together
Then life will be better
I have it here, yeah, in my mind
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/