[Vorbis-dev] Fwd: Newbie q: decoupling vorbis from ogg

Michael Smith msmith at xiph.org
Thu Sep 15 02:47:25 PDT 2005


> Yes, the work will be open source.  It will recycle parts of the
> qtcomponents.sf.net project, providing new AudioCodec components to
> support Quicktime 7 and beyond.  I suppose we should keep the project
> there if possible, but we haven't contacted the maintainers of that
> project yet to discuss it.  We'll have to wait and see, but we may
> take you up on the offer for repository space.

Ok. Well, let us know (email, or come see us in #vorbis on
irc.freenode.net) if you do want to our resources (personally, I hate
sourceforge with a passion :-)
> 
> It sounds like maybe you're saying this is an internal dependency.  Is
> that correct?  That's fine, I'm not too concerned about what happens
> behind the scenes and I've got no problem linking libogg into the
> codec.  It was really just the apparent conceptual dependency in the
> Vorbis API that confused me.

Yeah, just an internal dependency on some of the code that happens to
live in libogg.

> 
> Well, if you insist...  ;^)  So looking at the decoder example, it
> looks like if I have an ogg stream handy I can basically do this
> (ignoring error checking for the moment):
>    ogg_stream_pagein(&oggstreamstate,&oggpage);
>    ogg_stream_packetout(&oggstreamstate,&oggpacket);
> 
> and now (assuming it worked) I have a nice ogg_packet to feed to
> vorbis_synthesis(...).  If, on the other hand, I'm completely
> disconnected from the container format and just have a buffer
> containing one or more raw vorbis packets (as I believe will be the
> case in the AudioCodec) is there a comparably simple way to get the
> ogg_packet struct filled out?  Or perhaps this is where the bitpacker
> ceases to be an internal dependency and I have to start reading the
> vorbis spec closely... :-/

So, let's start by looking at the ogg_packet struct (with comments
removed so I don't have to paste in quite so much)

typedef struct {
  unsigned char *packet;
  long  bytes;
  long  b_o_s;
  long  e_o_s;
  ogg_int64_t  granulepos;
  ogg_int64_t  packetno;
} ogg_packet;

'packet' and 'bytes' are simple - a pointer to the actual data buffer,
and the length of the buffer.

b_o_s and e_o_s are flags set on the first and last packet in the
stream respectively. You'll probably need to propagate this
information from some other part of the quicktime system somehow.

packetno is just a sequence number - you should get this from the
original data as well (it's needed so that libvorbis can know to throw
away some internal buffers if a packet is missed (this happens, for
instance, if some data was corrupted, or was simply missing).

granulepos is primarily used for seeking (presumably done in whatever
handles the ogg layer in quicktime), but needs to get propagated to
the vorbis decoder for correct handling of beginning and end of
stream. It won't normally be set on every packet (ogg doesn't provide
per-packet granulepos values, only per page. This is sufficient for
vorbis).

Mike


More information about the Vorbis-dev mailing list