[gst-devel] addition of a buffer flag

[Thomas Vander Stichele]

Hi,


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

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.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Buffy ...
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/