Skip to content
GitLab
Commit 14571fd2 authored by 藤森雅人's avatar 藤森雅人
Browse files

Initial commit

parents
Show whitespace changes
Inline Side-by-side
cpprestsdk_static_tester/libogg/doc/ogg-multiplex.html 0 → 100644
View file @ 14571fd2
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
<title>Ogg Documentation</title>
<style type="text/css">
body {
margin: 0 18px 0 18px;
padding-bottom: 30px;
font-family: Verdana, Arial, Helvetica, 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, h4, h4 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://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
</div>
<h1>Page Multiplexing and Ordering in a Physical Ogg Stream</h1>
<p>The low-level mechanisms of an Ogg stream (as described in the Ogg
Bitstream Overview) provide means for mixing multiple logical streams
and media types into a single linear-chronological stream. This
document specifies the high-level arrangement and use of page
structure to multiplex multiple streams of mixed media type within a
physical Ogg stream.</p>
<h2>Design Elements</h2>
<p>The design and arrangement of the Ogg container format is governed by
several high-level design decisions that form the reasoning behind
specific low-level design decisions.</p>
<h3>Linear media</h3>
<p>The Ogg bitstream is intended to encapsulate chronological,
time-linear mixed media into a single delivery stream or file. The
design is such that an application can always encode and/or decode a
full-featured bitstream in one pass with no seeking and minimal
buffering. Seeking to provide optimized encoding (such as two-pass
encoding) or interactive decoding (such as scrubbing or instant
replay) is not disallowed or discouraged, however no bitstream feature
must require nonlinear operation on the bitstream.</p>
<h3>Multiplexing</h3>
<p>Ogg bitstreams multiplex multiple logical streams into a single
physical stream at the page level. Each page contains an abstract
time stamp (the Granule Position) that represents an absolute time
landmark within the stream. After the pages representing stream
headers (all logical stream headers occur at the beginning of a
physical bitstream section before any logical stream data), logical
stream data pages are arranged in a physical bitstream in strict
non-decreasing order by chronological absolute time as
specified by the granule position.</p>
<p>The only exception to arranging pages in strictly ascending time order
by granule position is those pages that do not set the granule
position value. This is a special case when exceptionally large
packets span multiple pages; the specifics of handling this special
case are described later under 'Continuous and Discontinuous
Streams'.</p>
<h3>Seeking</h3>
<p>Ogg is designed to use an interpolated bisection search to
implement exact positional seeking. Interpolated bisection search is
a spec-mandated mechanism.</p>
<p><i>An index may improve objective performance, but it seldom
improves subjective performance outside of a few high-latency use
cases and adds no additional functionality as bisection search
delivers the same functionality for both one- and two-pass stream
types. For these reasons, use of indexes is discouraged, except in
cases where an index provides demonstrable and noticable performance
improvement.</i></p>
<p>Seek operations are by absolute time; a direct bisection search must
find the exact time position requested. Information in the Ogg
bitstream is arranged such that all information to be presented for
playback from the desired seek point will occur at or after the
desired seek point. Seek operations are neither 'fuzzy' nor
heuristic.</p>
<p><i>Although key frame handling in video appears to be an exception to
"all needed playback information lies ahead of a given seek",
key frames can still be handled directly within this indexless
framework. Seeking to a key frame in video (as well as seeking in other
media types with analogous restraints) is handled as two seeks; first
a seek to the desired time which extracts state information that
decodes to the time of the last key frame, followed by a second seek
directly to the key frame. The location of the previous key frame is
embedded as state information in the granulepos; this mechanism is
described in more detail later.</i></p>
<h3>Continuous and Discontinuous Streams</h3>
<p>Logical streams within a physical Ogg stream belong to one of two
categories, "Continuous" streams and "Discontinuous" streams.
Although these are discussed in more detail later, the distinction is
important to a high-level understanding of how to buffer an Ogg
stream.</p>
<p>A stream that provides a gapless, time-continuous media type with a
fine-grained timebase is considered to be 'Continuous'. A continuous
stream should never be starved of data. Clear examples of continuous
data types include broadcast audio and video.</p>
<p>A stream that delivers data in a potentially irregular pattern or with
widely spaced timing gaps is considered to be 'Discontinuous'. A
discontinuous stream may be best thought of as data representing
scattered events; although they happen in order, they are typically
unconnected data often located far apart. One possible example of a
discontinuous stream types would be captioning. Although it's
possible to design captions as a continuous stream type, it's most
natural to think of captions as widely spaced pieces of text with
little happening between.</p>
<p>The fundamental design distinction between continuous and
discontinuous streams concerns buffering.</p>
<h3>Buffering</h3>
<p>Because a continuous stream is, by definition, gapless, Ogg buffering
is based on the simple premise of never allowing any active continuous
stream to starve for data during decode; buffering proceeds ahead
until all continuous streams in a physical stream have data ready to
decode on demand.</p>
<p>Discontinuous stream data may occur on a fairly regular basis, but the
timing of, for example, a specific caption is impossible to predict
with certainty in most captioning systems. Thus the buffering system
should take discontinuous data 'as it comes' rather than working ahead
(for a potentially unbounded period) to look for future discontinuous
data. As such, discontinuous streams are ignored when managing
buffering; their pages simply 'fall out' of the stream when continuous
streams are handled properly.</p>
<p>Buffering requirements need not be explicitly declared or managed for
the encoded stream; the decoder simply reads as much data as is
necessary to keep all continuous stream types gapless (also ensuring
discontinuous data arrives in time) and no more, resulting in optimum
implicit buffer usage for a given stream. Because all pages of all
data types are stamped with absolute timing information within the
stream, inter-stream synchronization timing is always explicitly
maintained without the need for explicitly declared buffer-ahead
hinting.</p>
<p>Further details, mechanisms and reasons for the differing arrangement
and behavior of continuous and discontinuous streams is discussed
later.</p>
<h3>Whole-stream navigation</h3>
<p>Ogg is designed so that the simplest navigation operations treat the
physical Ogg stream as a whole summary of its streams, rather than
navigating each interleaved stream as a separate entity.</p>
<p>First Example: seeking to a desired time position in a multiplexed (or
unmultiplexed) Ogg stream can be accomplished through a bisection
search on time position of all pages in the stream (as encoded in the
granule position). More powerful searches (such as a key frame-aware
seek within video) are also possible with additional search
complexity, but similar computational complexity.</p>
<p>Second Example: A bitstream section may consist of three multiplexed
streams of differing lengths. The result of multiplexing these
streams should be thought of as a single mixed stream with a length
equal to the longest of the three component streams. Although it is
also possible to think of the multiplexed results as three concurrent
streams of different lengths and it is possible to recover the three
original streams, it will also become obvious that once multiplexed,
it isn't possible to find the internal lengths of the component
streams without a linear search of the whole bitstream section.
However, it is possible to find the length of the whole bitstream
section easily (in near-constant time per section) just as it is for a
single-media unmultiplexed stream.</p>
<h2>Granule Position</h2>
<h3>Description</h3>
<p>The Granule Position is a signed 64 bit field appearing in the header
of every Ogg page. Although the granule position represents absolute
time within a logical stream, its value does not necessarily directly
encode a simple timestamp. It may represent frames elapsed (as in
Vorbis), a simple timestamp, or a more complex bit-division encoding
(such as in Theora). The exact encoding of the granule position is up
to a specific codec.</p>
<p>The granule position is governed by the following rules:</p>
<ul>
<li>Granule Position must always increase forward or remain equal from
page to page, be unset, or be zero for a header page. The absolute
time to which any correct sequence of granule position maps must
similarly always increase forward or remain equal. <i>(A codec may
make use of data, such as a control sequence, that only affects codec
working state without producing data and thus advancing granule
position and time. Although the packet sequence number increases in
this case, the granule position, and thus the time position, do
not.)</i></li>
<li>Granule position may only be unset if there no packet defining a
time boundary on the page (that is, if no packet in a continuous
stream ends on the page, or no packet in a discontinuous stream begins
on the page. This will be discussed in more detail under Continuous
and Discontinuous streams).</li>
<li>A codec must be able to translate a given granule position value
to a unique, deterministic absolute time value through direct
calculation. A codec is not required to be able to translate an
absolute time value into a unique granule position value.</li>
<li>Codecs shall choose a granule position definition that allows that
codec means to seek as directly as possible to an immediately
decodable point, such as the bit-divided granule position encoding of
Theora allows the codec to seek efficiently to key frame without using
an index. That is, additional information other than absolute time
may be encoded into a granule position value so long as the granule
position obeys the above points.</li>
</ul>
<h4>Example: timestamp</h4>
<p>In general, a codec/stream type should choose the simplest granule
position encoding that addresses its requirements. The examples here
are by no means exhaustive of the possibilities within Ogg.</p>
<p>A simple granule position could encode a timestamp directly. For
example, a granule position that encoded milliseconds from beginning
of stream would allow a logical stream length of over 100,000,000,000
days before beginning a new logical stream (to avoid the granule
position wrapping).</p>
<h4>Example: framestamp</h4>
<p>A simple millisecond timestamp granule encoding might suit many stream
types, but a millisecond resolution is inappropriate to, eg, most
audio encodings where exact single-sample resolution is generally a
requirement. A millisecond is both too large a granule and often does
not represent an integer number of samples.</p>
<p>In the event that audio frames are always encoded as the same number of
samples, the granule position could simply be a linear count of frames
since beginning of stream. This has the advantages of being exact and
efficient. Position in time would simply be <tt>[granule_position] *
[samples_per_frame] / [samples_per_second]</tt>.</p>
<h4>Example: samplestamp (Vorbis)</h4>
<p>Frame counting is insufficient in codecs such as Vorbis where an audio
frame [packet] encodes a variable number of samples. In Vorbis's
case, the granule position is a count of the number of raw samples
from the beginning of stream; the absolute time of
a granule position is <tt>[granule_position] /
[samples_per_second]</tt>.</p>
<h4>Example: bit-divided framestamp (Theora)</h4>
<p>Some video codecs may be able to use the simple framestamp scheme for
granule position. However, most modern video codecs introduce at
least the following complications:</p>
<ul>
<li>video frames are relatively far apart compared to audio samples;
for this reason, the point at which a video frame changes to the next
frame is usually a strictly defined offset within the frame 'period'.
That is, video at 50fps could just as easily define frame transitions
&lt;.015, .035, .055...&gt; as at &lt;.00, .02, .04...&gt;.</li>
<li>frame rates often include drop-frames, leap-frames or other
rational-but-non-integer timings.</li>
<li>Decode must begin at a 'key frame' or 'I frame'. Keyframes usually
occur relatively seldom.</li>
</ul>
<p>The first two points can be handled straightforwardly via the fact
that the codec has complete control mapping granule position to
absolute time; non-integer frame rates and offsets can be set in the
codec's initial header, and the rest is just arithmetic.</p>
<p>The third point appears trickier at first glance, but it too can be
handled through the granule position mapping mechanism. Here we
arrange the granule position in such a way that granule positions of
key frames are easy to find. Divide the granule position into two
fields; the most-significant bits are an absolute frame counter, but
it's only updated at each key frame. The least significant bits encode
the number of frames since the last key frame. In this way, each
granule position both encodes the absolute time of the current frame
as well as the absolute time of the last key frame.</p>
<p>Seeking to a most recent preceding key frame is then accomplished by
first seeking to the original desired point, inspecting the granulepos
of the resulting video page, extracting from that granulepos the
absolute time of the desired key frame, and then seeking directly to
that key frame's page. Of course, it's still possible for an
application to ignore key frames and use a simpler seeking algorithm
(decode would be unable to present decoded video until the next
key frame). Surprisingly many player applications do choose the
simpler approach.</p>
<h3>granule position, packets and pages</h3>
<p>Although each packet of data in a logical stream theoretically has a
specific granule position, only one granule position is encoded
per page. It is possible to encode a logical stream such that each
page contains only a single packet (so that granule positions are
preserved for each packet), however a one-to-one packet/page mapping
is not intended to be the general case.</p>
<p>Because Ogg functions at the page, not packet, level, this
once-per-page time information provides Ogg with the finest-grained
time information is can use. Ogg passes this granule positioning data
to the codec (along with the packets extracted from a page); it is the
responsibility of codecs to track timing information at granularities
finer than a single page.</p>
<h3>start-time and end-time positioning</h3>
<p>A granule position represents the <em>instantaneous time location
between two pages</em>. However, continuous streams and discontinuous
streams differ on whether the granulepos represents the end-time of
the data on a page or the start-time. Continuous streams are
'end-time' encoded; the granulepos represents the point in time
immediately after the last data decoded from a page. Discontinuous
streams are 'start-time' encoded; the granulepos represents the point
in time of the first data decoded from the page.</p>
<p>An Ogg stream type is declared continuous or discontinuous by its
codec. A given codec may support both continuous and discontinuous
operation so long as any given logical stream is continuous or
discontinuous for its entirety and the codec is able to ascertain (and
inform the Ogg layer) as to which after decoding the initial stream
header. The majority of codecs will always be continuous (such as
Vorbis) or discontinuous (such as Writ).</p>
<p>Start- and end-time encoding do not affect multiplexing sort-order;
pages are still sorted by the absolute time a given granulepos maps to
regardless of whether that granulepos represents start- or
end-time.</p>
<h2>Multiplex/Demultiplex Division of Labor</h2>
<p>The Ogg multiplex/demultiplex layer provides mechanisms for encoding
raw packets into Ogg pages, decoding Ogg pages back into the original
codec packets, determining the logical structure of an Ogg stream, and
navigating through and synchronizing with an Ogg stream at a desired
stream location. Strict multiplex/demultiplex operations are entirely
in the Ogg domain and require no intervention from codecs.</p>
<p>Implementation of more complex operations does require codec
knowledge, however. Unlike other framing systems, Ogg maintains
strict separation between framing and the framed bitstream data; Ogg
does not replicate codec-specific information in the page/framing
data, nor does Ogg blur the line between framing and stream
data/metadata. Because Ogg is fully data-agnostic toward the data it
frames, operations which require specifics of bitstream data (such as
'seek to key frame') also require interaction with the codec layer
(because, in this example, the Ogg layer is not aware of the concept
of key frames). This is different from systems that blur the
separation between framing and stream data in order to simplify the
separation of code. The Ogg system purposely keeps the distinction in
data simple so that later codec innovations are not constrained by
framing design.</p>
<p>For this reason, however, complex seeking operations require
interaction with the codecs in order to decode the granule position of
a given stream type back to absolute time or in order to find
'decodable points' such as key frames in video.</p>
<h2>Unsorted Discussion Points</h2>
<p>flushes around key frames? RFC suggestion: repaginating or building a
stream this way is nice but not required</p>
<h2>Appendix A: multiplexing examples</h2>
<div id="copyright">
The Xiph Fish Logo is a
trademark (&trade;) of Xiph.Org.<br/>
These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
</div>
</body>
</html>
cpprestsdk_static_tester/libogg/doc/oggstream.html 0 → 100644
View file @ 14571fd2
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
<title>Ogg Documentation</title>
<style type="text/css">
body {
margin: 0 18px 0 18px;
padding-bottom: 30px;
font-family: Verdana, Arial, Helvetica, 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;
}
.caption {
color: #000000;
background-color: #aabbff;
margin: 1em;
margin-left: 2em;
margin-right: 2em;
padding: 1em;
padding-bottom: 0em;
overflow: hidden;
}
.caption p {
clear: none;
}
.caption img {
display: block;
margin: 0px;
margin-left: auto;
margin-right: auto;
margin-bottom: 1.5em;
background-color: #ffffff;
padding: 10px;
}
#thepage {
margin-left: auto;
margin-right: auto;
width: 840px;
}
</style>
</head>
<body>
<div id="thepage">
<div id="xiphlogo">
<a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
</div>
<h1>Ogg bitstream overview</h1>
<p>This document serves as starting point for understanding the design
and implementation of the Ogg container format. If you're new to Ogg
or merely want a high-level technical overview, start reading here.
Other documents linked from the <a href="index.html">index page</a>
give distilled technical descriptions and references of the container
mechanisms. This document is intended to aid understanding.
<h2>Container format design points</h2>
<p>Ogg is intended to be a simplest-possible container, concerned only
with framing, ordering, and interleave. It can be used as a stream delivery
mechanism, for media file storage, or as a building block toward
implementing a more complex, non-linear container (for example, see
the <a href="skeleton.html">Skeleton</a> or <a
href="http://en.wikipedia.org/wiki/Annodex">Annodex/CMML</a>).
<p>The Ogg container is not intended to be a monolithic
'kitchen-sink'. It exists only to frame and deliver in-order stream
data and as such is vastly simpler than most other containers.
Elementary and multiplexed streams are both constructed entirely from a
single building block (an Ogg page) comprised of eight fields
totalling twenty-eight bytes (the page header) a list of packet lengths
(up to 255 bytes) and payload data (up to 65025 bytes). The structure
of every page is the same. There are no optional fields or alternate
encodings.
<p>Stream and media metadata is contained in Ogg and not built into
the Ogg container itself. Metadata is thus compartmentalized and
layered rather than part of a monolithic design, an especially good
idea as no two groups seem able to agree on what a complete or
complete-enough metadata set should be. In this way, the container and
container implementation are isolated from unnecessary metadata design
flux.
<h3>Streaming</h3>
<p>The Ogg container is primarily a streaming format,
encapsulating chronological, time-linear mixed media into a single
delivery stream or file. The design is such that an application can
always encode and/or decode all features of a bitstream in one pass
with no seeking and minimal buffering. Seeking to provide optimized
encoding (such as two-pass encoding) or interactive decoding (such as
scrubbing or instant replay) is not disallowed or discouraged, however
no container feature requires nonlinear access of the bitstream.
<h3>Variable Bit Rate, Variable Payload Size</h3>
<p>Ogg is designed to contain any size data payload with bounded,
predictable efficiency. Ogg packets have no maximum size and a
zero-byte minimum size. There is no restriction on size changes from
packet to packet. Variable size packets do not require the use of any
optional or additional container features. There is no optimal
suggested packet size, though special consideration was paid to make
sure 50-200 byte packets were no less efficient than larger packet
sizes. The original design criteria was a 2% overhead at 50 byte
packets, dropping to a maximum working overhead of 1% with larger
packets, and a typical working overhead of .5-.7% for most practical
uses.
<h3>Simple pagination</h3>
<p>Ogg is a byte-aligned container with no context-dependent, optional
or variable-length fields. Ogg requires no repacking of codec data.
The page structure is written out in-line as packet data is submitted
to the streaming abstraction. In addition, it is possible to
implement both Ogg mux and demux as MT-hot zero-copy abstractions (as
is done in the Tremor sourcebase).
<h3>Capture</h3>
<p>Ogg is designed for efficient and immediate stream capture with
high confidence. Although packets have no size limit in Ogg, pages
are a maximum of just under 64kB meaning that any Ogg stream can be
captured with confidence after seeing 128kB of data or less [worst
case; typical figure is 6kB] from any random starting point in the
stream.
<h3>Seeking</h3>
<p>Ogg implements simple coarse- and fine-grained seeking by design.
<p>Coarse seeking may be performed by simply 'moving the tone arm' to a
new position and 'dropping the needle'. Rapid capture with
accompanying timecode from any location in an Ogg file is guaranteed
by the stream design. From the acquisition of the first timecode,
all data needed to play back from that time code forward is ahead of
the stream cursor.
<p>Ogg implements full sample-granularity seeking using an
interpolated bisection search built on the capture and timecode
mechanisms used by coarse seeking. As above, once a search finds
the desired timecode, all data needed to play back from that time code
forward is ahead of the stream cursor.
<p>Both coarse and fine seeking use the page structure and sequencing
inherent to the Ogg format. All Ogg streams are fully seekable from
creation; seekability is unaffected by truncation or missing data, and
is tolerant of gross corruption. Seek operations are neither 'fuzzy' nor
heuristic.
<p>Seeking without use of an index is a major point of the Ogg
design. There two primary reasons why Ogg transport forgoes an index:
<ol>
<li>An index is only marginally useful in Ogg for the complexity
added; it adds no new functionality and seldom improves performance
noticeably. Empirical testing shows that indexless interpolation
search does not require many more seeks in practice than using an
index would.
<li>'Optional' indexes encourage lazy implementations that can seek
only when indexes are present, or that implement indexless seeking
only by building an internal index after reading the entire file
beginning to end. This has been the fate of other containers that
specify optional indexing.
</ol>
<p>In addition, it must be possible to create an Ogg stream in a
single pass. Although an optional index can simply be tacked on the
end of the created stream, some software groups object to
end-positioned indexes and claim to be unwilling to support indexes
not located at the stream beginning.
<p><i>All this said, it's become clear that an optional index is a
demanded feature. For this reason, the <a
href="http://wiki.xiph.org/Ogg_Index">OggSkeleton now defines a
proposed index.</a></i>
<h3>Simple multiplexing</h3>
<p>Ogg multiplexes streams by interleaving pages from multiple elementary streams into a
multiplexed stream in time order. The multiplexed pages are not
altered. Muxing an Ogg AV stream out of separate audio,
video and data streams is akin to shuffling several decks of cards
together into a single deck; the cards themselves remain unchanged.
Demultiplexing is similarly simple (as the cards are marked).
<p>The goal of this design is to make the mux/demux operation as
trivial as possible to allow live streaming systems to build and
rebuild streams on the fly with minimal CPU usage and no additional
storage or latency requirements.
<h3>Continuous and Discontinuous Media</h3>
<p>Ogg streams belong to one of two categories, "Continuous" streams and
"Discontinuous" streams.
<p>A stream that provides a gapless, time-continuous media type with a
fine-grained timebase is considered to be 'Continuous'. A continuous
stream should never be starved of data. Examples of continuous data
types include broadcast audio and video.
<p>A stream that delivers data in a potentially irregular pattern or
with widely spaced timing gaps is considered to be 'Discontinuous'. A
discontinuous stream may be best thought of as data representing
scattered events; although they happen in order, they are typically
unconnected data often located far apart. One example of a
discontinuous stream types would be captioning such as <a
href="http://wiki.xiph.org/OggKate">Ogg Kate</a>. Although it's
possible to design captions as a continuous stream type, it's most
natural to think of captions as widely spaced pieces of text with
little happening between.
<p>The fundamental reason for distinction between continuous and
discontinuous streams concerns buffering.
<h3>Buffering</h3>
<p>A continuous stream is, by definition, gapless. Ogg buffering is based
on the simple premise of never allowing an active continuous stream
to starve for data during decode; buffering works ahead until all
continuous streams in a physical stream have data ready and no further.
<p>Discontinuous stream data is not assumed to be predictable. The
buffering design takes discontinuous data 'as it comes' rather than
working ahead to look for future discontinuous data for a potentially
unbounded period. Thus, the buffering process makes no attempt to fill
discontinuous stream buffers; their pages simply 'fall out' of the
stream when continuous streams are handled properly.
<p>Buffering requirements in this design need not be explicitly
declared or managed in the encoded stream. The decoder simply reads as
much data as is necessary to keep all continuous stream types gapless
and no more, with discontinuous data processed as it arrives in the
continuous data. Buffering is implicitly optimal for the given
stream. Because all pages of all data types are stamped with absolute
timing information within the stream, inter-stream synchronization
timing is always maintained without the need for explicitly declared
buffer-ahead hinting.
<h3>Codec metadata</h3>
<p>Ogg does not replicate codec-specific metadata into the mux layer
in an attempt to make the mux and codec layer implementations 'fully
separable'. Things like specific timebase, keyframing strategy, frame
duration, etc, do not appear in the Ogg container. The mux layer is,
instead, expected to query a codec through a centralized interface,
left to the implementation, for this data when it is needed.
<p>Though modern design wisdom usually prefers to predict all possible
needs of current and future codecs then embed these dependencies and
the required metadata into the container itself, this strategy
increases container specification complexity, fragility, and rigidity.
The mux and codec code becomes more independent, but the
specifications become logically less independent. A codec can't do
what a container hasn't already provided for. Novel codecs are harder
to support, and you can do fewer useful things with the ones you've
already got (eg, try to make a good splitter without using any codecs.
Such a splitter is limited to splitting at keyframes only, or building
yet another new mechanism into the container layer to mark what frames
to skip displaying).
<p>Ogg's design goes the opposite direction, where the specification
is to be as simple, easy to understand, and 'proofed' against novel
codecs as possible. When an Ogg mux layer requires codec-specific
information, it queries the codec (or a codec stub). This trades a
more complex implementation for a simpler, more flexible
specification.
<h3>Stream structure metadata</h3>
<p>The Ogg container itself does not define a metadata system for
declaring the structure and interrelations between multiple media
types in a muxed stream. That is, the Ogg container itself does not
specify data like 'which steam is the subtitle stream?' or 'which
video stream is the primary angle?'. This metadata still exists, but
is stored by the Ogg container rather than being built into the Ogg
container itself. Xiph specifies the 'Skeleton' metadata format for Ogg
streams, but this decoupling of container and stream structure
metadata means it is possible to use Ogg with any metadata
specification without altering the container itself, or without stream
structure metadata at all.
<h3>Frame accurate absolute position</h3>
<p>Every Ogg page is stamped with a 64 bit 'granule position' that
serves as an absolute timestamp for mux and seeking. A few nifty
little tricks are usually also embedded in the granpos state, but
we'll leave those aside for the moment (strictly speaking, they're
part of each codec's mapping, not Ogg).
<p>As previously mentioned above, granule positions are mapped into
absolute timestamps by the codec, rather than being a hard timestamp.
This allows maximally efficient use of the available 64 bits to
address every sample/frame position without approximation while
supporting new and previously unknown timebase encodings without
needing to extend or update the mux layer. When a codec needs a novel
timebase, it simply brings the code for that mapping along with it.
This is not a theoretical curiosity; new, wholly novel timebases were
deployed with the adoption of both Theora and Dirac. "Rolling INTRA"
(keyframeless video) also benefits from novel use of the granule
position.
<h2>Ogg stream arrangement</h2>
<h3>Packets, pages, and bitstreams</h3>
<p>Ogg codecs place raw compressed data into <em>packets</em>.
Packets are octet payloads containing the data needed for a single
decompressed unit, eg, one video frame. Packets have no maximum size
and may be zero length. They do not generally have any framing
information; strung together, the unframed packets form a <em>logical
bitstream</em> of codec data with no internal landmarks.
<div class="caption">
<img src="packets.png">
<p> Packets of raw codec data are not typically internally framed.
When they are strung together into a stream without any container to
provide framing, they lose their individual boundaries. Seek and
capture are not possible within an unframed stream, and for many
codecs with variable length payloads and/or early-packet termination
(such as Vorbis), it may become impossible to recover the original
frame boundaries even if the stream is scanned linearly from
beginning to end.
</div>
<p>Logical bitstream packets are grouped and framed into Ogg pages
along with a unique stream <em>serial number</em> to produce a
<em>physical bitstream</em>. An <em>elementary stream</em> is a
physical bitstream containing only a single logical bitstream. Each
page is a self contained entity, although a packet may be split and
encoded across one or more pages. The page decode mechanism is
designed to recognize, verify and handle single pages at a time from
the overall bitstream.
<div class="caption">
<img src="pages.png">
<p> The primary purpose of a container is to provide framing for raw
packets, marking the packet boundaries so the exact packets can be
retrieved for decode later. The container also provides secondary
functions such as capture, timestamping, sequencing, stream
identification and so on. Not all of these functions are represented in the diagram.
<p>In the Ogg container, pages do not necessarily contain
integer numbers of packets. Packets may span across page boundaries
or even multiple pages. This is necessary as pages have a maximum
possible size in order to provide capture guarantees, but packet
size is unbounded.
</div>
<p><a href="framing.html">Ogg Bitstream Framing</a> specifies
the page format of an Ogg bitstream, the packet coding process
and elementary bitstreams in detail.
<h3>Multiplexed bitstreams</h3>
<p>Multiple logical/elementary bitstreams can be combined into a single
<em>multiplexed bitstream</em> by interleaving whole pages from each
contributing elementary stream in time order. The result is a single
physical stream that multiplexes and frames multiple logical streams.
Each logical stream is identified by the unique stream serial number
stamped in its pages. A physical stream may include a 'meta-header'
(such as the <a href="skeleton.html">Ogg Skeleton</a>) comprising its
own Ogg page at the beginning of the physical stream. A decoder
recovers the original logical/elementary bitstreams out of the
physical bitstream by taking the pages in order from the physical
bitstream and redirecting them into the appropriate logical decoding
entity.
<div class="caption">
<img src="multiplex1.png">
<p>Multiple media types are mutliplexed into a single Ogg stream by
interleaving the pages from each elementary physical stream.
</div>
<p><a href="ogg-multiplex.html">Ogg Bitstream Multiplexing</a> specifies
proper multiplexing of an Ogg bitstream in detail.
<h3>Chaining</h3>
<p>Multiple Ogg physical bitstreams may be concatenated into a single new
stream; this is <em>chaining</em>. The bitstreams do not overlap; the
final page of a given logical bitstream is immediately followed by the
initial page of the next.</p>
<p>Each logical bitstream in a chain must have a unique serial number
within the scope of the full physical bitstream, not only within a
particular <em>link</em> or <em>segment</em> of the chain.</p>
<h3>Continuous and discontinuous streams</h3>
<p>Within Ogg, each stream must be declared (by the codec) to be
continuous- or discontinuous-time. Most codecs treat all streams they
use as either inherently continuous- or discontinuous-time, although
this is not a requirement. A codec may, as part of its mapping, choose
according to data in the initial header.
<p>Continuous-time pages are stamped by end-time, discontinuous pages
are stamped by begin-time. Pages in a multiplexed stream are
interleaved in order of the time stamp regardless of stream type.
Both continuous and discontinuous logical streams are used to seek
within a physical stream, however only continuous streams are used to
determine buffering depth; because discontinuous streams are stamped
by start time, they will always 'fall out' at the proper time when
buffering the continuous streams. See 'Examples' for an illustration
of the buffering mechanism.
<h2>Multiplexing Requirements</h2>
<p>Multiplexing requirements within Ogg are straightforward. When
constructing a single-link (unchained) physical bitstream consisting
of multiple elementary streams:
<ol>
<li><p> The initial header for each stream appears in sequence, each
header on a single page. All initial headers must appear with no
intervening data (no auxiliary header pages or packets, no data pages
or packets). Order of the initial headers is unspecified. The
'beginning of stream' flag is set on each initial header.
<li><p> All auxiliary headers for all streams must follow. Order
is unspecified. The final auxiliary header of each stream must flush
its page.
<li><p>Data pages for each stream follow, interleaved in time order.
<li><p>The final page of each stream sets the 'end of stream' flag.
Unlike initial pages, terminal pages for the logical bitstreams need
not occur contiguously; indeed it may not be possible for them to do so.
</oL>
<p><p>Each grouped bitstream must have a unique serial number within the
scope of the physical bitstream.</p>
<h3>chaining and multiplexing</h3>
<p>Multiplexed and/or unmultiplexed bitstreams may be chained
consecutively. Such a physical bitstream obeys all the rules of both
chained and multiplexed streams. Each link, when unchained, must
stand on its own as a valid physical bitstream. Chained streams do
not mix or interleave; a new segment may not begin until all streams
in the preceding segment have terminated. </p>
<h2>Codec Mapping Requirements</h2>
<p>Each codec is allowed some freedom in deciding how its logical
bitstream is encapsulated into an Ogg bitstream (even if it is a
trivial mapping, eg, 'plop the packets in and go'). This is the
codec's <em>mapping</em>. Ogg imposes a few mapping requirements
on any codec.
<ol>
<li><p>The <a href="framing.html">framing specification</a> defines
'beginning of stream' and 'end of stream' page markers via a header
flag (it is possible for a stream to consist of a single page). A
correct stream always consists of an integer number of pages, an easy
requirement given the variable size nature of pages.</p>
<li><p>The first page of an elementary Ogg bitstream consists of a single,
small 'initial header' packet that must include sufficient information
to identify the exact CODEC type. From this initial header, the codec
must also be able to determine its timebase and whether or not it is a
continuous- or discontinuous-time stream. The initial header must fit
on a single page. If a codec makes use of auxiliary headers (for
example, Vorbis uses two auxiliary headers), these headers must follow
the initial header immediately. The last header finishes its page;
data begins on a fresh page.
<p><p>As an example, Ogg Vorbis places the name and revision of the
Vorbis CODEC, the audio rate and the audio quality into this initial
header. Vorbis comments and detailed codec setup appears in the larger
auxiliary headers.</p>
<li><p>Granule positions must be translatable to an exact absolute
time value. As described above, the mux layer is permitted to query a
codec or codec stub plugin to perform this mapping. It is not
necessary for an absolute time to be mappable into a single unique
granule position value.
<li><p>Codecs are not required to use a fixed duration-per-packet (for
example, Vorbis does not). the mux layer is permitted to query a
codec or codec stub plugin for the time duration of a packet.
<li><p>Although an absolute time need not be translatable to a unique
granule position, a codec must be able to determine the unique granule
position of the current packet using the granule position of a
preceeding packet.
<li><p>Packets and pages must be arranged in ascending
granule-position and time order.
</ol>
<h2>Examples</h2>
<em>[More to come shortly; this section is currently being revised and expanded]</em>
<p>Below, we present an example of a multiplexed and chained bitstream:</p>
<p><img src="stream.png" alt="stream"/></p>
<p>In this example, we see pages from five total logical bitstreams
multiplexed into a physical bitstream. Note the following
characteristics:</p>
<ol>
<li>Multiplexed bitstreams in a given link begin together; all of the
initial pages must appear before any data pages. When concurrently
multiplexed groups are chained, the new group does not begin until all
the bitstreams in the previous group have terminated.</li>
<li>The ordering of pages of concurrently multiplexed bitstreams is
goverened by timestamp (not shown here); there is no regular
interleaving order. Pages within a logical bitstream appear in
sequence order.</li>
</ol>
<div id="copyright">
The Xiph Fish Logo is a
trademark (&trade;) of Xiph.Org.<br/>
These pages &copy; 1994 - 2010 Xiph.Org. All rights reserved.
</div>
</div>
</body>
</html>
cpprestsdk_static_tester/libogg/doc/rfc3533.txt 0 → 100644
View file @ 14571fd2
Network Working Group S. Pfeiffer
Request for Comments: 3533 CSIRO
Category: Informational May 2003
The Ogg Encapsulation Format Version 0
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the Ogg bitstream format version 0, which is
a general, freely-available encapsulation format for media streams.
It is able to encapsulate any kind and number of video and audio
encoding formats as well as other data streams in a single bitstream.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [2].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements for a generic encapsulation format . . . . . . . 3
4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . . 3
5. The encapsulation process . . . . . . . . . . . . . . . . . . 6
6. The Ogg page format . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A. Glossary of terms and abbreviations . . . . . . . . . . . . . 13
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
Pfeiffer Informational [Page 1]
RFC 3533 OGG May 2003
1. Introduction
The Ogg bitstream format has been developed as a part of a larger
project aimed at creating a set of components for the coding and
decoding of multimedia content (codecs) which are to be freely
available and freely re-implementable, both in software and in
hardware for the computing community at large, including the Internet
community. It is the intention of the Ogg developers represented by
Xiph.Org that it be usable without intellectual property concerns.
This document describes the Ogg bitstream format and how to use it to
encapsulate one or several media bitstreams created by one or several
encoders. The Ogg transport bitstream is designed to provide
framing, error protection and seeking structure for higher-level
codec streams that consist of raw, unencapsulated data packets, such
as the Vorbis audio codec or the upcoming Tarkin and Theora video
codecs. It is capable of interleaving different binary media and
other time-continuous data streams that are prepared by an encoder as
a sequence of data packets. Ogg provides enough information to
properly separate data back into such encoder created data packets at
the original packet boundaries without relying on decoding to find
packet boundaries.
Please note that the MIME type application/ogg has been registered
with the IANA [1].
2. Definitions
For describing the Ogg encapsulation process, a set of terms will be
used whose meaning needs to be well understood. Therefore, some of
the most fundamental terms are defined now before we start with the
description of the requirements for a generic media stream
encapsulation format, the process of encapsulation, and the concrete
format of the Ogg bitstream. See the Appendix for a more complete
glossary.
The result of an Ogg encapsulation is called the "Physical (Ogg)
Bitstream". It encapsulates one or several encoder-created
bitstreams, which are called "Logical Bitstreams". A logical
bitstream, provided to the Ogg encapsulation process, has a
structure, i.e., it is split up into a sequence of so-called
"Packets". The packets are created by the encoder of that logical
bitstream and represent meaningful entities for that encoder only
(e.g., an uncompressed stream may use video frames as packets). They
do not contain boundary information - strung together they appear to
be streams of random bytes with no landmarks.
Pfeiffer Informational [Page 2]
RFC 3533 OGG May 2003
Please note that the term "packet" is not used in this document to
signify entities for transport over a network.
3. Requirements for a generic encapsulation format
The design idea behind Ogg was to provide a generic, linear media
transport format to enable both file-based storage and stream-based
transmission of one or several interleaved media streams independent
of the encoding format of the media data. Such an encapsulation
format needs to provide:
o framing for logical bitstreams.
o interleaving of different logical bitstreams.
o detection of corruption.
o recapture after a parsing error.
o position landmarks for direct random access of arbitrary positions
in the bitstream.
o streaming capability (i.e., no seeking is needed to build a 100%
complete bitstream).
o small overhead (i.e., use no more than approximately 1-2% of
bitstream bandwidth for packet boundary marking, high-level
framing, sync and seeking).
o simplicity to enable fast parsing.
o simple concatenation mechanism of several physical bitstreams.
All of these design considerations have been taken into consideration
for Ogg. Ogg supports framing and interleaving of logical
bitstreams, seeking landmarks, detection of corruption, and stream
resynchronisation after a parsing error with no more than
approximately 1-2% overhead. It is a generic framework to perform
encapsulation of time-continuous bitstreams. It does not know any
specifics about the codec data that it encapsulates and is thus
independent of any media codec.
4. The Ogg bitstream format
A physical Ogg bitstream consists of multiple logical bitstreams
interleaved in so-called "Pages". Whole pages are taken in order
from multiple logical bitstreams multiplexed at the page level. The
logical bitstreams are identified by a unique serial number in the
Pfeiffer Informational [Page 3]
RFC 3533 OGG May 2003
header of each page of the physical bitstream. This unique serial
number is created randomly and does not have any connection to the
content or encoder of the logical bitstream it represents. Pages of
all logical bitstreams are concurrently interleaved, but they need
not be in a regular order - they are only required to be consecutive
within the logical bitstream. Ogg demultiplexing reconstructs the
original logical bitstreams from the physical bitstream by taking the
pages in order from the physical bitstream and redirecting them into
the appropriate logical decoding entity.
Each Ogg page contains only one type of data as it belongs to one
logical bitstream only. Pages are of variable size and have a page
header containing encapsulation and error recovery information. Each
logical bitstream in a physical Ogg bitstream starts with a special
start page (bos=beginning of stream) and ends with a special page
(eos=end of stream).
The bos page contains information to uniquely identify the codec type
and MAY contain information to set up the decoding process. The bos
page SHOULD also contain information about the encoded media - for
example, for audio, it should contain the sample rate and number of
channels. By convention, the first bytes of the bos page contain
magic data that uniquely identifies the required codec. It is the
responsibility of anyone fielding a new codec to make sure it is
possible to reliably distinguish his/her codec from all other codecs
in use. There is no fixed way to detect the end of the codec-
identifying marker. The format of the bos page is dependent on the
codec and therefore MUST be given in the encapsulation specification
of that logical bitstream type. Ogg also allows but does not require
secondary header packets after the bos page for logical bitstreams
and these must also precede any data packets in any logical
bitstream. These subsequent header packets are framed into an
integral number of pages, which will not contain any data packets.
So, a physical bitstream begins with the bos pages of all logical
bitstreams containing one initial header packet per page, followed by
the subsidiary header packets of all streams, followed by pages
containing data packets.
The encapsulation specification for one or more logical bitstreams is
called a "media mapping". An example for a media mapping is "Ogg
Vorbis", which uses the Ogg framework to encapsulate Vorbis-encoded
audio data for stream-based storage (such as files) and transport
(such as TCP streams or pipes). Ogg Vorbis provides the name and
revision of the Vorbis codec, the audio rate and the audio quality on
the Ogg Vorbis bos page. It also uses two additional header pages
per logical bitstream. The Ogg Vorbis bos page starts with the byte
0x01, followed by "vorbis" (a total of 7 bytes of identifier).
Pfeiffer Informational [Page 4]
RFC 3533 OGG May 2003
Ogg knows two types of multiplexing: concurrent multiplexing (so-
called "Grouping") and sequential multiplexing (so-called
"Chaining"). Grouping defines how to interleave several logical
bitstreams page-wise in the same physical bitstream. Grouping is for
example needed for interleaving a video stream with several
synchronised audio tracks using different codecs in different logical
bitstreams. Chaining on the other hand, is defined to provide a
simple mechanism to concatenate physical Ogg bitstreams, as is often
needed for streaming applications.
In grouping, all bos pages of all logical bitstreams MUST appear
together at the beginning of the Ogg bitstream. The media mapping
specifies the order of the initial pages. For example, the grouping
of a specific Ogg video and Ogg audio bitstream may specify that the
physical bitstream MUST begin with the bos page of the logical video
bitstream, followed by the bos page of the audio bitstream. Unlike
bos pages, eos pages for the logical bitstreams need not all occur
contiguously. Eos pages may be 'nil' pages, that is, pages
containing no content but simply a page header with position
information and the eos flag set in the page header. Each grouped
logical bitstream MUST have a unique serial number within the scope
of the physical bitstream.
In chaining, complete logical bitstreams are concatenated. The
bitstreams do not overlap, i.e., the eos page of a given logical
bitstream is immediately followed by the bos page of the next. Each
chained logical bitstream MUST have a unique serial number within the
scope of the physical bitstream.
It is possible to consecutively chain groups of concurrently
multiplexed bitstreams. The groups, when unchained, MUST stand on
their own as a valid concurrently multiplexed bitstream. The
following diagram shows a schematic example of such a physical
bitstream that obeys all the rules of both grouped and chained
multiplexed bitstreams.
physical bitstream with pages of
different logical bitstreams grouped and chained
-------------------------------------------------------------
|*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#|
-------------------------------------------------------------
bos bos bos eos eos eos bos eos
In this example, there are two chained physical bitstreams, the first
of which is a grouped stream of three logical bitstreams A, B, and C.
The second physical bitstream is chained after the end of the grouped
bitstream, which ends after the last eos page of all its grouped
logical bitstreams. As can be seen, grouped bitstreams begin
Pfeiffer Informational [Page 5]
RFC 3533 OGG May 2003
together - all of the bos pages MUST appear before any data pages.
It can also be seen that pages of concurrently multiplexed bitstreams
need not conform to a regular order. And it can be seen that a
grouped bitstream can end long before the other bitstreams in the
group end.
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.
A specific definition of a media mapping using Ogg may put further
constraints on its specific use of the Ogg bitstream format. For
example, a specific media mapping may require that all the eos pages
for all grouped bitstreams need to appear in direct sequence. An
example for a media mapping is the specification of "Ogg Vorbis".
Another example is the upcoming "Ogg Theora" specification which
encapsulates Theora-encoded video data and usually comes multiplexed
with a Vorbis stream for an Ogg containing synchronised audio and
video. As Ogg does not specify temporal relationships between the
encapsulated concurrently multiplexed bitstreams, the temporal
synchronisation between the audio and video stream will be specified
in this media mapping. To enable streaming, pages from various
logical bitstreams will typically be interleaved in chronological
order.
5. The encapsulation process
The process of multiplexing different logical bitstreams happens at
the level of pages as described above. The bitstreams provided by
encoders are however handed over to Ogg as so-called "Packets" with
packet boundaries dependent on the encoding format. The process of
encapsulating packets into pages will be described now.
From Ogg's perspective, packets can be of any arbitrary size. A
specific media mapping will define how to group or break up packets
from a specific media encoder. As Ogg pages have a maximum size of
about 64 kBytes, sometimes a packet has to be distributed over
several pages. To simplify that process, Ogg divides each packet
into 255 byte long chunks plus a final shorter chunk. These chunks
are called "Ogg Segments". They are only a logical construct and do
not have a header for themselves.
Pfeiffer Informational [Page 6]
RFC 3533 OGG May 2003
A group of contiguous segments is wrapped into a variable length page
preceded by a header. A segment table in the page header tells about
the "Lacing values" (sizes) of the segments included in the page. A
flag in the page header tells whether a page contains a packet
continued from a previous page. Note that a lacing value of 255
implies that a second lacing value follows in the packet, and a value
of less than 255 marks the end of the packet after that many
additional bytes. A packet of 255 bytes (or a multiple of 255 bytes)
is terminated by a lacing value of 0. Note also that a 'nil' (zero
length) packet is not an error; it consists of nothing more than a
lacing value of zero in the header.
The encoding is optimized for speed and the expected case of the
majority of packets being between 50 and 200 bytes large. This is a
design justification rather than a recommendation. This encoding
both avoids imposing a maximum packet size as well as imposing
minimum overhead on small packets. In contrast, e.g., simply using
two bytes at the head of every packet and having a max packet size of
32 kBytes would always penalize small packets (< 255 bytes, the
typical case) with twice the segmentation overhead. Using the lacing
values as suggested, small packets see the minimum possible byte-
aligned overhead (1 byte) and large packets (>512 bytes) see a fairly
constant ~0.5% overhead on encoding space.
Pfeiffer Informational [Page 7]
RFC 3533 OGG May 2003
The following diagram shows a schematic example of a media mapping
using Ogg and grouped logical bitstreams:
logical bitstream with packet boundaries
-----------------------------------------------------------------
> | packet_1 | packet_2 | packet_3 | <
-----------------------------------------------------------------
|segmentation (logically only)
v
packet_1 (5 segments) packet_2 (4 segs) p_3 (2 segs)
------------------------------ -------------------- ------------
.. |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | ..
------------------------------ -------------------- ------------
| page encapsulation
v
page_1 (packet_1 data) page_2 (pket_1 data) page_3 (packet_2 data)
------------------------ ---------------- ------------------------
|H|------------------- | |H|----------- | |H|------------------- |
|D||seg_1|seg_2|seg_3| | |D|seg_4|s_5 | | |D||seg_1|seg_2|seg_3| | ...
|R|------------------- | |R|----------- | |R|------------------- |
------------------------ ---------------- ------------------------
|
pages of |
other --------| |
logical -------
bitstreams | MUX |
-------
|
v
page_1 page_2 page_3
------ ------ ------- ----- -------
... || | || | || | || | || | ...
------ ------ ------- ----- -------
physical Ogg bitstream
In this example we take a snapshot of the encapsulation process of
one logical bitstream. We can see part of that bitstream's
subdivision into packets as provided by the codec. The Ogg
encapsulation process chops up the packets into segments. The
packets in this example are rather large such that packet_1 is split
into 5 segments - 4 segments with 255 bytes and a final smaller one.
Packet_2 is split into 4 segments - 3 segments with 255 bytes and a
Pfeiffer Informational [Page 8]
RFC 3533 OGG May 2003
final very small one - and packet_3 is split into two segments. The
encapsulation process then creates pages, which are quite small in
this example. Page_1 consists of the first three segments of
packet_1, page_2 contains the remaining 2 segments from packet_1, and
page_3 contains the first three pages of packet_2. Finally, this
logical bitstream is multiplexed into a physical Ogg bitstream with
pages of other logical bitstreams.
6. The Ogg page format
A physical Ogg bitstream consists of a sequence of concatenated
pages. Pages are of variable size, usually 4-8 kB, maximum 65307
bytes. A page header contains all the information needed to
demultiplex the logical bitstreams out of the physical bitstream and
to perform basic error recovery and landmarks for seeking. Each page
is a self-contained entity such that the page decode mechanism can
recognize, verify, and handle single pages at a time without
requiring the overall bitstream.
The Ogg page header has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capture_pattern: Magic number for page start "OggS" | 0-3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | header_type | granule_position | 4-7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 8-11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | bitstream_serial_number | 12-15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | page_sequence_number | 16-19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | CRC_checksum | 20-23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |page_segments | segment_table | 24-27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | 28-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSb (least significant bit) comes first in the Bytes. Fields
with more than one byte length are encoded LSB (least significant
byte) first.
Pfeiffer Informational [Page 9]
RFC 3533 OGG May 2003
The fields in the page header have the following meaning:
1. capture_pattern: a 4 Byte field that signifies the beginning of a
page. It contains the magic numbers:
0x4f 'O'
0x67 'g'
0x67 'g'
0x53 'S'
It helps a decoder to find the page boundaries and regain
synchronisation after parsing a corrupted stream. Once the
capture pattern is found, the decoder verifies page sync and
integrity by computing and comparing the checksum.
2. stream_structure_version: 1 Byte signifying the version number of
the Ogg file format used in this stream (this document specifies
version 0).
3. header_type_flag: the bits in this 1 Byte field identify the
specific type of this page.
* bit 0x01
set: page contains data of a packet continued from the previous
page
unset: page contains a fresh packet
* bit 0x02
set: this is the first page of a logical bitstream (bos)
unset: this page is not a first page
* bit 0x04
set: this is the last page of a logical bitstream (eos)
unset: this page is not a last page
4. granule_position: an 8 Byte field containing position information.
For example, for an audio stream, it MAY contain the total number
of PCM samples encoded after including all frames finished on this
page. For a video stream it MAY contain the total number of video
Pfeiffer Informational [Page 10]
RFC 3533 OGG May 2003
frames encoded after this page. This is a hint for the decoder
and gives it some timing and position information. Its meaning is
dependent on the codec for that logical bitstream and specified in
a specific media mapping. A special value of -1 (in two's
complement) indicates that no packets finish on this page.
5. bitstream_serial_number: a 4 Byte field containing the unique
serial number by which the logical bitstream is identified.
6. page_sequence_number: a 4 Byte field containing the sequence
number of the page so the decoder can identify page loss. This
sequence number is increasing on each logical bitstream
separately.
7. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of
the page (including header with zero CRC field and page content).
The generator polynomial is 0x04c11db7.
8. number_page_segments: 1 Byte giving the number of segment entries
encoded in the segment table.
9. segment_table: number_page_segments Bytes containing the lacing
values of all segments in this page. Each Byte contains one
lacing value.
The total header size in bytes is given by:
header_size = number_page_segments + 27 [Byte]
The total page size in Bytes is given by:
page_size = header_size + sum(lacing_values: 1..number_page_segments)
[Byte]
7. Security Considerations
The Ogg encapsulation format is a container format and only
encapsulates content (such as Vorbis-encoded audio). It does not
provide for any generic encryption or signing of itself or its
contained content bitstreams. However, it encapsulates any kind of
content bitstream as long as there is a codec for it, and is thus
able to contain encrypted and signed content data. It is also
possible to add an external security mechanism that encrypts or signs
an Ogg physical bitstream and thus provides content confidentiality
and authenticity.
As Ogg encapsulates binary data, it is possible to include executable
content in an Ogg bitstream. This can be an issue with applications
that are implemented using the Ogg format, especially when Ogg is
used for streaming or file transfer in a networking scenario. As
Pfeiffer Informational [Page 11]
RFC 3533 OGG May 2003
such, Ogg does not pose a threat there. However, an application
decoding Ogg and its encapsulated content bitstreams has to ensure
correct handling of manipulated bitstreams, of buffer overflows and
the like.
8. References
[1] Walleij, L., "The application/ogg Media Type", RFC 3534, May
2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Pfeiffer Informational [Page 12]
RFC 3533 OGG May 2003
Appendix A. Glossary of terms and abbreviations
bos page: The initial page (beginning of stream) of a logical
bitstream which contains information to identify the codec type
and other decoding-relevant information.
chaining (or sequential multiplexing): Concatenation of two or more
complete physical Ogg bitstreams.
eos page: The final page (end of stream) of a logical bitstream.
granule position: An increasing position number for a specific
logical bitstream stored in the page header. Its meaning is
dependent on the codec for that logical bitstream and specified in
a specific media mapping.
grouping (or concurrent multiplexing): Interleaving of pages of
several logical bitstreams into one complete physical Ogg
bitstream under the restriction that all bos pages of all grouped
logical bitstreams MUST appear before any data pages.
lacing value: An entry in the segment table of a page header
representing the size of the related segment.
logical bitstream: A sequence of bits being the result of an encoded
media stream.
media mapping: A specific use of the Ogg encapsulation format
together with a specific (set of) codec(s).
(Ogg) packet: A subpart of a logical bitstream that is created by the
encoder for that bitstream and represents a meaningful entity for
the encoder, but only a sequence of bits to the Ogg encapsulation.
(Ogg) page: A physical bitstream consists of a sequence of Ogg pages
containing data of one logical bitstream only. It usually
contains a group of contiguous segments of one packet only, but
sometimes packets are too large and need to be split over several
pages.
physical (Ogg) bitstream: The sequence of bits resulting from an Ogg
encapsulation of one or several logical bitstreams. It consists
of a sequence of pages from the logical bitstreams with the
restriction that the pages of one logical bitstream MUST come in
their correct temporal order.
Pfeiffer Informational [Page 13]
RFC 3533 OGG May 2003
(Ogg) segment: The Ogg encapsulation process splits each packet into
chunks of 255 bytes plus a last fractional chunk of less than 255
bytes. These chunks are called segments.
Appendix B. Acknowledgements
The author gratefully acknowledges the work that Christopher
Montgomery and the Xiph.Org foundation have done in defining the Ogg
multimedia project and as part of it the open file format described
in this document. The author hopes that providing this document to
the Internet community will help in promoting the Ogg multimedia
project at http://www.xiph.org/. Many thanks also for the many
technical and typo corrections that C. Montgomery and the Ogg
community provided as feedback to this RFC.
Author's Address
Silvia Pfeiffer
CSIRO, Australia
Locked Bag 17
North Ryde, NSW 2113
Australia
Phone: +61 2 9325 3141
EMail: Silvia.Pfeiffer@csiro.au
URI: http://www.cmis.csiro.au/Silvia.Pfeiffer/
Pfeiffer Informational [Page 14]
RFC 3533 OGG May 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pfeiffer Informational [Page 15]
cpprestsdk_static_tester/libogg/doc/rfc5334.txt 0 → 100644
View file @ 14571fd2
Network Working Group I. Goncalves
Request for Comments: 5334 S. Pfeiffer
Obsoletes: 3534 C. Montgomery
Category: Standards Track Xiph
September 2008
Ogg Media Types
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document describes the registration of media types for the Ogg
container format and conformance requirements for implementations of
these types. This document obsoletes RFC 3534.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Changes Since RFC 3534 . . . . . . . . . . . . . . . . . . 2
3. Conformance and Document Conventions . . . . . . . . . . . 3
4. Deployed Media Types and Compatibility . . . . . . . . . . 3
5. Relation between the Media Types . . . . . . . . . . . . . 5
6. Encoding Considerations . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . 6
8. Interoperability Considerations . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 7
10.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 7
10.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
12. Copying Conditions . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . . 11
Goncalves, et al. Standards Track [Page 1]
RFC 5334 Ogg Media Types September 2008
1. Introduction
This document describes media types for Ogg, a data encapsulation
format defined by the Xiph.Org Foundation for public use. Refer to
"Introduction" in [RFC3533] and "Overview" in [Ogg] for background
information on this container format.
Binary data contained in Ogg, such as Vorbis and Theora, has
historically been interchanged using the application/ogg media type
as defined by [RFC3534]. This document obsoletes [RFC3534] and
defines three media types for different types of content in Ogg to
reflect this usage in the IANA media type registry, to foster
interoperability by defining underspecified aspects, and to provide
general security considerations.
The Ogg container format is known to contain [Theora] or [Dirac]
video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC]
audio, and [CMML] timed text/metadata. As Ogg encapsulates binary
data, it is possible to include any other type of video, audio,
image, text, or, generally speaking, any time-continuously sampled
data.
While raw packets from these data sources may be used directly by
transport mechanisms that provide their own framing and packet-
separation mechanisms (such as UDP datagrams or RTP), Ogg is a
solution for stream based storage (such as files) and transport (such
as TCP streams or pipes). The media types defined in this document
are needed to correctly identify such content when it is served over
HTTP, included in multi-part documents, or used in other places where
media types [RFC2045] are used.
2. Changes Since RFC 3534
o The type "application/ogg" is redefined.
o The types "video/ogg" and "audio/ogg" are defined.
o New file extensions are defined.
o New Macintosh file type codes are defined.
o The codecs parameter is defined for optional use.
o The Ogg Skeleton extension becomes a recommended addition for
content served under the new types.
Goncalves, et al. Standards Track [Page 2]
RFC 5334 Ogg Media Types September 2008
3. Conformance and Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119] and
indicate requirement levels for compliant implementations.
Requirements apply to all implementations unless otherwise stated.
An implementation is a software module that supports one of the media
types defined in this document. Software modules may support
multiple media types, but conformance is considered individually for
each type.
Implementations that fail to satisfy one or more "MUST" requirements
are considered non-compliant. Implementations that satisfy all
"MUST" requirements, but fail to satisfy one or more "SHOULD"
requirements, are said to be "conditionally compliant". All other
implementations are "unconditionally compliant".
4. Deployed Media Types and Compatibility
The application/ogg media type has been used in an ad hoc fashion to
label and exchange multimedia content in Ogg containers.
Use of the "application" top-level type for this kind of content is
known to be problematic, in particular since it obfuscates video and
audio content. This document thus defines the media types,
o video/ogg
o audio/ogg
which are intended for common use and SHOULD be used when dealing
with video or audio content, respectively. This document also
obsoletes the [RFC3534] definition of application/ogg and marks it
for complex data (e.g., multitrack visual, audio, textual, and other
time-continuously sampled data), which is not clearly video or audio
data and thus not suited for either the video/ogg or audio/ogg types.
Refer to the following section for more details.
An Ogg bitstream generally consists of one or more logical bitstreams
that each consist of a series of header and data pages packetising
time-continuous binary data [RFC3533]. The content types of the
logical bitstreams may be identified without decoding the header
pages of the logical bitstreams through use of a [Skeleton]
bitstream. Using Ogg Skeleton is REQUIRED for content served under
Goncalves, et al. Standards Track [Page 3]
RFC 5334 Ogg Media Types September 2008
the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
as Skeleton contains identifiers to describe the different
encapsulated data.
Furthermore, it is RECOMMENDED that implementations that identify a
logical bitstream that they cannot decode SHOULD ignore it, while
continuing to decode the ones they can. Such precaution ensures
backward and forward compatibility with existing and future data.
These media types can optionally use the "codecs" parameter described
in [RFC4281]. Codecs encapsulated in Ogg require a text identifier
at the beginning of the first header page, hence a machine-readable
method to identify the encapsulated codecs would be through this
header. The following table illustrates how those header values map
into strings that are used in the "codecs" parameter when dealing
with Ogg media types.
Codec Identifier | Codecs Parameter
-----------------------------------------------------------
char[5]: 'BBCD\0' | dirac
char[5]: '\177FLAC' | flac
char[7]: '\x80theora' | theora
char[7]: '\x01vorbis' | vorbis
char[8]: 'CELT ' | celt
char[8]: 'CMML\0\0\0\0' | cmml
char[8]: '\213JNG\r\n\032\n' | jng
char[8]: '\x80kate\0\0\0' | kate
char[8]: 'OggMIDI\0' | midi
char[8]: '\212MNG\r\n\032\n' | mng
char[8]: 'PCM ' | pcm
char[8]: '\211PNG\r\n\032\n' | png
char[8]: 'Speex ' | speex
char[8]: 'YUV4MPEG' | yuv4mpeg
An up-to-date version of this table is kept at Xiph.org (see
[Codecs]).
Possible examples include:
o application/ogg; codecs="theora, cmml, ecmascript"
o video/ogg; codecs="theora, vorbis"
o audio/ogg; codecs=speex
Goncalves, et al. Standards Track [Page 4]
RFC 5334 Ogg Media Types September 2008
5. Relation between the Media Types
As stated in the previous section, this document describes three
media types that are targeted at different data encapsulated in Ogg.
Since Ogg is capable of encapsulating any kind of data, the multiple
usage scenarios have revealed interoperability issues between
implementations when dealing with content served solely under the
application/ogg type.
While this document does redefine the earlier definition of
application/ogg, this media type will continue to embrace the widest
net possible of content with the video/ogg and audio/ogg types being
smaller subsets of it. However, the video/ogg and audio/ogg types
take precedence in a subset of the usages, specifically when serving
multimedia content that is not complex enough to warrant the use of
application/ogg. Following this line of thought, the audio/ogg type
is an even smaller subset within video/ogg, as it is not intended to
refer to visual content.
As such, the application/ogg type is the recommended choice to serve
content aimed at scientific and other applications that require
various multiplexed signals or streams of continuous data, with or
without scriptable control of content. For bitstreams containing
visual, timed text, and any other type of material that requires a
visual interface, but that is not complex enough to warrant serving
under application/ogg, the video/ogg type is recommended. In
situations where the Ogg bitstream predominantly contains audio data
(lyrics, metadata, or cover art notwithstanding), it is recommended
to use the audio/ogg type.
6. Encoding Considerations
Binary: The content consists of an unrestricted sequence of octets.
Note:
o Ogg encapsulated content is binary data and should be transmitted
in a suitable encoding without CR/LF conversion, 7-bit stripping,
etc.; base64 [RFC4648] is generally preferred for binary-to-text
encoding.
o Media types described in this document are used for stream based
storage (such as files) and transport (such as TCP streams or
pipes); separate types are used to identify codecs such as in
real-time applications for the RTP payload formats of Theora
[ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
as for identification of encapsulated data within Ogg through
Skeleton.
Goncalves, et al. Standards Track [Page 5]
RFC 5334 Ogg Media Types September 2008
7. Security Considerations
Refer to [RFC3552] for a discussion of terminology used in this
section.
The Ogg encapsulation format is a container and only a carrier of
content (such as audio, video, and displayable text data) with a very
rigid definition. This format in itself is not more vulnerable than
any other content framing mechanism.
Ogg does not provide for any generic encryption or signing of itself
or its contained bitstreams. However, it encapsulates any kind of
binary content and is thus able to contain encrypted and signed
content data. It is also possible to add an external security
mechanism that encrypts or signs an Ogg bitstream and thus provides
content confidentiality and authenticity.
As Ogg encapsulates binary data, it is possible to include executable
content in an Ogg bitstream. Implementations SHOULD NOT execute such
content without prior validation of its origin by the end-user.
Issues may arise on applications that use Ogg for streaming or file
transfer in a networking scenario. In such cases, implementations
decoding Ogg and its encapsulated bitstreams have to ensure correct
handling of manipulated bitstreams, of buffer overflows, and similar
issues.
It is also possible to author malicious Ogg bitstreams, which attempt
to call for an excessively large picture size, high sampling-rate
audio, etc. Implementations SHOULD protect themselves against this
kind of attack.
Ogg has an extensible structure, so that it is theoretically possible
that metadata fields or media formats might be defined in the future
which might be used to induce particular actions on the part of the
recipient, thus presenting additional security risks. However, this
type of capability is currently not supported in the referenced
specification.
Implementations may fail to implement a specific security model or
other means to prevent possibly dangerous operations. Such failure
might possibly be exploited to gain unauthorized access to a system
or sensitive information; such failure constitutes an unknown factor
and is thus considered out of the scope of this document.
Goncalves, et al. Standards Track [Page 6]
RFC 5334 Ogg Media Types September 2008
8. Interoperability Considerations
The Ogg container format is device-, platform-, and vendor-neutral
and has proved to be widely implementable across different computing
platforms through a wide range of encoders and decoders. A broadly
portable reference implementation [libogg] is available under the
revised (3-clause) BSD license, which is a Free Software license.
The Xiph.Org Foundation has defined the specification,
interoperability, and conformance and conducts regular
interoperability testing.
The use of the Ogg Skeleton extension has been confirmed to not cause
interoperability issues with existing implementations. Third parties
are, however, welcome to conduct their own testing.
9. IANA Considerations
In accordance with the procedures set forth in [RFC4288], this
document registers two new media types and redefines the existing
application/ogg as defined in the following section.
10. Ogg Media Types
10.1. application/ogg
Type name: application
Subtype name: ogg
Required parameters: none
Optional parameters: codecs, whose syntax is defined in RFC 4281.
See section 4 of RFC 5334 for a list of allowed values.
Encoding considerations: See section 6 of RFC 5334.
Security considerations: See section 7 of RFC 5334.
Interoperability considerations: None, as noted in section 8 of RFC
5334.
Published specification: RFC 3533
Applications which use this media type: Scientific and otherwise that
require various multiplexed signals or streams of data, with or
without scriptable control of content.
Goncalves, et al. Standards Track [Page 7]
RFC 5334 Ogg Media Types September 2008
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
correspond to the string "OggS".
File extension(s): .ogx
RFC 3534 defined the file extension .ogg for application/ogg,
which RFC 5334 obsoletes in favor of .ogx due to concerns where,
historically, some implementations expect .ogg files to be solely
Vorbis-encoded audio.
Macintosh File Type Code(s): OggX
Person & Email address to contact for further information: See
"Authors' Addresses" section.
Intended usage: COMMON
Restrictions on usage: The type application/ogg SHOULD only be used
in situations where it is not appropriate to serve data under the
video/ogg or audio/ogg types. Data served under the application/ogg
type SHOULD use the .ogx file extension and MUST contain an Ogg
Skeleton logical bitstream to identify all other contained logical
bitstreams.
Author: See "Authors' Addresses" section.
Change controller: The Xiph.Org Foundation.
10.2. video/ogg
Type name: video
Subtype name: ogg
Required parameters: none
Optional parameters: codecs, whose syntax is defined in RFC 4281.
See section 4 of RFC 5334 for a list of allowed values.
Encoding considerations: See section 6 of RFC 5334.
Security considerations: See section 7 of RFC 5334.
Interoperability considerations: None, as noted in section 8 of RFC
5334.
Goncalves, et al. Standards Track [Page 8]
RFC 5334 Ogg Media Types September 2008
Published specification: RFC 3533
Applications which use this media type: Multimedia applications,
including embedded, streaming, and conferencing tools.
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
correspond to the string "OggS".
File extension(s): .ogv
Macintosh File Type Code(s): OggV
Person & Email address to contact for further information: See
"Authors' Addresses" section.
Intended usage: COMMON
Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
bitstreams containing visual, audio, timed text, or any other type of
material that requires a visual interface. It is intended for
content not complex enough to warrant serving under "application/
ogg"; for example, a combination of Theora video, Vorbis audio,
Skeleton metadata, and CMML captioning. Data served under the type
"video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
Implementations interacting with the type "video/ogg" SHOULD support
multiplexed bitstreams.
Author: See "Authors' Addresses" section.
Change controller: The Xiph.Org Foundation.
10.3. audio/ogg
Type name: audio
Subtype name: ogg
Required parameters: none
Optional parameters: codecs, whose syntax is defined in RFC 4281.
See section 4 of RFC 5334 for a list of allowed values.
Encoding considerations: See section 6 of RFC 5334.
Security considerations: See section 7 of RFC 5334.
Goncalves, et al. Standards Track [Page 9]
RFC 5334 Ogg Media Types September 2008
Interoperability considerations: None, as noted in section 8 of RFC
5334.
Published specification: RFC 3533
Applications which use this media type: Multimedia applications,
including embedded, streaming, and conferencing tools.
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
correspond to the string "OggS".
File extension(s): .oga, .ogg, .spx
Macintosh File Type Code(s): OggA
Person & Email address to contact for further information: See
"Authors' Addresses" section.
Intended usage: COMMON
Restrictions on usage: The type "audio/ogg" SHOULD be used when the
Ogg bitstream predominantly contains audio data. Content served
under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
bitstream when using the default .oga file extension. The .ogg and
.spx file extensions indicate a specialization that requires no
Skeleton due to backward compatibility concerns with existing
implementations. In particular, .ogg is used for Ogg files that
contain only a Vorbis bitstream, while .spx is used for Ogg files
that contain only a Speex bitstream.
Author: See "Authors' Addresses" section.
Change controller: The Xiph.Org Foundation.
11. Acknowledgements
The authors gratefully acknowledge the contributions of Magnus
Westerlund, Alfred Hoenes, and Peter Saint-Andre.
12. Copying Conditions
The authors agree to grant third parties the irrevocable right to
copy, use and distribute the work, with or without modification, in
any medium, without royalty, provided that, unless separate
permission is granted, redistributed modified works do not contain
misleading author, version, name of work, or endorsement information.
Goncalves, et al. Standards Track [Page 10]
RFC 5334 Ogg Media Types September 2008
13. References
13.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533, May 2003.
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
Parameter for "Bucket" Media Types", RFC 4281,
November 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288,
December 2005.
13.2. Informative References
[CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
Media Markup Language (CMML)", Work in Progress,
March 2006.
[Codecs] Pfeiffer, S. and I. Goncalves, "Specification of MIME
types and respective codecs parameter", July 2008,
<http://wiki.xiph.org/index.php/MIMETypesCodecs>.
[Dirac] Dirac Group, "Dirac Specification",
<http://diracvideo.org/specifications/>.
[FLAC] Coalson, J., "The FLAC Format",
<http://flac.sourceforge.net/format.html>.
[libogg] Xiph.Org Foundation, "The libogg API", June 2000,
<http://xiph.org/ogg/doc/libogg>.
[Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
logical and physical bitstream overview, Ogg logical
bitstream framing, Ogg multi-stream multiplexing",
<http://xiph.org/ogg/doc>.
[RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
May 2003.
Goncalves, et al. Standards Track [Page 11]
RFC 5334 Ogg Media Types September 2008
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded
Audio", RFC 5215, August 2008.
[Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
Bitstream", November 2007,
<http://xiph.org/ogg/doc/skeleton.html>.
[Speex] Valin, J., "The Speex Codec Manual", February 2002,
<http://speex.org/docs/manual/speex-manual>.
[SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
"RTP Payload Format for the Speex Codec", Work
in Progress, February 2008.
[Theora] Xiph.Org Foundation, "Theora Specification",
October 2007, <http://theora.org/doc/Theora.pdf>.
[ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded
Video", Work in Progress, June 2006.
[Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004,
<http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
Goncalves, et al. Standards Track [Page 12]
RFC 5334 Ogg Media Types September 2008
Authors' Addresses
Ivo Emanuel Goncalves
Xiph.Org Foundation
21 College Hill Road
Somerville, MA 02144
US
EMail: justivo@gmail.com
URI: xmpp:justivo@gmail.com
Silvia Pfeiffer
Xiph.Org Foundation
EMail: silvia@annodex.net
URI: http://annodex.net/
Christopher Montgomery
Xiph.Org Foundation
EMail: monty@xiph.org
URI: http://xiph.org
Goncalves, et al. Standards Track [Page 13]
RFC 5334 Ogg Media Types September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Goncalves, et al. Standards Track [Page 14]
cpprestsdk_static_tester/libogg/doc/skeleton.html 0 → 100644
View file @ 14571fd2
<!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>
\ No newline at end of file
cpprestsdk_static_tester/libogg/include/Makefile.am 0 → 100644
View file @ 14571fd2
## Process this file with automake to produce Makefile.in
SUBDIRS = ogg
cpprestsdk_static_tester/libogg/include/Makefile.in 0 → 100644
View file @ 14571fd2
# Makefile.in generated by automake 1.15 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2014 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
subdir = include
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
RECURSIVE_TARGETS = all-recursive check-recursive cscopelist-recursive \
ctags-recursive dvi-recursive html-recursive info-recursive \
install-data-recursive install-dvi-recursive \
install-exec-recursive install-html-recursive \
install-info-recursive install-pdf-recursive \
install-ps-recursive install-recursive installcheck-recursive \
installdirs-recursive pdf-recursive ps-recursive \
tags-recursive uninstall-recursive
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive \
distclean-recursive maintainer-clean-recursive
am__recursive_targets = \
$(RECURSIVE_TARGETS) \
$(RECURSIVE_CLEAN_TARGETS) \
$(am__extra_recursive_targets)
AM_RECURSIVE_TARGETS = $(am__recursive_targets:-recursive=) TAGS CTAGS \
distdir
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
# Read a list of newline-separated strings from the standard input,
# and print each of them once, without duplicates. Input order is
# *not* preserved.
am__uniquify_input = $(AWK) '\
BEGIN { nonempty = 0; } \
{ items[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in items) print i; }; } \
'
# Make sure the list of sources is unique. This is necessary because,
# e.g., the same source file might be shared among _SOURCES variables
# for different programs/libraries.
am__define_uniq_tagged_files = \
list='$(am__tagged_files)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | $(am__uniquify_input)`
ETAGS = etags
CTAGS = ctags
DIST_SUBDIRS = $(SUBDIRS)
am__DIST_COMMON = $(srcdir)/Makefile.in
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
am__relativize = \
dir0=`pwd`; \
sed_first='s,^\([^/]*\)/.*$$,\1,'; \
sed_rest='s,^[^/]*/*,,'; \
sed_last='s,^.*/\([^/]*\)$$,\1,'; \
sed_butlast='s,/*[^/]*$$,,'; \
while test -n "$$dir1"; do \
first=`echo "$$dir1" | sed -e "$$sed_first"`; \
if test "$$first" != "."; then \
if test "$$first" = ".."; then \
dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \
dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \
else \
first2=`echo "$$dir2" | sed -e "$$sed_first"`; \
if test "$$first2" = "$$first"; then \
dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \
else \
dir2="../$$dir2"; \
fi; \
dir0="$$dir0"/"$$first"; \
fi; \
fi; \
dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \
done; \
reldir="$$dir2"
ACLOCAL = @ACLOCAL@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
AR = @AR@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CYGPATH_W = @CYGPATH_W@
DEBUG = @DEBUG@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DLLTOOL = @DLLTOOL@
DSYMUTIL = @DSYMUTIL@
DUMPBIN = @DUMPBIN@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
FGREP = @FGREP@
GREP = @GREP@
INCLUDE_INTTYPES_H = @INCLUDE_INTTYPES_H@
INCLUDE_STDINT_H = @INCLUDE_STDINT_H@
INCLUDE_SYS_TYPES_H = @INCLUDE_SYS_TYPES_H@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LD = @LD@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LIBTOOL_DEPS = @LIBTOOL_DEPS@
LIB_AGE = @LIB_AGE@
LIB_CURRENT = @LIB_CURRENT@
LIB_REVISION = @LIB_REVISION@
LIPO = @LIPO@
LN_S = @LN_S@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
MAINT = @MAINT@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MKDIR_P = @MKDIR_P@
NM = @NM@
NMEDIT = @NMEDIT@
OBJDUMP = @OBJDUMP@
OBJEXT = @OBJEXT@
OPT = @OPT@
OTOOL = @OTOOL@
OTOOL64 = @OTOOL64@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PROFILE = @PROFILE@
RANLIB = @RANLIB@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
SIZE16 = @SIZE16@
SIZE32 = @SIZE32@
SIZE64 = @SIZE64@
STRIP = @STRIP@
USIZE16 = @USIZE16@
USIZE32 = @USIZE32@
VERSION = @VERSION@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_AR = @ac_ct_AR@
ac_ct_CC = @ac_ct_CC@
ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
SUBDIRS = ogg
all: all-recursive
.SUFFIXES:
$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu include/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --gnu include/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
esac;
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
mostlyclean-libtool:
-rm -f *.lo
clean-libtool:
-rm -rf .libs _libs
# This directory's subdirectories are mostly independent; you can cd
# into them and run 'make' without going through this Makefile.
# To change the values of 'make' variables: instead of editing Makefiles,
# (1) if the variable is set in 'config.status', edit 'config.status'
# (which will cause the Makefiles to be regenerated when you run 'make');
# (2) otherwise, pass the desired values on the 'make' command line.
$(am__recursive_targets):
@fail=; \
if $(am__make_keepgoing); then \
failcom='fail=yes'; \
else \
failcom='exit 1'; \
fi; \
dot_seen=no; \
target=`echo $@ | sed s/-recursive//`; \
case "$@" in \
distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
*) list='$(SUBDIRS)' ;; \
esac; \
for subdir in $$list; do \
echo "Making $$target in $$subdir"; \
if test "$$subdir" = "."; then \
dot_seen=yes; \
local_target="$$target-am"; \
else \
local_target="$$target"; \
fi; \
($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
|| eval $$failcom; \
done; \
if test "$$dot_seen" = "no"; then \
$(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
fi; test -z "$$fail"
ID: $(am__tagged_files)
$(am__define_uniq_tagged_files); mkid -fID $$unique
tags: tags-recursive
TAGS: tags
tags-am: $(TAGS_DEPENDENCIES) $(am__tagged_files)
set x; \
here=`pwd`; \
if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
include_option=--etags-include; \
empty_fix=.; \
else \
include_option=--include; \
empty_fix=; \
fi; \
list='$(SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
test ! -f $$subdir/TAGS || \
set "$$@" "$$include_option=$$here/$$subdir/TAGS"; \
fi; \
done; \
$(am__define_uniq_tagged_files); \
shift; \
if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
test -n "$$unique" || unique=$$empty_fix; \
if test $$# -gt 0; then \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
"$$@" $$unique; \
else \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$unique; \
fi; \
fi
ctags: ctags-recursive
CTAGS: ctags
ctags-am: $(TAGS_DEPENDENCIES) $(am__tagged_files)
$(am__define_uniq_tagged_files); \
test -z "$(CTAGS_ARGS)$$unique" \
|| $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
$$unique
GTAGS:
here=`$(am__cd) $(top_builddir) && pwd` \
&& $(am__cd) $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) "$$here"
cscopelist: cscopelist-recursive
cscopelist-am: $(am__tagged_files)
list='$(am__tagged_files)'; \
case "$(srcdir)" in \
[\\/]* | ?:[\\/]*) sdir="$(srcdir)" ;; \
*) sdir=$(subdir)/$(srcdir) ;; \
esac; \
for i in $$list; do \
if test -f "$$i"; then \
echo "$(subdir)/$$i"; \
else \
echo "$$sdir/$$i"; \
fi; \
done >> $(top_builddir)/cscope.files
distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
distdir: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
@list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
if test "$$subdir" = .; then :; else \
$(am__make_dryrun) \
|| test -d "$(distdir)/$$subdir" \
|| $(MKDIR_P) "$(distdir)/$$subdir" \
|| exit 1; \
dir1=$$subdir; dir2="$(distdir)/$$subdir"; \
$(am__relativize); \
new_distdir=$$reldir; \
dir1=$$subdir; dir2="$(top_distdir)"; \
$(am__relativize); \
new_top_distdir=$$reldir; \
echo " (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) top_distdir="$$new_top_distdir" distdir="$$new_distdir" \\"; \
echo " am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)"; \
($(am__cd) $$subdir && \
$(MAKE) $(AM_MAKEFLAGS) \
top_distdir="$$new_top_distdir" \
distdir="$$new_distdir" \
am__remove_distdir=: \
am__skip_length_check=: \
am__skip_mode_fix=: \
distdir) \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-recursive
all-am: Makefile
installdirs: installdirs-recursive
installdirs-am:
install: install-recursive
install-exec: install-exec-recursive
install-data: install-data-recursive
uninstall: uninstall-recursive
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-recursive
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-recursive
clean-am: clean-generic clean-libtool mostlyclean-am
distclean: distclean-recursive
-rm -f Makefile
distclean-am: clean-am distclean-generic distclean-tags
dvi: dvi-recursive
dvi-am:
html: html-recursive
html-am:
info: info-recursive
info-am:
install-data-am:
install-dvi: install-dvi-recursive
install-dvi-am:
install-exec-am:
install-html: install-html-recursive
install-html-am:
install-info: install-info-recursive
install-info-am:
install-man:
install-pdf: install-pdf-recursive
install-pdf-am:
install-ps: install-ps-recursive
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-recursive
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-recursive
mostlyclean-am: mostlyclean-generic mostlyclean-libtool
pdf: pdf-recursive
pdf-am:
ps: ps-recursive
ps-am:
uninstall-am:
.MAKE: $(am__recursive_targets) install-am install-strip
.PHONY: $(am__recursive_targets) CTAGS GTAGS TAGS all all-am check \
check-am clean clean-generic clean-libtool cscopelist-am ctags \
ctags-am distclean distclean-generic distclean-libtool \
distclean-tags distdir dvi dvi-am html html-am info info-am \
install install-am install-data install-data-am install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-strip installcheck installcheck-am installdirs \
installdirs-am maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic mostlyclean-libtool pdf pdf-am \
ps ps-am tags tags-am uninstall uninstall-am
.PRECIOUS: Makefile
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
cpprestsdk_static_tester/libogg/include/ogg/Makefile.am 0 → 100644
View file @ 14571fd2
## Process this file with automake to produce Makefile.in
oggincludedir = $(includedir)/ogg
ogginclude_HEADERS = ogg.h os_types.h
nodist_ogginclude_HEADERS = config_types.h
cpprestsdk_static_tester/libogg/include/ogg/Makefile.in 0 → 100644
View file @ 14571fd2
# Makefile.in generated by automake 1.15 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2014 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
subdir = include/ogg
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(ogginclude_HEADERS) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/config.h
CONFIG_CLEAN_FILES = config_types.h
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(oggincludedir)" \
"$(DESTDIR)$(oggincludedir)"
HEADERS = $(nodist_ogginclude_HEADERS) $(ogginclude_HEADERS)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
# Read a list of newline-separated strings from the standard input,
# and print each of them once, without duplicates. Input order is
# *not* preserved.
am__uniquify_input = $(AWK) '\
BEGIN { nonempty = 0; } \
{ items[$$0] = 1; nonempty = 1; } \
END { if (nonempty) { for (i in items) print i; }; } \
'
# Make sure the list of sources is unique. This is necessary because,
# e.g., the same source file might be shared among _SOURCES variables
# for different programs/libraries.
am__define_uniq_tagged_files = \
list='$(am__tagged_files)'; \
unique=`for i in $$list; do \
if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
done | $(am__uniquify_input)`
ETAGS = etags
CTAGS = ctags
am__DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/config_types.h.in
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
AR = @AR@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CYGPATH_W = @CYGPATH_W@
DEBUG = @DEBUG@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DLLTOOL = @DLLTOOL@
DSYMUTIL = @DSYMUTIL@
DUMPBIN = @DUMPBIN@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
EGREP = @EGREP@
EXEEXT = @EXEEXT@
FGREP = @FGREP@
GREP = @GREP@
INCLUDE_INTTYPES_H = @INCLUDE_INTTYPES_H@
INCLUDE_STDINT_H = @INCLUDE_STDINT_H@
INCLUDE_SYS_TYPES_H = @INCLUDE_SYS_TYPES_H@
INSTALL = @INSTALL@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LD = @LD@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
LIBTOOL_DEPS = @LIBTOOL_DEPS@
LIB_AGE = @LIB_AGE@
LIB_CURRENT = @LIB_CURRENT@
LIB_REVISION = @LIB_REVISION@
LIPO = @LIPO@
LN_S = @LN_S@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
MAINT = @MAINT@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MKDIR_P = @MKDIR_P@
NM = @NM@
NMEDIT = @NMEDIT@
OBJDUMP = @OBJDUMP@
OBJEXT = @OBJEXT@
OPT = @OPT@
OTOOL = @OTOOL@
OTOOL64 = @OTOOL64@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PROFILE = @PROFILE@
RANLIB = @RANLIB@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
SIZE16 = @SIZE16@
SIZE32 = @SIZE32@
SIZE64 = @SIZE64@
STRIP = @STRIP@
USIZE16 = @USIZE16@
USIZE32 = @USIZE32@
VERSION = @VERSION@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_AR = @ac_ct_AR@
ac_ct_CC = @ac_ct_CC@
ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
oggincludedir = $(includedir)/ogg
ogginclude_HEADERS = ogg.h os_types.h
nodist_ogginclude_HEADERS = config_types.h
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu include/ogg/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --gnu include/ogg/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
esac;
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
config_types.h: $(top_builddir)/config.status $(srcdir)/config_types.h.in
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
mostlyclean-libtool:
-rm -f *.lo
clean-libtool:
-rm -rf .libs _libs
install-nodist_oggincludeHEADERS: $(nodist_ogginclude_HEADERS)
@$(NORMAL_INSTALL)
@list='$(nodist_ogginclude_HEADERS)'; test -n "$(oggincludedir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(oggincludedir)'"; \
$(MKDIR_P) "$(DESTDIR)$(oggincludedir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(oggincludedir)'"; \
$(INSTALL_HEADER) $$files "$(DESTDIR)$(oggincludedir)" || exit $$?; \
done
uninstall-nodist_oggincludeHEADERS:
@$(NORMAL_UNINSTALL)
@list='$(nodist_ogginclude_HEADERS)'; test -n "$(oggincludedir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(oggincludedir)'; $(am__uninstall_files_from_dir)
install-oggincludeHEADERS: $(ogginclude_HEADERS)
@$(NORMAL_INSTALL)
@list='$(ogginclude_HEADERS)'; test -n "$(oggincludedir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(oggincludedir)'"; \
$(MKDIR_P) "$(DESTDIR)$(oggincludedir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_HEADER) $$files '$(DESTDIR)$(oggincludedir)'"; \
$(INSTALL_HEADER) $$files "$(DESTDIR)$(oggincludedir)" || exit $$?; \
done
uninstall-oggincludeHEADERS:
@$(NORMAL_UNINSTALL)
@list='$(ogginclude_HEADERS)'; test -n "$(oggincludedir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(oggincludedir)'; $(am__uninstall_files_from_dir)
ID: $(am__tagged_files)
$(am__define_uniq_tagged_files); mkid -fID $$unique
tags: tags-am
TAGS: tags
tags-am: $(TAGS_DEPENDENCIES) $(am__tagged_files)
set x; \
here=`pwd`; \
$(am__define_uniq_tagged_files); \
shift; \
if test -z "$(ETAGS_ARGS)$$*$$unique"; then :; else \
test -n "$$unique" || unique=$$empty_fix; \
if test $$# -gt 0; then \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
"$$@" $$unique; \
else \
$(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
$$unique; \
fi; \
fi
ctags: ctags-am
CTAGS: ctags
ctags-am: $(TAGS_DEPENDENCIES) $(am__tagged_files)
$(am__define_uniq_tagged_files); \
test -z "$(CTAGS_ARGS)$$unique" \
|| $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
$$unique
GTAGS:
here=`$(am__cd) $(top_builddir) && pwd` \
&& $(am__cd) $(top_srcdir) \
&& gtags -i $(GTAGS_ARGS) "$$here"
cscopelist: cscopelist-am
cscopelist-am: $(am__tagged_files)
list='$(am__tagged_files)'; \
case "$(srcdir)" in \
[\\/]* | ?:[\\/]*) sdir="$(srcdir)" ;; \
*) sdir=$(subdir)/$(srcdir) ;; \
esac; \
for i in $$list; do \
if test -f "$$i"; then \
echo "$(subdir)/$$i"; \
else \
echo "$$sdir/$$i"; \
fi; \
done >> $(top_builddir)/cscope.files
distclean-tags:
-rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
distdir: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(HEADERS)
installdirs:
for dir in "$(DESTDIR)$(oggincludedir)" "$(DESTDIR)$(oggincludedir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic clean-libtool mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic distclean-tags
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-nodist_oggincludeHEADERS \
install-oggincludeHEADERS
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic mostlyclean-libtool
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-nodist_oggincludeHEADERS \
uninstall-oggincludeHEADERS
.MAKE: install-am install-strip
.PHONY: CTAGS GTAGS TAGS all all-am check check-am clean clean-generic \
clean-libtool cscopelist-am ctags ctags-am distclean \
distclean-generic distclean-libtool distclean-tags distdir dvi \
dvi-am html html-am info info-am install install-am \
install-data install-data-am install-dvi install-dvi-am \
install-exec install-exec-am install-html install-html-am \
install-info install-info-am install-man \
install-nodist_oggincludeHEADERS install-oggincludeHEADERS \
install-pdf install-pdf-am install-ps install-ps-am \
install-strip installcheck installcheck-am installdirs \
maintainer-clean maintainer-clean-generic mostlyclean \
mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
tags tags-am uninstall uninstall-am \
uninstall-nodist_oggincludeHEADERS uninstall-oggincludeHEADERS
.PRECIOUS: Makefile
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
cpprestsdk_static_tester/libogg/include/ogg/config_types.h.in 0 → 100644
View file @ 14571fd2
#ifndef __CONFIG_TYPES_H__
#define __CONFIG_TYPES_H__
/* these are filled in by configure */
#define INCLUDE_INTTYPES_H @INCLUDE_INTTYPES_H@
#define INCLUDE_STDINT_H @INCLUDE_STDINT_H@
#define INCLUDE_SYS_TYPES_H @INCLUDE_SYS_TYPES_H@
#if INCLUDE_INTTYPES_H
# include <inttypes.h>
#endif
#if INCLUDE_STDINT_H
# include <stdint.h>
#endif
#if INCLUDE_SYS_TYPES_H
# include <sys/types.h>
#endif
typedef @SIZE16@ ogg_int16_t;
typedef @USIZE16@ ogg_uint16_t;
typedef @SIZE32@ ogg_int32_t;
typedef @USIZE32@ ogg_uint32_t;
typedef @SIZE64@ ogg_int64_t;
#endif
cpprestsdk_static_tester/libogg/include/ogg/ogg.h 0 → 100644
View file @ 14571fd2
/********************************************************************
* *
* THIS FILE IS PART OF THE OggVorbis SOFTWARE CODEC SOURCE CODE. *
* USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
* GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
* IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
* *
* THE OggVorbis SOURCE CODE IS (C) COPYRIGHT 1994-2007 *
* by the Xiph.Org Foundation http://www.xiph.org/ *
* *
********************************************************************
function: toplevel libogg include
last mod: $Id$
********************************************************************/
#ifndef _OGG_H
#define _OGG_H
#ifdef __cplusplus
extern "C" {
#endif
#include <stddef.h>
#include <ogg/os_types.h>
typedef struct {
void *iov_base;
size_t iov_len;
} ogg_iovec_t;
typedef struct {
long endbyte;
int endbit;
unsigned char *buffer;
unsigned char *ptr;
long storage;
} oggpack_buffer;
/* ogg_page is used to encapsulate the data in one Ogg bitstream page *****/
typedef struct {
unsigned char *header;
long header_len;
unsigned char *body;
long body_len;
} ogg_page;
/* ogg_stream_state contains the current encode/decode state of a logical
Ogg bitstream **********************************************************/
typedef struct {
unsigned char *body_data; /* bytes from packet bodies */
long body_storage; /* storage elements allocated */
long body_fill; /* elements stored; fill mark */
long body_returned; /* elements of fill returned */
int *lacing_vals; /* The values that will go to the segment table */
ogg_int64_t *granule_vals; /* granulepos values for headers. Not compact
this way, but it is simple coupled to the
lacing fifo */
long lacing_storage;
long lacing_fill;
long lacing_packet;
long lacing_returned;
unsigned char header[282]; /* working space for header encode */
int header_fill;
int e_o_s; /* set when we have buffered the last packet in the
logical bitstream */
int b_o_s; /* set after we've written the initial page
of a logical bitstream */
long serialno;
long pageno;
ogg_int64_t packetno; /* sequence number for decode; the framing
knows where there's a hole in the data,
but we need coupling so that the codec
(which is in a separate abstraction
layer) also knows about the gap */
ogg_int64_t granulepos;
} ogg_stream_state;
/* ogg_packet is used to encapsulate the data and metadata belonging
to a single raw Ogg/Vorbis packet *************************************/
typedef struct {
unsigned char *packet;
long bytes;
long b_o_s;
long e_o_s;
ogg_int64_t granulepos;
ogg_int64_t packetno; /* sequence number for decode; the framing
knows where there's a hole in the data,
but we need coupling so that the codec
(which is in a separate abstraction
layer) also knows about the gap */
} ogg_packet;
typedef struct {
unsigned char *data;
int storage;
int fill;
int returned;
int unsynced;
int headerbytes;
int bodybytes;
} ogg_sync_state;
/* Ogg BITSTREAM PRIMITIVES: bitstream ************************/
extern void oggpack_writeinit(oggpack_buffer *b);
extern int oggpack_writecheck(oggpack_buffer *b);
extern void oggpack_writetrunc(oggpack_buffer *b,long bits);
extern void oggpack_writealign(oggpack_buffer *b);
extern void oggpack_writecopy(oggpack_buffer *b,void *source,long bits);
extern void oggpack_reset(oggpack_buffer *b);
extern void oggpack_writeclear(oggpack_buffer *b);
extern void oggpack_readinit(oggpack_buffer *b,unsigned char *buf,int bytes);
extern void oggpack_write(oggpack_buffer *b,unsigned long value,int bits);
extern long oggpack_look(oggpack_buffer *b,int bits);
extern long oggpack_look1(oggpack_buffer *b);
extern void oggpack_adv(oggpack_buffer *b,int bits);
extern void oggpack_adv1(oggpack_buffer *b);
extern long oggpack_read(oggpack_buffer *b,int bits);
extern long oggpack_read1(oggpack_buffer *b);
extern long oggpack_bytes(oggpack_buffer *b);
extern long oggpack_bits(oggpack_buffer *b);
extern unsigned char *oggpack_get_buffer(oggpack_buffer *b);
extern void oggpackB_writeinit(oggpack_buffer *b);
extern int oggpackB_writecheck(oggpack_buffer *b);
extern void oggpackB_writetrunc(oggpack_buffer *b,long bits);
extern void oggpackB_writealign(oggpack_buffer *b);
extern void oggpackB_writecopy(oggpack_buffer *b,void *source,long bits);
extern void oggpackB_reset(oggpack_buffer *b);
extern void oggpackB_writeclear(oggpack_buffer *b);
extern void oggpackB_readinit(oggpack_buffer *b,unsigned char *buf,int bytes);
extern void oggpackB_write(oggpack_buffer *b,unsigned long value,int bits);
extern long oggpackB_look(oggpack_buffer *b,int bits);
extern long oggpackB_look1(oggpack_buffer *b);
extern void oggpackB_adv(oggpack_buffer *b,int bits);
extern void oggpackB_adv1(oggpack_buffer *b);
extern long oggpackB_read(oggpack_buffer *b,int bits);
extern long oggpackB_read1(oggpack_buffer *b);
extern long oggpackB_bytes(oggpack_buffer *b);
extern long oggpackB_bits(oggpack_buffer *b);
extern unsigned char *oggpackB_get_buffer(oggpack_buffer *b);
/* Ogg BITSTREAM PRIMITIVES: encoding **************************/
extern int ogg_stream_packetin(ogg_stream_state *os, ogg_packet *op);
extern int ogg_stream_iovecin(ogg_stream_state *os, ogg_iovec_t *iov,
int count, long e_o_s, ogg_int64_t granulepos);
extern int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og);
extern int ogg_stream_pageout_fill(ogg_stream_state *os, ogg_page *og, int nfill);
extern int ogg_stream_flush(ogg_stream_state *os, ogg_page *og);
extern int ogg_stream_flush_fill(ogg_stream_state *os, ogg_page *og, int nfill);
/* Ogg BITSTREAM PRIMITIVES: decoding **************************/
extern int ogg_sync_init(ogg_sync_state *oy);
extern int ogg_sync_clear(ogg_sync_state *oy);
extern int ogg_sync_reset(ogg_sync_state *oy);
extern int ogg_sync_destroy(ogg_sync_state *oy);
extern int ogg_sync_check(ogg_sync_state *oy);
extern char *ogg_sync_buffer(ogg_sync_state *oy, long size);
extern int ogg_sync_wrote(ogg_sync_state *oy, long bytes);
extern long ogg_sync_pageseek(ogg_sync_state *oy,ogg_page *og);
extern int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og);
extern int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og);
extern int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op);
extern int ogg_stream_packetpeek(ogg_stream_state *os,ogg_packet *op);
/* Ogg BITSTREAM PRIMITIVES: general ***************************/
extern int ogg_stream_init(ogg_stream_state *os,int serialno);
extern int ogg_stream_clear(ogg_stream_state *os);
extern int ogg_stream_reset(ogg_stream_state *os);
extern int ogg_stream_reset_serialno(ogg_stream_state *os,int serialno);
extern int ogg_stream_destroy(ogg_stream_state *os);
extern int ogg_stream_check(ogg_stream_state *os);
extern int ogg_stream_eos(ogg_stream_state *os);
extern void ogg_page_checksum_set(ogg_page *og);
extern int ogg_page_version(const ogg_page *og);
extern int ogg_page_continued(const ogg_page *og);
extern int ogg_page_bos(const ogg_page *og);
extern int ogg_page_eos(const ogg_page *og);
extern ogg_int64_t ogg_page_granulepos(const ogg_page *og);
extern int ogg_page_serialno(const ogg_page *og);
extern long ogg_page_pageno(const ogg_page *og);
extern int ogg_page_packets(const ogg_page *og);
extern void ogg_packet_clear(ogg_packet *op);
#ifdef __cplusplus
}
#endif
#endif /* _OGG_H */
cpprestsdk_static_tester/libogg/include/ogg/os_types.h 0 → 100644
View file @ 14571fd2
/********************************************************************
* *
* THIS FILE IS PART OF THE OggVorbis SOFTWARE CODEC SOURCE CODE. *
* USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
* GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
* IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
* *
* THE OggVorbis SOURCE CODE IS (C) COPYRIGHT 1994-2002 *
* by the Xiph.Org Foundation http://www.xiph.org/ *
* *
********************************************************************
function: #ifdef jail to whip a few platforms into the UNIX ideal.
last mod: $Id$
********************************************************************/
#ifndef _OS_TYPES_H
#define _OS_TYPES_H
/* make it easy on the folks that want to compile the libs with a
different malloc than stdlib */
#define _ogg_malloc malloc
#define _ogg_calloc calloc
#define _ogg_realloc realloc
#define _ogg_free free
#if defined(_WIN32)
# if defined(__CYGWIN__)
# include <stdint.h>
typedef int16_t ogg_int16_t;
typedef uint16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef uint32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;
typedef uint64_t ogg_uint64_t;
# elif defined(__MINGW32__)
# include <sys/types.h>
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
typedef unsigned long long ogg_uint64_t;
# elif defined(__MWERKS__)
typedef long long ogg_int64_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
# else
# if defined(_MSC_VER) && (_MSC_VER >= 1800) /* MSVC 2013 and newer */
# include <stdint.h>
typedef int16_t ogg_int16_t;
typedef uint16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef uint32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;
typedef uint64_t ogg_uint64_t;
# else
/* MSVC/Borland */
typedef __int64 ogg_int64_t;
typedef __int32 ogg_int32_t;
typedef unsigned __int32 ogg_uint32_t;
typedef __int16 ogg_int16_t;
typedef unsigned __int16 ogg_uint16_t;
# endif
# endif
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
typedef int16_t ogg_int16_t;
typedef uint16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef uint32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;
#elif defined(__HAIKU__)
/* Haiku */
# include <sys/types.h>
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
#elif defined(__BEOS__)
/* Be */
# include <inttypes.h>
typedef int16_t ogg_int16_t;
typedef uint16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef uint32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;
#elif defined (__EMX__)
/* OS/2 GCC */
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
#elif defined (DJGPP)
/* DJGPP */
typedef short ogg_int16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
#elif defined(R5900)
/* PS2 EE */
typedef long ogg_int64_t;
typedef int ogg_int32_t;
typedef unsigned ogg_uint32_t;
typedef short ogg_int16_t;
#elif defined(__SYMBIAN32__)
/* Symbian GCC */
typedef signed short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef signed int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long int ogg_int64_t;
#elif defined(__TMS320C6X__)
/* TI C64x compiler */
typedef signed short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef signed int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long int ogg_int64_t;
#else
# include <ogg/config_types.h>
#endif
#endif /* _OS_TYPES_H */
cpprestsdk_static_tester/libogg/install-sh 0 → 100644
View file @ 14571fd2
#!/bin/sh
# install - install a program, script, or datafile
scriptversion=2013-12-25.23; # UTC
# This originates from X11R5 (mit/util/scripts/install.sh), which was
# later released in X11R6 (xc/config/util/install.sh) with the
# following copyright and license.
#
# Copyright (C) 1994 X Consortium
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to
# deal in the Software without restriction, including without limitation the
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
# sell copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#
# Except as contained in this notice, the name of the X Consortium shall not
# be used in advertising or otherwise to promote the sale, use or other deal-
# ings in this Software without prior written authorization from the X Consor-
# tium.
#
#
# FSF changes to this file are in the public domain.
#
# Calling this script install-sh is preferred over install.sh, to prevent
# 'make' implicit rules from creating a file called install from it
# when there is no Makefile.
#
# This script is compatible with the BSD install script, but was written
# from scratch.
tab=' '
nl='
'
IFS=" $tab$nl"
# Set DOITPROG to "echo" to test this script.
doit=${DOITPROG-}
doit_exec=${doit:-exec}
# Put in absolute file names if you don't have them in your path;
# or use environment vars.
chgrpprog=${CHGRPPROG-chgrp}
chmodprog=${CHMODPROG-chmod}
chownprog=${CHOWNPROG-chown}
cmpprog=${CMPPROG-cmp}
cpprog=${CPPROG-cp}
mkdirprog=${MKDIRPROG-mkdir}
mvprog=${MVPROG-mv}
rmprog=${RMPROG-rm}
stripprog=${STRIPPROG-strip}
posix_mkdir=
# Desired mode of installed file.
mode=0755
chgrpcmd=
chmodcmd=$chmodprog
chowncmd=
mvcmd=$mvprog
rmcmd="$rmprog -f"
stripcmd=
src=
dst=
dir_arg=
dst_arg=
copy_on_change=false
is_target_a_directory=possibly
usage="\
Usage: $0 [OPTION]... [-T] SRCFILE DSTFILE
or: $0 [OPTION]... SRCFILES... DIRECTORY
or: $0 [OPTION]... -t DIRECTORY SRCFILES...
or: $0 [OPTION]... -d DIRECTORIES...
In the 1st form, copy SRCFILE to DSTFILE.
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
In the 4th, create DIRECTORIES.
Options:
--help display this help and exit.
--version display version info and exit.
-c (ignored)
-C install only if different (preserve the last data modification time)
-d create directories instead of installing files.
-g GROUP $chgrpprog installed files to GROUP.
-m MODE $chmodprog installed files to MODE.
-o USER $chownprog installed files to USER.
-s $stripprog installed files.
-t DIRECTORY install into DIRECTORY.
-T report an error if DSTFILE is a directory.
Environment variables override the default commands:
CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
RMPROG STRIPPROG
"
while test $# -ne 0; do
case $1 in
-c) ;;
-C) copy_on_change=true;;
-d) dir_arg=true;;
-g) chgrpcmd="$chgrpprog $2"
shift;;
--help) echo "$usage"; exit $?;;
-m) mode=$2
case $mode in
*' '* | *"$tab"* | *"$nl"* | *'*'* | *'?'* | *'['*)
echo "$0: invalid mode: $mode" >&2
exit 1;;
esac
shift;;
-o) chowncmd="$chownprog $2"
shift;;
-s) stripcmd=$stripprog;;
-t)
is_target_a_directory=always
dst_arg=$2
# Protect names problematic for 'test' and other utilities.
case $dst_arg in
-* | [=\(\)!]) dst_arg=./$dst_arg;;
esac
shift;;
-T) is_target_a_directory=never;;
--version) echo "$0 $scriptversion"; exit $?;;
--) shift
break;;
-*) echo "$0: invalid option: $1" >&2
exit 1;;
*) break;;
esac
shift
done
# We allow the use of options -d and -T together, by making -d
# take the precedence; this is for compatibility with GNU install.
if test -n "$dir_arg"; then
if test -n "$dst_arg"; then
echo "$0: target directory not allowed when installing a directory." >&2
exit 1
fi
fi
if test $# -ne 0 && test -z "$dir_arg$dst_arg"; then
# When -d is used, all remaining arguments are directories to create.
# When -t is used, the destination is already specified.
# Otherwise, the last argument is the destination. Remove it from $@.
for arg
do
if test -n "$dst_arg"; then
# $@ is not empty: it contains at least $arg.
set fnord "$@" "$dst_arg"
shift # fnord
fi
shift # arg
dst_arg=$arg
# Protect names problematic for 'test' and other utilities.
case $dst_arg in
-* | [=\(\)!]) dst_arg=./$dst_arg;;
esac
done
fi
if test $# -eq 0; then
if test -z "$dir_arg"; then
echo "$0: no input file specified." >&2
exit 1
fi
# It's OK to call 'install-sh -d' without argument.
# This can happen when creating conditional directories.
exit 0
fi
if test -z "$dir_arg"; then
if test $# -gt 1 || test "$is_target_a_directory" = always; then
if test ! -d "$dst_arg"; then
echo "$0: $dst_arg: Is not a directory." >&2
exit 1
fi
fi
fi
if test -z "$dir_arg"; then
do_exit='(exit $ret); exit $ret'
trap "ret=129; $do_exit" 1
trap "ret=130; $do_exit" 2
trap "ret=141; $do_exit" 13
trap "ret=143; $do_exit" 15
# Set umask so as not to create temps with too-generous modes.
# However, 'strip' requires both read and write access to temps.
case $mode in
# Optimize common cases.
*644) cp_umask=133;;
*755) cp_umask=22;;
*[0-7])
if test -z "$stripcmd"; then
u_plus_rw=
else
u_plus_rw='% 200'
fi
cp_umask=`expr '(' 777 - $mode % 1000 ')' $u_plus_rw`;;
*)
if test -z "$stripcmd"; then
u_plus_rw=
else
u_plus_rw=,u+rw
fi
cp_umask=$mode$u_plus_rw;;
esac
fi
for src
do
# Protect names problematic for 'test' and other utilities.
case $src in
-* | [=\(\)!]) src=./$src;;
esac
if test -n "$dir_arg"; then
dst=$src
dstdir=$dst
test -d "$dstdir"
dstdir_status=$?
else
# Waiting for this to be detected by the "$cpprog $src $dsttmp" command
# might cause directories to be created, which would be especially bad
# if $src (and thus $dsttmp) contains '*'.
if test ! -f "$src" && test ! -d "$src"; then
echo "$0: $src does not exist." >&2
exit 1
fi
if test -z "$dst_arg"; then
echo "$0: no destination specified." >&2
exit 1
fi
dst=$dst_arg
# If destination is a directory, append the input filename; won't work
# if double slashes aren't ignored.
if test -d "$dst"; then
if test "$is_target_a_directory" = never; then
echo "$0: $dst_arg: Is a directory" >&2
exit 1
fi
dstdir=$dst
dst=$dstdir/`basename "$src"`
dstdir_status=0
else
dstdir=`dirname "$dst"`
test -d "$dstdir"
dstdir_status=$?
fi
fi
obsolete_mkdir_used=false
if test $dstdir_status != 0; then
case $posix_mkdir in
'')
# Create intermediate dirs using mode 755 as modified by the umask.
# This is like FreeBSD 'install' as of 1997-10-28.
umask=`umask`
case $stripcmd.$umask in
# Optimize common cases.
*[2367][2367]) mkdir_umask=$umask;;
.*0[02][02] | .[02][02] | .[02]) mkdir_umask=22;;
*[0-7])
mkdir_umask=`expr $umask + 22 \
- $umask % 100 % 40 + $umask % 20 \
- $umask % 10 % 4 + $umask % 2
`;;
*) mkdir_umask=$umask,go-w;;
esac
# With -d, create the new directory with the user-specified mode.
# Otherwise, rely on $mkdir_umask.
if test -n "$dir_arg"; then
mkdir_mode=-m$mode
else
mkdir_mode=
fi
posix_mkdir=false
case $umask in
*[123567][0-7][0-7])
# POSIX mkdir -p sets u+wx bits regardless of umask, which
# is incompatible with FreeBSD 'install' when (umask & 300) != 0.
;;
*)
tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
trap 'ret=$?; rmdir "$tmpdir/d" "$tmpdir" 2>/dev/null; exit $ret' 0
if (umask $mkdir_umask &&
exec $mkdirprog $mkdir_mode -p -- "$tmpdir/d") >/dev/null 2>&1
then
if test -z "$dir_arg" || {
# Check for POSIX incompatibilities with -m.
# HP-UX 11.23 and IRIX 6.5 mkdir -m -p sets group- or
# other-writable bit of parent directory when it shouldn't.
# FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
ls_ld_tmpdir=`ls -ld "$tmpdir"`
case $ls_ld_tmpdir in
d????-?r-*) different_mode=700;;
d????-?--*) different_mode=755;;
*) false;;
esac &&
$mkdirprog -m$different_mode -p -- "$tmpdir" && {
ls_ld_tmpdir_1=`ls -ld "$tmpdir"`
test "$ls_ld_tmpdir" = "$ls_ld_tmpdir_1"
}
}
then posix_mkdir=:
fi
rmdir "$tmpdir/d" "$tmpdir"
else
# Remove any dirs left behind by ancient mkdir implementations.
rmdir ./$mkdir_mode ./-p ./-- 2>/dev/null
fi
trap '' 0;;
esac;;
esac
if
$posix_mkdir && (
umask $mkdir_umask &&
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir"
)
then :
else
# The umask is ridiculous, or mkdir does not conform to POSIX,
# or it failed possibly due to a race condition. Create the
# directory the slow way, step by step, checking for races as we go.
case $dstdir in
/*) prefix='/';;
[-=\(\)!]*) prefix='./';;
*) prefix='';;
esac
oIFS=$IFS
IFS=/
set -f
set fnord $dstdir
shift
set +f
IFS=$oIFS
prefixes=
for d
do
test X"$d" = X && continue
prefix=$prefix$d
if test -d "$prefix"; then
prefixes=
else
if $posix_mkdir; then
(umask=$mkdir_umask &&
$doit_exec $mkdirprog $mkdir_mode -p -- "$dstdir") && break
# Don't fail if two instances are running concurrently.
test -d "$prefix" || exit 1
else
case $prefix in
*\'*) qprefix=`echo "$prefix" | sed "s/'/'\\\\\\\\''/g"`;;
*) qprefix=$prefix;;
esac
prefixes="$prefixes '$qprefix'"
fi
fi
prefix=$prefix/
done
if test -n "$prefixes"; then
# Don't fail if two instances are running concurrently.
(umask $mkdir_umask &&
eval "\$doit_exec \$mkdirprog $prefixes") ||
test -d "$dstdir" || exit 1
obsolete_mkdir_used=true
fi
fi
fi
if test -n "$dir_arg"; then
{ test -z "$chowncmd" || $doit $chowncmd "$dst"; } &&
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dst"; } &&
{ test "$obsolete_mkdir_used$chowncmd$chgrpcmd" = false ||
test -z "$chmodcmd" || $doit $chmodcmd $mode "$dst"; } || exit 1
else
# Make a couple of temp file names in the proper directory.
dsttmp=$dstdir/_inst.$$_
rmtmp=$dstdir/_rm.$$_
# Trap to clean up those temp files at exit.
trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
# Copy the file name to the temp name.
(umask $cp_umask && $doit_exec $cpprog "$src" "$dsttmp") &&
# and set any options; do chmod last to preserve setuid bits.
#
# If any of these fail, we abort the whole thing. If we want to
# ignore errors from any of these, just make sure not to ignore
# errors from the above "$doit $cpprog $src $dsttmp" command.
#
{ test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } &&
{ test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } &&
{ test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } &&
{ test -z "$chmodcmd" || $doit $chmodcmd $mode "$dsttmp"; } &&
# If -C, don't bother to copy if it wouldn't change the file.
if $copy_on_change &&
old=`LC_ALL=C ls -dlL "$dst" 2>/dev/null` &&
new=`LC_ALL=C ls -dlL "$dsttmp" 2>/dev/null` &&
set -f &&
set X $old && old=:$2:$4:$5:$6 &&
set X $new && new=:$2:$4:$5:$6 &&
set +f &&
test "$old" = "$new" &&
$cmpprog "$dst" "$dsttmp" >/dev/null 2>&1
then
rm -f "$dsttmp"
else
# Rename the file to the real destination.
$doit $mvcmd -f "$dsttmp" "$dst" 2>/dev/null ||
# The rename failed, perhaps because mv can't rename something else
# to itself, or perhaps because mv is so ancient that it does not
# support -f.
{
# Now remove or move aside any old file at destination location.
# We try this two ways since rm can't unlink itself on some
# systems and the destination file might be busy for other
# reasons. In this case, the final cleanup might fail but the new
# file should still install successfully.
{
test ! -f "$dst" ||
$doit $rmcmd -f "$dst" 2>/dev/null ||
{ $doit $mvcmd -f "$dst" "$rmtmp" 2>/dev/null &&
{ $doit $rmcmd -f "$rmtmp" 2>/dev/null; :; }
} ||
{ echo "$0: cannot unlink or rename $dst" >&2
(exit 1); exit 1
}
} &&
# Now rename the file to the real destination.
$doit $mvcmd "$dsttmp" "$dst"
}
fi || exit 1
trap '' 0
fi
done
# Local variables:
# eval: (add-hook 'write-file-hooks 'time-stamp)
# time-stamp-start: "scriptversion="
# time-stamp-format: "%:y-%02m-%02d.%02H"
# time-stamp-time-zone: "UTC"
# time-stamp-end: "; # UTC"
# End:
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment