Vorbis dev - Apr 2002 - Howto use ogg_page_granulepos for exact playback position?

I have the following problem.
Be an encoder application (station) and a decoder application (receiver).
If I feed the vorbis encoder with 'n' pcm samples in the station I want
to
know how many pcm samples will be decoded in the receiver if I feed the
decoder with the encoded output. The ogg_page_granulepos is right for the
purpose?

I read the documentation about the ogg_page_granulepos function. There is
the following:
"Returns the exact granular position of the packet data contained at the
end
of this page.
This is useful for tracking location when seeking or decoding.
For example, in audio codecs this position is the pcm sample number and in
video this is the frame number."

I don't understand the meaning of 'exact granular position of the packet
data contained at the end of this page'.

While I feed the encoder and no page boundary were found between two feeding
cycles (there is no effective encoded output), the ogg_page_granulepos is
increasing continuously. How I understand ogg_page_granulepos is not the
right function for me.

Does anybody know the solution ?

Tibor

<p>--- >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-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Tuesday, April 16, 2002, at 09:33 AM, Tibor Kiss wrote:
> I don't understand the meaning of 'exact granular position of the
packet
> data contained at the end of this page'.
Perhaps the version in the ogg framing spec is more clear:

  The  position specified is the total samples encoded after including all
  packets finished on this page (packets begun on this page but
  continuing on to thenext page do not count).  The rationale here is
  that the position specified in the frame header of the last page
  tells how long the PCM data coded by the bitstream is.  A truncated
  stream will still return the proper number of samples that can be
  decoded fully.

<p>> While I feed the encoder and no page boundary were found between
two 
> feeding
> cycles (there is no effective encoded output), the ogg_page_granulepos 
> is
> increasing continuously. How I understand ogg_page_granulepos is not the
> right function for me.
So what gets written as the granulepos when the page is flushed is the 
last sample that can be fully decoded using that page. So as packets are 
added to the page buffer, of course this number increased, and indeed 
that's how it's passed in in the packet structure. Thus it tells you how
many samples have been encoded assuming you flush the page now.

Is that what you were asking?

  -r

<p>--- >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-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.