FishFaq: Difference between revisions

Latest revision as of 08:08, 23 June 2016

This page combines questions related to all Xiph projects.

General Ogg Questions

What is a granulepos?

A granulepos (Granule Position) is a representation for a timestamp, on a scale specific to each 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 ?

The positioning and length of granulepos data will vary from codec to codec, meaning that you'll have to look at the relevant codecs' specifications to see how they handle Granule Positions.

Quote from the Ogg RFC:

 Ogg does not know any specifics about the codec data except that each
 logical bitstream belongs to a different codec, the data from the
 codec comes in order and has position markers (so-called "Granule
 positions").  Ogg does not have a concept of 'time': it only knows
 about sequentially increasing, unitless position markers.  An
 application can only get temporal information through higher layers
 which have access to the codec APIs to assign and convert granule
 positions or time.

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 1: / Line 1: @@
 This page combines questions related to all Xiph projects.
-== General Ogg questions ==
+== General Ogg Questions ==
-=== What is a granulepos ? ===
+=== 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."
+A '''granulepos''' (Granule Position) is a representation for a timestamp, on a scale specific to each 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 ? ===
+The positioning and length of granulepos data will vary from codec to codec, meaning that you'll have to look at the relevant codecs' specifications to see how they handle Granule Positions.
+Quote from the [https://tools.ietf.org/html/rfc3533#page-6 Ogg RFC]:
+  Ogg does not know any specifics about the codec data except that each
+  logical bitstream belongs to a different codec, the data from the
+  codec comes in order and has position markers (so-called "Granule
+  positions").  Ogg does not have a concept of 'time': it only knows
+  about sequentially increasing, unitless position markers.  An
+  application can only get temporal information through higher layers
+  which have access to the codec APIs to assign and convert granule
+  positions or time.
 === How does the Ogg packet number work ? ===
-The Ogg bitstream does not store packet numbers in the bitstream.  Only page sequence numbers are
+The Ogg bitstream does not store packet numbers in the bitstream.  Only page sequence numbers are stored.
-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()).
+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 ==
+== 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:
+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.
-- 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
+[[Category:Ogg]]
-- 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.