[gst-devel] addition of a buffer flag
Thomas Vander Stichele
thomas at apestaart.org
Wed May 19 02:31:01 CEST 2004
> > > 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 difference between ogg and every other container is that header data for
> codec wrapped in ogg is part of the codec while for every other container
> it's part of the container. So you obviously need knowledge about the
> codecs when you use ogg and only in that case. Blame the container
You don't need any more "knowledge about the codecs" than "this buffer
is header data". That doesn't mean anything needs to be codec-specific;
all it means is that a framework that wants to mux ogg needs some way of
having the codec-specific bits telling the ogg muxer what the headers
are. Nothing more, nothing less. This isn't codec-specific in any way.
Blaming the container designers is a strawman's argument. Ogg has some
very nice properties, and some that might be harder to implement. Just
like any container format. The Xiph guys did a nice job - if you can do
better, go right ahead. But if we are a streaming media framework,
implementing ogg correctly is one of our TODO's.
> > 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).
> It solves the issue of making sure you don't get any wrong connections. If
> you hope to just stream application/ogg you still need to fix typefind as
> I said above.
Your example mentioned something unrelated to streaming. AFAICT you
seem to assume the streaming element needs to know the mime type of what
it's streaming. I see no such requirement; in fact, it's very much
mimetype-independent, just like filesink.
I'll explain the complete problem separately in another mail, because I
still haven't received an alternative solution that works, and I want to
move forward. All this silly discussing about the merits of ogg vs.
others is unproductive.
Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If I wanted to fight, you could tell
by the being dead already
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/
More information about the gstreamer-devel