ogg dev - Dec 2015 - A question on ogg_packet->packetno for corrupted streams

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

Daniel Armyr wrote:
> Is there something here I am misunderstanding with how packetno works?
Probably. packetno is not stored in the stream. The demuxer makes it up 
from whole cloth. Each _page_ has a sequence number that does get stored 
in the stream.

When the demuxer sees a gap in page sequence numbers, it knows that some 
data was lost, but not how many packets it was contained in. So it 
increments packetno an extra time to signal to applications that only 
looks at packetno and not page-level sequence numbers that there was a 
gap. But there's no guarantee that the numbers that are returned will 
match what would have been returned before the corruption.

In other words, the fact that the numbers in packetno are not 
consecutive is significant, but the actual value of those numbers is not.