[gst-devel] addition of a buffer flag

[Thomas Vander Stichele]

On Thu, 2004-05-13 at 13:22, Benjamin Otte wrote:
> Here's why you can't make a codec agnostic streaming element that just
> streams partial streams: filesrc
> If you had a codec agnostic streaming element stream_element, filesrc !
> stream_element would work.

Of course nobody expects a filesrc and a streamer element to be able to
figure out everything on their own.  That is not the point up for
discussion.

The point up for discussion is where to abstract away the knowledge of
the format and codecs.

I personally think that:

a) GStreamer SHOULD be able to do network streaming on its own from
elements.  That includes at the very least stuff like raw data streaming
(e.g. netcat), some GStreamer-specific streaming (e.g. the data protocol
that turned out fine), and some standard streaming protocols (.e.g.
http: which is really easy to implement, and maybe rtp which might be
harder to implement correctly and is more tied to the codec).

b) Streaming elements SHOULD NOT need codec- or format-specific data
unless the streaming tranport imposes this.  For example, RTP has
specific codec-dependant ways of handling the stream, so obviously it's
fine for it to have codec-specific knowledge.  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.

In your case the solution is trivial; an oggparser element inbetween can
properly mark buffers before sending them to the server.  Internally it
can either be done by an oggparser element that knows about the codecs
inside, or by demuxing internally to mark the buffers that contain
header info, and then just muxing them back in the same order as they
were in the incoming muxed stream.  It doesn't need to know about
timestamps calculated from ogg granules since the original stream coming
into the oggparser was already properly muxed.

>  Obviously there is no way to make filesrc set
> buffer flags the way you want them. I therefore believe your idea does not
> work. If you provide me with a solution that makes filesrc !
> stream_element work with clients connecting late for all streams (or at
> least all streams we can typefind), I'll believe in codec agnostic servers
> again. 

> As it stands now, I believe you need some codec specific elements

No, you need format-specific elements.  Which is trivially obvious.  But
different from codec-specific :)

> in between that prepare the data for your server element. And if you
> already have that, you can make those elements output data in
> application/stream-element-data and use custom events like
> "header-starts-here" and "real-stream-starts-here" without needing any
> changes in the core.

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

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Come on baby take a walk with me honey
Tell me who do you love
Who do you love
* 
I pulled myself together
It tore us apart
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/