Re: Ogg Vorbis assignment


Good work.  This email is correct in my estimation.  I've added one more bit at the bottom..

As I recall, you discussed Ogg segments, pages and packets in the lecture, and how while it wasn't in the notes, you'd upload your PowerPoint slides containing these points... could you do so?  should do it.

Sequence of packet within current page (size, bytes)
0 (768) 1 (510) 0 (34) 0 (509) 0 (863) 1 (256) 2 (17)
Segment size, bytes
255 255 255 3 255 255 0 34 255 254 255 255 255 98 255 1 17
1 2 3 4

To zoom in on page 1:
'Page segments' field: 5 <-- means that the page contains 5 segments, and that the following page segment table is 5 bytes long.
'Segment table': 255, 255, 255, 3, 255 <-- we can see here that there is the end of one packet, and the beginning of another packet. this segment table describes the sizes of the segments - it doesn't contain the segments themselves. That comes next, in the payload.
Payload: [A complete packet of 768 bytes] [the first 255 bytes of a second packet]

As the last value in the segment table = 255, we know that this page contains only part of the second packet (packet #1, counting from 0). That is, we should save this segment away, and we'll find the rest of the packet's segments in the next page. Or at least, more of the packet's segments.

This is all good.  But here is a bit more detail to check everyone is clear.

The diagram above shows a total of 4 Ogg Pages - these are the individual blocks of data which are pulled off the server.  Ogg Pages are variable size up to a maximum value. 

The 4 Ogg Pages in the diagram contain data for 6 Packets - as Duncan correctly says, each packet is a unit of data to be sent to the Vorbis decoder.

The granule number is given per Ogg Page so in this example we could say the granules of each of the four pages are 1,2,3,4 for arguments sake - there is no guarantee however that the granule number is continuous - it will jump by uneven amounts between pages. It will also wrap occasionally but you can ignore that for this practical if you want.  

So, assuming granule numbers 1,2,3,4 for the four ogg pages then I would number the packets as follows: 1/0,1/1,2/0,3/0,4/0,4/1,4/2   - using the notation granule/packet number

Note that the packet I labelled 1/1 is started in page 1 and finished in page 2, and the packet I labelled 2/0 is actually the second block of data you'll see from page 2 since the first block is the remainder of packet 1/1.  

Merging with a later email now...

> And I'm guessing it's safe to assume that the first time _PacketReceiver.packetData() is called with a particular granulePosition x, it's guaranteed that this is the first bit of packet data in a page? i.e. can we use granule position as the page ID, and is the first 
> thing to come along with granule x the beginning of the page?

Yes and no.  packetData gets called for every new page and every new packet.  So in the diagram above it would get called at the start of page 1 with all the data of page 1/0.  Then it would get called again in the middle of page 1 with the first segment of data of packet 1/1.  Then it gets called again with the start of page 2 with the remainder of the segments for packet 1/1.  Then it gets called again from the middle of page 2 with all of the data for packet 2/0 which happens to coincide with the end of the page too.

So, from the above, you'll see the granule position change for the second part of the packet 1/1 because the granule position of the page that this data is coming from is 2 but you are actually building a packet with granule position 1 still.

> Bear in mind that I'm not nearly done with the assignment yet... so I'd hold on until The Authority gives the nod that I'm not talking nonsense...!

The Authority nods.....

This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.