tool to add skeleton (was Re: [Vorbis-dev] Re: [ogg-dev] Peer review draft for the new)

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Mon Oct 22 16:47:54 PDT 2007


On 10/23/07, Ian Malone <ibmalone at gmail.com> wrote:
> Ivo Emanuel Gonçalves wrote:
> > On 10/19/07, Aaron Colwell <acolwell at real.com> wrote:
> >> I'm assuming your referring to the audio/vorbis-config type.
> >
> > Yes.
> >
> >> Xiph's philosophy of allowing unique
> >> codebooks for every encode and Ogg's chaining feature make this necessary.
> >
> > I see.
> >
> > I wonder; would it be possible to change this behavior on Vorbis RTP
> > as it's Oggless?  Or would that make for an impossible implementation
> > so drastic would be the change?
> >
>
> This is a codec issue; you would have to specify a subset of Vorbis
> to be allowed with fixed codebooks or disallow chaining.  Making a
> specific Vorbis subset is pretty drastic.  Disallowing chaining is
> apparently part of the Vorbis RTP proposal
> <http://wiki.xiph.org/index.php/VorbisRTP>, but you still need to
> have the code-books to start decoding (it's just you only need one
> set).  I don't know enough about RTP to say the out-of-band
> mechanism is needed for that but reading the IETF draft it seems
> to be preferred for good reasons (delivery not guaranteed for
> RTP streams).

Vorbis is about the only codec in the world that doesn't have fixed
code-books (or so I was being told :). This is the reason why it was
necessary to have an out-of-band mechanism over a reliable connection
to transport the codebooks to the client over RTP. I remember the
lengthy discussion at IETF about this issues way back at the only IETF
meeting that I ever attended in person. The current solution is the
only way that was acceptable.

Also: this has nothing to do with having an Ogg container around the
data or not - this is RTP, which has its own framing mechanism.

Cheers,
Silvia.


More information about the Vorbis-dev mailing list