Computing PTS for Vorbis

[videophool]

I am writing a tool to put oggvorbis into a container that requires PTS. Is it possible to determine how many samples per channel a vorbis frame contains without decoding it? Thanks.

[jruggle]

I am writing a tool to put oggvorbis into a container that requires PTS. Is it possible to determine how many samples per channel a vorbis frame contains without decoding it? Thanks.
If you have an ogg/vorbis source, you can use the granulepos from the ogg stream to determine pts. It's tricky though... you have to watch out for delay in the first packet, which is determined by the difference between the calculated and actual granulepos of the first page.

If you just want to use the vorbis data itself, you can probably do a simple parsing of the packet data to determine the duration of each one without doing a full decode.

[videophool]

The granule position of the first OGG page that contains audio data is 79552 (the third page in the stream). Would this be considered a constant 'preroll' that could be subtracted from each granule position?

Using this method, I would not know the true duration of the stream. It seems that if I want to know the true duration of the stream, I will need to parse the vorbis audio packets.

Thanks,
David

[jruggle]

The granule position of the first OGG page that contains audio data is 79552 (the third page in the stream). Would this be considered a constant 'preroll' that could be subtracted from each granule position?

Using this method, I would not know the true duration of the stream. It seems that if I want to know the true duration of the stream, I will need to parse the vorbis audio packets.

Well, if you want to know the true duration of each packet, yes you are correct, you have to parse the vorbis data. But if you only want to know the duration of each page, and of the whole stream, you can use the granule positions.

Parsing the vorbis packets involves more than I expected, but it is certainly possible. I had a quick look at the FFmpeg vorbis decoder, and it seems you would have to parse the headers to get the block flag for each mode and the 2 block sizes. This mostly involves skipping a lot of unneeded stuff. Then you can read the mode used for each frame and the previous frame to determine the frame size.

[videophool]

The first Ogg page with audio packet has a granule position of 79552, which equates to ~1.8s. The spec says that the stream need not begin at 0, and I suspect that is the case for this stream. Must I parse the audio in the first page?

[Dark Shikari]

This blog entry (http://hardwarebug.org/2008/11/17/ogg-timestamps-explored) has some information on Ogg timestamps.