[vorbis] packetno, granulepos, streaming and framing

[Michael Smith]

>
>In the first scenario (case #1) the packetno
>variable for the 3 first packets are rather large (or uninitialized), but
>for case #2, the variable is 0,1 and 2 for packet # 1, 2 and 3.

Packetno is internal (i.e. it does not exist in the bitstream in any form),
and is really only needed on decode side (for consistency, it mostly gets
set correctly on encode as well - apparently not for header packets, though).
You shouldn't care about it on encode side, basically.

<p>>
>  a) Why is that the case ?
>  b) Is that intended ?
>  c) Can I safely set the packetno in case #1 to 0,1 and 2 for the 3 first
>     packets before submitting them to a framer like ogg_stream_packetin() ?

You can safely do this. I believe it is ignored.

>
>Here comes my second set of questions.
>
>	a) In the second scenario (case #2), the granulepos value of the
>	second packet (the comnment) is set to -1. Shouldn't it be 0 ?

No. granulepos exists at the ogg lever (in the framing information). On
encode, correct granulepos is set on every packet - this is neccesary so
that the framer (ogg) can set it correctly.

On decode, it is difficult (and unneccesary) to set granulepos on any
packet which is not the final packet in the page (specifically, it is the
last packet to _end_ on that page). Although it is possible to calculate
it, this requires information from inside the vorbis packet - this breaks
the seperation between the two. Since the decoder doesn't need this 
information (there are some special cases at beginning/end of stream, but
this still doesn't require granulepos to be set on every packet. See
doc/vorbis-clip.txt for full details if you need to know).

<p>>
>	b) Also in case #2, the granulepos for packet # 4-43 is -1 while
>	packet #44 is 16320. Shouldn't the granulepos for the packets
>	between packet # 4 and 44 have a more reasonable values like
>	0, 576, 1600 etc. (or something similar) ?

See above. These are generated on encode but are not needed on decode. 

>
>I assume the granulepos value for packet #44 is the granulepos value
>for the whole pacge that packet # 4-44 was part of. Is that correct ?

Yes.

>Not having access to the exact granulepos for the individual ogg_packets
>makes it really really difficult to fit into existing OSS streaming
>software. Is it possible to chaneg the code of ogg_stream_packetout()
>so the ogg_packets will be assigned the exact granulepos rather than
>the granulepos of the page they were once framed into ?

As explained above, no. Calculating granulepos per-packet is fairly
complex, and depends on the contents of the vorbis packets. You can
certainly calculate it yourself externally, but libogg cannot do so.

vcut needs to do this for various reasons, so feel free to dig around
in there for code examples (sorry, the code's messy and a bit old.)
Short version: to calculate the granulepos of packet N, you need the
blocksize of packet N-1 and packet N. You can count backwards from the
known value for the final packet in the page, then.

>PS, still don't see May and half of June Vorbis mail archive. Is that
>the intention ?

Problem with the archiver. Fixed now - not sure if the dropped stuff
is going to be retrieved or not. 

<p>Michael

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