FishFaq: Difference between revisions

Revision as of 03:26, 13 February 2008

This page combines questions related to all Xiph projects.

General Ogg questions

What is a granulepos ?

A granulepos is a representation for a timestamp on a scale specific to the codec. Conrad Parker clarifies the definition of granulepos as "representing the presentation time for the last presentable data item in an Ogg packet."

Where is the granulepos stored in the bitstream ?

How does the Ogg packet number work ?

The Ogg bitstream does not store packet numbers in the bitstream. Only page sequence numbers are stored. libogg will count packets and give each Ogg packet a packet number. Normally these are in sequence; when Ogg notices a discontinuity however (page sequence numbers don't match up (FIXME: is this actually in the code ?), or the lacing values don't match up) it will increment the page counter by 1, which thus shows up as a missing packet (see http://trac.xiph.org/cgi-bin/trac.cgi/file/trunk/ogg/src/framing.c, _packetout()).

Player implementation questions

What use cases do I need to consider when writing a player ?

There are different ways in which an ogg stream reaches your player. Each of these ways has some specific restrictions and potential problems that your player needs to be able to deal with. These are:

the "ideal" case: a correctly muxed Ogg stream as a seekable file, with correct bos packets, header packets, and eos packets, time-correct muxing, and a continuous set of Ogg pages
the "lossless streaming" case (e.g. HTTP streaming): you receive correct bos and header packets, and a string of Ogg packets in pages that are continuous, but start with a discontinuity. The stream might or might not be seekable, and you do not get eos pages
the "saved from lossless streaming" case: as above, but you can seek. You still don't have eos pages
the "lossy streaming" case (e.g. RTP streaming): some of the Ogg pages get lost in transmission. In the case of RTP, you actually may have less, or different, information to go on, since it is recommended that RTP packetizing is used instead of Ogg packetizing. An HTTP stream could also be lossy, if the server for example decides that the client is not reading fast enough and drops a set of intermediary buffers.
the "no feedback" case (e.g. satellite broadcasts): there is no way for the client to communicate with the server. The client needs to get the header pages through other means, and then interpret the Ogg stream it receives.

@@ Line 25: / Line 25: @@
 There are different ways in which an ogg stream reaches your player.  Each of these ways has some specific restrictions and potential problems that your player needs to be able to deal with.  These are:
-- the "ideal" case: a correctly muxed Ogg stream as a seekable file, with correct bos packets, header packets, and eos packets, time-correct muxing, and a continuous set of Ogg pages
+* the "ideal" case: a correctly muxed Ogg stream as a seekable file, with correct bos packets, header packets, and eos packets, time-correct muxing, and a continuous set of Ogg pages
-- the "lossless streaming" case (e.g. HTTP streaming): you receive correct bos and header packets, and a string of Ogg packets in pages that are continuous, but start with a discontinuity.  The stream might or might not be seekable, and you do not get eos pages
+* the "lossless streaming" case (e.g. HTTP streaming): you receive correct bos and header packets, and a string of Ogg packets in pages that are continuous, but start with a discontinuity.  The stream might or might not be seekable, and you do not get eos pages
-- the "saved from lossless streaming" case: as above, but you can seek.  You still don't have eos pages
+* the "saved from lossless streaming" case: as above, but you can seek.  You still don't have eos pages
-- the "lossy streaming" case (e.g. RTP streaming): some of the Ogg pages get lost in transmission. In the case of RTP, you actually may have less, or different, information to go on, since it is recommended that RTP packetizing is used instead of Ogg packetizing.  An HTTP stream could also be lossy, if the server for example decides that the client is not reading fast enough and drops a set of intermediary buffers.
+* the "lossy streaming" case (e.g. RTP streaming): some of the Ogg pages get lost in transmission. In the case of RTP, you actually may have less, or different, information to go on, since it is recommended that RTP packetizing is used instead of Ogg packetizing.  An HTTP stream could also be lossy, if the server for example decides that the client is not reading fast enough and drops a set of intermediary buffers.
-- the "no feedback" case (e.g. satellite broadcasts): there is no way for the client to communicate with the server.  The client needs to get the header pages through other means, and then interpret the Ogg stream it receives.
+* the "no feedback" case (e.g. satellite broadcasts): there is no way for the client to communicate with the server.  The client needs to get the header pages through other means, and then interpret the Ogg stream it receives.
 [[Category:Ogg]]