[ogg-dev] A question on ogg_packet->packetno for corrupted streams

[Daniel Armyr]

Hi.
I am trying to implement an ogg codec using libogg, and testing with a piece of encoded data you can see below. It consists of 4 pages, the first two being header data, the third containing two packets of data and the last containing one packet of data. I am confused at the results I get if I corrupt the third page (The first one of the two that contain data).

If I corrupt the first page, then I will successfully read out packets with the packetno set to 1, 2, 3,  and 4 respectively which is what I expect. Packet 0 is the first page which is corrupt and can therefore not be read out.

I get the similar results if I corrupt the second page. Specifically, I get packets with packetno set to 0, 2, 3, and 4. 

But, if I corrupt the third page, then I get packets number 0, 1, and 3. How can this happen? Packet 3 is the second half of the third page, and the third page is corrupt and should not be read out. Looking at the actual data returned, it is clear that the data refers to the packet that gets number 4 in the uncorrupted stream.

Is there something here I am misunderstanding with how packetno works?

The data I am using looks like this:
[79, 103, 103, 83, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 57, 48, 0, 0, 0, 0, 0, 0, 189, 48, 234, 15, 1, 19, 79, 112, 117, 115, 72, 101, 97, 100, 1, 1, 120, 0, 68, 172, 0, 0, 0, 0, 0, 79, 103, 103, 83, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 57, 48, 0, 0, 1, 0, 0, 0, 154, 72, 203, 178, 1, 28, 79, 112, 117, 115, 84, 97, 103, 115, 12, 0, 0, 0, 83, 111, 117, 110, 100, 87, 105, 116, 110, 101, 115, 115, 0, 0, 0, 0, 79, 103, 103, 83, 0, 0, 128, 7, 0, 0, 0, 0, 0, 0, 57, 48, 0, 0, 2, 0, 0, 0, 63, 2, 201, 64, 2, 18, 18, 8, 130, 137, 190, 114, 64, 119, 135, 85, 254, 130, 171, 104, 117, 44, 140, 168, 232, 8, 188, 54, 226, 106, 45, 22, 96, 24, 143, 135, 110, 86, 248, 109, 5, 89, 19, 79, 103, 103, 83, 0, 4, 64, 11, 0, 0, 0, 0, 0, 0, 57, 48, 0, 0, 3, 0, 0, 0, 131, 142, 37, 255, 1, 22, 8, 188, 54, 226, 106, 45, 22, 96, 24, 143, 131, 53, 207, 141, 182, 125, 187, 235, 225, 73, 83, 104]


When corrupting, I have incremented the bytes at index 1, 48 and 104 respectively by 1.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20151210/3ba135f1/attachment.htm