FishFaq - Revision history

MrZeus: added bit trying to explain granulepos not being defined in Ogg

2016-06-23T16:08:55Z

added bit trying to explain granulepos not being defined in Ogg

← Older revision		Revision as of 16:08, 23 June 2016
Line 1:		Line 1:
	This page combines questions related to all Xiph projects.		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 ? ===		=== 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 ? ===		=== 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 ? ===		=== 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 '''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]]		[[Category:Ogg]]

Ogg.k.ogg.k: fix formatting

2008-02-13T11:26:12Z

fix formatting

← Older revision		Revision as of 11:26, 13 February 2008
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:		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]]		[[Category:Ogg]]

Saoshyant: cat

2008-02-12T23:40:43Z

cat

← Older revision		Revision as of 23:40, 12 February 2008
Line 30:		Line 30:
	- 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]]

Tbullock: Restored after Vandalism

2006-07-06T04:57:48Z

Restored after Vandalism

@@ Line 1: / Line 1: @@
-<div id="nolabel" style="overflow:auto;height:1px;">
+This page combines questions related to all Xiph projects.
-[http://www.action-meds.com cheap butalbital]
+=== What is a granulepos ? ===
-[http://spaces.msn.com/cheap-tramadol/ cheap tramadol]
+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."
-SEO: UndoneHeaven
+=== Where is the granulepos stored in the bitstream ? ===
-[http://www.thepublish.com press release]
+=== How does the Ogg packet number work ? ===
-[http://www.ez-agents.com wholesale atv]
+The Ogg bitstream does not store packet numbers in the bitstream.  Only page sequence numbers are
-</div>
+stored.  libogg will count packets and give each Ogg packet a packet number.  Normally these are

Julli9 at 16:36, 4 July 2006

2006-07-04T16:36:28Z

@@ Line 1: / Line 1: @@
-This page combines questions related to all Xiph projects.
+<div id="nolabel" style="overflow:auto;height:1px;">
-=== What is a granulepos ? ===
+[http://www.action-meds.com cheap butalbital]
-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."
+[http://spaces.msn.com/cheap-tramadol/ cheap tramadol]
-=== Where is the granulepos stored in the bitstream ? ===
+SEO: UndoneHeaven
-=== How does the Ogg packet number work ? ===
+[http://www.thepublish.com press release]
-The Ogg bitstream does not store packet numbers in the bitstream.  Only page sequence numbers are
+[http://www.ez-agents.com wholesale atv]
-stored.  libogg will count packets and give each Ogg packet a packet number.  Normally these are
+</div>

ThomasVanderStichele at 16:19, 9 June 2005

2005-06-09T16:19:49Z

← Older revision		Revision as of 16:19, 9 June 2005
Line 28:		Line 28:
	- 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.		- 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.

ThomasVanderStichele at 15:55, 9 June 2005

2005-06-09T15:55:20Z

@@ Line 6: / Line 6: @@
 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."
 === How does the Ogg packet number work ? ===
@@ Line 13: / Line 17: @@
 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()).

ThomasVanderStichele at 09:36, 6 June 2005

2005-06-06T09:36:39Z

← Older revision		Revision as of 09:36, 6 June 2005
Line 1:		Line 1:
	This page combines questions related to all Xiph projects.		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 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."

			=== 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()).

ThomasVanderStichele at 09:27, 6 June 2005

2005-06-06T09:27:40Z

← Older revision		Revision as of 09:27, 6 June 2005
Line 1:		Line 1:
	This page combines questions related to all Xiph projects.		This page combines questions related to all Xiph projects.

	~~TECHNICAL 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 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."

ThomasVanderStichele at 09:23, 6 June 2005

2005-06-06T09:23:01Z

New page

This page combines questions related to all Xiph projects.

TECHNICAL 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."