ONVIF码流格式

ONVIF? Streaming Specification

Version 2.1

June, 2011

2008-2011 by ONVIF: Open Network Video Interface Forum Inc.. All rights reserved.

Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document.

THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION.

CONTENTS

1Scope 4 2Normative references 4 3Terms and Definitions 4

3.1Definitions (5)

3.2Abbreviations (5)

4Overview 6 5Live Streaming 7

5.1Media stream protocol (7)

5.1.1Transport format (7)

5.1.2Media Transport (8)

5.1.3Synchronization Point (13)

5.1.4JPEG over RTP (13)

5.2Media control protocol (16)

5.2.1Stream control (16)

5.3Back Channel Connection (20)

5.3.1RTSP Require- Tag (20)

5.3.2Connection setup for a bi- directional connection (21)

5.3.3Multicast streaming (23)

5.4Error Handling (23)

6Playback 25

6.1.1RTSP describe (25)

6.2RTP header extension (25)

6.2.1NTP Timestamps (26)

6.2.2Compatibility with the JPEG header extension (26)

6.3RTSP Feature Tag (27)

6.4Initiating Playback (27)

6.4.1Range header field (28)

6.4.2Rate-Control header field (28)

6.4.3Frames header field (28)

6.4.4Synchronization points (29)

6.5Reverse replay (29)

6.5.1Packet transmission order (30)

6.5.2RTP sequence numbers (30)

6.5.3RTP timestamps (30)

6.6RTSP Keepalive (30)

6.7Currently recording footage (31)

6.8End of footage (31)

6.9Go To Time (31)

6.10Use of RTCP (31)

1 Scope

This document defines the ONVIF specific streaming extensions for live and replay streaming. The corresponding web service APIs to retrieve the streaming URIs are defined in separate documents and are not covered in this document.

2 Normative references

ISO/IEC 14496-2:2004, Information technology -- Coding of audio-visual objects -- Part 2: Visual

ISO/IEC 14496-3:2005, Information technology -- Coding of audio-visual objects -- Part 3: Audio

ISO/IEC 14496-10:2008, Information technology -- Coding of audio-visual objects -- Part 10: Advanced Video Coding

ITU-T G.711, Pulse code modulation (PCM) of voice frequencies

< http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.711-198811-I!!PDF-E&type=items>

ITU-T G.726, 40, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)

RSA Laboratories, PKCS #10 v1.7: Certification Request Syntax Standard, RSA Laboratories

IETF RFC 2246, The TLS Protocol Version 1.0

IETF RFC 2326, Real Time Streaming Protocol (RTSP)

IETF RFC 2435, RFC2435 - RTP Payload Format for JPEG-compressed Video

IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications

IETF RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control

IETF RFC 3984, RTP Payload Format for H.264 Video

IETF RFC 4566, SDP: Session Description Protocol

IETF RFC 4571, Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport

IETF RFC 4585, Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)

IETF 5104, Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)

ONVIF Core Specification

ONVIF Media Service Specification

3 Terms and Definitions

3.1 Definitions

Metadata All streaming data except video and audio, including video analytics results, PTZ

position data and other metadata (such as textual data from POS applications). Recording Represents the currently stored media (if any) and metadata on the NVS from a single

data source. A recording comprises one or more tracks. A recording can have more

than one track of the same type e.g. two different video tracks recorded in parallel with

different settings

Track An individual data channel consisting of video, audio, or metadata. This definition is

consistent with the definition of track in [RFC 2326]

3.2 Abbreviations

AAC Advanced Audio Coding

EOI End Of Image

JFIF JPEG File Interchange Format

JPEG Joint Photographic Expert Group

MPEG-4Moving Picture Experts Group - 4

PTZ Pan/Tilt/Zoom

RTCP RTP Control Protocol

RTP Realtime Transport Protocol

RTSP Real Time Streaming Protocol

SDP Session Description Protocol

SOI Start Of Image

SOF Start Of Frame

SOS Start Of Scan

TCP Transmission Control Protocol

UDP User Datagram Protocol

Time

UTC Coordinated

Universal

UTF Unicode Transformation Format

4 Overview

Figure 1: Layer structure

This standard defines media streaming options and formats. A distinction is made between media plane and control plane, as illustrated in Figure 1. A set of media streaming (audio, video and meta data) options, all based on RTP [RFC 3550], are described in order to provide interoperable media streaming services.

The metadata streaming container format allows well-defined, real-time streaming of analytics, PTZ status and notification data.

Media configuration is done over SOAP/HTTP and is covered by the media configuration service as discussed in Section 4.6.

Media control is accomplished over RTSP as defined in RFC 2326. This standard utilizes RTP, RTCP and RTSP profiling, as well as JPEG over RTP extensions and multicast control mechanisms.

The standard introduces extensions to the RTSP standard to allow bi-directional streaming connections.

Streaming configurations for the following video codecs are provided:

JPEG (over RTP), see 5.1.4.

?MPEG-4, Simple Profile (SP) [ISO 14496-2]

? MPEG-4, Advanced Simple Profile (ASP) [ISO 14496-2]

?H.264, baseline [ISO 14496-10]

?H.264, main [ISO 14496-10]

?H.264, extended [ISO 14496-10]

?H.264, high [ISO 14496-10]

and for the following audio codecs:

?G.711 [ITU-T G.711]

?G.726 [ITU-T G.726]

? AAC [ISO 14496-3]

5 Live Streaming

This section describes real-time streaming of video, audio and metadata. There is no specific service associated with the real-time streaming. The real-time configurations via Web Service commands are defined in the Media Service and the ReceiverService.

5.1 Media stream protocol

5.1.1 Transport format

Real-time Transport Protocol (RTP) is a media transfer protocol (see Section 5.1.2). The following four sections describe RTP data transfer.

5.1.1.1 RTP data transfer via UDP

UDP has the smallest overhead and is able to transfer real-time data in an efficient manner. A device shall support the RTP/UDP protocol and the device should support RTP/UDP multicasting.

5.1.1.2 RTP/TCP

This optional mode has been deprecated due to ambiguities in the interpretation of the respective RFCs. RTP/TCP protocol is defined in [RFC 4571] and [RFC 4572].

5.1.1.3 RTP/RTSP/TCP

The device should support media transfer using RTP/RTSP to traverse a firewall using an RTSP tunnel. This protocol shall conform to [RFC 2326] Section 10.12.

5.1.1.4 RTP/RTSP/HTTP/TCP

The data stream shall be sent via HTTP to traverse a firewall. A device shall support media transfer using RTP/RTSP/HTTP/TCP. And if a device supports TLS1.0, the data stream shall

be sent or received via HTTPS to traverse a firewall, and a device shall support media transfer using RTP/RTSP/HTTPS/TCP.

This protocol shall conform to [RFC 2326] (RTSP Section 5.2.1.1: Embedded [Interleaved] Binary Data).

This tunnelling method shall also conform to QuickTime available from Apple Inc. The mandatory parts of the following document shall be implemented by an NVT.

https://www.sodocs.net/doc/d614230381.html,/quicktime/icefloe/dispatch028.html

5.1.2 Media Transport

5.1.2.1 RTP

The Real-time Transport Protocol provides real-time transfer for media streams between two

end points. The RTP protocol provides support for re-ordering, de-jittering and media synchronization.

All media streams transferred by the RTP protocol shall conform to [RFC 3550], [RFC 3551], [RFC 3984], [RFC 3016] and JPEG over RTP (see Section 5.1.3).

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 P X CC M PT sequence number

time stamp

synchronization source (SSRC) identifier

Figure 2: RTP header

An RTP header shall be filled up with following values.

Table 1: RTP header value

Header field Value Description

Version (V): 2 bits 2

Padding (P): 1 bit 0/1 If the payload includes

padding octet, this should be

set to “1”

Extension (X): 1 bit 0/1 Depends on the use of

extension of RTP header.

The specification defines two

scenarios where a RTP

header extension could be

used to transmit additional

information:

1) “JPEG over RTP” (see

Section 5.1.3).

2) Replay (see Section 6)

If the header extension is

used the Extension bit shall

be set.

CSRC count (CC):

4 bits

Marker (M): 1 bit 0/1 The usage shall be conform

to related RFCs (e.g. [RFC

3984] for H.264 Video) or to

this standard e.g “JPEG over

RTP” (see Section 5.1.3) or

RTP streaming of metadata

(see Section 5.1.2.1.1).

Payload type (PT):

7 bits

See [RFC 3551] Section 6.

Sequence Number: 16 bits The initial value of the “sequence number”should be random (unpredictable) to make known-plaintext attacks on encryption more difficult.

This number increments by

one for each RTP data packet sent

timestamp: 32 bits The initial value of the “timestamp” should be random (unpredictable) to make known-plaintext attacks on encryption more difficult.

See Section 5.1.2.2.1 for further details of Media Synchronization.

The usage of the timestamp

is dependent on the codec.

SSRC 32 bits The synchronization source for the data stream. This specification makes no restrictions on the use of this field.

5.1.2.1.1 RTP for Metadata stream

Metadata streams are also transported by RTP. The usage of payload type, marker and timestamp for RTP header for the metadata stream is defined in the following way:

? A dynamic payload type (96-127) shall be used for payload type which is assigned in the process of a RTSP session setup.

?The RTP marker bit shall be set to “1” when the XML document is closed.

?It is RECOMMENDED to use an RTP timestamp representing the creation time of the RTP packet with a RTP clock rate of 90000 Hz. Only UTC timestamps shall be used within the metadata stream. The synchronization of video and audio data streams is done using RTCP.

The Metadata payload is an XML document with root node tt:MetaDataStream. There is no limitation on the size of the XML document. When a synchronization point (see section “Synchronization Points” of the ONVIF Media Service Specification) is requested for the stream, the previous XML document shall be closed and a new one started. It is RECOMMENDED to start new XML documents after 1 second, at the longest. The RTP timestamp of the Metadata stream has no specific meaning. The Metadata stream multiplexes Metadata from different sources. This specification defines placeholders for the Scene Description of the Video Analytics, the PTZ Status of the PTZ controller and the Notifications of the Event Configuration. A device can select which of these parts should be multiplexed into the Metadata during the Media Configuration (see seciont “Metadata Configuration” of the ONVIF Media Service Specification). Each part can appear multiple times in arbitrary order within the document. A Metadata connection can be bi-directional using the backchannel mechanism (see Section 5.3).

Metadata stream contains the following elements:

? VideoAnalyticsStream

? PTZStream

? EventStream

The place-holders for the different metadata sources have the following XMLstructure:

...

...

...

The following is an example of a metadata XML document:

...

...

...

5.1.2.2 RTCP

The RTP Control Protocol provides feedback on quality of service being provided by RTP and synchronization of different media streams. The RTCP protocol shall conform to [RFC 3550]. For a feedback request, [RFC 4585] and [RFC 5104] should be supported.

server client

RTCP SR

RTCP RR

Figure 3: RTCP sequence

5.1.2.2.1 Media synchronization

A client MAY receive audio and video streams simultaneously from more than one device. In this case, each stream uses a different clock (from data acquisition to packet receiving). RTCP Sender Reports (SR) are used to synchronize different media streams. RTCP SRs shall conform to [RFC 3550].

The RTCP Sender Report (SR) packet has fields for the RTP timestamp and for a wall clock timestamp (absolute date and time, 64bit NTP [Network Time Protocol]). See Figure 4.

A device shall support RTCP Sender Report for media synchronization. The client should use RTCP for the media synchronization.

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 P RC PT=SR=200 length

SSRC of sender

NTP timestamp, most significant word

NTP timestamp, least significant word

RTP timestamp

sender's packet count

:

:

Figure 4: RTCP Sender Report

The wall clock should be common in the device and each timestamp value should be determined properly. The client can synchronize different media streams at the appropriate timing based on the RTP clock and wall clock timestamps (see Figure 5).

In case of multiple devices, the NTP timestamp should be common to all devices, and the NTP server should be required in the system 1.

receiver

Figure 5: Media Synchronization

1 The client can get information about “NTP server availability” from the devices by using the GetNTP command.

Refer to Section 8.2.5

5.1.3 Synchronization Point Synchronization points allow clients to decode and correctly use data after the synchronization point. A synchronization point MAY be requested by a client in case of decoder error (e.g. in consequence of packet loss) to enforce the device to add an I-Frame as soon as possible or to request the current ptz or event status.

The WebService based methods require to support the Synchronization Point request as defined in the section “Synchronization Point” of the ONVIF Media Service Specification.

In addition it is recommended to support the PLI messages as described in [RFC 4585] in order to allow receivers as defined in the ONVIF Receiver Service Specification to request a Synchronization Point.

5.1.4 JPEG over RTP

5.1.4.1 Overall packet structure

The syntax for transmitting JPEG streams follows [RFC 2435]. The syntax does allow embedding additional data, beyond the limits of [RFC 2435], by using an optional RTP header extension, as specified below, with some of the RTP packets. This option, however, changes the exact semantics for frames which include such packets.

The overall format of the JPEG RTP packet is shown in Figure 6.

Standard RTP header according to RFC 3550

extension payload:

sequence of additional JPEG marker segments

padded with 0xFF to the total extension length

RTP/JPEG header according to RFC 2435

entropy-encoded scan data section

0xFFD8 / 0xFFFF (see below ) e xtension length

(opt.header extension )0 1 2 7 3 4 5 9 8 6 01 2 73 4 5 986 012734598601

0 123

Figure 6: RTP/JPEG packet structure (only the typical content

is listed for the extension payload)

In order to distinguish an optional RTP header extension from possible other header extensions, the first 16 bits (the first two octets of the four-octet extension header) of an RTP

shall have the value 0xFFD8 (JPEG SOI marker) for the initial packet and 0xFFFF for other RTP packets within a frame.

As required by [RFC 3550], the presence of the optional header extension shall be signalled via the X-bit of the RTP header. The extension length field within the header extension counts the number of 32-bit items following as extension payloads. For example, a zero-length field following the 32-bit extension header represents an empty header extension).

The entropy-encoded scan data section MAY not be present in all RTP packets. A complete RTP/JPEG header however shall be present in the initial packet of every frame and all packets containing an entropy-encoded scan data section, otherwise it MAY be missing.

The fragment offset field within the RTP/JPEG header, according to [RFC 2435], should be used as if no header extension would be present. Additionally, if a packet does not contain an entropy-encoded scan data segment, but contains a header extension the fragment offset field shall not be zero if any packets containing an entropy-encoded scan data section for the same frame have been transmitted. If the initial packet of a frame contains no header extension, according to this standard, its fragment offset field shall be zero, otherwise it should be zero. All packets including an RTP/JPEG header with a fragment offset of zero and

a Q value between 128-255 shall include a quantization table header according to Section

3.1.8 of [RFC 2435], other packets shall NOT include this header.

5.1.4.2 Logical decoding specification

For the decoding specification, it is assumed that the original packet order within the RTP stream has been restored according to the RTP sequence numbering.

If the initial packet of a frame contains no RTP header extension as specified above, decoders shall generate the complete scan header and perform the decoding as specified by [RFC 2435]. The scan data sections and payloads of any header extension conforming to this specification, up to and including the next RTP packet with its marker bit set, shall be concatenated as they occur within the stream ignoring their fragment offset values.

Otherwise (at least an empty header extension as specified above is present in the initial packet of a frame), the following rules apply for each such frame:

?If the initial packet of a frame does not contain an entropy-encoded scan data segment, but contains a header extension as specified above, then decoders shall concatenate its header extension payload with (possibly empty or not existing) header extension payload(s) conforming to this specification of the subsequent packets up to and including the first packet with the RTP marker bit set or containing an entropy-encoded scan data segment.

?The concatenated initial RTP header extension payload (sequence) shall be logically prepended with a JPEG SOI marker (0xFFD8).

?If the Q-value of the RTP/JPEG scan header within the initial packet of a frame is not zero, the quantization tables shall be pre-initialized according to the rules of [RFC 2435]. If Q is equal to zero the quantization tables shall be copied from the previous frame, allowing for DQT markers within this initial header extension payload (sequence) to override them.

?If this frame is the initial frame of a sequence, the Huffman tables shall be pre-initialized according to [RFC 2435]. The Huffman tables for all subsequent frames shall be copied from the previous frame, allowing the frames to be overridden by DHT markers within the initial header extension payload (sequence).

?If the initial RTP header extension payload (sequence) supplies no DRI marker, but the RTP/JPEG header of the initial packet of a frame contains an RTP/JPEG restart marker, a DRI marker corresponding to the rules of [RFC 2435] shall be appended to the initial header extension payload (sequence). Otherwise, if the initial RTP header extension (sequence) supplies a DRI marker, the marker shall take precedence over any other RTP/JPEG restart marker according to [RFC 2435] for the same frame.

However, for compatibility with decoders conforming to [RFC 2435] only, encoders normally should use an RTP/JPEG restart marker with consistent values, if restart intervals are to be used.

?DRI markers shall NOT be derived from previous frames.

?If the initial RTP header extension payload (sequence) supplies no SOF marker, which otherwise takes precedence, a SOF marker shall be appended to it with the following values:

o If both the width and height field of the RTP/JPEG header are zero, the SOF marker of the previous frame shall be used.

o Otherwise it shall be derived according to the rules of [RFC 2435].

However, as long as the (rounded up) image size fits within the range as specified in [RFC 2435], encoders should specify the image size within the RTP/JPEG header consistent with the values of an additional SOF header.

?If the initial header extension payload (sequence) supplies no SOS marker, a corresponding marker shall be derived according to [RFC 2435] and appended to it, otherwise the SOS marker in the extension takes precedence.

An SOS marker shall NOT be derived from previous frames.

If the SOS marker is present and not followed by entropy-encoded scan data within the extension, the marker shall be the final marker within the initial extension payload (sequence) of a frame. Necessary padding with 0xFF-octets shall NOT follow this marker but MAY precede it.

?The remaining entropy-encoded scan data and header extensions payloads shall be logically appended in the same order as they occur within the RTP stream up to the end of the frame as indicated by the RTP marker bit. A final EOI marker shall also be added if it is not yet present within the logical sequence for this frame,.

For each frame, the resulting sequence up to and including the first (possibly added) EOI marker shall be a valid (possibly abbreviated) JPEG stream, resulting in one complete image from the decoding process for this frame. The meaning of any data after this first EOI marker for each frame is outside the scope of this specification.

5.1.4.3 Supported colour spaces and sampling factors

A Transmitter should use only greyscale and YCbCr colour space. A Client shall support both greyscale and YCbCr.

The sampling factors for YCbCr shall correspond to the values supported by [RFC 2435]. For example, a sampling factor of 4:2:0 (preferred) or 4:2:2.

5.1.4.4 Pixel aspect ratio handling

The pixel aspect ratio of JPEG files can be specified within the JFIF marker. If the pixel aspect ratio is different from the standard 1:1 and 1:2 ratio according to [RFC 2435], this marker should be transmitted in the initial header extension payload (sequence) of every frame to specify the (for interlaced material field-based) pixel aspect ratio.

5.1.4.5 Interlaced handling

Interlaced video is encoded as two independent fields and signalled as specified by [RFC 2435] within the RTP/JPEG header.

Both fields shall use the same colour space, sampling factors and pixel aspect ratio. Interlaced encoding should NOT be used if the frame was originally scanned progressively. 5.2 Media control protocol

5.2.1 Stream control

The media stream is controlled using the protocol defined in the URI. The URI is returned in response to the GetStreamUri command defined in the ONVIF Media Service Specification.

client

Figure 7: Stream Control

5.2.1.1 RTSP All devices and clients shall support RTSP ([RFC 2326]) for session initiation and playback control. RTSP shall use TCP as its transport protocol, the default TCP port for RTSP traffic is 554. The Session Description Protocol (SDP) shall be used to provide media stream information and SDP shall conform to [RFC 4566].

Table 2: RTSP methods. Method

Direction SPEC 2 Description OPTIONS R->T

T->R M X Required to get optional method capability and to allow different versions in the future.

DESCRIBE R->T M Required to retrieve media parameters within the designated profile.

ANNOUNCE R->T

T->R X

SETUP R->T M Required to set media session parameters.

PLAY R->T M Required to start media stream.

PAUSE R->T O Required to temporarily stop media stream.

Handling multiple streams in a narrow bandwidth network, by suspending RTP stream, the traffic can be

well controlled by reducing redundant data and

congested network traffic can be avoided.

TEARDOWN

R->T M Required to release a media session. GET_PARAMETER R->T

T->R O

SET_PARAMETER R->T T->R O

O An optional method to keep an RTSP session alive (R->T direction only).

REDIRECT T->R X

RECORD R->T X

Devices shall support aggregate stream control, in which PLAY commands are sent to the control URI for the whole session. Devices may support non aggregate stream control, in which PLAY commands are sent separately to the stream control URIs in the media sections of the SDP file. Support for non aggregate stream control is signalled via the Media Streaming Capabilities.

2 X: Not supported, M: Mandatory, O: Optional

5.2.1.1.1 Keep-alive method for RTSP session

A RTSP client keeps the RTSP Session alive and prevents it from session timeout (see [RFC 2326] Section 12.37). This specification recommends the following methods to keep RTSP alive for both Unicast and Multicast streaming.

1) The client can optionally set the Timeout parameter (in seconds) using the

SetEncoderConfiguration command defined in the

ONVIF Media Service Specification, otherwise a default value of ”60” is used.

2) In all RTSP SETUP responses, a transmitter should include the Timeout value according

to [RFC 2326] Section 12.37 and the transmitter should use the Timeout value for keep-

alive.

3) To keep the RTSP Session alive, a client shall call the RTSP server using any RTSP

method or send RTCP receiver reports. SET_PARAMETER is the RECOMMENDED RTSP

method to use.

RTSP

Stream setup

within the timeout period

server

client

Figure 8: Keep Alive

5.2.1.1.2 RTSP Audio and Video Synchronization In order that clients may immediately begin synchronizing video and audio streams, and

computing absolute UTC timestamps for incoming packets for recording purposes, a

transmitter should include the following header fields in the RTSP PLAY response:

? Range ([RFC 2326] section 12.29). This SHALL include a start time in clock units

([RFC 2326] section 3.7), not SMPTE or NPT units.

? RTP-Info ([RFC 2326] section 12.33). This SHALL include an rtptime value which

corresponds to the start time specified in the Range header.

Example:

client->server: PLAY rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/video RTSP/1.0

CSeq: 4

npt=now-

Range:

12345678

Session:

server->client: RTSP/1.0 200 OK

4

CSeq:

12345678

Session:

Range:

20100217T143720.257Z-

url=rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/video; RTP-Info:

seq=1234;rtptime=3450012

5.2.1.1.3 RTSP session for a Metadata stream

In the case of a metadata stream, the SDP description “application” should be used in the DESCRIBE response for media type and “vnd.onvif.metadata” should be used for encoding a name.

Example RTSP DESCRIBE message exchange between an RTSP Server (server) and an RTSP

client (client):

client->server: DESCRIBE rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera RTSP/1.0

1

CSeq:

server->client: RTSP/1.0 200 OK

1

CSeq:

application/sdp

Content-Type:

XXX

Content-Length:

v=0

o=- 2890844256 2890842807 IN IP4 172.16.2.93

Session

s=RTSP

m=audio 0 RTP/AVP 0

/audio a=control:rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera

m=video 0 RTP/AVP 26

/video a=control:rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera

m=application 0 RTP/AVP 107

a=control:rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/metadata

a=recvonly

a=rtpmap

a=rtpmap:107 vnd.onvif.metadata/90000

5.2.1.1.4 RTSP message example

This example shows the message transfer between an RTSP client (client) and an RTSP server (server). The client requests one audio and one video stream from the device. The Stream Uri “rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera” can be retrieved using the GetStreamUri command. Refer to Section …Stream URI“ of the ONVIF Media Service Specification.

client->server: DESCRIBE rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera RTSP/1.0

CSeq: 1

server->client: RTSP/1.0 200 OK

CSeq: 1

Content-Type: application/sdp

Content-Length: XXX

v=0

o=- 2890844256 2890842807 IN IP4 172.16.2.93

s=RTSP Session

m=audio 0 RTP/AVP 0

a=control:rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/audio

m=video 0 RTP/AVP 26

a=control:rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/video client->server: SETUP rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/audio RTSP/1.0

CSeq: 2

Transport: RTP/AVP;unicast;client_port=8002-8003 server->client: RTSP/1.0 200 OK

CSeq: 2

Transport: RTP/AVP;unicast;client_port=8002-8003;

server_port=9004-9005

Session: 12345678; timeout=60

client->server: SETUP rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/video RTSP/1.0

CSeq: 3

Transport: RTP/AVP;unicast;client_port=8004-8005

12345678

Session:

server->client: RTSP/1.0 200 OK

CSeq: 3

Transport: RTP/AVP;unicast;client_port=8004-8005;

server_port=9006-9007

Session: 12345678; timeout=60

client->server: PLAY rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera RTSP/1.0

CSeq: 4

Range: npt=now-

Session: 12345678

server->client: RTSP/1.0 200 OK

CSeq: 4

Session: 12345678

RTP-Info: url=rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/video;

seq=1234;rtptime=3450012,

url=rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera/audio;

seq=22434;rtptime=1234566

client->server: TEARDOWN rtsp://https://www.sodocs.net/doc/d614230381.html,/onvif_camera RTSP/1.0

CSeq: 5

Session: 12345678

server->client: RTSP/1.0 200 OK

CSeq: 5

Session: 12345678

5.2.1.2 RTSP over HTTP

The RTSP over HTTP/HTTPS shall be supported in order to traverse a firewall. See Section 5.1.1.4 RTP/RTSP/HTTP/TCP.

5.3 Back Channel Connection

This section describes how a bidirectional connection can be established between a client and a server. The backchannel connection handling is done using RTSP [RFC 2326]. Therefore a mechanism is introduced which indicates that a client wants to built up a backchannel connection. RTSP provides feature-tags to deal with such functionality additions.

A device that supports bi-directional connections (e.g audio or metadata connections) shall support the introduced RTSP extensions.

When the backchannel data stream is sent via RTSP/HTTP/TCP, a client shall use HTTP GET connection which is defined for sending the data stream without base64 encoding (see 5.1.1.4).

5.3.1 RTSP Require- Tag

The RTSP standard [RFC 2326] can be extended by using additional headers objects. For that purpose a Require tag is introduced to handle special functionality additions (see [RFC 2326], 1.5 Extending Rtsp and 12.32 Require).

视频监控行业常用标准带宽计算

1、首先计算 720P（1280×720）单幅图像照片的数据量 每像素用24比特表示，则： 720P图像照片的原始数据量= 1280×720×24/8/1024＝2700 KByte 2、计算视频会议活动图像的数据量 国内PAL活动图像是每秒传输25帧。数字动态图像是由I帧/B帧/P帧构成。 其中I帧是参考帧：可以认为是一副真实的图像照片。B帧和P帧可简单理解为预测帧，主要是图像的增量变化数据，数据量一般较小。 极限情况下，25帧均为I帧，即每帧传输的图像完全不同。则： 720P活动图像的每秒传输的极限数据量= 2700 KByte×25 = 67500 KByte/s 转换成网络传输Bit流= 67500×8 = 540000 Kbit/s，即528M的带宽。 在实际视频会议应用中，由于有固定场景，因此以传输增量数据为主（传输以B帧和P帧为主），一般在10%-40% 之间，40%为变化较多的会议场景。计算如下： 增量数据在10%的情况下， 原始数据量= 2700 KByte×10%×24 + 2700 KByte =9180 KByte/s = 72 Mbit/s 增量数据在20%的情况下， 原始数据量= 2700 KByte×20%×24+ 2700 KByte =15660 KByte/s = 123 Mbit/s 增量数据在40%的情况下， 原始数据量= 2700 KByte×40%×24+ 2700 KByte =28620 KByte/s = 224 Mbit/s 3、H.264压缩比 H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。举个例子，原始文件为88GB，采用MPEG-2压缩后为3.5GB，压缩比为25∶1，而采用H.264压缩后为1.1GB，从88GB到1.1GB，H.264的压缩比达到惊人的80∶1。 4、采用H.264压缩后的净荷数据量 视频会议中都对原始码流进行编解码压缩。采用H.264，压缩比取80：1。计算如下：在10%的情况下，压缩后的净荷数据量= 72/80 = 0.9 Mbit/s 在20%的情况下，压缩后的净荷数据量= 123/80 = 1.6 Mbit/s 在40%的情况下，压缩后的净荷数据量= 224/80 = 2.8 Mbit/s 5、采用H.264压缩后的传输数据量 加上网络开销，传输数据量= 净荷数据量* 1.3 在10%的情况下，压缩后的传输数据量= 0.9 * 1.3 = 1.17 Mbit/s 在20%的情况下，压缩后的传输数据量= 1.6 * 1.3 = 2.08 Mbit/s 在40%的情况下，压缩后的传输数据量= 2.8 * 1.3 = 3.64 Mbit/s 6、厂商情况 部分厂商宣传的1M 720P超高清应用，有诸多使用限制。 如宝利通在其《HDX管理员指南》P56中明确指出：“在将视频质量设置为“清晰度”

视频监控中常用码流计算

视频监控中常用码流计算 在视频监控系统中，对存储空间容量的大小需求是与画面质量的高低、及视频线路等都有很大关系。下面对视频存储空间大小与传输带宽的之间的计算方法简单介绍。 比特率是指每秒传送的比特(bit)数。单位为bps(BitPerSecond)，比特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；假如比特率越少则情况恰好相反。 码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。 上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上往，影响上传速度的就是“上行速率”。 下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。 不同的格式的比特率和码流的大小定义表： 传输带宽计算： 比特率大小×摄像机的路数=网络带宽至少大小； 注：监控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心)；监控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心)；例：电信2Mbps的ADSL宽带，50米红外摄像机理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/。

安防监控硬盘容量计算公式

1080P、720P、4CIF、CIF所需要的理论带宽在视频监控系统中，对存储空间容量的大小需求是与画面质量的高低、及视频线路等都有很大关系。下面对视频存储空间大小与传输带宽的之间的计算方法做以先容。 比特率是指每秒传送的比特(bit)数。单位为bps(BitPerSecond)，比特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；假如比特率越少则情况恰好相反。 码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。 上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上往，影响上传速度的就是“上行速率”。 下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。 不同的格式的比特率和码流的大小定义表： 传输带宽计算： 比特率大小×摄像机的路数=网络带宽至少大小； 注：监控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心)；监控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心)；例：电信2Mbps的ADSL宽带，50米红外摄像机理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/。 例：监控分布在5个不同的地方，各地方的摄像机的路数：n=10(20路)1个监控中心，远程监看及存储视频信息，存储时间为30天。不同视频格式的带宽及存储空间大小计算如下： 地方监控点： CIF视频格式每路摄像头的比特率为512Kbps，即每路摄像头所需的数据传输带宽为

传输带宽计算方法

比特率是指每秒传送的比特(bit)数。单位为bps(BitPerSecond)，比 特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0,要 么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；如果比特率越少则情况刚好相反。 码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码 率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码 流越大，压缩比就越小，画面质量就越咼。 上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上去，影响上传速度的就是“上行速率”。 下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。 不同的格式的比特率和码流的大小定义表： 传输带宽计算： 比特率大小X摄像机的路数=网络带宽至少大小； 注：监控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心);监控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心);例：电信2Mbps的ADSL宽带，理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/s

例：监控分布在5个不同的地方，各地方的摄像机的路数：n=10（20路）1 个监控中心，远程监看及存储视频信息，存储时间为30天。不同视频格式的带宽及存储空间大小计算如下： 地方监控点： CIF视频格式每路摄像头的比特率为512Kbps,即每路摄像头所需的数据传输带宽为512Kbps, 10路摄像机所需的数据传输带宽为： 512Kbps（视频格式的比特率）X 10（摄像机的路 数）?5120Kbps=5Mbps上行带宽） 即:采用CIF视频格式各地方监控所需的网络上行带宽至少为5Mbps; D1视频格式每路摄像头的比特率为，即每路摄像头所需的数据传输带宽为，10路摄像机所需的数据传输带宽为： （视频格式的比特率）X 10（摄像机的路数）=15Mbps（上行带宽） 即:采用D1视频格式各地方监控所需的网络上行带宽至少为15Mbps; 720P（100万像素）的视频格式每路摄像头的比特率为2Mbps即每路摄像头所需的数据传输带宽为2Mbps 10路摄像机所需的数据传输带宽为： 2Mbps（视频格式的比特率）X 10（摄像机的路数）=20Mbps（上行带宽） 即:采用720P的视频格式各地方监控所需的网络上行带宽至少为 20Mbps; 像头所需的数据传输带宽为4Mbps 10路摄像机所需的数据传输带宽为:

监控存计算公式

视频监控存储空间计算方法 在视频监控系统中，对存储空间容量的大小需求是与画面质量的高低、及视频线路等都有很大关系。下面对视频存储空间大小与传输带宽的之间的计算方法做以介绍。比特率是指每秒传送的比特(bit)数。单位为 bps(BitPerSecond)，比特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大;如果比特率越少则 情况刚好相反。码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上去，影响上传速度的就是“上行速率”。下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。不同的格式的比特率和码流的大小定义表： 传输带宽计算：比特率大小×摄像机的路数=网络带宽至少大小; 注：监 控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心);监 控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心);例：电信2Mbps的ADSL宽带，理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/s 例：监控分布在5个不同的地方，各地方的摄 像机的路数：n=10(20路)1个监控中心，远程监看及存储视频信息，存储时间为30天。不同视频格式的带宽及存储空间大小计算如下：地方监控点：CIF 视频格式每路摄像头的比特率为512Kbps，即每路摄像头所需的数据传输带宽 为512Kbps，10路摄像机所需的数据传输带宽为：512Kbps(视频格式的比特率)×10(摄像机的路数)≈5120Kbps=5Mbps(上行带宽) 即：采用CIF视频 格式各地方监控所需的网络上行带宽至少为5Mbps; D1视频格式每路摄像 头的比特率为1.5Mbps，即每路摄像头所需的数据传输带宽为1.5Mbps，10路摄像机所需的数据传输带宽为： 1.5Mbps(视频格式的比特率)×10(摄像机的路数)=15Mbps(上行带宽) 即：采用D1视频格式各地方监控所需的网络上行带宽至少为15Mbps; 720P(100万像素)的视频格式每路摄像头的比特率为 2Mbps，即每路摄像头所需的数据传输带宽为2Mbps，10路摄像机所需的数据传输带宽为：2Mbps(视频格式的比特率)×10(摄像机的路数)=20Mbps(上行带宽) 即：采用720P的视频格式各地方监控所需的网络上行带宽至少为 20Mbps; 1080P(200万像素)的视频格式每路摄像头的比特率为4Mbps，即每路摄像头所需的数据传输带宽为4Mbps，10路摄像机所需的数据传输带宽为：4Mbps(视频格式的比特率)×10(摄像机的路数)=40Mbps(上行带宽) 即：采用1080P的视频格式各地方监控所需的网络上行带宽至少为40Mbps;监控中心：

监控带宽计算方法

视频监控存储空间大小计算方法 在视频监控系统中，对存储空间容量的大小需求是与画面质量的高低、及视频线路等都有很大关系。下 面对视频存储空间大小与传输带宽的之间的计算方法做以介绍。 比特率是指每秒传送的比特(bit)数。单位为bps(BitPerSecond)，比特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大;如果比特率越少则情况刚好相反。 码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。 上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上去，影响上传速度的就是“上行速率”。 下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。 不同的格式的比特率和码流的大小定义表： 传输带宽计算： 比特率大小×摄像机的路数=网络带宽至少大小; 注：监控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心); 监控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心);例：电信2Mbps的ADSL宽带，理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/s 例：监控分布在5个不同的地方，各地方的摄像机的路数：n=10(20路)1个监控中心，远程监看及存储视频信息，存储时间为30天。不同视频格式的带宽及存储空间大小计算如下： 地方监控点： CIF视频格式每路摄像头的比特率为512Kbps，即每路摄像头所需的数据传输带宽为512Kbps，10路摄像机所需的数据传输带宽为： 512Kbps(视频格式的比特率)×10(摄像机的路数)≈5120Kbps=5Mbps(上行带宽) 即：采用CIF视频格式各地方监控所需的网络上行带宽至少为5Mbps; D1（4CIF）视频格式每路摄像头的比特率为1.5Mbps，即每路摄像头所需的数据传输 带宽为1.5Mbps，10路摄像机所需的数据传输带宽为：

影片文件码率与大小计算

音视频文件码率与大小计算 编码率/比特率直接与文件体积有关。且编码率与编码格式配合是否合适，直接关系到视频文件是否清晰。 在视频编码领域，比特率常翻译为编码率，单位是Kbps，例如800Kbps 其中， 1K=1024 1M=1024K b 为比特（bit）这个就是电脑文件大小的计量单位，1KB=8Kb，区分大小写，B代表字节(Byte) s 为秒（second） p 为每（per）以800kbps来编码表示经过编码后的数据每秒钟需要用800K比特来表示。 1MB=8Mb=1024KB=8192Kb Windows系统文件大小经常用B(字节)为单位表示，但网络运营商则用b(比特)，也就是为什么2Mb速度宽带在电脑上显示速度最快只有约256KB的原因，网络运营商宣传网速的时候省略了计量单位。 完整的视频文件是由音频流与视频流2个部分组成的，音频和视频分别使用的是不同的编码率，因此一个视频文件的最终技术大小的编码率是音频编码率+视频编码率。例如一个音频编码率为128Kbps，视频编码率为800Kbps的文件，其总编码率为928Kbps，意思是经过编码后的数据每秒钟需要用928K比特来表示。 了解了编码率的含义以后，根据视频播放时间长度，就不难了解和计算出最终文件的大小。编码率也高，视频播放时间越长，文

件体积就越大。不是分辨率越大文件就越大，只是一般情况下，为了保证清晰度，较高的分辨率需要较高的编码率配合，所以使人产生分辨率越大的视频文件体积越大的感觉。 计算输出文件大小公式： （音频编码率（Kbit为单位）/8 + 视频编码率（Kbit为单位）/8）× 影片总长度（秒为单位）= 文件大小（MB为单位） 这样以后大家就能精确的控制输出文件大小了。 例：有一个1.5小时（5400秒）的影片，希望转换后文件大小刚好为700M 计算方法如下： 700×8÷5400×1024≈1061Kbps 意思是只要音频编码率加上视频编码率之和为1061Kb，则1个半小时的影片转换后文件体积大小刚好为700M。 至于音频编码率和视频编码率具体如何设置，就看选择的编码格式和个人喜好了，只要2者之和为1061即可。如可以设置为视频编码格式H264，视频编码率900 Kbps，音频编码格式AAC，编码率161 Kbps。 与文件体积大小有关的码率是指的平均码率，因此，不论是使用固定比特一次编码方式还是使用二次（多次）动态编码方式，都是可以保证文件大小的。只有使用基于质量编码的方式的时候，文件大小才不可控制。

关于如何计算视频监控录像存储空间

关于如何计算视频监控录像存储空间 集团公司文件内部编码：（TTT-UUTT-MMYB-URTTY-ITTLTY-

关于如何计算视频监控录像存储空间 随着广西分公司公司摄像头监控点的不断增加，录像存储时间越来越延长，因此存储系统的问题也越来越受到重视，在保证视频画面质量的前提下，如何合理利用存储空间就显得及其重要。下面就视频存储空间大小的计算做简单介绍。 在此之前先了解个概念： 视频码流包括单码流、双码流、三码流，指视频文件在单位时间内使用的数据流量，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，画面质量就越高。 目前市面上比较主流的视频格式及码流大小合理设置 格式类型CIFD1720P1080P 比特率大小512kbps1.5Mbps2Mbps4Mbps 码流大小64KB/s192KB/s256KB/s512KB/s 根据上面表格的数据，我们可以计算出不同视频格式的摄像头一段时间内录像存储的大小，具体对于摄像头的存储空间大小的计算方式如下: 所需存储大小=码流大小（单位：KB/s;即比特率/8）X3600(单位：秒；一个小时的秒数)X24（单位：小时；一天的小时数）X保存天数X监控通道数（需要存储的摄像头的数量）（注：存储单位换算1T=1024G;1G=1024M;1M=1024KB） 例如：公司保卫部有30个摄像头，视频格式分别为CIF，720P，视频录像要求存储30天，分别需要的存储大小为多少？ CIF格式：存储计算=64KB/秒x3600秒x24x30x30≈4746G=4.63T 720P格式：存储计算=256KB/秒x3600秒x24x30x30=18984.375G≈18.5T 通过这个公式，我们根据用户的监控需求（例如：录像保存天数，视频画面质量等等），来计算出不同格式，不同码流的视频所需要的存储空间，然后通过计算出来的所需存储大小，合理购买硬盘数量，合理分配磁盘空间。通过这个方式最大限度的避免了存储资源和金钱的浪费。

码流计算

各种分辨率下采用什么样的码流可以获得较好的图像质量 DS-8000HC嵌入式网络硬盘录像机NVR支持多种分辨率，我们一般使用CIF、DCIF、D1三种。在不同的视频分辨率下，我们建议用户采用如下码流设置方式CIF：512Kbps，在变码率设置下图像质量选择“较好”或“次好” DCIF：768Kbps，在变码率设置下图像质量选择“较好”或“次好” D1：2Mbps，在变码率设置下图像质量选择“较好”或“次好” 如何进行硬盘容量的计算 bps是bits per second的缩写，一般是指传输速度，表示为: 比特/秒。 bps=bits/s=bytes/8s （1Bps每8秒传送1Byte数据） bytes是字节的意思，是个大小单位,简写B 1GB=1024MB 1MB=1024KB 1KB=1024B 每小时录像文件大小计算公式：码流大小×3600÷8÷1024= MB/小时 硬盘录像机硬盘容量计算遵循以下公式： 每小时录像文件大小×每天录像时间×硬盘录像机路数×需要保存的天数 例如：8路硬盘录像机，视音频录像，采用512Kbps定码流，每天定时录像12小时，录像资料保留15天，计算公式如下： 每小时录像文件大小=512×3600÷8÷1024=225MB 硬盘录像机所需硬盘容量=225×8×12×15=324000MB≈320GB 音频码流为固定16kbps，每小时所占容量很小，可以忽略不计 目前国内主流的硬盘录像机采用两种分辨率：CIF和D1。 硬盘录像机常见的路数有1路、2路、4路、8路、9路、12路和16路。最大可以连接8块2000GB的硬盘，总容量可高达1.6T（目前市面上最大的硬盘在1000GB左右），如果采用CIF分辨率，通常每1路的硬盘容量为180MB~250MB/小时，通常情况下取值200MB/小时；如果是D1的分辨率每小时录像需要的硬盘容量为720MB~1000MB/小时，通常情况下为了减少硬盘的容量可以按照500MB/小时计算，帧率智能设

视频监控中常用码流计算

视频监控中常用码流计 算 Document serial number【LGGKGB-LGG98YT-LGGT8CB-LGUT-

视频监控中常用码流计算 在视频监控系统中，对存储空间容量的大小需求是与画面质量的高低、及视频线路等都有很大关系。下面对视频存储空间大小与传输带宽的之间的计算方法简单介绍。 比特率是指每秒传送的比特(bit)数。单位为bps(BitPerSecond)，比特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；假如比特率越少则情况恰好相反。 码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。 上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上往，影响上传速度的就是“上行速率”。

下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。 不同的格式的比特率和码流的大小定义表： 传输带宽计算： 比特率大小×摄像机的路数=网络带宽至少大小；

注：监控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心)；监控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心)；例：电信2Mbps的ADSL宽带，50米红外摄像机理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/。 例：监控分布在5个不同的地方，各地方的摄像机的路数：n=10(20路)1个监控中心，远程监看及存储视频信息，存储时间为30天。不同视频格式的带宽及存储空间大小计算如下： 监控点： CIF视频格式每路摄像头的比特率为512Kbps，即每路摄像头所需的数据传输带宽为512Kbps，10路摄像机所需的数据传输带宽为：

视频会议-系统带宽的计算方法

客户端带宽： 下行带宽=接受视频路数*视频码流+音频带宽 上行带宽=广播视频路数*视频码流+音频带宽 服务器带宽： 下行带宽=视频带宽+音频带宽=广播视频路数*视频码流+发言人数*音频带宽 上行带宽=视频带宽+音频带宽=（客户端数量-1）*广播视频路数*码流+（开会人数-1）*音频带宽 举例：假设20个点的会议，广播2路视频，1人发言。（视频码流150K，音频带宽24K。）计算如下： 客户端（下行）=广播视频路数*视频码流+音频带宽=2*150K+24K=324K 客户端（上行）=广播视频路数*视频码流+音频带宽 服务器（下行）=广播视频路数*视频码流+发言人数1*音频带宽=2*150K+1*24=324K 服务器（上行）=（客户端数量-1）*广播视频路数*码流+（开会人数-1）*音频带宽=19*2*150K+19*24K=6M 上面是理论值，实际会高一点，还需考虑其带宽利用率和损耗。

相关小知识： 文件大小的最小单位是byte字节,我们一般说文件都多少兆(字节) 算带宽的时候是按位算的;流量最小单位是bit 位 1Byte=8bit 在计算机网络、IDC机房中，其宽带速率的单位用bps(或b/s)表示；换算关系为：1Byte=8bit 1B=8b ---------- 1B/s=8b/s(或1Bps=8bps) 1KB=1024B ---------- 1KB/s=1024B/s 1MB=1024KB ---------- 1MB/s=1024KB/s 在实际上网应用中，下载软件时常常看到诸如下载速度显示为128KB（KB/s），103KB/s等等宽带速率大小字样，因为网络带宽单位是：位/每秒（即：bit/s),而内存等带宽单位却是：字节/每秒（即：byte/s)。我们可以按照换算公式换算一下：128KB/s=128×8(Kb/s)=1024Kb/s=1Mb/s即：128KB/s=1Mb/s 理论上：2M（即2Mb/s）宽带理论速率是：256KB/s（即2048Kb/s），实际速率大约为80--200kB/s；(其原因是受用户计算机性能、网络设备质量、资源使用情况、网络高峰期、网站服务能力、线路衰耗，信号衰减等多因素的影响而造成的)。4M（即4Mb/s）的宽带理论速率是： 512KB/s，实际速率大约为200---440kB/s。

码流换算

例如：8路硬盘录像机，视音频录像，采用512Kbps定码流，每天定时录像12小时，录像资料保留15天，计算公式如下： 每小时录像文件大小=512×3600÷8÷1024=225MB 硬盘录像机所需硬盘容量=225×8×12×15=324000MB≈320GB 各种分辨率下采用什么样的码流可以获得较好的图像质量，一般的硬盘录像机都支持多种分辨率，我们一般使用CIF、DCIF、D1三种。在不同的视频分辨率下，我们建议用户采用如下码流设置方式 CIF：512Kbps，在变码率设置下图像质量选择“较好”或“次好” DCIF：768Kbps，在变码率设置下图像质量选择“较好”或“次好” D1：2Mbps，在变码率设置下图像质量选择“较好”或“次好” 如何进行硬盘容量的计算 每小时录像文件大小计算公式：码流大小×3600÷8÷1024= MB/小时 硬盘录像机硬盘容量计算遵循以下公式： 每小时录像文件大小×每天录像时间×硬盘录像机路数×需要保存的天数 例如：8路硬盘录像机，视音频录像，采用512Kbps定码流，每天定时录像12小时，录像资料保留15天，计算公式如下： 每小时录像文件大小=512×3600÷8÷1024=225MB 硬盘录像机所需硬盘容量=225×8×12×15=324000MB≈320GB 音频码流为固定16kbps，每小时所占容量很小，可以忽略不计 注：为什么除以8，其实很简单，我们计算的是硬盘容量，硬盘容量是以多少兆字节为单位的，而“码流大小×3600”计算出来的是多少比特，一字节（byte）等于8比特（bits），换算成兆字节就要÷8÷1024了。 目前国内主流的硬盘录像机采用两种分辨率：CIF和D1。 硬盘录像机常见的路数有1路、2路、4路、8路、9路、12路和16路。最大可以连接8块2000GB的硬盘，总容量可高达1.6T（目前市面上最大的硬盘在1000GB左右），如果采用CIF分辨率，通常每1路的硬盘容量为180MB~250MB/小时，通常情况下取值200MB/小时；如果是D1的分辨率每小时录像需要的硬盘容量为720MB~1000MB/小时，通常情况下为了减少硬盘的容量可以按照500MB/小时计算，帧率智能设置比25fps 少一些，码流也要少一些！相信大家可以计算出一台装满8块500GB的16路硬盘录像机可以录像多长时间了？ 计算举例：8路CIF格式24小时不间断录像30天所需硬盘容量？ 8路×200M×24小时×30天÷1024M = 1125G (注：1G = 1024M) 硬盘占用时间计算：以正常画面质量计算，每路每小时 200M。例如16路硬盘录像机，同时录像的情况下每小时共占用硬盘 3.2G。根据不同应用场所，可以采用动态录像等方式进行录像，这样保证录像资料均为有效部分。 硬盘录满后将自动对前面的录像资料循环覆盖。可用光盘刻录机将需要长期保存的录像内容刻在光盘上。 有些情况下为减少硬盘投入，可按每路每小时100M设置录像质量，但画面质量不能保证。建议只在要求不高的情况下使用。

监控视频存储计算

监控图像计算硬盘容量的方法 内主流的硬盘录像机采用两种分辨率：CIF和D1。 硬盘录像机常见的路数有1路、2路、4路、8路、9路、12路和16路。最大可以连接8块2000GB的硬盘，总容量可高达1.6T（目前市面上最大的硬盘在1000GB 左右），如果采用CIF分辨率，通常每1路的硬盘容量为180MB~250MB/小时，通常情况下取值200MB/小时；如果是D1的分辨率每小时录像需要的硬盘容量为720MB~1000MB/小时，通常情况下为了减少硬盘的容量可以按照500MB/小时计算，帧率智能设置比25fps少一些，码流也要少一些！相信大家可以计算出一台装满8块500GB的16路硬盘录像机可以录像多长时间了吧？ 计算举例：8路CIF格式24小时不间断录像30天所需硬盘容量？ 8路×200M×24小时×30天÷1024M = 1125G 码流的定义 码流——编码器生成的比特流码流（Data Rate），是指视频文件在单位时间内使用的数据流量，也叫码率，是他是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高简单的说就是音频或者视频质量的好坏，一般视频文件在400Kbps~1000Kbps之间就够了。太大会使文件容量很大，但太小就会使画质变差。 摄像机镜头的换算公式 公式1：F= w D / W 公式2：F= h D / H 说明： F ：镜头焦距 D ：被摄物体距镜头的距离 W：被摄物体需摄取的宽度 H ：被摄物体需摄取的高度 W：CCD 靶面的宽度 H ：CCD 靶面的高度

例：某闭路监控工程中，用1/3”的摄像机，摄像机安装在收银员的2 米高 的上方，需要监控制收银员2 米宽的柜台情况，选用多少毫米的镜头？ 按F= w D / W 公式计算 F=4.8 X 2000 / 2000 =4.8 mms 则选用4.8 mm 的镜头即可. 监控的图像格式CIF，D1简介 CIF简介 CIF是常用的标准化图像格式（Common Intermediate Format）。在H.323协议簇中，规定了视频采集设备的标准采集分辨率。CIF = 352×288像素 QCIF全称Quarter common intermediate format。QCIF也是常用的标准化图像格式。在H.323中，规定QCIF = 176×144像素。 CIF格式具有如下特性： (1) 电视图像的空间分辨率为家用录像系统(Video Home System，VHS)的分辨率，即352×288。 (2) 使用非隔行扫描(non-interlaced scan)。 (3) 使用NTSC帧速率，电视图像的最大帧速率为30 000/1001≈29.97幅/秒。 (4) 使用1/2的PAL水平分辨率，即288线。 (5) 对亮度和两个色差信号(Y、Cb和Cr)分量分别进行编码，它们的取值范围同ITU-R BT.601。即黑色=16，白色=235，色差的最大值等于240，最小值等于16。 下面为5种CIF 图像格式的参数说明。参数次序为“图象格式亮度取样的象素个数(dx) 亮度取样的行数 (dy) 色度取样的象素个数(dx/2) 色度取样的行数(dy/2)”。 sub-QCIF 128×96 64 48 QCIF 176×144 88 72 CIF 352×288 176 144 4CIF 704×576 352 288（即我们经常说的D1） 16CIF 1408×1152 704 576 目前监控行业中主要使用Qcif（176×144）、CIF（352×288）、HALF D1（704×288）、D1 （704×576）等几种分辨率，CIF录像分辨率是主流分辨率，绝大部分产品都采用CIF分辨率。目前市场接受CIF分辨率，主要理由有四点：1、目前数码监控要求视频码流不能太高；2、视频传输带宽也有限制；3、使用HALF D1、D1分辨率可以提高清晰度，满足高质量的要求，但是以高码流为代价的。

视频监控码流计算

视频监控码流计算 在视频监控系统中，对存储空间容量的大小需求是与画面质量的高低、及视频线路等都有很大关系。下面对视频存储空间大小与传输带宽的之间的计算方法简单介绍。 比特率是指每秒传送的比特(bit)数。单位为bps(BitPerSecond)，比特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大；假如比特率越少则情况恰好相反。 码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。 上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上往，影响上传速度的就是“上行速率”。 下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。 不同的格式的比特率和码流的大小定义表： 传输带宽计算： 比特率大小×摄像机的路数=网络带宽至少大小； 注：监控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心)；监控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心)；例：电信2Mbps的ADSL宽带，50米红外摄像机理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/。

关于视频存储容量的计算

视频存储总容量的计算 视频存储容量的计算公式如下： 容量 = 码流/8 ×视频路数×监控天数× 24小时× 3600秒 注：码流是以Mbps或Kbps为单位，码流除以8是把码流从bit 转换为byte，结果相应的是MB或KB。 按计算公式，以一个中小规模的例子计算： 500路监控路数，2Mbps D1格式，数据存储30天，需要的存储容量： 2Mbps/8 × 500路× 30天× 24小时× 3600秒/1024/1024 ≈ 300TB 存储空间单位换算：1TB = 1024GB = 1024 × 1024MB = 1024 ×1024 × 1024KB = 1,073,741,824Byte 硬盘容量单位换算：1TB = 1000GB = 1000 × 1000MB = 1000 ×1000 × 1000KB = 1,000,000,000Byte

基本的算法是：【码率】(kbps)=【文件大小(字节)】X8/【时间(秒)】/1024 码流（Data Rate）是指视频文件在单位时间内使用的数据流量，也叫码率，是他是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。

所以应该是一样的,只是称谓不同 1、最困难的事就是认识自己。20.7.307.30.202011:2411:24:54Jul-2011:24 2、自知之明是最难得的知识。二〇二〇年七月三十日2020年7月30日星期四 3、越是无能的人，越喜欢挑剔别人。11:247.30.202011:247.30.202011:2411:24:547.30.202011:247.30.2020 4、与肝胆人共事，无字句处读书。7.30.20207.30.202011:2411:2411:24:5411:24:54 5、三军可夺帅也。Thursday, July 30, 2020July 20Thursday, July 30, 20207/30/2020 6、最大的骄傲于最大的自卑都表示心灵的最软弱无力。11时24分11时24分30-Jul-207.30.2020 7、人生就是学校。20.7.3020.7.3020.7.30。2020年7月30日星期四二〇二〇年七月三十日 8、你让爱生命吗，那么不要浪费时间。11:2411:24:547.30.2020Thursday, July 30, 2020 亲爱的用户： 烟雨江南，画屏如展。在那桃花盛开的地方，在这醉人芬芳的季节，愿你生活像春天一样阳光，心情像桃花一样美丽，感谢你的阅读。

音视频文件码率与大小计算

音视频文件码率与大小计算 2009-08-08 10:26 编码率/比特率直接与文件体积有关。且编码率与编码格式配合是否合适，直接关系到视频文件是否清晰。 在视频编码领域，比特率常翻译为编码率，单位是Kbps，例如800Kbps 其中， 1K=1024 1M=1024K b 为比特（bit）这个就是电脑文件大小的计量单位，1KB=8Kb，区分大小写，B代表字节(Byte) s 为秒（second） p 为每（per） 以800kbps来编码表示经过编码后的数据每秒钟需要用800K比特来表示。 1MB=8Mb=1024KB=8192Kb Windows系统文件大小经常用B(字节)为单位表示，但网络运营商则用b(比特)，也就是为什么2Mb速度宽带在电脑上显示速度最快只有约256KB的原因，网络运营商宣传网速的时候省略了计量单位。 完整的视频文件是由音频流与视频流2个部分组成的，音频和视频分别使用的是不同的编码率，因此一个视频文件的最终技术大小的编码率是音频编码率+视频编码率。例如一个音频编码率为128Kbps，视频编码率为800Kbps的文件，其总编码率为928Kbps，意思是经过编码后的数据每秒钟需要用928K比特来表示。了解了编码率的含义以后，根据视频播放时间长度，就不难了解和计算出最终文件的大小。编码率也高，视频播放时间越长，文件体积就越大。不是分辨率越大文件就越大，只是一般情况下，为了保证清晰度，较高的分辨率需要较高的编码率配合，所以使人产生分辨率越大的视频文件体积越大的感觉。 计算输出文件大小公式： （音频编码率（Kbit为单位）/8 + 视频编码率（Kbit为单位）/8）× 影片总长度（秒为单位）= 文件大小（MB为单位） 这样以后大家就能精确的控制输出文件大小了。 例：有一个1.5小时（5400秒）的影片，希望转换后文件大小刚好为700M 计算方法如下： 700×8÷5400×1024≈1061Kbps 意思是只要音频编码率加上视频编码率之和为1061Kb，则1个半小时的影片转换后文件体积大小刚好为700M。 至于音频编码率和视频编码率具体如何设置，就看选择的编码格式和个人喜好了，只要2者之和为1061即可。如可以设置为视频编码格式H264，视频编码率900 Kbps，音频编码格式AAC，编码率161 Kbps。 与文件体积大小有关的码率是指的平均码率，因此，不论是使用固定比特一次编码方式还是使用二次（多次）动态编码方式，都是可以保证文件大小的。只有使用基于质量编码的方式的时候，文件大小才不可控制。 编码格式有很多种，在技术不断进步的情况下，针对不同的用途，产生了各种编码格式。不同编码格式的压缩率不一样，且有各自的特点，有些在低码率情况下能保持较高的画面质量，但在高码率情况下反而画面质量提示不大，有些适合在高码率情况下保持高清晰度画面，但可能在低码率情况下效果不佳。介绍常见的几种。 RMVB/RM在制定的时候主要考虑的是网络传播，目的在于利用不快的网速传播视

视频传输带宽及码流换算

视频监控存储空间大小与传输带宽计算方法 在视频监控系统中，对存储空间容量的大小需求是与画面质量的高低、及视频线路等都有很大关系。下面对视频存储空间大小与传输带宽的之间的计算方法做以介绍。 比特率是指每秒传送的比特(bit)数。单位为bps(BitPerSecond)，比特率越高，传送的数据越大。比特率表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示，而比特就是二进制里面最小的单位，要么是0，要么是1。比特率与音、视频压缩的关系，简单的说就是比特率越高，音、视频的质量就越好，但编码后的文件就越大;如果比特率越少则情况刚好相反。码流(DataRate)是指视频文件在单位时间内使用的数据流量，也叫码率，是视频编码中画面质量控制中最重要的部分。同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。 上行带宽就是本地上传信息到网络上的带宽。上行速率是指用户电脑向网络发送信息时的数据传输速率，比如用FTP上传文件到网上去，影响上传速度的就是“上行速率”。 下行带宽就是从网络上下载信息的带宽。下行速率是指用户电脑从网络下载信息时的数据传输速率，比如从FTP服务器上文件下载到用户电脑，影响下传速度的就是“下行速率”。 不同的格式的比特率和码流的大小定义表： 传输带宽计算： 比特率大小×摄像机的路数=网络带宽至少大小; 注：监控点的带宽是要求上行的最小限度带宽(监控点将视频信息上传到监控中心);监控中心的带宽是要求下行的最小限度带宽(将监控点的视频信息下载到监控中心);例：电信2Mbps的ADSL宽带，理论上其上行带宽是512kbps=64kb/s，其下行带宽是2Mbps=256kb/s 例：监控分布在5个不同的地方，各地方的摄像机的路数：n=10(20路)1个监控中心，远程监看及存储视频信息，存储时间为30天。不同视频格式的带宽及存储空间大小计算如下： 地方监控点： CIF视频格式每路摄像头的比特率为512Kbps，即每路摄像头所需的数据传输带宽为512Kbps，10路摄像机所需的数据传输带宽为： 512Kbps(视频格式的比特率)×10(摄像机的路数)≈5120Kbps=5Mbps(上行带宽) 即：采用CIF视频格式各地方监控所需的网络上行带宽至少为5Mbps;