Vorbis dev - Jun 2005 - ogg_sync_pageout

It seems to me that running ogg_sync_pageout doesn't automatically advance
the page. This is good if you haven't worked with the given page, makes
coding somewhat easier. However, when does a page advance. Is it after a
call to ogg_stream_pagein?

On a side note, I need to do seeking on top of libvorbis, I'd love to use
vorbisfile but sadly I can't. Is there a reasonable way to
"rewind" without
calling various resets and returning to the beginning of the file? It looks
like I'd have to call:

Ogg_sync_reset
Vorbis_synthesis_restart

Would you also need to call ogg_sync_destroy, and pretty much start over? Or
is there a way you can feed it new data without destroying the buffer?

Thanks a ton,
Christopher

On Wed, Jun 22, 2005 at 09:32:52AM -0500, Christopher Egner wrote:
> It seems to me that running ogg_sync_pageout doesn't automatically
advance
> the page. This is good if you haven't worked with the given page, makes
> coding somewhat easier. However, when does a page advance. Is it after a
> call to ogg_stream_pagein?
Can you elaborate on what you mean by 'advance the page'? 
ogg_sync_pageout() fills out the pointers in the ogg_page struct to 
reference data that's been passed in and marked with ogg_sync_wrote(). I 
suppose conceptually in libogg ownership of that data passes with the 
ogg_page struct to the caller, and then back into libogg only when you 
call ogg_stream_pagein(). 

Is that what you mean? Another call to ogg_sync_pageout() could return 
another page if there's more data buffered inside the ogg_sync struct.
> Would you also need to call ogg_sync_destroy, and pretty much start over?
Or
> is there a way you can feed it new data without destroying the buffer?
You don't need to call ogg_sync_destroy, you can just start feeding it 
data from the seek point and it will find the next page boundary and 
continue handing you new pages from there.

If you've passed a chain boundary you'll need to seek for the headers 
and tear down and re-initialize your decoder if they're different, of 
course.

FWIW,
 -r
> 
> Thanks a ton,
> Christopher
> 
> 
> _______________________________________________
> Vorbis-dev mailing list
> Vorbis-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/vorbis-dev

> Can you elaborate on what you mean by 'advance the page'?
> ogg_sync_pageout() fills out the pointers in the ogg_page struct to
> reference data that's been passed in and marked with ogg_sync_wrote().
I
> suppose conceptually in libogg ownership of that data passes with the
> ogg_page struct to the caller, and then back into libogg only when you
> call ogg_stream_pagein().
> 
> Is that what you mean? Another call to ogg_sync_pageout() could return
> another page if there's more data buffered inside the ogg_sync struct.
I was looking at the decoder example (decoder_example.c in the ogg vorbis
SDK) and thought I'd noticed a problem. Line 94 has the first call to
pageout. This should be the first page, and only include the vorbis header
(presuming that it is in fact a strict oggvorbis file). Then on line 149,
another call to pageout is made. This time, we should have the second page
(since all the data in the first has been handled). This may be called once,
maybe twice. Depending on how the file was encoded. Where the problem (I
thought) is on line 207. We make another call to pageout without checking to
see if we have valid packets. It is possible, from my understanding, to
encode pcm data in that second page (it doesn't seem to be normal with the
reference encoder, but it should be theoretically possible).

Like I said, I THOUGHT there was a problem, but it didn't make sense that
such a simple example would be flawed for so long without anyone noticing
(the amount of pcm data would be negligible, but still it doesn't seem
right). So I ran some tests on ogg_sync_pageout. You can run it a million
times, and it returns the same ptrs. I assume that you have to make a call
to ogg_stream_pagein for ogg_sync_pageout to scan to the next page. Perhaps
something was wrong in my test though.
> 
> You don't need to call ogg_sync_destroy, you can just start feeding it
> data from the seek point and it will find the next page boundary and
> continue handing you new pages from there.
Is this after a call to ogg_sync_reset?
> If you've passed a chain boundary you'll need to seek for the
headers
> and tear down and re-initialize your decoder if they're different, of
> course.
So as long as I have stream serial numbers, I don't need to concern myself
with any changes to the vorbis stuff at all? Or do I still need a
vorbis_synthesis_reset to get rid of old left hand window data?

Thanks Ralph, I need to send you a case of caffeinated beverages or
something...
Christopher