Network Working Group Y. Kikuchi Request for Comments: 3016 Toshiba Category: Standards Track T. Nomura NEC S. Fukunaga Oki Y. Matsui Matsushita H. Kimata NTT November 2000 RTP Payload Format for MPEG-4 Audio/Visual Streams
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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes Real-Time Transport Protocol (RTP) payload
formats for carrying each of MPEG-4 Audio and MPEG-4 Visual
bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies
fragmentation rules. It also provides specifications for
Multipurpose Internet Mail Extensions (MIME) type registrations and
the use of Session Description Protocol (SDP).
1. Introduction
The RTP payload formats described in this document specify how MPEG-4 Audio [3][5] and MPEG-4 Visual streams [2][4] are to be fragmented
and mapped directly onto RTP packets.
These RTP payload formats enable transport of MPEG-4 Audio/Visual
streams without using the synchronization and stream management
functionality of MPEG-4 Systems [6]. Such RTP payload formats will
be used in systems that have intrinsic stream management
Kikuchi, et al. Standards Track [Page 1]
functionality and thus require no such functionality from MPEG-4
Systems. H.323 terminals are an example of such systems, where
MPEG-4 Audio/Visual streams are not managed by MPEG-4 Systems Object Descriptors but by H.245. The streams are directly mapped onto RTP
packets without using MPEG-4 Systems Sync Layer. Other examples are SIP and RTSP where MIME and SDP are used. MIME types and SDP usages of the RTP payload formats described in this document are defined to directly specify the attribute of Audio/Visual streams (e.g., media
type, packetization format and codec configuration) without using
MPEG-4 Systems. The obvious benefit is that these MPEG-4
Audio/Visual RTP payload formats can be handled in an unified way
together with those formats defined for non-MPEG-4 codecs. The
disadvantage is that interoperability with environments using MPEG-4 Systems may be difficult, other payload formats may be better suited to those applications.
The semantics of RTP headers in such cases need to be clearly
defined, including the association with MPEG-4 Audio/Visual data
elements. In addition, it is beneficial to define the fragmentation rules of RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resilience tools provided inside
the MPEG-4 Video stream.
1.1 MPEG-4 Visual RTP payload format
MPEG-4 Visual is a visual coding standard with many new features:
high coding efficiency; high error resiliency; multiple, arbitrary
shape object-based coding; etc. [2]. It covers a wide range of
bitrates from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost
error-free to mobile networks with high error rates.
With respect to the fragmentation rules for an MPEG-4 Visual
bitstream defined in this document, since MPEG-4 Visual is used for a wide variety of networks, it is desirable not to apply too much
restriction on fragmentation, and a fragmentation rule such as "a
single video packet shall always be mapped on a single RTP packet"
may be inappropriate. On the other hand, careless, media unaware
fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are
flexible but manage to define the minimum rules for preventing
meaningless fragmentation while utilizing the error resilience
functionalities of MPEG-4 Visual.
The fragmentation rule recommends not to map more than one VOP in an RTP packet so that the RTP timestamp uniquely indicates the VOP time framing. On the other hand, MPEG-4 video may generate VOPs of very
small size, in cases with an empty VOP (vop_coded=0) containing only Kikuchi, et al. Standards Track [Page 2]
VOP header or an arbitrary shaped VOP with a small number of coding
blocks. To reduce the overhead for such cases, the fragmentation
rule permits concatenating multiple VOPs in an RTP packet. (See
fragmentation rule (4) in section 3.2 and marker bit and timestamp in section 3.1.)
While the additional media specific RTP header defined for such video coding tools as H.261 or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, MPEG-4 Visual has already error resilience functionalities for recovering corrupt headers, and these can be used on RTP/IP networks as well as on other networks
(H.223/mobile, MPEG-2/TS, etc.). Therefore, no extra RTP header
fields are defined in this MPEG-4 Visual RTP payload format.
1.2 MPEG-4 Audio RTP payload format
MPEG-4 Audio is a new kind of audio standard that integrates many
different types of audio coding tools. Low-overhead MPEG-4 Audio
Transport Multiplex (LATM) manages the sequences of audio data with
relatively small overhead. In audio-only applications, then, it is
desirable for LATM-based MPEG-4 Audio bitstreams to be directly
mapped onto the RTP packets without using MPEG-4 Systems.
While LATM has several multiplexing features as follows;
- Carrying configuration information with audio data,
- Concatenation of multiple audio frames in one audio stream,
- Multiplexing multiple objects (programs),
- Multiplexing scalable layers,
in RTP transmission there is no need for the last two features.
Therefore, these two features MUST NOT be used in applications based on RTP packetization specified by this document. Since LATM has been developed for only natural audio coding tools, i.e., not for
synthesis tools, it seems difficult to transmit Structured Audio (SA) data and Text to Speech Interface (TTSI) data by LATM. Therefore, SA data and TTSI data MUST NOT be transported by the RTP packetization
in this document.
For transmission of scalable streams, audio data of each layer SHOULD be packetized onto different RTP packets allowing for the different
layers to be treated differently at the IP level, for example via
some means of differentiated service. On the other hand, all
configuration data of the scalable streams are contained in one LATM configuration data "StreamMuxConfig" and every scalable layer shares the StreamMuxConfig. The mapping between each layer and its
configuration data is achieved by LATM header information attached to Kikuchi, et al. Standards Track [Page 3]
the audio data. In order to indicate the dependency information of
the scalable streams, a restriction is applied to the dynamic
assignment rule of payload type (PT) values (see section 4.2).
For MPEG-4 Audio coding tools, as is true for other audio coders, if the payload is a single audio frame, packet loss will not impair the decodability of adjacent packets. Therefore, the additional media
specific header for recovering errors will not be required for MPEG-4 Audio. Existing RTP protection mechanisms, such as Generic Forward
Error Correction (RFC 2733) and Redundant Audio Data (RFC 2198), MAY be applied to improve error resiliency.
2. Conventions used in this document
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 RFC-2119 [7].
3. RTP Packetization of MPEG-4 Visual bitstream
This section specifies RTP packetization rules for MPEG-4 Visual
content. An MPEG-4 Visual bitstream is mapped directly onto RTP
packets without the addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode MUST be used so that configuration information will be carried
to the same RTP port as the elementary stream. (see 6.2.1 "Start
codes" of ISO/IEC 14496-2 [2][9][4]) The configuration information
MAY additionally be specified by some out-of-band means. If needed
for an H.323 terminal, H.245 codepoint
"decoderConfigurationInformation" MUST be used for this purpose. If needed by systems using MIME content type and SDP parameters, e.g.,
SIP and RTSP, the optional parameter "config" MUST be used to specify the configuration information (see 5.1 and 5.2).
When the short video header mode is used, the RTP payload format for H.263 SHOULD be used (the format defined in RFC 2429 is RECOMMENDED, but the RFC 2190 format MAY be used for compatibility with older
implementations).
Kikuchi, et al. Standards Track [Page 4]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number | RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | RTP
| MPEG-4 Visual stream (byte aligned) | Pay-
| | load
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - An RTP packet for MPEG-4 Visual stream
3.1 Use of RTP header fields for MPEG-4 Visual
Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding,
or if that is not done then a payload type in the dynamic range SHALL be chosen by means of an out of band signaling protocol (e.g., H.245, SIP, etc).
Extension (X) bit: Defined by the RTP profile used.
Sequence Number: Incremented by one for each RTP data packet sent,
starting, for security reasons, with a random initial value.
Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. When multiple VOPs are carried in the same RTP packet, the marker bit is set to one.
Timestamp: The timestamp indicates the sampling instance of the VOP
contained in the RTP packet. A constant offset, which is random, is added for security reasons.
- When multiple VOPs are carried in the same RTP packet, the
timestamp indicates the earliest of the VOP times within the VOPs carried in the RTP packet. Timestamp information of the rest of Kikuchi, et al. Standards Track [Page 5]
the VOPs are derived from the timestamp fields in the VOP header
(modulo_time_base and vop_time_increment).
- If the RTP packet contains only configuration information and/or
Group_of_VideoObjectPlane() fields, the timestamp of the next VOP in the coding order is used.
- If the RTP packet contains only visual_object_sequence_end_code
information, the timestamp of the immediately preceding VOP in the coding order is used.
The resolution of the timestamp is set to its default value of 90kHz, unless specified by an out-of-band means (e.g., SDP parameter or MIME parameter as defined in section 5).
Other header fields are used as described in RFC 1889 [8].
3.2 Fragmentation of MPEG-4 Visual bitstream
A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary
streams mode is used. The following rules apply for the
fragmentation.
In the following, header means one of the following:
- Configuration information (Visual Object Sequence Header, Visual
Object Header and Video Object Layer Header)
- visual_object_sequence_end_code
- The header of the entry point function for an elementary stream
(Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject())
- The video packet header (video_packet_header() excluding
next_resync_marker())
- The header of gob_layer()
See 6.2.1 "Start codes" of ISO/IEC 14496-2 [2][9][4] for the
definition of the configuration information and the entry point
functions.
(1) Configuration information and Group_of_VideoObjectPlane() fields SHALL be placed at the beginning of the RTP payload (just after the
RTP header) or just after the header of the syntactically upper layer function.
(2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function.
Note: The visual_object_sequence_end_code is regarded as the lowest
function.
Kikuchi, et al. Standards Track [Page 6]
(3) A header SHALL NOT be split into a plurality of RTP packets.
(4) Different VOPs SHOULD be fragmented into different RTP packets so that one RTP packet consists of the data bytes associated with a
unique VOP time instance (that is indicated in the timestamp field in the RTP packet header), with the exception that multiple consecutive VOPs MAY be carried within one RTP packet in the decoding order if
the size of the VOPs is small.
Note: When multiple VOPs are carried in one RTP payload, the
timestamp of the VOPs after the first one may be calculated by the
decoder. This operation is necessary only for RTP packets in which
the marker bit equals to one and the beginning of RTP payload
corresponds to a start code. (See timestamp and marker bit in section 3.1.)
(5) It is RECOMMENDED that a single video packet is sent as a single RTP packet. The size of a video packet SHOULD be adjusted in such a way that the resulting RTP packet is not larger than the path-MTU.
Note: Rule (5) does not apply when the video packet is disabled by
the coder configuration (by setting resync_marker_disable in the VOL header to 1), or in coding tools where the video packet is not
supported. In this case, a VOP MAY be split at arbitrary byte-
positions.
The video packet starts with the VOP header or the video packet
header, followed by motion_shape_texture(), and ends with
next_resync_marker() or next_start_code().
3.3 Examples of packetized MPEG-4 Visual bitstream
Figure 2 shows examples of RTP packets generated based on the
criteria described in 3.2
(a) is an example of the first RTP packet or the random access point of an MPEG-4 Visual bitstream containing the configuration
information. According to criterion (1), the Visual Object Sequence Header(VS header) is placed at the beginning of the RTP payload,
preceding the Visual Object Header and the Video Object Layer
Header(VO header, VOL header). Since the fragmentation rule defined in 3.2 guarantees that the configuration information, starting with
visual_object_sequence_start_code, is always placed at the beginning of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is
visual_object_sequence_start_code.
Kikuchi, et al. Standards Track [Page 7]
(b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a video packet in the VOP following the configuration
information. Since the length of the configuration information is
relatively short (typically scores of bytes) and an RTP packet
containing only the configuration information may thus increase the
overhead, the configuration information and the immediately following GOV and/or (a part of) VOP can be packetized into a single RTP packet as in this example.
(c) is an example of an RTP packet that contains
Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is placed at the beginning of the RTP payload. It would be a waste of
RTP/IP header overhead to generate an RTP packet containing only a
GOV whose length is 7 bytes. Therefore, (a part of) the following
VOP can be placed in the same RTP packet as shown in (c).
(d) is an example of the case where one video packet is packetized
into one RTP packet. When the packet-loss rate of the underlying
network is high, this kind of packetization is recommended. Even
when the RTP packet containing the VOP header is discarded by a
packet loss, the other RTP packets can be decoded by using the
HEC(Header Extension Code) information in the video packet header.
No extra RTP header field is necessary.
(e) is an example of the case where more than one video packet is
packetized into one RTP packet. This kind of packetization is
effective to save the overhead of RTP/IP headers when the bit-rate of the underlying network is low. However, it will decrease the
packet-loss resiliency because multiple video packets are discarded
by a single RTP packet loss. The optimal number of video packets in an RTP packet and the length of the RTP packet can be determined
considering the packet-loss rate and the bit-rate of the underlying
network.
(f) is an example of the case when the video packet is disabled by
setting resync_marker_disable in the VOL header to 1. In this case, a VOP may be split into a plurality of RTP packets at arbitrary
byte-positions. For example, it is possible to split a VOP into
fixed-length packets. This kind of coder configuration and RTP
packet fragmentation may be used when the underlying network is
guaranteed to be error-free. On the other hand, it is not
recommended to use it in error-prone environment since it provides
only poor packet loss resiliency.
Figure 3 shows examples of RTP packets prohibited by the criteria of 3.2.
Kikuchi, et al. Standards Track [Page 8]
Fragmentation of a header into multiple RTP packets, as in (a), will not only increase the overhead of RTP/IP headers but also decrease
the error resiliency. Therefore, it is prohibited by the criterion
(3).
When concatenating more than one video packets into an RTP packet,
VOP header or video_packet_header() shall not be placed in the middle of the RTP payload. The packetization as in (b) is not allowed by
criterion (2) due to the aspect of the error resiliency. Comparing
this example with Figure 2(d), although two video packets are mapped onto two RTP packets in both cases, the packet-loss resiliency is not identical. Namely, if the second RTP packet is lost, both video
packets 1 and 2 are lost in the case of Figure 3(b) whereas only
video packet 2 is lost in the case of Figure 2(d).
+------+------+------+------+
(a) | RTP | VS | VO | VOL |
|header|header|header|header|
+------+------+------+------+
+------+------+------+------+------------+
(b) | RTP | VS | VO | VOL |Video Packet|
|header|header|header|header| |
+------+------+------+------+------------+
+------+-----+------------------+
(c) | RTP | GOV |Video Object Plane|
|header| | |
+------+-----+------------------+
+------+------+------------+ +------+------+------------+
(d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet|
|header|header| (1) | |header|header| (2) |
+------+------+------------+ +------+------+------------+
+------+------+------------+------+------------+------+------------+ (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video Packet| |header|header| (1) |header| (2) |header| (3) | +------+------+------------+------+------------+------+------------+ +------+------+------------+ +------+------------+
(f) | RTP | VOP |VOP fragment| | RTP |VOP fragment|
|header|header| (1) | |header| (2) | ___
+------+------+------------+ +------+------------+
Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream Kikuchi, et al. Standards Track [Page 9]
+------+-------------+ +------+------------+------------+
(a) | RTP |First half of| | RTP |Last half of|Video Packet|
|header| VP header | |header| VP header | |
+------+-------------+ +------+------------+------------+
+------+------+----------+ +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video Packet|
|header|header| of VP(1) | |header| of VP(1)|header| (2) |
+------+------+----------+ +------+---------+------+------------+
Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream
4. RTP Packetization of MPEG-4 Audio bitstream
This section specifies RTP packetization rules for MPEG-4 Audio
bitstreams. MPEG-4 Audio streams MUST be formatted by LATM (Low-
overhead MPEG-4 Audio Transport Multiplex) tool [5], and the LATM-
based streams are then mapped onto RTP packets as described the three sections below.
4.1 RTP Packet Format
LATM-based streams consist of a sequence of audioMuxElements that
include one or more audio frames. A complete audioMuxElement or a
part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 4). The first byte of each audioMuxElement SHALL be located at the first payload
location in an RTP packet.
Kikuchi, et al. Standards Track [Page 10]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |RTP
: audioMuxElement (byte aligned) :Payload | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - An RTP packet for MPEG-4 Audio
In order to decode the audioMuxElement, the following
muxConfigPresent information is required to be indicated by an out-
of-band means. When SDP is utilized for this indication, MIME
parameter "cpresent" corresponds to the muxConfigPresent information (see section 5.3).
muxConfigPresent: If this value is set to 1 (in-band mode), the
audioMuxElement SHALL include an indication bit "useSameStreamMux"
and MAY include the configuration information for audio compression
"StreamMuxConfig". The useSameStreamMux bit indicates whether the
StreamMuxConfig element in the previous frame is applied in the
current frame. If the useSameStreamMux bit indicates to use the
StreamMuxConfig from the previous frame, but if the previous frame
has been lost, the current frame may not be decodable. Therefore, in case of in-band mode, the StreamMuxConfig element SHOULD be
transmitted repeatedly depending on the network condition. On the
other hand, if muxConfigPresent is set to 0 (out-band mode), the
StreamMuxConfig element is required to be transmitted by an out-of-
band means. In case of SDP, MIME parameter "config" is utilized (see section 5.3).
4.2 Use of RTP Header Fields for MPEG-4 Audio
Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, Kikuchi, et al. Standards Track [Page 11]
or if that is not done then a payload type in the dynamic range shall be chosen by means of an out of band signaling protocol (e.g., H.245, SIP, etc). In the dynamic assignment of RTP payload types for
scalable streams, a different value SHOULD be assigned to each layer. The assigned values SHOULD be in order of enhance layer dependency,
where the base layer has the smallest value.
Marker (M) bit: The marker bit indicates audioMuxElement boundaries. It is set to one to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement.
Timestamp: The timestamp indicates the sampling instance of the first audio frame contained in the RTP packet. Timestamps are recommended to start at a random value for security reasons.
Unless specified by an out-of-band means, the resolution of the
timestamp is set to its default value of 90 kHz.
Sequence Number: Incremented by one for each RTP packet sent,
starting, for security reasons, with a random value.
Other header fields are used as described in RFC 1889 [8].
4.3 Fragmentation of MPEG-4 Audio bitstream
It is RECOMMENDED to put one audioMuxElement in each RTP packet. If the size of an audioMuxElement can be kept small enough that the size of the RTP packet containing it does not exceed the size of the
path-MTU, this will be no problem. If it cannot, the audioMuxElement MAY be fragmented and spread across multiple packets.
5. MIME type registration for MPEG-4 Audio/Visual streams
The following sections describe the MIME type registrations for
MPEG-4 Audio/Visual streams. MIME type registration and SDP usage
for the MPEG-4 Visual stream are described in Sections 5.1 and 5.2,
respectively, while MIME type registration and SDP usage for MPEG-4
Audio stream are described in Sections 5.3 and 5.4, respectively.
5.1 MIME type registration for MPEG-4 Visual
MIME media type name: video
MIME subtype name: MP4V-ES
Required parameters: none
Optional parameters:
Kikuchi, et al. Standards Track [Page 12]
rate: This parameter is used only for RTP transport. It indicates the resolution of the timestamp field in the RTP header. If this parameter is not specified, its default value of 90000 (90kHz) is used.
profile-level-id: A decimal representation of MPEG-4 Visual
Profile and Level indication value (profile_and_level_indication) defined in Table G-1 of ISO/IEC 14496-2 [2][4]. This parameter
MAY be used in the capability exchange or session setup procedure to indicate MPEG-4 Visual Profile and Level combination of which
the MPEG-4 Visual codec is capable. If this parameter is not
specified by the procedure, its default value of 1 (Simple
Profile/Level 1) is used.
config: This parameter SHALL be used to indicate the configuration of the corresponding MPEG-4 Visual bitstream. It SHALL NOT be
used to indicate the codec capability in the capability exchange
procedure. It is a hexadecimal representation of an octet string that expresses the MPEG-4 Visual configuration information, as
defined in subclause 6.2.1 Start codes of ISO/IEC14496-2
[2][4][9]. The configuration information is mapped onto the octet string in an MSB-first basis. The first bit of the configuration information SHALL be located at the MSB of the first octet. The
configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first_half_vbv_occupancy and
latter_half_vbv_occupancy, if exist, which may vary in the
repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2).
Example usages for these parameters are:
- MPEG-4 Visual Simple Profile/Level 1:
Content-type: video/mp4v-es; profile-level-id=1
- MPEG-4 Visual Core Profile/Level 2:
Content-type: video/mp4v-es; profile-level-id=34
- MPEG-4 Visual Advanced Real Time Simple Profile/Level 1:
Content-type: video/mp4v-es; profile-level-id=145
Published specification:
The specifications for MPEG-4 Visual streams are presented in
ISO/IEC 14469-2 [2][4][9]. The RTP payload format is described in RFC 3016.
Kikuchi, et al. Standards Track [Page 13]
Encoding considerations:
Video bitstreams MUST be generated according to MPEG-4 Visual
specifications (ISO/IEC 14496-2). A video bitstream is binary
data and MUST be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for
transfer via RTP. The RTP packets MUST be packetized according to the MPEG-4 Visual RTP payload format defined in RFC 3016.
Security considerations:
See section 6 of RFC 3016.
Interoperability considerations:
MPEG-4 Visual provides a large and rich set of tools for the
coding of visual objects. For effective implementation of the
standard, subsets of the MPEG-4 Visual tool sets have been
provided for use in specific applications. These subsets, called ’Profiles’, limit the size of the tool set a decoder is required
to implement. In order to restrict computational complexity, one or more Levels are set for each Profile. A Profile@Level
combination allows:
o a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices
included in the same combination, and
o checking whether MPEG-4 devices comply with the standard (’
conformance testing’).
The visual stream SHALL be compliant with the MPEG-4 Visual
Profile@Level specified by the parameter "profile-level-id".
Interoperability between a sender and a receiver may be achieved
by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange/announcement procedure to set this parameter mutually to the same value.
Applications which use this media type:
Audio and visual streaming and conferencing tools, Internet
messaging and Email applications.
Additional information: none
Person & email address to contact for further information:
The authors of RFC 3016. (See section 8.)
Intended usage: COMMON
Author/Change controller:
The authors of RFC 3016. (See section 8.)
Kikuchi, et al. Standards Track [Page 14]
5.2 SDP usage of MPEG-4 Visual
The MIME media type video/MP4V-ES string is mapped to fields in the
Session Description Protocol (SDP), RFC 2327, as follows:
o The MIME type (video) goes in SDP "m=" as the media name.
o The MIME subtype (MP4V-ES) goes in SDP "a=rtpmap" as the encoding
name.
o The optional parameter "rate" goes in "a=rtpmap" as the clock
rate.
o The optional parameter "profile-level-id" and "config" go in the
"a=fmtp" line to indicate the coder capability and configuration,
respectively. These parameters are expressed as a MIME media type string, in the form of as a semicolon separated list of
parameter=value pairs.
The following are some examples of media representation in SDP:
Simple Profile/Level 1, rate=90000(90kHz), "profile-level-id" and "config" are present in "a=fmtp" line:
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=1;config=000001B001000001B509000001000000012 0008440FA282C2090A21F
Core Profile/Level 2, rate=90000(90kHz), "profile-level-id" is present in "a=fmtp" line:
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=34
Advance Real Time Simple Profile/Level 1, rate=90000(90kHz),
"profile-level-id" is present in "a=fmtp" line:
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 MP4V-ES/90000
a=fmtp:98 profile-level-id=145
5.3 MIME type registration of MPEG-4 Audio
MIME media type name: audio
MIME subtype name: MP4A-LATM
Kikuchi, et al. Standards Track [Page 15]
Required parameters:
rate: the rate parameter indicates the RTP time stamp clock rate. The default value is 90000. Other rates MAY be specified only if they are set to the same value as the audio sampling rate (number of samples per second).
Optional parameters:
profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in ISO/IEC 14496-1 ([6] and its
amendments). This parameter indicates which MPEG-4 Audio tool
subsets the decoder is capable of using. If this parameter is not specified in the capability exchange or session setup procedure,
its default value of 30 (Natural Audio Profile/Level 1) is used.
object: a decimal representation of the MPEG-4 Audio Object Type
value defined in ISO/IEC 14496-3 [5]. This parameter specifies
the tool to be used by the coder. It CAN be used to limit the
capability within the specified "profile-level-id".
bitrate: the data rate for the audio bit stream.
cpresent: a boolean parameter indicates whether audio payload
configuration data has been multiplexed into an RTP payload (see
section 4.1). A 0 indicates the configuration data has not been
multiplexed into an RTP payload, a 1 indicates that it has. The
default if the parameter is omitted is 1.
config: a hexadecimal representation of an octet string that
expresses the audio payload configuration data "StreamMuxConfig", as defined in ISO/IEC 14496-3 [5] (see section 4.1).
Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration data SHALL be located
at the MSB of the first octet. In the last octet, zero-padding
bits, if necessary, SHALL follow the configuration data.
ptime: RECOMMENDED duration of each packet in milliseconds.
Published specification:
Payload format specifications are described in this document.
Encoding specifications are provided in ISO/IEC 14496-3 [3][5].
Encoding considerations:
This type is only defined for transfer via RTP.
Security considerations:
See Section 6 of RFC 3016.
Kikuchi, et al. Standards Track [Page 16]
Interoperability considerations:
MPEG-4 Audio provides a large and rich set of tools for the coding of audio objects. For effective implementation of the standard,
subsets of the MPEG-4 Audio tool sets similar to those used in
MPEG-4 Visual have been provided (see section 5.1).
The audio stream SHALL be compliant with the MPEG-4 Audio
Profile@Level specified by the parameter "profile-level-id".
Interoperability between a sender and a receiver may be achieved
by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this
parameter mutually to the same value. Furthermore, the "object"
parameter can be used to limit the capability within the specified Profile@Level in capability exchange.
Applications which use this media type:
Audio and video streaming and conferencing tools.
Additional information: none
Personal & email address to contact for further information:
See Section 8 of RFC 3016.
Intended usage: COMMON
Author/Change controller:
See Section 8 of RFC 3016.
5.4 SDP usage of MPEG-4 Audio
The MIME media type audio/MP4A-LATM string is mapped to fields in the Session Description Protocol (SDP), RFC 2327, as follows:
o The MIME type (audio) goes in SDP "m=" as the media name.
o The MIME subtype (MP4A-LATM) goes in SDP "a=rtpmap" as the
encoding name.
o The required parameter "rate" goes in "a=rtpmap" as the clock
rate.
o The optional parameter "ptime" goes in SDP "a=ptime" attribute.
o The optional parameter "profile-level-id" goes in the "a=fmtp"
line to indicate the coder capability. The "object" parameter
goes in the "a=fmtp" attribute. The payload-format-specific
parameters
Kikuchi, et al. Standards Track [Page 17]
"bitrate", "cpresent" and "config" go in the "a=fmtp" line. These parameters are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=value pairs.
The following are some examples of the media representation in SDP: For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz),
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/8000
a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
a=ptime:20
For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of 24 kHz),
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/24000
a=fmtp:96 profile-level-id=1; bitrate=64000; cpresent=0;
config=9122620000
In the above two examples, audio configuration data is not
multiplexed into the RTP payload and is described only in SDP.
Furthermore, the "clock rate" is set to the audio sampling rate.
If the clock rate has been set to its default value and it is
necessary to obtain the audio sampling rate, this can be done by
parsing the "config" parameter (see the following example).
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/90000
a=fmtp:96 object=8; cpresent=0; config=9128B1071070
The following example shows that the audio configuration data appears in the RTP payload.
m=audio 49230 RTP/AVP 96
a=rtpmap:96 MP4A-LATM/90000
a=fmtp:96 object=2; cpresent=1
6. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [8]. This implies that confidentiality of the media
streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be
performed on the compressed data so there is no conflict between the two operations.
Kikuchi, et al. Standards Track [Page 18]
The complete MPEG-4 system allows for transport of a wide range of
content, including Java applets (MPEG-J) and scripts. Since this
payload format is restricted to audio and video streams, it is not
possible to transport such active content in this format.
7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 ISO/IEC 14496-2:1999, "Information technology - Coding of audio-
visual objects - Part2: Visual".
3 ISO/IEC 14496-3:1999, "Information technology - Coding of audio-
visual objects - Part3: Audio".
4 ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part 2: Visual, Amendment 1: Visual
extensions".
5 ISO/IEC 14496-3:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part3: Audio, Amendment 1: Audio
extensions".
6 ISO/IEC 14496-1:1999, "Information technology - Coding of audio-
visual objects - Part1: Systems".
7 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A Transport Protocol for Real Time Applications", RFC 1889, January 1996.
9 ISO/IEC 14496-2:1999/Cor.1:2000, "Information technology - Coding of audio-visual objects - Part2: Visual, Technical corrigendum 1". Kikuchi, et al. Standards Track [Page 19]
8. Authors’ Addresses
Yoshihiro Kikuchi
Toshiba corporation
1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan
EMail: yoshihiro.kikuchi@toshiba.co.jp
Yoshinori Matsui
Matsushita Electric Industrial Co., LTD.
1006, Kadoma, Kadoma-shi, Osaka, Japan
EMail: matsui@drl.mei.co.jp
Toshiyuki Nomura
NEC Corporation
4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN
EMail: t-nomura@ccm.cl.nec.co.jp
Shigeru Fukunaga
Oki Electric Industry Co., Ltd.
1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan.
EMail: fukunaga444@oki.co.jp
Hideaki Kimata
Nippon Telegraph and Telephone Corporation
1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan
EMail: kimata@nttvdt.hil.ntt.co.jp
Kikuchi, et al. Standards Track [Page 20]
几秒种分区格式化500G大硬盘 近日陪好友去装机，在大容量硬盘盛行的今天，他毫不犹豫地选择了一块500GB的硬盘。看着他得意的眼神，我除了羡慕外，也暗自“窃喜”：这么大的容量，待会儿分区格式化够你受的！凭我的经验，500GB的硬盘分区格式化少则半个小时多则一个小时，再加上装系统的时间…… 所有硬件安装完毕后，装机人员在主板BIOS中设置好相关选项，这时我发现他并没有用常见的Fdisk、Format进行分区格式化，也不是用大名鼎鼎的PartitionMagic或DM，而是取出一张软盘在上面敲了一个命令（没看清），几秒钟后，重启计算机，500GB的硬盘已然分区格式化完毕，可以装系统了！我惊奇的看着他，难道有什么“特异软件”？！在随后与他的闲聊中，我“套”出了其中的“秘密”。其实，他用的根本不是什么专用软件，而是我们最常见的硬盘对拷工具：Ghost，再加上些技巧而已。 由于Ghost具有克隆整块硬盘的功能，在还原备份时，Ghost会对目标盘按照被克隆硬盘的分区比例重新分配并复制文件。如果是新硬盘还将事先自动完成格式化。按照上述的原理，可用一块已分区格式化好的硬盘为“模板”（该硬盘不装任何文件），利用Ghost备份并还原到新硬盘上，这样就能快速对大硬盘分区格式化了。具体做法：找一块任意容量大小的硬盘，对它用Fdisk、Format按照你想要对大硬盘分区的比例分区格式化好，注意不要在上面安装任何文件；然后用带有Ghost程序的启动盘启动计算机，运行Ghost，利用“Local-Disk-To Image”命令将刚刚分区格式化好的硬盘镜像成一个软件，把这个文件保存在启动盘上（放心，这个文件应该很小），并起个名字如myfdisk.gho；接着，在启动盘上制作一个DOS批处理文件（用edit命令可编辑），内容为：ghost.exe-clone,mode=load,src=a:myfdisk.gho, dst=1，把它保存成bat文件，并起个名字如myfdisk.bat。这样以后哪个硬盘要分区格式化，用这张启动盘启动电脑，然后执行myfdisk.bat，用不了一分钟，不论多大的硬盘都可以顺利完成分区和格式化了。如果你想改变分区比例，只要修改myfdisk.bat文件就可以了，如分了4个区并想把比例变为1∶3∶3∶3，只需修改myfdisk.bat内容为：“ghost.exe-clone,mode=load,src=a:myfdisk.gho, dst=1,size1=10P,size2=30P,sze3=30P,sze4 =30P”即可。如果你还有更多的要求，还可在DOS状态下键入“ghost.exe -h”来查看命令帮助。当然，你也完全可以键入“ghost.exe”进入Ghsot的主界面来对镜像文件进行恢复操作，不过这样你就要多敲几次键了。 我个人认为这种分区格式化的方法十分实用，特别适用于那些经常要分区格式化大容量硬盘的朋友，如装机商、电脑维修者、电脑发烧友等，因此写下此文，希望能对包括他们在内的所有电脑爱好者有所帮助。
江苏省徐州技师学院理论授课教案（首页） 授课日期2016.11.7 2016.11.8 任课老师班级16程序2,16信管2 16程序1,16媒体赵启辉 课程：计算机组装与维护 课题：硬盘分区与格式化 教学目的要求：1、使学生了解硬盘使用过程；2、使学生掌握硬盘分区的步骤；3、使学生掌握分区工具的使用方法；4、提高学生的动手能力及实际操作能力 教学重点：掌握多种硬盘配置的方法。 教学难点：掌握在不同的条件下对硬盘分区格式化的方法。 授课方法：讲授法、列举法、引入法、分析法等 教学参考及教具（含多媒体教学设备）投影、多媒体计算机 授课执行情况及分析： 板书设计或授课提纲 1、硬盘使用过程 2、硬盘分区的步骤 3、分区工具的使用方法
教学环节及时间分配教学内容教学方 法 组织教学10’ 讲授主课40’一、课前提问 1. 描述计算机主机的基本部件。 2. 组装计算机主机的步骤。 二、导入新课 在安装操作系统之前首先要对硬盘进行分区格式化。 对硬盘分区格式化会破坏硬盘中的数据。所以在此之前一 定要对硬盘中的数据进行备份。 提问学生：你们是否有过对硬盘进行分区格式化操作 的经验？ 你喜欢用什么方法对硬盘进行分区格式 化？ 引导学生思考、回答并相互补充。 教师总结归纳同学们的回答，进入教学课题。 三、新课教学 硬盘的分区与格式化 1 基本知识：硬盘的数据结构 1.1 硬盘的分区与格式化 提问：硬盘的格式化有低级格式化和高级格式化两 种，它们之间有什么区别？ 学生思考、看书、回答； 教师总结： 现在制造的硬盘在出厂时均做过低级格式化，用户一般不必重做。除非 所用硬盘坏道较多或染上无法清除的病毒，不得不做一次低级格式化。 低级格式化的主要目的是划分磁柱面（磁道），建立扇区数和选择扇区 的间隔比，即为每个扇区标注地址和扇区头标志，并以硬盘能识别的方式进 行数据编码。 讲授 多媒 体教 学
第三讲DOS环境下磁盘管理 本讲的目的；目标： 磁盘管理命令 DOS命令对磁盘的管理 编辑命令EDIT的使用 重新定向命令 理解msdos.sys配置文件 教学的重点和难点： 磁盘管理命令 重新定向命令技巧 Edit命令的使用 知识点回顾/习问题： 文件管理命令回顾 功能相似文件管理命令的区别 比较文件管理和磁盘管理命令，区别不同 一、磁盘格式化format 1．功能：对磁盘进行格式化，划分磁道和扇区；同时检查出整个磁盘上有无带缺陷的磁道，对坏道加注标记；建立目录区和文件分配表，使磁盘作好接收DOS的准备。 2．类型：外部命令 3．格式：formAT〈盘符：〉[/S][/4][/Q] 4．使用说明： （1）命令后的盘符不可缺省，若对硬盘进行格式化，则会如下列提示：WARNING:ALL DATA ON NON ——REMOVABLE DISK DRIVE C:WILL BE LOST ！ Proceed with format (Y/N)？ （警告：所有数据在C盘上，将会丢失，确实要继续格式化吗？） （2）若是对软盘进行格式化，则会如下提示：Insert mew diskette for drive A; and press ENTER when ready… （在A驱中插入新盘，准备好后按回车键）。 （3）选用[/S]参数，将把DOS系统文件IO.SYS 、MSDOS.SYS及https://www.doczj.com/doc/b71794230.html,复制到磁盘上，使该磁盘可以做为DOS启动盘。若不选用/S参数，则格式化后的磙盘只能读写信息，而不能做为启动盘； （4）选用[/4]参数，在1.2MB的高密度软驱中格式化360KB的低密度盘； （5）选用[/Q]参数，快速格式化，这个参数并不会重新划分磁盘的磁道貌岸然和扇区，只能将磁盘根目录、文件分配表以及引导扇区清成空白，因此，格式化的速度较快。 （6）选用[/u]参数，表示无条件格式化，即破坏原来磁盘上所有数据。不加/U，则为安全格式化，这时先建立一个镜象文件保存原来的FAT表和根目录，必要时可用UNFORRMAT恢复原来的数据。 二、恢复格式化命令Unformat 1．功能：对进行过格式化误操作丢失数据的磁盘进行恢复。 2．类型：外部命令
用Gdisk快速搞定大容量硬盘分区格式化 发表：2004-6-5 6:05:21 出处：你的博客网(https://www.doczj.com/doc/b71794230.html,) ▲▲用Gdisk快速搞定大容量硬盘分区格式化▲▲ 假设是一块80GB的新硬盘，主分区为5GB，扩展分区依次划为4个逻辑盘：10GB、10GB、20GB、35GB。我们可以做成这样一个批处理文件： gdisk 1 /cre /pri /sz:5000 /for /q gdisk 1 /cre /ext gdisk 1 /cre /log /sz:10000/for /q gdisk 1 /cre /log /sz:10000 /for /q gdisk 1 /cre /log /sz:20000/for /q gdisk 1 /cre /log /for /q 这样一张快速分区格式化磁盘的工具盘就做好了。将新硬盘挂到电脑上(注意哟，一定要挂在主板第一个IDE接口上，因为我们指定的硬盘号为1，否则就需要修改批处理文件)，设置好从A盘启动。插入刚刚做好的工具盘，启动，执行批处理文件FD.bat。瞧瞧吧，再也不需要漫长的格式化等待了，不要你烦心，海量硬盘分区、格式化立马搞定。 硬盘容量不同，我们只需修改批处理文件中分区的个数和每个分区容量大小就可以同样轻松搞定。 如果是手头已有的硬盘想重新安排分区、格式化，只需先执行一下下列命令： gdisk /del /all (删除所有硬盘分区)。 再执行分区格式化批处理命令，同样不需要花多少时间即可重新搞定。不过在动手之前一定要把硬盘上重要的数据备份出来，不然，两三分钟后可就欲哭无泪了。 参数说明： 1——指的是第一块硬盘。如果挂有多块硬盘，就要相应的指明其硬盘号1、2…… /cre——当前工作模式为创建分区 /pri——创建主分区 /sz:5000——创建分区大小为5000MB即5GB。 /for——格式化磁盘 /q——快速格式化磁盘(这是Gdisk.exe的一大优势所在，新分区的硬盘一样可以快速格式化，这可是Windows 9x系列自带的format命令所望尘莫及的哟)。 /ext——创建扩展分区 /log——创建逻辑分区 自定义分区大小，请键入gdisk [参数]5GB---5000 gdisk 1 /cre /pri /sz:%1 /for /q gdisk 1 /cre /ext gdisk 1 /cre /log /sz:%2 /for /q gdisk 1 /cre /log /sz:%3 /for /q gdisk 1 /cre /log /sz:%4 /for /q gdisk 1 /cre /log /sz:%5 /for /q gdisk 1 /cre /log /sz:%6 /for /q gdisk 1 /cre /log /sz:%7 /for /q gdisk 1 /cre /log /sz:%8 /for /q
【入党申请书格式】 如何在 BIOS 下格式化硬盘或分区?下面是收集整理关于在 BIOS 下格式化硬盘或分区的资料以供大家参考学习，希望大家喜欢。 在 BIOS 下格式化硬盘或分区的方法 一、GDISK实例 如果我告诉你80GB的硬盘分区加格式化一共只需3分钟，你或许会瞪大眼睛看着我可能吗?现在我要告诉你这是完全可以实现的，而且操作非常简单。 首先下载gdisk.exe，这个软件只有270KB，可以独立使用。不要小看它哟，我们快速分区、格式化硬盘全靠它了。找张软盘，制作成启动盘，将gdisk.exe拷到盘上，再建一个批处理文件FD.bat。假设是一块80GB的新硬盘，主分区为5GB，扩展分区依次划为4个逻辑盘10GB、10GB、20GB、35GB。我们可以做成这样一个批处理文件 gdisk 1 /cre /pri /sz:5000 /for /q gdisk 1 /cre /ext gdisk 1 /cre /log /sz:10000/for /q gdisk 1 /cre /log /sz:10000 /for /q gdisk 1 /cre /log /sz:20000/for /q gdisk 1 /cre /log /for /q 这样一张快速分区格式化磁盘的工具盘就做好了。将新硬盘挂到电脑上(注意哟，一定要挂在主板第一个IDE接口上，因为我们指定的硬盘号为1，否则就需要修改批处理文件)，设置好从A盘启动。插入刚刚做好的工具盘，启动，执行批处理文件FD.bat。瞧瞧吧，再也不需要漫长的格式化等待了，不要你烦心，海量硬盘分区、格式化立马搞定。 硬盘容量不同，我们只需修改批处理文件中分区的个数和每个分区容量大小就可以同样轻松搞定。 如果是手头已有的硬盘想重新安排分区、格式化，只需先执行一下下列命令 gdisk /del /all (删除所有硬盘分区)。 再执行分区格式化批处理命令，同样不需要花多少时间即可重新搞定。不过在动手之前一定要把硬盘上重要的数据备份出来，不然，两三分钟后可就欲哭无泪了。
手把手教你硬盘分区格式化 你从商场买来的硬盘并不能直接使用，必须对它进行分区并进行格式化的才能储存数据。如果把新买来的硬盘比喻成白纸，你要把它变成写文章的稿纸的话，分区就好像给它规定可以写字的范围，格式化就好像给它画出写每一个字的格子。 在建立磁盘区以前，你必须对“物理磁盘(Phys-ical Disk)”和“逻辑磁盘(Logical Disk)”有点概念才行。物理磁盘就是你购买的磁盘实体，逻辑磁盘则是经过分割所建立的磁盘区。如果你在一个物理磁盘上建立了3个磁盘区，每一个磁盘区就是一个逻辑磁盘，你的物理硬盘上就存在了3个逻辑磁盘。 在建立分区以前，最好先规划你要如何配置，也就是要先解决以下问题: 1.这个硬盘要分割成几个区？ 2.每个分区占有大多的容量？ 3.每个分区都使用什么文件系统？ 要分割成几个分区以及第一个分区所占有的容量，取决于使用者自己的想法，有些人喜欢将整个硬盘规划单一分区，有些人则认为分割成几个分区比较利于管理。例如，分割成两个分区，一个储存操作系统文件，另一个储存应用程序文件;或者一个储存操作系统和应用程序档案，另一个储存个人和备份的资料。至于分区所使用的文件系统，则取决于你要安装的操作系统，操作系统分区所能使用的文件系统如表一所示。 如果你要安装的是Windows 98，可以选择的文件系统则有FAT16和 FAT32，使用FAT16的分区大小不能超过2GB，而且会浪费较多的硬盘空间。如果你打算执行一些DOS工具程序，可以考虑将操作系统分区规划成FAT16文件系统，如果没有特别的打算，还是建议使用FAT32文件系统。 整块硬盘规划成单一分区的做法 1、使用Windows 98的启动盘开机，选择开机选单的第一个选项。 2、在DOS命令行输入“fdisk”，按下Enter键执行。 3、屏幕上出现信息问你是否要启用FAT32支持，回答“Y”会建立FAT32分区，回答“N”则会使用FAT16,决定以后按Enter键。
批处理文件，在中，文件是可执行文件，有一系列命令构成，其中可以包含对其他程序地调用. 首先，批处理文件是一个文本文件，这个文件地每一行都是一条命令（大部分时候就好像我们在提示符下执行地命令行一样），你可以使用下地或者地记事本()等任何文本文件编辑工具创建和修改批处理文件.个人收集整理勿做商业用途 其次，批处理文件是一种简单地程序，可以通过条件语句()和流程控制语句()来控制命令运行地流程，在批处理中也可以使用循环语句()来循环执行一条命令.当然，批处理文件地编程能力与语言等编程语句比起来是十分有限地，也是十分不规范地.批处理地程序语句就是一条条地命令（包括内部命令和外部命令），而批处理地能力主要取决于你所使用地命令.个人收集整理勿做商业用途 第三，每个编写好地批处理文件都相当于一个地外部命令，你可以把它所在地目录放到你地搜索路径()中来使得它可以在任意位置运行.一个良好地习惯是在硬盘上建立一个或者目录（例如:\），然后将所有你编写地批处理文件放到该目录中，这样只要在中设置上:\，你就可以在任意位置运行所有你编写地批处理程序.个人收集整理勿做商业用途 第四，在和系统下，:盘根目录下地批处理文件是自动运行批处理文件，每次系统启动时会自动运行该文件，你可以将系统每次启动时都要运行地命令放入该文件中，例如设置搜索路径，调入鼠标驱动和磁盘缓存，设置系统环境变量等.下面是一个运行于下地地示例：个人收集整理勿做商业用途 :\:\\:\:\:\:\:\个人收集整理勿做商业用途 :\ :\ 批处理地作用 简单地说，批处理地作用就是自动地连续执行多条命令. 这里先讲一个最简单地应用：在启动软件时，每次都必须执行（>前面内容表示提示符）： :\> :\> :\>
如何写批处理文件 扩展名是bat(在nt/2000/xp/2003下也可以是cmd)的文件就是批处理文件。首先批处理文件是一个文本文件，这个文件的每一行都是一条DOS命令（大部分时候就好象我们在DOS提示符下执行的命令行一样），你可以使用DOS下的Edit或者Windows的记事本(notepad)等任何文本文件编辑工具创建和修改批处理文件。其次，批处理文件是一种简单的程序，可以通过条件语句(if)和流程控制语句(goto)来控制命令运行的流程，在批处理中也可以使用循环语句(for)来循环执行一条命令。当然，批处理文件的编程能力与C语言等编程语句比起来是十分有限的，也是十分不规范的。批处理的程序语句就是一条条的DOS命令（包括内部命令和外部命令），而批处理的能力主要取决于你所使用的命令。第三，每个编写好的批处理文件都相当于一个DOS 的外部命令，你可以把它所在的目录放到你的DOS搜索路径(path)中来使得它可以在任意位置运行。一个良好的习惯是在硬盘上建立一个bat或者batch目录（例如C:\ BA TCH），然后将所有你编写的批处理文件放到该目录中，这样只要在path中设置上c:\batch，你就可以在任意位置运行所有你编写的批处理程序。 第四，在DOS和Win9x/Me系统下，C:盘根目录下的AUTOEXEC.BA T 批处理文件是自动运行批处理文件，每次系统启动时会自动运行该文件，你可以将系统每次启动时都要运行的命令放入该文件中，例如设置搜索路径，调入鼠标驱动和磁盘缓存，设置系统环境变量等。下面是一个运行于Windows 98下的autoexec.bat的示例： @ECHO OFF PA TH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UCDOS;C:\DOSTools; C:\SYSTOOLS;C:\WINTOOLS;C:\BA TCH LH SMARTDRV.EXE /X LH https://www.doczj.com/doc/b71794230.html, /INSERT LH CTMOUSE.EXE SET TEMP=D:\TEMP SET TMP=D:\TEMP 批处理的作用 简单的说，批处理的作用就是自动的连续执行多条命令。 这里先讲一个最简单的应用：在启动wps软件时，每次都必须执行（>前面内容表示DOS提示符）： C:\>cd wps C:\WPS>spdos
DOS命令大全(最全版)
正文： DOS命令大全 一）MD——建立子目录 1．功能：创建新的子目录 2．类型：内部命令 3．格式：MD[盘符：][路径名]〈子目录名〉4．使用说明： （1）“盘符”：指定要建立子目录的磁盘驱动器字母，若省略，则为当前驱动器； （2）“路径名”：要建立的子目录的上级目录名，若缺省则建在当前目录下。 例：（1）在C盘的根目录下创建名为FOX的子目录；（2）在FOX子目录下再创建USER子目录。C：、＞MD FOX （在当前驱动器C盘下创建子目录FOX） C：、＞MD FOX \USER （在FOX 子目录下再创建USER子目录） （二）CD——改变当前目录 1．功能：显示当前目录 2．类型：内部命令 3．格式：CD[盘符：][路径名][子目录名] 4．使用说明：
除，操作如下： 第一步：先将USER子目录下的文件删空； C、＞DEL C：\FOX\USER\*.* 第二步，删除USER子目录。 C、＞RD Ｃ：\FOX\USER （四）DIR——显示磁盘目录命令 1．功能：显示磁盘目录的内容。 2．类型：内部命令 3．格式：DIR [盘符][路径][/P][/W] 4． 使用说明：/P的使用；当欲查看的目录太多，无法在一屏显示完屏幕会一直往上卷，不容易看清，加上/P参数后，屏幕上会分面一次显示23行的文件信息，然后暂停，并提示；Press any key to continue /W的使用：加上/W只显示文件名，至于文件大小及建立的日期和时间则都省略。加上参数后，每行可以显示五个文件名。 PATH——路径设置命令 1．功能：设备可执行文件的搜索路径，只对文件有效。 2．类型：内部命令
] 80GB的硬盘分区加格式化一共只需3分钟！ 80GB的硬盘分区加格式化一共只需3分钟！ 找张软盘，制作成启动盘，将gdisk.exe拷到盘上，再建一个批处理文件FD.bat。 假设是一块80GB的新硬盘，主分区为5GB，扩展分区依次划为4个逻辑盘：10GB、 10GB、20GB、35GB。我们可以做成这样一个批处理文件： gdisk 1 /cre /pri /sz:5000 /for /q gdisk 1 /cre /ext gdisk 1 /cre /log /sz:10000/for /q gdisk 1 /cre /log /sz:10000 /for /q gdisk 1 /cre /log /sz:20000/for /q gdisk 1 /cre /log /for /q 这样一张快速分区格式化磁盘的工具盘就做好了。将新硬盘挂到电脑上(注意哟，一定要挂在主板第一个IDE接口上，因为我们指定的硬盘号为1，否则就需要修改批处理文件)，设置好从A盘启动。插入刚刚做好的工具盘，启动，执行批处理文件FD.bat。瞧瞧吧，再也不需要漫长的格式化等待了，不要你烦心，海量硬盘分区、格式化立马搞定。 硬盘容量不同，我们只需修改批处理文件中分区的个数和每个分区容量大小就可以同样轻松搞定。 如果是手头已有的硬盘想重新安排分区、格式化，只需先执行一下下列命令： gdisk /del /all (删除所有硬盘分区)。 再执行分区格式化批处理命令，同样不需要花多少时间即可重新搞定。不过在动手之前一定要把硬盘上重要的数据备份出来，不然，两三分钟后可就欲哭无泪了。 参数说明： 1——指的是第一块硬盘。如果挂有多块硬盘，就要相应的指明其硬盘号1、2…… /cre——当前工作模式为创建分区 /pri——创建主分区 /sz:5000——创建分区大小为5000MB即5GB。 /for——格式化磁盘 /q——快速格式化磁盘(这是Gdisk.exe的一大优势所在，新分区的硬盘一样可以快速格式化，这可是Windows 9x系列自带的format命令所望尘莫及的哟)。 /ext——创建扩展分区 /log——创建逻辑分区 附件为gdisk下载，其中有参数的英文说明！
cmd和批处理命令大全.txt心态决定状态，心胸决定格局，眼界决定境界。当你的眼泪忍不住要流出来的时候，睁大眼睛，千万别眨眼，你会看到世界由清晰到模糊的全过程。cmd和批处理命令大全 1.Echo 命令 打开回显或关闭请求回显功能，或显示消息。如果没有任何参数，echo 命令将显示当前回显设置。 语法 echo [{on|off}] [message] Sample：echo off / echo hello world 在实际应用中我们会把这条命令和重定向符号（也称为管道符号，一般用> >> ^）结合来实现输入一些命令到特定格式的文件中.这将在以后的例子中体现出来。 2.@ 命令 表示不显示@后面的命令，在入侵过程中（例如使用批处理来格式化敌人的硬盘）自然不能让对方看到你使用的命令啦。 Sample：@echo off @echo Now initializing the program,please wait a minite... @format X: /q/u/autoset (format 这个命令是不可以使用/y这个参数的，可喜的是微软留了个autoset这个参数给我们，效果和/y是一样的。) 3.Goto 命令 指定跳转到标签，找到标签后，程序将处理从下一行开始的命令。 语法：goto label （label是参数，指定所要转向的批处理程序中的行。） Sample： if {%1}=={} goto noparms if {%2}=={} goto noparms（如果这里的if、%1、%2你不明白的话，先跳过去，后面会有详细的解释。） @Rem check parameters if null show usage :noparms echo Usage: monitor.bat ServerIP PortNumber goto end 标签的名字可以随便起，但是最好是有意义的字母啦，字母前加个：用来表示这个字母是标签，goto命令就是根据这个：来寻找下一步跳到到那里。最好有一些说明这样你别人看起来才会理解你的意图啊。 4.Rem 命令 注释命令，在C语言中相当与/*--------*/,它并不会被执行，只是起一个注释的作用，便于别人阅读和你自己日后修改。 Rem Message Sample：@Rem Here is the description. 5.Pause 命令 运行 Pause 命令时，将显示下面的消息： Press any key to continue . . .
1,FAT32转化成NTFS格式的方法： 开始--运行，输入Convert X:/fs:ntfs--回车。（转化 对文件、系统都没有影响。）X盘的fat32格式就转化成了NTFS格式。X代表要转化格式的盘符（如：C、D、E、F等） 2，但是，NTFS格式不能转化成FAT32格式。要使某盘（例如D盘）的NTFS格式变成F AT32格式，必须重新将D盘格式化。方法是：重启电脑按del进入bios设置光盘启动按f10退出。然后放入winXP安装光盘。重启电脑，当进程到格式化分区D时选择FAT32 格式把D格掉。原NTFS格式就去掉了，取而代之的就是FAT32格式了。（这里要提醒你的是在d盘重新格式化之前必须将d盘中的资料备份好。）。不过一般不会这样做，就保留NTFS格式。既然你要改成FAT32格式，那只有用这个办法。当然使用分区软件也可以。它不能采用1中所叙述的办法转化 Windows XP控制台图解教程 基础知识： xp的分区格式化功能要远远强于98的Fdisk，不但是图形界面，而且功能强大。 它的分区命令是Diskpart，是Fdisk的改进版；用Diskpart分区，你根本就不用知道什么主DOS分区、什么扩展分区、什么逻辑分区。而且不用重启，可以一气呵成。 它的格式化命令仍是Format，但已经不是98那样简单的Format命令了，它可以通过加参数直接格式化硬盘为fat/fat32/ntfs格式，灵活很多。 进入正题 一、对新硬盘分区 1.在BIOS中设置CD-ROM为第一启动，插入XP安装光盘，开始……一直到出现这个界面（等一会儿吧，会出现的）
2.按下“R”键，回车！如果是裸体盘，会出现以下界面：此主题相关图片如下： 3.按下“C”，回车！出现这个界面：
格式化格式化指定卷中的磁盘以接受 Windows 文件。 语法 format volume [/fs:file-system] [/v:label] [/q] [/a:UnitSize] [/c] [/x] format volume [/v:label] [/q] [/f:size] format volume [/v:label] [/q] [/t:tracks /n:sectors] format volume [/v:label] [/q] format volume [/q] 参数 volume 指定要格式化的驱动器的装入点、卷名或驱动器号。如果不指定以下的任何命令行选项，format 将使用卷类型来决定磁盘的默认格式。 /fs:file-system 指定要使用的文件系统：FAT、FAT32 或 NTFS。软盘只能使用 FAT 文件系统。 /v:label 指定卷标。如果省略 /v 命令行选项或使用它而不指定卷标，format 将在格式化完成后提示输入卷标。使用语法 /v:来防止提示输入卷标。如果利用一个 format 命令格式化多个磁盘，则对所有磁盘指定相同的卷标。有关磁盘卷标的详细信息，请单击“相关主题”列表中的 Dir、Label 和 Vol。 /a:UnitSize 指定要在 FAT、FAT32 或 NTFS 卷上使用的分配单位大小。如果没有指定 UnitSize，将根据卷的大小进行选择。下表列出了 UnitSize 的有效值。值说明 512 每个簇 512 字节。 1024 每个簇 1024 字节。 2048 每个簇 2048 字节。 4096 每个簇 4096 字节。 8192 每个簇 8192 字节。 16K 每个簇 16K 字节。 32K 每个簇 32K 字节。 64K 每个簇 64K 字节。 /q 执行快速格式化。删除以前已格式化卷的文件表和根目录，但不在扇区之间扫描损坏区域。使用 /q 命令行选项应该仅格式化以前已格式化的完好的卷。 /f:size 指定要格式化的软盘大小。可能的话，使用此命令行选项取代 /t 和 /n 命令行选项。Windows 接受如下大小的值： 1440 或 1440k 或 1440kb 或 1.44 或 1.44m 或 1.44mb
扩展名是bat(在nt/2000/xp/2003下也可以是cmd)的文件就是批处理文件。 首先批处理文件是一个文本文件，这个文件的每一行都是一条DOS命令（大部分时候就好象我们在DOS提示符下执行的命令行一样），你可以使用DOS下的Edit或者Windows的记事本(notepad)等任何文本文件编辑工具创建和修改批处理文件。 其次，批处理文件是一种简单的程序，可以通过条件语句(if)和流程控制语句(goto)来控制命令运行的流程，在批处理中也可以使用循环语句(for)来循环执行一条命令。当然，批处理文件的编程能力与C语言等编程语句比起来是十分有限的，也是十分不规范的。批处理的程序语句就是一条条的DOS命令（包括内部命令和外部命令），而批处理的能力主要取决于你所使用的命令。 第三，每个编写好的批处理文件都相当于一个DOS的外部命令，你可以把它所在的目录放到你的DOS搜索路径(path)中来使得它可以在任意位置运行。一个良好的习惯是在硬盘上建立一个bat或者batch目录（例如C:\BATCH），然后将所有你编写的批处理文件放到该目录中，这样只要在path中设置上c:\batch，你就可以在任意位置运行所有你编写的批处理程序。 第四，在DOS和Win9x/Me系统下，C:盘根目录下的AUTOEXEC.BAT批处理文件是自动运行批处理文件，每次系统启动时会自动运行该文件，你可以将系统每次启动时都要运行的命令放入该文件中，例如设置搜索路径，调入鼠标驱动和磁盘缓存，设置系统环境变量等。下面是一个运行于Windows 98下的autoexec.bat的示例： @ECHO OFF PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\UCDOS;C:\DOSTools;C:\SYSTOOLS;C:\WINT OOLS;C:\BATCH LH SMARTDRV.EXE /X LH https://www.doczj.com/doc/b71794230.html, /INSERT LH CTMOUSE.EXE SET TEMP=D:\TEMP SET TMP=D:\TEMP 批处理的作用 简单的说，批处理的作用就是自动的连续执行多条命令。 这里先讲一个最简单的应用：在启动wps软件时，每次都必须执行（>前面内容表示DOS 提示符）：
DOS和Windows最大的不同在于DOS命令方式操作，所以使用者需要记住大量命令及其格式使用方法，DOS命令分为内部命令和外部命令，内部命令是随每次启动的https://www.doczj.com/doc/b71794230.html,装入并常驻内存，而外部命令是一条单独的可执行文件。在操作时要记住的是，内部命令在任何时候都可以使用，而外部命令需要保证命令文件在当前的目录中，或在Autoexec.bat文件已经被加载了路径。 常用的内部命令 DOS的内部命令是DOS操作的基础，下面就来介绍一些常用的DOS内部命令。 1、DIR 含义：显示指定路径上所有文件或目录的信息 格式：DIR [盘符：][路径][文件名] [参数] 参数： /W：宽屏显示，一排显示5个文件名，而不会显示修改时间，文件大小等信息； /P：分页显示，当屏幕无法将信息完全显示时，可使用其进行分页显示； /A：显示具有特殊属性的文件； /S：显示当前目录及其子目录下所有的文件。 举例：DIR /P 将分屏显示当前目录下文件。在当前屏最后有一个“Press any key to continue . . .”提示，表示按任意键继续。 2、CD 含义：进入指定目录 格式：CD [路径] 举例：CD DOS CD命令只能进入当前盘符中的目录，其中“CD\”为返回到根目录，“CD..”为返回到上一层目录。 3、MD 含义：建立目录 格式：MD [盘符][路径] 举例：MD TEMP 表示在当前盘符下建立一个名为TEMP的目录。 4、RD 含义：删除目录 格式：RD [盘符][路径] 举例：RD TEMP 表示删除当前路径下的TEMP目录，需要注意的是，此命令只能删除空目录。 5、COPY 含义：拷贝文件
批处理文件BAT命令大全 一.简单批处理内部命令简介 命令 打开回显或关闭请求回显功能，或显示消息。如果没有任何参数，echo 命令将显示当前回显设置。 语法 echo [{on│off}] [message] Sample：@echo off / echo hello world 在实际应用中我们会把这条命令和重定向符号（也称为管道符号，一般用> >> ^）结合来实现输入一些命令到特定格式的文件中.这将在以后的例子中体现出来。 2.@ 命令 表示不显示@ 后面的命令，在入侵过程中（例如使用批处理来格式化敌人的硬盘）自然不能让对方看到你使用的命令啦。 Sample：@echo off @echo Now initializing the program,please wait a minite... @format X: /q/u/autoset (format 这个命令是不可以使用/y这个参数的，可喜的是微软留了个autoset这个参数给我们，效果和/y 是一样的。) 命令
指定跳转到标签，找到标签后，程序将处理从下一行开始的命令。 语法：goto label （label是参数，指定所要转向的批处理程序中 的行。） Sample： if {%1}=={} goto noparms if {%2}=={} goto noparms（如果这里的if、%1、%2就是表示变量。）@Rem check parameters if null show usage :noparms echo Usage: ServerIP PortNumber goto end 标签的名字可以随便起，但是最好是有意义的字母啦，字母前加个： 用来表示这个字母是标签， : 开头的字符行 , 在批处理中都被视作标号 , 而直接忽略其后的所有内容 , 只是为了与正常的标号相区 别 , 建议使用 goto 所无法识别的标号 , 即在 : 后紧跟一个非字母数字的一个特殊符号 . goto 命令就是根据这个：来寻找下一步跳 到到那里。最好有一些说明这样你别人看起来才会理解你的意图啊。 命令 注释命令，起一个注释的作用，便于别人阅读和你自己日后修改。 Rem Message Sample：@Rem Here is the description.