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?
This email started off by me trying to wrap sensible questions around my confusion and, hopefully, has evolved into an answer worth sharing, based off what I've reconstituted from memory plus http://www.xiph.org/vorbis/doc/framing.html (either I'm being thick or this page could do a better job of describing the relationship between pages and packets...). Please correct the following if I've lost the plot:
* Physical stream: all the data you're fetching from the server.
* Logical stream: subdivided parts of that physical stream, e.g. one for audio, such as Vorbis; and maybe a Theora logical stream for video, and potentially others. A physical stream contains 1..* logical streams.
* Page: an Ogg data structure. Each page has a header and a payload for one logical stream. A physical stream is a sequence of pages, e.g. perhaps a repeated sequence of four video pages followed by an audio page.
* Packet: the payload of a logical stream, e.g. the actual Vorbis data in our case. Can be split across multiple pages (can start in the middle of a page, too). Composed of one or more segments.
* Segment: a piece of a packet. Pages contain up to 255 segments, which can be parts of multiple packets. A segment is 0..255 bytes in length. A segment of length 255 is never the last in the segment; the last one always has length 0..254.
* To play Vorbis audio, what we want to 'get at' is the packets. But the units we find in the Vorbis logical stream are pages, which contain segments. So we need to reconstruct the packets from the segments in each page.
* A page contains a variable number of segments. We use the 'page segments' field to find out how many there are, and the 'segment table' to find out the length of each segment.
* Individual segments are always contained within a single page, but packets can span multiple pages, and can start in the middle of a page. You can spot the beginning of a new packet inside a page because in the segment table, the previous value will be 0..254.
* We can reference packets by the tuple (ID of page that the packet started in, sequence of packet within that page). In the example below, the first packet is 1/0, as it starts in packet 1 and has sequence number 0. The last packet in the example is 4/2, as it's the third (index 2) packet to start in page 4.
* Pretty well everything is variable length: a page can contain up to 255 segments. A segment is 0..255 bytes long. A packet has, as far as I can see, no limit on its length...
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.
Le 23/10/2010 22:41, Andrew Rice a écrit :
Yep. Duncan is correct. On 23 October 2010 11:57, Alistair Stead <ags46 at cam.ac.uk> wrote:Ahh that makes sense, thanks! On 23 October 2010 11:15, Duncan Roberts <dr369 at cam.ac.uk> wrote:The server will give you everything it has for that location. My interpretation of the requirement: you should track which messages you've already received. Something you've not yet received, even if it's weeks or months old is 'new'. Le 23/10/2010 11:12, Alistair Stead a écrit :This is probably an extremely stupid question but, the extended requirements are to get any "new messages near this location". Are we to assume the messages returned from ServerHelper are the newest (given a message doesn't have a time) or should we be checking the time some other way? Alistair