1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 |
在PHP中读写文件,可以用到一下内置函数: 1.fopen(创建文件和打开文件) 语法: fopen(filename,mode) filename,规定要打开的文件。mode,打开文件的模式,可能的值见下表。 mode 说明 "r" 只读方式打开,将文件指针指向文件开头。 "r+" 读写方式打开,将文件指针指向文件开头。 "w" 写入方式打开,将文件指针指向文件开头并将文件大小截为零。如果文件不存在则尝试创建。 "w+" 读写方式打开,将文件指针指向文件开头并将文件大小截为零。如果文件不存在则尝试创建。 "a" 写入方式打开,将文件指针指向文件末尾。如果文件不存在则尝试创建。 "a+" 读写方式打开,将文件指针指向文件末尾。如果文件不存在则尝试创建。 如果成功打开文件,fopen函数的返回值是一个文件指针,如果出错,返回 FALSE。 示例: <?php $fp = fopen("test.txt", "r"); ?> 2.fclose(关闭文件) 语法: fclose(filepointer) filepointer,要关闭的文件指针。如果成功,fclose 函数返回 TRUE,如果失败,fclose 函数返回 FALSE。 示例: <?php $fp = fopen("test.txt", "r"); fclose($fp); ?> 3.feof(检测是否已到达文件末尾) 语法: feof(filepointer) filepointer,要检测的文件指针,该指针必须指向成功打开没有关闭的文件。如果文件指针到了文件末尾或者出错时,feof函数返回 TRUE。 示例: <?php $fp = fopen("test.txt", "r"); while(! feof($fp)) { echo fgets($fp). "<br />"; } fclose($fp); ?> 4.fgets(从文件指针中读取一行) 语法: fgets(filepointer) filepointer,要读取的文件指针。如果成功,从文件中读取一行并返回字符串,如果失败,返回 FALSE。 示例: <?php $fp = fopen("test.txt", "r"); if($fp) { for($i=1;! feof($fp);$i++) { echo "行".$i." : ".fgets($fp). "<br />"; } } else { echo "打开文件失败"; } fclose($fp); ?> 假设test.txt的内容为: hello world hello cnblogs hello heihaozi hello everyone 页面输出的结果为: 行1 : hello world 行2 : hello cnblogs 行3 : hello heihaozi 行4 : hello everyone 5.fwrite(写入文件) 语法: fwrite(filepointer,string) filepointer,要写入的文件指针。string,要写入的字符串。如果成功,返回写入的字符数,如果失败,返回 FALSE。 示例: view sourceprint?<?php $fp = fopen("test.txt", "w");//文件被清空后再写入 if($fp) { $count=0; for($i=1;$i<=5;$i++) { $flag=fwrite($fp,"行".$i." : "."Hello World!\r\n"); if(!$flag) { echo "写入文件失败<br>"; break; } $count+=$flag; } echo "共写入".$count."个字符"; } else { echo "打开文件失败"; } fclose($fp); ?> 页面输出的结果为: 共写入100个字符 test.txt文件会被写入: 行1 : Hello World! 行2 : Hello World! 行3 : Hello World! 行4 : Hello World! 行5 : Hello World! 注:为了简化操作,部分函数的可选参数没有列出。 |
分类目录归档:技术文献
Ogg文件格式
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]
EFI Shell 命令参考
对于使用使用DOS的人来说,会使用DOS命令是最基本的,而在当今即将盛行的EFI BIOS来说,就有了新的变化,如何操作EFI Shell 呢?至此我贴出了EFI Shell 的命令供大家学习。
EFI是Extensible Firmware Interface的缩写,是介于平台固件和操作系统之间的一层软件接口(及其详细规格说明文档)。EFI是Intel在1998年开始的一个项目演变而来,而在2005年Intel将EFI 1.10开源并交由Unified EFI开源社区去维护和开发,Intel自己的EFI也就不单独做了,都和开源社区共用一个。现在也通常用EFI来代指UEFI,二者不再有意区分。
命令 |
说明 |
引导命令 — EFI Shell 与 nPartition 引导有关的命令。 |
|
autoboot |
设置(查看)自动引导超时变量。 |
bcfg |
显示(或修改)驱动程序(或引导配置)。 |
boottest |
设置(或查看)BootTest 位。 |
dbprofile |
显示/修改要由 lanboot 使用的直接引导配置文件。 |
lanboot |
在 LAN 上引导。 |
reconfigreset |
重置系统 (nPartition) 进行重新配置;nPartition 保持非活动状态(为进行重新配置而关闭的状态)。 |
reset |
重置系统 (nPartition)。 |
search |
连接可引导设备的驱动程序。 |
配置命令 — EFI Shell 用于更改和检索系统 (nPartition) 信息的命令。 |
|
acpiconfig |
设置(或查看)ACPI 配置模式。 |
cellconfig |
取消配置(或重新配置)单元(设置单元的 use-on-next-boot 值)。 |
cpuconfig |
取消配置(或重新配置)处理器和处理器核心。 |
date |
显示当前日期或设置系统 (nPartition) 的日期。 |
dimmconfig |
取消配置(或重新配置)内存 (DIMM)。 |
err |
显示(或更改)错误级别。 |
errdump |
查看(或清除)日志。 |
fru |
查看 FRU 数据。 |
info |
显示硬件信息。 |
monarch |
设置(或查看)主处理器。 |
palproc |
调用 PAL。 |
romdrivers |
启用(或禁用)PCI 扩展 ROM 驱动程序。 |
rootcell |
设置(或查看)首选根单元(设置 nPartition 核心单元选择)。 |
salproc |
调用 SAL。 |
tftp |
对支持 bootp/DHCP 的 Unix 引导服务器执行 TFTP 操作。 |
time |
显示当前时间或设置系统 (nPartition) 时间。以 GMT(格林威治标准时间)设置和显示 EFI 时间。 |
variable |
保存(或恢复)特定的 EFI 变量。 |
ver |
显示版本信息。 |
设备、驱动程序和句柄命令 — EFI Shell 用于管理设备、驱动程序和句柄的命令。 |
|
baud |
查看串行端口 com 设置。 |
connect |
将驱动程序绑定到设备。 |
dblk |
BlkIo 设备的 Hex 转储。 |
devices |
显示 EFI 驱动程序管理的设备。 |
devtree |
显示设备树。 |
dh |
转储句柄信息。 |
disconnect |
断开驱动程序与设备的连接。 |
drivers |
显示驱动程序列表。 |
drvcfg |
调用驱动程序配置协议。 |
drvdiag |
调用驱动程序诊断协议。 |
guid |
转储已知的 GUID ID。 |
lanaddress |
显示 MAC 地址。 |
load |
加载 EFI 驱动程序。 |
map |
将短名称映射到设备路径。 |
openinfo |
显示指定句柄的开放协议。 |
pci |
显示 PCI 设备或 PCI 功能配置空间。 |
reconnect |
重新连接驱动程序与设备。 |
unload |
卸载协议映像。 |
文件系统命令 — EFI Shell 用于管理文件、目录和属性的命令。 |
|
attrib |
显示(或更改)文件(或目录)的属性。 |
cd |
更新(或查看)当前目录。 |
comp |
比较两个文件的内容。 |
cp |
将一个或多个文件(或目录)复制到另一个位置。 |
edit |
全屏编辑 ASCII 或 UNICODE 文件。 |
eficompress |
压缩 infile 并写入 outfile。 |
efidecompress |
解压缩 infile 并写入 outfile。 |
hexedit |
使用 hex 编辑文件、块设备或内存区域。 |
ls |
显示目录中的文件列表和子目录。 |
mkdir |
创建一个或多个目录。 |
mount |
在块设备上挂接文件系统。 |
rm |
删除一个或多个文件(或目录)。 |
setsize |
设置文件的大小。 |
touch |
使用当前时间更新文件(或目录)的时间。 |
类型 |
显示文件内容。 |
vol |
显示文件系统的卷信息。 |
内存命令 — EFI Shell 用于列出和管理内存、EFI 变量和 NVRAM 详细信息的命令。 |
|
default |
设置缺省的 NVRAM 值。 |
dmem |
转储内存或内存映射的 IO。 |
dmpstore |
显示所有 EFI 变量。 |
memmap |
显示内存映射。 |
mm |
显示(或修改)MEM/IO/PCI。 |
pdt |
查看/清除 nPartition 或单元内存页面取消分配表 (PDT)。 |
Shell 导航和其他命令 — EFI Shell 用于基本 EFI Shell 导航和定制的命令。 |
|
alias |
设置(或获取)别名设置。 |
cls |
使用可选背景颜色清除标准输出。 |
exit |
退出 EFI Shell 环境。 |
getmtc |
显示单调增加或减小的当前计数器值。 |
help 或 ? |
显示帮助。 |
mode |
显示控制台输出设备的模式。 |
set |
设置(或获取)环境变量。 |
xchar |
打开(或关闭)扩展字符功能。 |
Shell 脚本命令(或编程结构)— EFI Shell EFI shell 脚本命令。 |
|
echo |
将消息回显给 stdout 或切换脚本回显。 |
else |
仅限脚本:使用 IF THEN。 |
endfor |
仅限脚本:FOR 循环结构的分隔符。 |
endif |
仅限脚本:IF THEN 结构的分隔符。 |
for |
仅限脚本:循环结构。 |
goto |
仅限脚本:跳至脚本中的标签位置。 |
if |
仅限脚本:IF THEN 结构。 |
input |
获取用户输入并放到 EFI 变量中。 |
pause |
仅限脚本:提示退出或继续。 |
stall |
停止处理器几微秒。 |
动态磁盘 LDM结构
动态磁盘的结构相对普通分区表会有些复杂,这里贴出LDM的结构代码,仅供编程爱好者参考,如果大家想管理动态磁盘推荐大家使用DiskGenius来管理。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 |
struct privhead { /* Offsets and sizes are in sectors. */ u16 ver_major; u16 ver_minor; u64 logical_disk_start; u64 logical_disk_size; u64 config_start; u64 config_size; u8 disk_id[GUID_SIZE]; }; struct tocblock { /* We have exactly two bitmaps. */ u8 bitmap1_name[16]; u64 bitmap1_start; u64 bitmap1_size; u8 bitmap2_name[16]; u64 bitmap2_start; u64 bitmap2_size; }; struct vmdb { /* VMDB: The database header */ u16 ver_major; u16 ver_minor; u32 vblk_size; u32 vblk_offset; u32 last_vblk_seq; }; struct vblk_comp { /* VBLK Component */ u8 state[16]; u64 parent_id; u8 type; u8 children; u16 chunksize; }; struct vblk_dgrp { /* VBLK Disk Group */ u8 disk_id[64]; }; struct vblk_disk { /* VBLK Disk */ u8 disk_id[GUID_SIZE]; u8 alt_name[128]; }; struct vblk_part { /* VBLK Partition */ u64 start; u64 size; /* start, size and vol_off in sectors */ u64 volume_offset; u64 parent_id; u64 disk_id; u8 partnum; }; struct vblk_volu { /* VBLK Volume */ u8 volume_type[16]; u8 volume_state[16]; u8 guid[16]; u8 drive_hint[4]; u64 size; u8 partition_type; }; struct vblk_head { /* VBLK standard header */ u32 group; u16 rec; u16 nrec; }; struct vblk { /* Generalised VBLK */ u8 name[64]; u64 obj_id; u32 sequence; u8 flags; u8 type; union { struct vblk_comp comp; struct vblk_dgrp dgrp; struct vblk_disk disk; struct vblk_part part; struct vblk_volu volu; } vblk; struct list_head list; }; struct ldmdb { /* Cache of the database */ struct privhead ph; struct tocblock toc; struct vmdb vm; struct list_head v_dgrp; struct list_head v_disk; struct list_head v_volu; struct list_head v_comp; struct list_head v_part; }; |
x86寄存器说明
ebp和esp是32位的SP,BP
esp是堆栈指针
ebp是基址指针
ESP与SP的关系就象AX与AL,AH的关系.
32位CPU所含有的寄存器有:
4个数据寄存器(EAX、EBX、ECX和EDX)
2个变址和指针寄存器(ESI和EDI) 2个指针寄存器(ESP和EBP)
6个段寄存器(ES、CS、SS、DS、FS和GS)
1个指令指针寄存器(EIP) 1个标志寄存器(EFlags)
1、数据寄存器
数据寄存器主要用来保存操作数和运算结果等信息,从而节省读取操作数所需占用总线和访问存储器的时间。
32位CPU有4个32位的通用寄存器EAX、EBX、ECX和EDX。对低16位数据的存取,不会影响高16位的数据。这些
低16位寄存器分别命名为:AX、BX、CX和DX,它和先前的CPU中的寄存器相一致。
4个16位寄存器又可分割成8个独立的8位寄存器(AX:AH-AL、BX:BH-BL、CX:CH-CL、DX:DH-DL),每个寄
存器都有自己的名称,可独立存取。程序员可利用数据寄存器的这种“可分可合”的特性,灵活地处理字/字
节的信息。
寄存器AX和AL通常称为累加器(Accumulator),用累加器进行的操作可能需要更少时间。累加器可用于乘、
除、输入/输出等操作,它们的使用频率很高;
寄存器BX称为基地址寄存器(Base Register)。它可作为存储器指针来使用;
寄存器CX称为计数寄存器(Count Register)。在循环和字符串操作时,要用它来控制循环次数;在位操作
中,当移多位时,要用CL来指明移位的位数;
寄存器DX称为数据寄存器(Data Register)。在进行乘、除运算时,它可作为默认的操作数参与运算,也
可用于存放I/O的端口地址。
在16位CPU中,AX、BX、CX和DX不能作为基址和变址寄存器来存放存储单元的地址,但在32位CPU中,其32位
寄存器EAX、EBX、ECX和EDX不仅可传送数据、暂存数据保存算术逻辑运算结果,而且也可作为指针寄存器,
所以,这些32位寄存器更具有通用性。
2、变址寄存器
32位CPU有2个32位通用寄存器ESI和EDI。其低16位对应先前CPU中的SI和DI,对低16位数据的存取,不影响
高16位的数据。
寄存器ESI、EDI、SI和DI称为变址寄存器(Index Register),它们主要用于存放存储单元在段内的偏移量,
用它们可实现多种存储器操作数的寻址方式,为以不同的地址形式访问存储单元提供方便。
变址寄存器不可分割成8位寄存器。作为通用寄存器,也可存储算术逻辑运算的操作数和运算结果。
它们可作一般的存储器指针使用。在字符串操作指令的执行过程中,对它们有特定的要求,而且还具有特
殊的功能。
3、指针寄存器
32位CPU有2个32位通用寄存器EBP和ESP。其低16位对应先前CPU中的SBP和SP,对低16位数据的存取,不影
响高16位的数据。
寄存器EBP、ESP、BP和SP称为指针寄存器(Pointer Register),主要用于存放堆栈内存储单元的偏移量,
用它们可实现多种存储器操作数的寻址方式,为以不同的地址形式访问存储单元提供方便。
指针寄存器不可分割成8位寄存器。作为通用寄存器,也可存储算术逻辑运算的操作数和运算结果。
它们主要用于访问堆栈内的存储单元,并且规定:
BP为基指针(Base Pointer)寄存器,用它可直接存取堆栈中的数据;
SP为堆栈指针(Stack Pointer)寄存器,用它只可访问栈顶。
4、段寄存器
段寄存器是根据内存分段的管理模式而设置的。内存单元的物理地址由段寄存器的值和一个偏移量组合而成
的,这样可用两个较少位数的值组合成一个可访问较大物理空间的内存地址。
CPU内部的段寄存器:
CS——代码段寄存器(Code Segment Register),其值为代码段的段值;
DS——数据段寄存器(Data Segment Register),其值为数据段的段值;
ES——附加段寄存器(Extra Segment Register),其值为附加数据段的段值;
SS——堆栈段寄存器(Stack Segment Register),其值为堆栈段的段值;
FS——附加段寄存器(Extra Segment Register),其值为附加数据段的段值;
GS——附加段寄存器(Extra Segment Register),其值为附加数据段的段值。
在16位CPU系统中,它只有4个段寄存器,所以,程序在任何时刻至多有4个正在使用的段可直接访问;在32位
微机系统中,它有6个段寄存器,所以,在此环境下开发的程序最多可同时访问6个段。
32位CPU有两个不同的工作方式:实方式和保护方式。在每种方式下,段寄存器的作用是不同的。有关规定简
单描述如下:
实方式: 前4个段寄存器CS、DS、ES和SS与先前CPU中的所对应的段寄存器的含义完全一致,内存单元的逻辑
地址仍为“段值:偏移量”的形式。为访问某内存段内的数据,必须使用该段寄存器和存储单元的偏移量。
保护方式: 在此方式下,情况要复杂得多,装入段寄存器的不再是段值,而是称为“选择子”(Selector)的某个值。。
5、指令指针寄存器
32位CPU把指令指针扩展到32位,并记作EIP,EIP的低16位与先前CPU中的IP作用相同。
指令指针EIP、IP(Instruction Pointer)是存放下次将要执行的指令在代码段的偏移量。在具有预取指令功
能的系统中,下次要执行的指令通常已被预取到指令队列中,除非发生转移情况。所以,在理解它们的功能
时,不考虑存在指令队列的情况。
在实方式下,由于每个段的最大范围为64K,所以,EIP中的高16位肯定都为0,此时,相当于只用其低16位
的IP来反映程序中指令的执行次序。
6、标志寄存器
一、运算结果标志位
1、进位标志CF(Carry Flag)
进位标志CF主要用来反映运算是否产生进位或借位。如果运算结果的最高位产生了一个进位或借位,那么,其值为1,否则其值为0。
使用该标志位的情况有:多字(字节)数的加减运算,无符号数的大小比较运算,移位操作,字(字节)之间移位,专门改变CF值的指令等。
2、奇偶标志PF(Parity Flag)
奇偶标志PF用于反映运算结果中“1”的个数的奇偶性。如果“1”的个数为偶数,则PF的值为1,否则其值为0。
利用PF可进行奇偶校验检查,或产生奇偶校验位。在数据传送过程中,为了提供传送的可靠性,如果采用奇偶校验的方法,就可使用该标志位。
3、辅助进位标志AF(Auxiliary Carry Flag)
在发生下列情况时,辅助进位标志AF的值被置为1,否则其值为0:
(1)、在字操作时,发生低字节向高字节进位或借位时;
(2)、在字节操作时,发生低4位向高4位进位或借位时。
对以上6个运算结果标志位,在一般编程情况下,标志位CF、ZF、SF和OF的使用频率较高,而标志位PF和AF的使用频率较低。
4、零标志ZF(Zero Flag)
零标志ZF用来反映运算结果是否为0。如果运算结果为0,则其值为1,否则其值为0。在判断运算结果是否为0时,可使用此标志位。
5、符号标志SF(Sign Flag)
符号标志SF用来反映运算结果的符号位,它与运算结果的最高位相同。在微机系统中,有符号数采用补码表示法,所以,SF也就反映运算结果的正负号。运算结果为正数时,SF的值为0,否则其值为1。
6、溢出标志OF(Overflow Flag)
溢出标志OF用于反映有符号数加减运算所得结果是否溢出。如果运算结果超过当前运算位数所能表示的范围,则称为溢出,OF的值被置为1,否则,OF的值被清为0。
“溢出”和“进位”是两个不同含义的概念,不要混淆。如果不太清楚的话,请查阅《计算机组成原理》课程中的有关章节。
二、状态控制标志位
状态控制标志位是用来控制CPU操作的,它们要通过专门的指令才能使之发生改变。
1、追踪标志TF(Trap Flag)
当追踪标志TF被置为1时,CPU进入单步执行方式,即每执行一条指令,产生一个单步中断请求。这种方式主要用于程序的调试。
指令系统中没有专门的指令来改变标志位TF的值,但程序员可用其它办法来改变其值。
2、中断允许标志IF(Interrupt-enable Flag)
中断允许标志IF是用来决定CPU是否响应CPU外部的可屏蔽中断发出的中断请求。但不管该标志为何值,CPU都必须响应CPU外部的不可屏蔽中断所发出的中断请求,以及CPU内部产生的中断请求。具体规定如下:
(1)、当IF=1时,CPU可以响应CPU外部的可屏蔽中断发出的中断请求;
(2)、当IF=0时,CPU不响应CPU外部的可屏蔽中断发出的中断请求。
CPU的指令系统中也有专门的指令来改变标志位IF的值。
3、方向标志DF(Direction Flag)
方向标志DF用来决定在串操作指令执行时有关指针寄存器发生调整的方向。具体规定在第5.2.11节——字符串操作指令——中给出。在微机的指令系统中,还提供了专门的指令来改变标志位DF的值。
三、32位标志寄存器增加的标志位
1、I/O特权标志IOPL(I/O Privilege Level)
I/O特权标志用两位二进制位来表示,也称为I/O特权级字段。该字段指定了要求执行I/O指令的特权级。如果当前的特权级别在数值上小于等于IOPL的值,那么,该I/O指令可执行,否则将发生一个保护异常。
2、嵌套任务标志NT(Nested Task)
嵌套任务标志NT用来控制中断返回指令IRET的执行。具体规定如下:
(1)、当NT=0,用堆栈中保存的值恢复EFLAGS、CS和EIP,执行常规的中断返回操作;
(2)、当NT=1,通过任务转换实现中断返回。
3、重启动标志RF(Restart Flag)
重启动标志RF用来控制是否接受调试故障。规定:RF=0时,表示“接受”调试故障,否则拒绝之。在成功执行完一条指令后,处理机把RF置为0,当接受到一个非调试故障时,处理机就把它置为1。
4、虚拟8086方式标志VM(Virtual 8086 Mode)
如果该标志的值为1,则表示处理机处于虚拟的8086方式下的工作状态,否则,处理机处于一般保护方式下的工作状态。