Re: Theora packets with granulepos of -1

2009/2/16 Robin Siegemund <[email protected]>:
>
> Thanks for your fast reply.
>
> Well, my decoding loop is based on the sample code that comes with Theora so there are all necessary checks included. I think there is even no other way to decode video/audio properly without checking the function results because you need the feedback if more data is needed, a page is ready, packetOut is successfully, etc.
> And those -1 packets have correct packet numbers (in order) and they are true content data.
>
> I also checked out the results from oggzdump. But this tool is even more confusing because it seems not telling the truth. In the output you have packets like:
> 00:00:11.200: serialno 0000025769, granulepos 129|39, packetno 170: 513 bytes
>
> But also packets like:
> 00:00:11.266: serialno 0000025769, calc. gpos 129|40, packetno 171: 1.013 kB
>
> So why it shows "calc. gpos"? I think this means oggzdump has to calculate the position because it's originally not there. So I suppose it's the same issue here but the tool doesn't want to print a -1.

that's right -- there is no granulepos recorded in the file for those
packets. Oggz is calculating the granulepos by keeping track of frame
numbers and parsing the Theora packet headers.

Older versions of oggz-dump printed -1, before the code to calculate
the missing values was added.

> It should be mentioned that I still use an aged 1.0alpha7 version of libtheora but if the -1 granulepos is already in some packets of a file then this is not decoder related at all. So maybe there was a bug in the old encoder and the latest ffmpeg2theora still uses it, I don't know.

It's not a bug (in theora or in your code). The granulepos of a packet
is only recorded in the stream if it is the last packet ending on some
page. So even in a case as simple as having a page that contains two
complete packets, one after another, the first one will not have its
granulepos recorded in the stream -- even though the encoder passed a
granulepos value to libogg for writing.

When that stream is parsed with libogg, libogg will set a value of -1
in the ogg_packet structure for that first packet of the page.

Ogg is a lossy container format, in that it will discard some
timestamp information. (That information can usually be reconstructed,
as oggz does, with some understanding of the codec).

This is one reason that Ogg formats which require granulepos on all
packets (like CMML and Kate :) mandate that only one packet is allowed
per page.

Conrad.