search for: repaginate

...tuff, I figure there's a small change that we need to make to the way headers are done. Headers should be page aligned. Ie, when the header ends, the current page in the ogg stream should end, so that vorbis packets start in a fresh page. This is necessary because i don't want to have to repaginate the entire stream because I have to cache a header to be replayed to clients. This is mostly just a note to monty :) jack. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-...

Monty, Thanks for writing up your thoughts on the mux design (ogg/doc/ogg-multiplex.html in cvs) Now that there's something to argue with, I'd like to comment. To recap, the documented proposal is that we make two categories of streams within the OggFile multiplexing library. Pages are sorted chronologically by the timestamp equivalent of their granulepos fields. Normal data like

dear list, i am trying to write a small program which reads an ogg file and writes it to another ogg file (and changes serial number, granulepos etc on the fly). reading the ogg file is ok (ogg_sync_pageout, ogg_stream_pagein, ogg_stream_packetout). but writing the file doesn't work - the granulepos and page structures don't match with the original file. here's what i am doing.

...start after seek still requires new code; that part of skeleton doesn't work. Muxing overhead for one-page-per-packet is excessive for small packets. 3% (vs 0.7%) for 230 kbps video, up to 10% for 50 kbps. This isn't going to work for cell phone video. Many Ogg tools assume they can repaginate, and probably won't get the one-page-per-packet stuff right. This leads to the usual argument that the demuxer has to be able to reconstruct the timestamps anyway, if it's going to be liberal in what it accepts, so the demuxer isn't actually simpler. The granulepos will no long...