[ogg-dev] libogg++ release 0.1.1

[Elaine YueLien]

Hi Conrad,

Just a word of thanks to you and other authors at xiph for your work.
libogg++ is not meant to duplicate functionality that libogg and liboggz
already provide. Rather, it offers a different partitioning of logical
from transport, and is oriented to threaded execution.

On Wed, 2007-05-02 at 20:42 +0900, Conrad Parker wrote: 
> Just to make sure we're not using the same word to mean two different
> things, I'm not quite sure what you mean by "seeking without a
> metric". In liboggz I used the word "metric" to mean the function that
> converts a granulepos value to time, so that granulepos from different
> logical bitstreams can be compared. That kind of function is of course
> necessary to seek to a particular time point, or to merge streams. So
> perhaps you mean something different ...

libogg++ provides only forward seeking for each logical stream
relatively by packet increments, and absolutely by granule positions,
guaranteeing only that the sequence of the packets you get will be
greater than or equal to what you asked for. For that, you do not need a
metric. I am giving up more capable seeking at finer resolution to
decouple libogg++ from the codecs. A codec orders Transport to go
forward to a patch where the codec, with its greater knowledge, can zero
in on the precise point in the logical stream. 

Metrics ARE needed for merging multiple logical streams so their
sequential positions can be compared and the interleaving ordered
(demonstrated in the example rewriter). But the application, often a
codec, rather than libogg++, supplies the metrics and order function.

> Well, there's plenty of corner cases ... :-) I guess the simplest test
> of demux/mux is to make sure that your rewriter creates legal files
> (eg. files that pass oggz-validate) or if possible identical files.
> (oggz's examples/identity doesn't always create identical files as the
> page segmentation info is not passed through at the packet level; hogg
> rewrite does, but that involves quite a bit of overhead).

The example rewriter output passes oggz-validate, but is not identical
to the input. I realized that identity would require Transport to get
deep into the decoding, which I want to avoid. However, at least with
the Ogg Theora/Vorbis streams I tested, the loss of information due to
the gross granule positions does not seem to matter for playback, as
long as the page ordering function, bool
Transport::laterThan(Page&,Page&), is well-formed.

> 
> The simplest test of seeking is to jump around between a few locations
> in a file. Jumping to near the end (but not the very end) is a good
> test.
Will try that. 
>  You might want to try something similar to liboggz's
> tests/seek-stress on your ogg files.

libogg++ seek is limited, and passes the buck to the codecs ;)

> Generally, files with wierd
> paging (many packets broken across multiple pages) are good tests, and
> if you are doing theora frame seeking then files with keyframes buried
> inside pages are a good test also.
> 
> There are some useful test files in the mplayer archives:
> http://www1.mplayerhq.hu/MPlayer/samples/ogg/
> 
> cheers, and happy ogg hacking ...

Thanks for the info.

Elaine