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 refine.> * - 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. Elaine
Hi, Several months ago, I asked a question about seeking without a metric. You can find one answer in this beta release, demonstrated in the example program multiThreadSeek. There is also an example demuxer, and a rewriter. Downloads and checkouts are available at http://savannah.nongnu.org/projects/liboggpp . Please see the news items there for directions. I will be using libogg++ for multi-stream codecs, and hope others can use it for a similar purpose. Currently, I have access to only a limited number of platforms. I have tested it on a limited number of ogg streams of Theora/Vorbis only. I have not thoroughly checked out boundary cases. So I welcome any input from people on this list. Elaine
On 02/05/07, Elaine YueLien <et@ihear.com> wrote:> Hi, > > Several months ago, I asked a question about seeking without a metric. > You can find one answer in this beta release, demonstrated in the > example program multiThreadSeek. There is also an example demuxer, and a > rewriter.Hi Elaine, congratulations :-) that's a nicely designed API you've got there. 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 ...> Currently, I have access to only a limited number of platforms. I have > tested it on a limited number of ogg streams of Theora/Vorbis only. I > have not thoroughly checked out boundary cases. So I welcome any input > from people on this list.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 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. You might want to try something similar to liboggz's tests/seek-stress on your ogg files. 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 ... Conrad.