[gst-devel] ogg and friends

[Thomas Vander Stichele]

On Wed, 2004-05-19 at 23:57, David Schleef wrote:
> On Wed, May 19, 2004 at 07:38:56PM +0200, Thomas Vander Stichele wrote:
> > - encoding and muxing an "Ogg A/V" stream and create a live TCP stream:
> >   ... oggmux ! tcpserversink
> >   clients can connect to this server at any given point in time, and
> > when they do, tcpserversink should give them all the "bos pages" and
> > "additional header pages" before serving them encoded data.
> 
> I have long suspected that you were trying to do this, but I never
> brought it up because it sounded so dumb.

You wouldn't have had to suspect if you read the mails I sent :) I never
said anything else than "I want to make ogg streaming to multiple
clients work directly from GStreamer."  But I respect your brutal
honesty nonetheless.

>   In this case, you are
> making tcpserversink into a "post-muxer", which takes an already
> muxed ogg stream and _remuxes_ it to make the first data packet
> going out the tcp socket correspond to the current time.

remuxes ? No such thing is being done.  All that is being done is that
the starting pages are sent to each new client.  It is the same thing
that the tcpserversink I'm about to commit already does for sending caps
to new clients using the data protocol.

>   This is
> fine if you want to write it that way, but it only works with OGG.
> Other stream formats (MPEG, QT, etc) don't work in a way that you
> can just chop some bytes out of the center

No bytes are being chopped out of the center.  What do you mean exactly
?
>  and still get a workable
> stream.

For MPEG it works by default already - ie, this mechanism doesn't get in
the way of that, and you will be able to use this tcpserversink, or a
later httpserversink, with both Ogg and MPEG, as well as for stuff like
mp3, multipart jpeg, and others.

I'd love to comment on QT, ASF/WMV, and RM, but at this point, I don't
know enough about how they actually do live streaming, so why don't you
fill us in so we can take it into account ?

>   And it's important to remember that you're making an element
> that does two fundamental tasks -- remuxing oggs streams and sending
> data over a tcp socket.

It doesn't remux ogg streams.  All it does is send data over a tcp
socket.  It just sends a bunch of data to each new client first (well,
I'd like it to if you'd let me) before letting it pick up the live
stream.
 
> So I would suggest moving to a model where you have a true oggremux
> element, and a simple tcpserversink.  The oggremux element needs
> only to know how to find header packets, and how to seek to the
> appropriate place in the stream.  For bonus points, you can make
> the oggremux element have lots of request source pads, and serve
> potentially lots of remuxed streams off one input stream.

I guess this means you propose to have "1 tcpserversink for each
client", which you tried to pitch before, but as I said, that's not a
very realistic plan at all, esp. given that a serversink element scales
*a lot* better to multiple clients than GStreamer does :)

Look, it's pretty simple, I don't see why you're making it hard just
because someone wants to do something with GStreamer that you haven't
had the need for before.  All of you can slag ogg all you want for its
drawbacks (which, I'm sorry to say, are design choices, not mistakes -
you all just don't happen to like those design choices).

But ogg got one thing at least very right; the fact that you can just
take the header pages for a stream, store them, and serve them as they
are to each new client.  This makes it *very easy* to serve ogg streams
through *any* protocol using *very scalable* code.

If you think supporting ogg, with its advantages, correctly in
GStreamer, is not something we should do, then please change the name of
your local copy to GLocalFileManipulator instead.  Meanwhile, I'll just
keep working on making it possible to use GStreamer to stream.

OTOH, I think I'll just switch over to the "don't discuss, just code and
commit" development model.  There's no good reason for me to try and
stick to it, it just wastes my time.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Surprise sometimes
will come around
I will surprise you sometime
I'll come around
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/