Re: Theora packets with granulepos of -1

Thanks a lot for all that information.
Well I understand that codecs used in an ogg container are lossy like Theora, Speex and Vorbis are. But why making the important basement - the container itself - lossy? Doesn't make any sense to me especially related to the granule position because this part is not compressed or smaller because a -1 is used instead of the right value.

And not to forget: This important issue is nowhere mentioned (as far as I kow) especially when it comes to seeking. Why is there no addendum to the Theora specs to discuss the issue of -1 packets if used in the ogg container? I think this is quite important. There is even a chapter about Theora in ogg container.

So if those -1 packets appear based on a determined system I should be able to find a way to calculate the correct granule position on myself... even if it's more complicated than necessary.

Are there also similar issues with vorbis? Are there also -1 packets to make the packet-handling... uhm, more funny?


Robin Siegemund


------------------------------------------


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.