RubyGems - gstreamer - Versions diffs - 1.1.0-x86-mingw32 - Mend

gstreamer 1.1.0-x86-mingw32

Files changed (1897) hide show

data/vendor/local/share/doc/libogg-1.3.0/skeleton.html ADDED Viewed

@@ -0,0 +1,222 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html dir="ltr" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+<title>The Ogg Skeleton Metadata Bitstream</title>
+<style type="text/css">
+body {
+  margin: 0 18px 0 18px;
+  padding-bottom: 30px;
+  font-family: Verdana, "DejaVu Sans", sans-serif;
+  color: #333333;
+  font-size: .8em;
+}
+a {
+  color: #3366cc;
+}
+img {
+  border: 0;
+}
+#xiphlogo {
+  margin: 30px 0 16px 0;
+}
+#content p {
+  line-height: 1.4;
+}
+h1, h1 a, h2, h2 a, h3, h3 a {
+  font-weight: bold;
+  color: #ff9900;
+  margin: 1.3em 0 8px 0;
+}
+h1 {
+  font-size: 1.3em;
+}
+h2 {
+  font-size: 1.2em;
+}
+h3 {
+  font-size: 1.1em;
+}
+li {
+  line-height: 1.4;
+}
+#copyright {
+  margin-top: 30px;
+  line-height: 1.5em;
+  text-align: center;
+  font-size: .8em;
+  color: #888888;
+  clear: both;
+}
+</style>
+</head>
+<body>
+<div id="xiphlogo">
+  <a href="http://xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"></a>
+</div>
+<h1>The Ogg Skeleton Metadata Bitstream</h1>
+<h2>Overview</h2>
+<p><strong>Ogg Skeleton</strong> provides structuring information for multitrack <a href="//xiph.org/ogg">Ogg</a> files. It is compatible with Ogg <a rel="external" href="//theora.org">Theora</a> and provides extra clues for synchronization and content negotiation such as language selection.</p>
+<p>Ogg is a generic container format for time-continuous data streams, enabling interleaving of several tracks of frame-wise encoded content in a time-multiplexed manner. As an example, an Ogg physical bitstream could encapsulate several tracks of video encoded in Theora and multiple tracks of audio encoded in Speex or Vorbis or FLAC at the same time. A player that decodes such a bitstream could then, for example, play one video channel as the main video playback, alpha-blend another one on top of it (e.g. a caption track), play a main Vorbis audio together with several FLAC audio tracks simultaneously (e.g. as sound effects), and provide a choice of Speex channels (e.g. providing commentary in different languages). Such a file is generally possible to create with Ogg, it is however not possible to generically parse such a file, seek on it, understand what codecs are contained in such a file, and dynamically handle and play back such content.</p>
+<p>Ogg does not know anything about the content it carries and leaves it to the media mapping of each codec to declare and describe itself. There is no meta information available at the Ogg level about the content tracks encapsulated within an Ogg physical bitstream. This is particularly a problem if you don't have all the decoder libraries available and just want to parse an Ogg file to find out what type of data it encapsulates (such as the "file" command under *nix to determine what file it is through magic numbers), or want to seek to a temporal offset without having to decode the data (such as on a Web server that just serves out Ogg files and parts thereof).</p>
+<p>Ogg Skeleton is being designed to overcome these problems. Ogg Skeleton is a logical bitstream within an Ogg stream that contains information about the other encapsulated logical bitstreams. For each logical bitstream it provides information such as its media type, and explains the way the granulepos field in Ogg pages is mapped to time.</p>
+<p>Ogg Skeleton is also designed to allow the creation of substreams from Ogg physical bitstreams that retain the original timing information. For example, when cutting out the segment between the 7th and the 59th second of an Ogg file, it would be nice to continue to start this cut out file with a playback time of 7 seconds and not of 0. This is of particular interest if you're streaming this file from a Web server after a query for a temporal subpart such as in http://example.com/video.ogv?t=7-59</p>
+<h2>Specification</h2>
+<h3>How to describe the logical bitstreams within an Ogg container?</h3>
+<p>The following information about a logical bitstream is of interest to contain as meta information in the Skeleton:</p>
+<ul>
+<li>the serial number: it identifies a content track</li>
+<li>the mime type: it identifies the content type</li>
+<li>other generic name-value fields that can provide meta information such as the language of a track or the video height and width</li>
+<li>the number of header packets: this informs a parser about the number of actual header packets in an Ogg logical bitstream</li>
+<li>the granule rate: the granule rate represents the data rate in Hz at which content is sampled for the particular logical bitstream, allowing to map a granule position to time by calculating "granulepos / granulerate"</li>
+<li>the preroll: the number of past content packets to take into account when decoding the current Ogg page, which is necessary for seeking (vorbis has generally 2, speex 3)</li>
+<li>the granuleshift: the number of lower bits from the granulepos field that are used to provide position information for sub-seekable units (like the keyframe shift in theora)</li>
+<li>a basetime: it provides a mapping for granule position 0 (for all logical bitstreams) to a playback time; an example use: most content in professional analog video creation actually starts at a time of 1 hour and thus adding this additional field allows them retain this mapping on digitizing their content</li>
+<li>a UTC time: it provides a mapping for granule position 0 (for all logical bitstreams) to a real-world clock time allowing to remember e.g. the recording or broadcast time of some content</li>
+</ul>
+<h3>How to allow the creation of substreams from an Ogg physical bitstream?</h3>
+<p>When cutting out a subpart of an Ogg physical bitstream, the aim is to keep all the content pages intact (including the framing and granule positions) and just change some information in the Skeleton that allows reconstruction of the accurate time mapping. When remultiplexing such a bitstream, it is necessary to take into account all the different contained logical bitstreams. A given cut-in time maps to several different byte positions in the Ogg physical bitstream because each logical bitstream has its relevant information for that time at a different location. In addition, the resolution of each logical bitstream may not be high enough to accommodate for the given cut-in time and thus there may be some surplus information necessary to be remuxed into the new bitstream.</p>
+<p>The following information is necessary to be added to the Skeleton to allow a correct presentation of a subpart of an Ogg bitstream:</p>
+<ul>
+<li>the presentation time: this is the actual cut-in time and all logical bitstreams are meant to start presenting from this time onwards, not from the time their data starts, which may be some time before that (because this time may have mapped right into the middle of a packet, or because the logical bitstream has a preroll or a keyframe shift)</li>
+<li>the basegranule: this represents the granule number with which this logical bitstream starts in the remuxed stream and provides for each logical bitstream the accurate start time of its data stream; this information is necessary to allow correct decoding and timing of the first data packets contained in a logcial bitstream of a remuxed Ogg stream</li>
+</ul>
+<h3>Ogg Skeleton version 3.0 Format Specification</h3>
+<p>Adding the above information into an Ogg bitstream without breaking existing Ogg functionality and code requires the use of a logical bitstream for Ogg Skeleton. This logical bitstream may be ignored on decoding such that existing players can still continue to play back Ogg files that have a Skeleton bitstream. Skeleton enriches the Ogg bitstream to provide meta information about structure and content of the Ogg bitstream.</p>
+<p>The Skeleton logical bitstream starts with an ident header that contains information about all of the logical bitstreams and is mapped into the Skeleton bos page.  The first 8 bytes provide the magic identifier "fishead\0".
+After the fishead follows a set of secondary header packets, each of which contains information about one logical bitstream. These secondary header packets are identified by an 8 byte code of "fisbone\0". The Skeleton logical bitstream has no actual content packets. Its eos page is included into the stream before any data pages of the other logical bitstreams appear and contains a packet of length 0.</p>
+<p>The fishead ident header looks as follows:</p>
+<pre>
+  0                   1                   2                   3
+  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'fishead\0'                                        | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version major                 | Version minor                 | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Presentationtime numerator                                    | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Presentationtime denominator                                  | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basetime numerator                                            | 28-31
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 32-35
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basetime denominator                                          | 36-39
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 40-43
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | UTC                                                           | 44-47
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 48-51
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 52-55
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 56-59
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 60-63
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+</pre>
+<p>The version fields provide version information for the Skeleton track, currently being 3.0 (the number having evolved within the Annodex project).</p>
+<p>Presentation time and basetime are specified as a rational number, the denominator providing the temporal resolution at which the time is given (e.g. to specify time in milliseconds, provide a denominator of 1000).</p>
+<p>The fisbone secondary header packet looks as follows:</p>
+<pre>
+  0                   1                   2                   3
+  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'fisbone\0'                                        | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Offset to message header fields                               | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Serial number                                                 | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of header packets                                      | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate numerator                                         | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate denominator                                       | 28-31
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 32-35
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basegranule                                                   | 36-39
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 40-43
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preroll                                                       | 44-47
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granuleshift  | Padding/future use                            | 48-51
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message header fields ...                                     | 52-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+</pre>
+<p>The mime type is provided as a message header field specified in the same way that HTTP header fields are given (e.g. "Content-Type: audio/vorbis"). Further meta information (such as language and screen size) are also included as message header fields. The offset to the message header fields at the beginning of a fisbone packet is included for forward compatibility - to allow further fields to be included into the packet without disrupting the message header field parsing.</p>
+<p>The granule rate is again given as a rational number in the same way that presentation time and basetime were provided above.</p>
+<p>A further restriction on how to encapsulate Skeleton into Ogg is proposed to allow for easier parsing:</p>
+<ul>
+<li>there can only be one Skeleton logical bitstream in a Ogg bitstream</li>
+<li>the Skeleton bos page is the very first bos page in the Ogg stream such that it can be identified straight away and decoders don't get confused about it being e.g. Ogg Vorbis without this meta information</li>
+<li>the bos pages of all the other logical bistreams come next (a requirement of Ogg)</li>
+<li>the secondary header pages of all logical bitstreams come next, including Skeleton's secondary header packets</li>
+<li>the Skeleton eos page end the control section of the Ogg stream before any content pages of any of the other logical bitstreams appear</li>
+</ul>
+<div id="copyright">
+  The Xiph Fish Logo is a
+  trademark (&trade;) of the Xiph.Org Foundation.<br>
+  These pages &copy; 1994 - 2008 Xiph.Org Foundation. Some rights reserved.
+</div>
+</body>
+</html>

data/vendor/local/share/doc/libogg-1.3.0/stream.png ADDED Viewed

Binary file

data/vendor/local/share/doc/libogg-1.3.0/vorbisword2.png ADDED Viewed

Binary file

data/vendor/local/share/doc/libogg-1.3.0/white-ogg.png ADDED Viewed

Binary file

data/vendor/local/share/doc/libogg-1.3.0/white-xifish.png ADDED Viewed

Binary file

data/vendor/local/share/doc/libtheora-1.1.1/color.html ADDED Viewed

@@ -0,0 +1,602 @@
+<HTML>
+<HEAD><TITLE>xiph.org: Ogg Theora documentation</TITLE></HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#202020" LINK="#006666" VLINK="#000000">
+<H1><FONT COLOR="#000070">
+Ogg Theora I specification: color space conventions
+</FONT></H1>
+<H1>Overview</H1>
+<P>
+There are a large number of different color standards used in digital video.
+Since Theora is a lossy codec, it restricts itself to only a few of them to
+ simplify playback.
+Unlike the alternate method of describing all the parameters of the color
+ model, this allows a few dedicated routines for color conversion to be written
+ and heavily optimized in a decoder.
+More flexible conversion functions should instead be specified in an encoder,
+ where additional computational complexity is more easily tolerated.
+The color spaces were selected to give a fair representation of color standards
+ in use around the world today.
+Most of the standards that do not exactly match one of these can be converted
+ to one fairly easily.
+</P>
+<P>
+The Theora codec identification header contains an 8-bit value that describes
+ the color space.
+This merely selects one of the color spaces available from an enumerated list.
+Currently, only two color spaces are defined, with a third possibility that
+ indicates the color space is "unknown".
+All of them are Y'C<SUB>b</SUB>C<SUB>r</SUB> color spaces with one luma channel
+ and two chroma channels.
+Each channel contains 8-bit discrete values in the range 0-255, which represent
+ non-linear gamma pre-corrected signals.
+</P>
+<H2>color space parameters</H2>
+<P>
+The parameters which describe each color space are listed below.
+These are the parameters needed to map colors from the encoded
+ Y'C<SUB>b</SUB>C<SUB>r</SUB> representation to the device-independent color
+ space CIE XYZ (1931).
+</P>
+<DL>
+<DT>Y'C<SUB>b</SUB>C<SUB>r</SUB> to Y'P<SUB>b</SUB>P<SUB>r</SUB></DT>
+<DD>
+<P>
+This conversion takes 8-bit discrete values in the range 0-255 and maps them to
+ real values in the range [0,1] for Y and [-1/2,1/2] for P<SUB>b</SUB>
+ and P<SUB>r</SUB>.
+Because some values may fall outside the offset and excursion defined for each
+ channel in the Y'C<SUB>b</SUB>C<SUB>r</SUB> space, the results may fall
+ outside these ranges in Y'P<SUB>b</SUB>P<SUB>r</SUB> space.
+No clamping should be done at this stage.
+</P>
+<P>
+Parameters: <EM>Offset<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM>,
+ <EM>Excursion<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB>,</SUB></EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">Y'<SUB>out</SUB></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(Y'<SUB>in</SUB>-<EM>Offset<SUB>Y</SUB></EM>)/
+ <EM>Excursion<SUB>Y</SUB></EM>
+</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">P<SUB>b</SUB></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(C<SUB>b</SUB>-<EM>Offset<SUB>C<SUB>b</SUB></SUB></EM>)/
+ <EM>Excursion<SUB>C<SUB>b</SUB></SUB></EM>
+</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">P<SUB>r</SUB></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(C<SUB>r</SUB>-<EM>Offset<SUB>C<SUB>r</SUB></SUB></EM>)/
+ <EM>Excursion<SUB>C<SUB>r</SUB></SUB></EM>
+</TD>
+</TR>
+</TABLE>
+</DD>
+<DT>Y'P<SUB>b</SUB>P<SUB>r</SUB> to R'G'B'</DT>
+<DD>
+<P>
+This conversion takes the one luma and two chroma channel representation and
+ maps it to the non-linear R'G'B' space used to drive actual output devices.
+Values should be clamped into the range [0,1] after this stage.
+<P>
+Parameters: <EM>K<SUB>b</SUB></EM>, <EM>K<SUB>r</SUB></EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">Y' + 2(1-<EM>K<SUB>r</SUB></EM>)P<SUB>r</SUB></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+Y' +
+ 2((<EM>K<SUB>b</SUB></EM>-1)<EM>K<SUB>b</SUB></EM>/
+ (1-<EM>K<SUB>b</SUB></EM>-<EM>K<SUB>r</SUB></EM>))P<SUB>b</SUB> +
+ 2((<EM>K<SUB>r</SUB></EM>-1)<EM>K<SUB>r</SUB></EM>/
+ (1-<EM>K<SUB>b</SUB></EM>-<EM>K<SUB>r</SUB></EM>))P<SUB>r</SUB>
+</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">Y' + 2(1-<EM>K<SUB>b</SUB></EM>)P<SUB>b</SUB></TD>
+</TR>
+</TABLE>
+</DD>
+<DT>R'G'B' to RGB (Output device gamma correction)</DT>
+<DD>
+<P>
+This conversion takes the non-linear R'G'B' voltage levels and maps it to the
+ linear light levels produced by the actual output device.
+Note that this conversion is only that of the output device, and its inverse is
+ <EM>not</EM> that used by the input device.
+Because a dim viewing environment is assumed in most television standards, the
+ overall gamma between the input and output devices is usually around 1.1 to
+ 1.2, and not a strict 1.0.
+</P>
+<P>
+For calibration with actual output devices, the model
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">L</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">(E'+&Delta;)<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+</TABLE>
+should be used, with &Delta; the free parameter and <EM>&gamma;</EM> held
+ fixed to the value specified in this document.
+The conversion function presented here is an idealized version with &Delta;=0.
+</P>
+<P>
+Parameters: <EM>&gamma;</EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">R'<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">G'<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">B'<SUP><EM>&gamma;</EM></SUP></TD>
+</TR>
+</TABLE>
+</DD>
+<DT>RGB to R'G'B' (Input device gamma correction)</DT>
+<DD>
+<P>
+This conversion takes linear light levels and maps them to the non-linear
+ voltage levels used to drive the actual output device.
+This information is merely informative.
+It is not required for building a decoder or for converting between the various
+ formats and the actual output capabilities of a particular device.
+</P>
+<P>
+A linear segment is introduced on the low end to reduce noise in dark areas of
+ the image.
+The rest of the scale is adjusted so that the power segment of the curve
+ intersects the linear segment with the proper slope, and so that it still maps
+ 0 to 0 and 1 to 1.
+</P>
+<P>
+Parameters: <EM>&beta;</EM>, <EM>&alpha;</EM>, <EM>&delta;</EM>,
+ <EM>&epsilon;</EM>
+</P>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(1+<EM>&epsilon;</EM>)R<SUP>&beta;</SUP>-<EM>&epsilon;</EM>
+</TD>
+<TD>for <EM>&delta;</EM> &le; R &le; 1</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">R'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><EM>&alpha;</EM>R</TD>
+<TD>for 0 &le; R &lt; <EM>&delta;</EM></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(1+<EM>&epsilon;</EM>)G<SUP>&beta;</SUP>-<EM>&epsilon;</EM>
+</TD>
+<TD>for <EM>&delta;</EM> &le; G &le; 1</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">G'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><EM>&alpha;</EM>G</TD>
+<TD>for 0 &le; G &lt; <EM>&delta;</EM></TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">
+(1+<EM>&epsilon;</EM>)B<SUP>&beta;</SUP>-<EM>&epsilon;</EM>
+</TD>
+<TD>for <EM>&delta;</EM> &le; B &le; 1</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">B'</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><EM>&alpha;</EM>B</TD>
+<TD>for 0 &le; B &lt; <EM>&delta;</EM></TD>
+</TR>
+</TABLE>
+</DD>
+<DT>RGB to CIE XYZ (1931)</DT>
+<DD>
+<P>
+This conversion maps a device-dependent linear RGB space to the
+ device-independent linear CIE XYZ space.
+The parameters are the CIE chromaticity coordinates of the three primaries,
+ red, green, and blue, as well as the chromaticity coordinates of the white
+ point of the device.
+This is how hardware manufacturers and standards typically describe a
+ particular RGB space.
+The math required to convert these parameters into a useful transformation
+ matrix is reproduced below.
+</P>
+<P>
+Parameters: <EM>x<SUB>r,g,b,w</SUB></EM>, <EM>y<SUB>r,g,b,w</SUB></EM>
+</P>
+<TABLE>
+<TR>
+<TD ALIGN="RIGHT">F</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><TABLE><TR>
+<TD><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR>
+<TD ALIGN="CENTER"><EM>x<SUB>r</SUB></EM>/<EM>y<SUB>r</SUB></EM></TD>
+<TD ALIGN="CENTER"><EM>x<SUB>g</SUB></EM>/<EM>y<SUB>g</SUB></EM></TD>
+<TD ALIGN="CENTER"><EM>x<SUB>b</SUB></EM>/<EM>y<SUB>b</SUB></EM></TD>
+</TR>
+<TR>
+<TD ALIGN="CENTER">1</TD>
+<TD ALIGN="CENTER">1</TD>
+<TD ALIGN="CENTER">1</TD>
+</TR>
+<TR>
+<TD ALIGN="CENTER">
+(1-<EM>x<SUB>r</SUB></EM>-<EM>y<SUB>r</SUB></EM>)/<EM>y<SUB>r</SUB></EM>
+</TD>
+<TD ALIGN="CENTER">
+(1-<EM>x<SUB>g</SUB></EM>-<EM>y<SUB>g</SUB></EM>)/<EM>y<SUB>g</SUB></EM>
+</TD>
+<TD ALIGN="CENTER">
+(1-<EM>x<SUB>b</SUB></EM>-<EM>y<SUB>b</SUB></EM>)/<EM>y<SUB>b</SUB></EM>
+</TD>
+</TR>
+</TABLE></TD>
+<TD<FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+</TR>
+<TR>
+<TD ALIGN="RIGHT"><TABLE><TR>
+<TD><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER">s<SUB>r</SUB></TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>g</SUB></TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>b</SUB></TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><TABLE><TR>
+<TD>F<SUP>-1</SUP><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER"><EM>x<SUB>w</SUB></EM>/<EM>y<SUB>w</SUB></EM></TD></TR>
+<TR><TD ALIGN="CENTER">1</TD></TR>
+<TR><TD ALIGN="CENTER">
+(1-<EM>x<SUB>w</SUB></EM>-<EM>y<SUB>w</SUB></EM>)/<EM>y<SUB>w</SUB></EM>
+</TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+</TR>
+<TR>
+<TD ALIGN="RIGHT"><TABLE><TR>
+<TD><FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER">X</TD></TR>
+<TR><TD ALIGN="CENTER">Y</TD></TR>
+<TR><TD ALIGN="CENTER">Z</TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT"><TABLE><TR>
+<TD>F<FONT SIZE="300%">(</FONT></TD>
+<TD><TABLE>
+<TR><TD ALIGN="CENTER">s<SUB>r</SUB>R</TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>g</SUB>G</TD></TR>
+<TR><TD ALIGN="CENTER">s<SUB>b</SUB>B</TD></TR>
+</TABLE></TD>
+<TD><FONT SIZE="300%">)</FONT></TD>
+</TR></TABLE></TD>
+</TR>
+</TABLE>
+</DD>
+</DL>
+<H2>available color spaces</H2>
+<P>
+These are the color spaces currently defined for use by Ogg Theora video.
+Each one has a short name, with which it is referred to in this document, and
+ a more detailed specification of the standards from which its parameters are
+ derived.
+Some standards do not specify all the parameters necessary.
+For these unspecified parameters, this document serves as the definition of
+ what should be used when encoding or decoding Ogg Theora video.
+<H3>Rec 470M (Rec. ITU-R BT.470-6 System M/NTSC with Rec. ITU-R BT.601-5)</H3>
+<P>
+This color space is used by broadcast television and DVDs in much of the
+ Americas, Japan, Korea, and the Union of Myanmar
+ [<A HREF="#Rec470">Rec470</A>].
+This color space may also be used for System M/PAL (Brazil), with an
+ appropriate conversion supplied by the encoder to compensate for the
+ different gamma value.
+See the Rec 470BG section for an appropriate gamma value to assume for M/PAL
+ input.
+</P>
+<P>
+In the US, studio monitors are adjusted to a D65 white point
+ (<EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>=0.313,0.329).
+In Japan, studio monitors are adjusted to a D white of 9300K
+ (<EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>=0.285,0.293).
+</P>
+<P>
+Rec 470 does not specify a digital encoding of the color signals.
+For Ogg Theora, Rec. ITU-R BT.601-5 is used, starting from the R'G'B' signals
+ specified by Rec 470 [<A HREF="#Rec601">Rec601</A>].
+</P>
+<P>
+<P>
+Rec 470 does not specify an input gamma function.
+For Ogg Theora, the Rec 709 input function is used.
+This is the same as that specified by SMPTE 170M, which claims to reflect
+ modern practice in the creation of NTSC signals (c. 1994)
+ [<A HREF="#SMPTE170M">SMPTE170M</A>].
+</P>
+<H4>parameters</H4>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>Offset<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(16,128,128)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+<EM>Excursion<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM>
+</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(219,224,224)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.114</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.299</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&gamma;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">2.2</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&beta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.45</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&alpha;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">4.5</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&delta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.018</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&epsilon;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.099</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>r</SUB></EM>,<EM>y<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.67,</TD>
+<TD>0.33</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>g</SUB></EM>,<EM>y<SUB>g</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.21,</TD>
+<TD>0.71</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>b</SUB></EM>,<EM>y<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.14,</TD>
+<TD>0.08</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+(Illuminant C) <EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>
+</TD>
+<TD>=</TD>
+<TD>0.310,</TD>
+<TD>0.316</TD>
+</TR>
+</TABLE>
+<H3>
+Rec 470BG (Rec. ITU-R BT.470-6 Systems B and G with Rec. ITU-R BT.601-5)
+</H3>
+<P>
+This color space is used by the PAL and SECAM systems in much of the rest of
+ the world [<A HREF="#Rec470">Rec470</A>].
+This can be used directly by systems (B, B1, D, D1, G, H, I, K, N)/PAL and (B,
+ D, G, H, K, K1, L)/SECAM.
+</P>
+<P>
+Note that the Rec 470BG chromaticity values are different from those specified
+ in Rec 470M.
+When PAL and SECAM systems were first designed, they were based upon the same
+ primaries as NTSC.
+However, as methods of making color picture tubes have changed, the primaries
+ used have changed as well.
+The US recommends using correction circuitry to approximate the existing,
+ standard NTSC primaries.
+Current PAL and SECAM systems have standardized on primaries in accord with
+ more recent technology.
+</P>
+<P>
+Rec 470 provisionally permits the use of the NTSC chromaticity values (given
+ above) with legacy PAL and SECAM equipment.
+In Ogg Theora, material must be decoded assuming the new PAL and SECAM
+ primaries.
+Material intended for display on old legacy devices should be converted by the
+ decoder.
+</P>
+<P>
+The official Rec 470BG specifies a gamma value of <EM>&gamma;</EM>=2.8.
+However, in practice this value is unrealistically high
+ [<A HREF="#RefPoy97">Poy97</A>].
+Rec 470BG states that the overall system gamma should be approximately
+ <EM>&gamma;</EM>/<EM>&beta;</EM>=1.2.
+However, most cameras pre-correct with a gamma value of <EM>&beta;</EM>=0.45,
+ which suggests an output device gamma of approximately <EM>&gamma;</EM>=2.67.
+This is the value recommended for use with PAL systems in Ogg Theora.
+</P>
+<P>
+Rec 470 does not specify a digital encoding of the color signals.
+For Ogg Theora, Rec. ITU-R BT.601-5 is used, starting from the R'G'B' signals
+ specified by Rec 470 [<A HREF="#Rec601">Rec601</A>].
+</P>
+<P>
+Rec 470 does not specify an input gamma function.
+For Ogg Theora, the Rec 709 input function is used.
+</P>
+<H4>parameters</H4>
+<TABLE>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>Offset<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(16,128,128)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+<EM>Excursion<SUB>Y,C<SUB>b</SUB>,C<SUB>r</SUB></SUB></EM>
+</TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">(219,224,224)</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.114</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>K<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT" COLSPAN="2">0.299</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&gamma;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">2.67</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&beta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.45</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&alpha;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">4.5</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&delta;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.018</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>&epsilon;</EM></TD>
+<TD>=</TD>
+<TD ALIGN="LEFT">0.099</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>r</SUB></EM>,<EM>y<SUB>r</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.64,</TD>
+<TD>0.33</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>g</SUB></EM>,<EM>y<SUB>g</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.29,</TD>
+<TD>0.60</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT"><EM>x<SUB>b</SUB></EM>,<EM>y<SUB>b</SUB></EM></TD>
+<TD>=</TD>
+<TD>0.15,</TD>
+<TD>0.06</TD>
+</TR>
+<TR VALIGN="BOTTOM">
+<TD ALIGN="RIGHT">
+(D65) <EM>x<SUB>w</SUB></EM>,<EM>y<SUB>w</SUB></EM>
+</TD>
+<TD>=</TD>
+<TD>0.313,</TD>
+<TD>0.329</TD>
+</TR>
+</TABLE>
+<H2>references</H2>
+<DL>
+<DT>[<A NAME="Poy97">Poy97</A>]</DT>
+<DD>
+Poynton, Charles, <I>Frequently-Asked Questions about Gamma</I>.
+ <A HREF="http://www.poynton.com/GammaFAQ.html">http://www.poynton.com/GammaFAQ/html</A>,
+ Feb. 1997.
+</DD>
+<DT>[<A NAME="Rec470">Rec470</A>]</DT>
+<DD>
+Recommendation ITU-R BT.470-6, <I>Conventional Television Systems</I>
+ (1970, revised 1998). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+</DD>
+<DT>[<A NAME="Rec601">Rec601</A>]</DT>
+<DD>
+Recommendation ITU-R BT.601-5, <I>Studio Encoding Parameters of
+ Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios</I>
+ (1982, revised 1995). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+</DD>
+<DT>[<A NAME="Rec709">Rec709</A>]</DT>
+<DD>
+Recommendation ITU-R BT.709-5, <I>Parameter values for the
+ HDTV standards for production and international programme exchange</I>
+ (1990, revised 2002). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+</DD>
+<DT>[<A NAME="SMPTE170M">SMPTE170M</A>]</DT>
+<DD>
+Society of Motion Picture and Television Engineers, <I>Television &mdash;
+ Composite Analog Video Signal &mdash; NTSC for Studio Applications</I>.
+ SMPTE-170M, 1994
+</DD>
+<DT>[<A NAME="SMPTE240M">SMPTE240M</A>]</DT>
+<DD>
+Society of Motion Picture and Television Engineers, <I>Television &mdash;
+ Signal Parameters &mdash; 1125-Line High-Definition Production</I>.
+ SMPTE-240M, 1999.
+</DD>
+</DL>
+</BODY>
+</HTML>