FishFaq: Difference between revisions
No edit summary |
No edit summary |
||
| 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." | 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 ? === | === 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 | 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()). | 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. | |||
Revision as of 07:55, 9 June 2005
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.