[gst-devel] addition of a buffer flag

[Benjamin Otte]

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

Or in short: You want to require flags being set in your element while
there's no way to provide those flags in a codec agnostic way.

Benjamin


On Wed, 12 May 2004, Thomas Vander Stichele wrote:

> Hi,
>
> for streaming purposes, we need a way for the network elements to know
> what part of the beginning of a data stream are to be considered
> "headers" and what is the raw data.  This isn't necessary for every
> format, but it is a requirement for Ogg.
>
> As an example, here's what needs to be done to stream Ogg/Theora+Vorbis.
>
> a) ogg page 1 contains a header for the vorbis stream
> b) ogg page 2 contains a header for the theora stream
> c) ogg page 3 contains two extra headers for the vorbis stream
> d) ogg page 4 contains two extra headers for the theora stream
> e) ogg page 5 is the first page containing data packets
>
> Every new client that picks up in the middle of the stream needs to
> first receive the first four ogg pages.  (Contrast with an mp3 stream,
> where you can pick in any time since each mp3 frame is preceded by a
> header, or with mpeg-video where the codec can choose to repeatedly send
> header info every few seconds).
>
> We discussed the various options.  We wanted to attach the information
> that some buffers represent a reusable header to the stream, instead of
> signalling it out-of-band through signals/deep_notify and property
> setting.
>
> So the choice is between events or buffer flags.  I prefer a buffer flag
> because it's the cleanest implementation:
> - the vorbis codec would generate the three packets of header info
> marked with this flag
> - same for theora
> - ogg muxer assembles pages with this flag
> - network streaming element looks at incoming flags, and puts all
> incoming buffers with this flag on an internal queue
> - every new connection to this element first receives the stored headers
> before picking in anywhere in the data stream.
>
> So, can I go ahead and add a _HEADER buffer flag for this ?
>
> Thomas
>
> Dave/Dina : future TV today ! - http://www.davedina.org/
> <-*- thomas (dot) apestaart (dot) org -*->
> Won't you come a
> little closer
> close enough so
> I can smell you
> <-*- thomas (at) apestaart (dot) org -*->
> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
> higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>