Vorbis - Jun 2002 - packetno, granulepos, streaming and framing

Hi

While implementing OSS Ogg/Vorbis encoding and streaming using RTP/RTCP
for both unicast and multicast, I have come across a few issues I need
to clear out regarding the numbering of ogg_packets and their granulepos
value. Below are the result for two different scenarios.

<p>In the first scenario, ogg_packets are generated using

        a) vorbis_analysis_headerout()
        b) while true
                vorbis_analysis_buffer()
                vorbis_analysis_wrote()

        c) while true
                vorbis_analysis_blockout()
                vorbis_analysis()
                vorbis_bitrate_addblock()
                vorbis_bitrate_flushpacket()

This generates ogg_packets with packetno and granulepos values as described
below

Case #1 : Generated ogg_packets

Packet #	packetno	granulepos
---------------------------------------------
1		Large		0
2		Large		0
3		Large		0
4		3		0
5		4		576

In the second scenario, ogg_packets has additional been processed through

        a) ogg_stream_packetin()
        b) ogg_stream_pageout()
        c) saved into an .ogg file.
        d) read from an .ogg file
        e) ogg_stream_pagein()
        f) ogg_stream_packetout()

This produces ogg_packets with packetno and granulepos as listed below.

Case #2 : Generated ogg_packets

Packet #	packetno	granulepos
---------------------------------------------
1		0		0
2		1		-1
3		2		0
4		3		-1
5		4		-1
..................................
44		43		16320

Now here comes my first set of questions.

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.

  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() ?

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 ?

        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) ?

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 ?
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 ?

Kind regards

--PMM

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

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

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