[ogg-dev] libogg++ seeking w/o metric

Elaine YueLien et at ihear.com
Wed Jan 17 14:13:27 PST 2007

Hi all,

I started out looking for a multi-stream format, which led naturally to
Ogg. I have been studying your web sites and code, and subscribed to
this list. Eventually we would like to have a multi-stream codec which
would have a discontinuous text component. In the meantime, I am working
on running the transport/en- de-capsulation on a separate thread, and
possibly with each codec on a separate thread also. Our development
language is C++, which is actually handy for protocol stacking. One
thing led to another, and I find myself writing a libogg++. It is as
codec-agnostic as I can understand the Ogg format. So we hope it may be
useful to others. There is some code at this point, and we may try to
have it hosted at nongnu. 

libogg++ would be like libogg and liboggz in one piece, but without the
functionality dealing with metrics, etc. (this could be added via class
derivation by codecs). I am looking at whether seeking is meaningful
with just the granule position ordering, without continuity and metric.
It seems possible, and fits the stated policy in liboggz[below], but
liboggz itself requires otherwise. Such seeking may be of low
resolution, and not as efficient, but tolerable if used normally for a
few forward seeks per stream. It would be up to the codecs to buffer and

>  * - Ogg is not a non-linear format. ... It is a media transport format
>  *   designed to do nothing more than deliver content, in a stream, and
>  *   have all the pieces arrive on time and in sync.
>  * - The Ogg layer does not know the specifics of the codec data it's
>  *   multiplexing into a stream. It knows nothing beyond 'Oooo, packets!',
>  *   that the packets belong to different buckets, that the packets go in
>  *   order, and that packets have position markers. Ogg does not even have
>  *   a concept of 'time'; it only knows about the sequentially increasing,
>  *   unitless position markers. It is up to higher layers which have
>  *   access to the codec APIs to assign and convert units of framing or
>  *   time.

TIA for some enlightenment on this.

More information about the ogg-dev mailing list