[gst-devel] addition of a buffer flag

Thomas Vander Stichele thomas at apestaart.org
Fri May 14 07:31:07 CEST 2004


On Fri, 2004-05-14 at 15:50, Benjamin Otte wrote:
> Quoting Thomas Vander Stichele <thomas at apestaart.org>:
> 
> > OTOH, Ogg does not care
> > about the data you are wrapping in it, so the streamer should be able to
> > get all hints it needs through GStreamer, without being ogg-specific.
> > 
> There is the one thing where you are irritated. Ogg itself doesn't care very 
> much, but the data contained in ogg does. Raw vorbis (or theora) very much 
> cares about setup data being resent.

Yes, of course.  But that still doesn't mean the streamer needs to have
ogg-specific knowledge.  It also doesn't mean ogg needs codec-specific
knowledge.

All that is needed is a way for
- Theora and Vorbis to tell the ogg muxer how it wants its buffers
wrapped
- any other codec to tell the ogg muxer how it would like to be wrapped
(it is the CODEC that specifies how it wants to use the CONTAINER
format)
- the ogg muxer, like any other muxer, tell the streaming element how
its buffers should be put on the wire.

>  Just like all the other _containers_.
> The difference between ogg and every other container is that header data for 
> ogg codec is part of the codec while for every other container it's part of the 
> container. So you obviously need knowledge about the codecs only if you use 
> ogg. Blame the container designers.

I'm not sure I'm understanding what you're saying correctly. I assume
that with "ogg codec" you mean "codec intended to be wrapped in ogg"
(like theora and vorbis are).  But then I still can't parse the
sentence, because the rest of it doesn't apply then.  What did you mean
here ?

> > The point I'm making is that whatever mechanism is chosen, it should be
> > a core mechanism, since a) the project is called GStreamer so we want it
> > to stream and b) this is a necessity for all formats except MPEG.
> > 
> > The reason it wasn't seen as a necessity before is because no one ever
> > did multiclient live streaming with something beside MPEG from GStreamer
> > (that's a mouthful).
> > 
> What you want is a magic solution that just takes ANY caps and magically 
> streams them with everything already somehow setup by some magic flags. You 
> won't get that I'm afraid. What you can already get quite easily though is a 
> way to use a general purpose streamer element that gets a custom mime type (say 
> application/x-fluendo-server) and loads of elements per format that transform 
> application/ogg or video/quicktime to application/x-fluendo-server. All of that 
> would work right now without changing anything in the current GStreamer core or 
> elements.

I'm not sure how the additional level of indirection solves the same
basic issue, namely "marking some buffers for retransmission to every
new connection).


> PS: I'm still not sure if it wouldn't be nicer to have elements similar to tee 
> that do the splitting. That way your server pipeline would look like this:
>                   / connection1
> source - splitter - connection2
>                   \ connection3
> Whenever you get a new connection you setup a new connection element and 
> connect it to the splitter who would then know how to setup the current format 
> correctly for streaming. This would of course not work in gst-launch but would 
> be able to construct headers on demand which might be useful if you need to 
> send different headers to different clients.

I don't think it's wise to create 1000 * 3 elements just because you
happen to have 1000 listeners connected, esp. when there's no need to. 
While your application also needs to work in GStreamer, the case where
you have one element serving multiple clients is also something that
should work.  The decision shouldn't be made by GStreamer; GStreamer
should support both methodologies and make sure that it has mechanisms
present to provide these elements what they need.

While I'd like to wish the problem away just as easily by saying "oh,
just create 124910 Gst elements" and then happily ignore the fact that
gstreamer cannot create as many elements as needed, that's not how it
should be done in practice.

If an element can be written easily to serve all these clients, there's
no reason to force an app writer to make it create one for each client.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
To all the clumsy lovers who never seem to get it right
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/






More information about the gstreamer-devel mailing list