I may be missing something, but is there a good way of finding the start position of an ogg page in a bitstream? Pages have to start with 'OggS', but this could also turn up elsewhere in the bitstream, so is there a simple strategy using the libogg API to find out which ones are the start of pages? (Other than trying to decode from successive 'OggS' markers and noting when the resulting page changes.) Is this what ogg_sync_page_seek is for? I can't quite work out from the documentation what it does. http://xiph.org/ogg/doc/libogg/ogg_sync_pageseek.html Does the sequence go, get a page, find a nearby 'OggS', put data from that point into a sync_state and ask pageseek whether we're in the right place? -- imalone
On Thu, Dec 07, 2006 at 03:18:02PM +0000, Ian Malone wrote:> Pages have to start with 'OggS', but this could also turn > up elsewhere in the bitstream, so is there a simple strategy > using the libogg API to find out which ones are the start of > pages?Yes, 'OggS' can occur randomly. So to be more sure, you can parse the subsequent bytes as a header. Calculate the offset to the start of the next ogg page and see if the 'OggS' sequence occurs there as well. You can also verify the CRC for the page as an additional check. ogg_sync_pageseek() does the CRC check, and scans for the next 'OggS' if it does not succeed, so by calling it repeatedly you can scan through the stream finding pages. Note that ogg_sync_pageout does this automatically. You can check the return code to identify any holes or corrupt pages in the data stream. HTH, -r
Ralph Giles wrote:> On Thu, Dec 07, 2006 at 03:18:02PM +0000, Ian Malone wrote: > >> Pages have to start with 'OggS', but this could also turn >> up elsewhere in the bitstream, so is there a simple strategy >> using the libogg API to find out which ones are the start of >> pages? > > Yes, 'OggS' can occur randomly. So to be more sure, you can parse the > subsequent bytes as a header. Calculate the offset to the start of the > next ogg page and see if the 'OggS' sequence occurs there as well. You > can also verify the CRC for the page as an additional check. > > ogg_sync_pageseek() does the CRC check, and scans for the next 'OggS' if > it does not succeed, so by calling it repeatedly you can scan through > the stream finding pages. > > Note that ogg_sync_pageout does this automatically. You can check the > return code to identify any holes or corrupt pages in the data stream. >Thanks (and thanks also to Michael Smith). What I hadn't understood about ogg_sync_pageseek is that when returning n >= 0 it's acting like ogg_sync_pageout and n < 0 it's saying it read through -n more bytes of the sync buffer. The documentation for it makes perfect sense now. -- imalone