RFC-2032RTPPayloadFormatforH.261VideoStreams(FIR)资源-CSDN文库

需积分: 1 27 浏览量 2023-08-07 10:39:06 上传评论收藏 16KB PDF 举报

资源推荐

资源详情

资源评论

Network Working Group T. Turletti

Request for Comments: 2032 MIT

Category: Standards Track C. Huitema

Bellcore

October 1996

RTP Payload Format for H.261 Video 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.

Table of Contents

1. Abstract ............................................. 1

2. Purpose of this document ............................. 2

3. Structure of the packet stream ....................... 2

3.1 Overview of the ITU-T recommendation H.261 .......... 2

3.2 Considerations for packetization .................... 3

4. Specification of the packetization scheme ............ 4

4.1 Usage of RTP ........................................ 4

4.2 Recommendations for operation with hardware codecs .. 6

5. Packet loss issues ................................... 7

5.1 Use of optional H.261-specific control packets ...... 8

5.2 H.261 control packets definition .................... 9

5.2.1 Full INTRA-frame Request (FIR) packet ............. 9

5.2.2 Negative ACKnowledgements (NACK) packet ........... 9

6. Security Considerations .............................. 10

Authors’ Addresses ..................................... 10

Acknowledgements ....................................... 10

References ............................................. 11

1. Abstract

This memo describes a scheme to packetize an H.261 video stream for

transport using the Real-time Transport Protocol, RTP, with any of

the underlying protocols that carry RTP.

This specification is a product of the Audio/Video Transport working

group within the Internet Engineering Task Force. Comments are

solicited and should be addressed to the working group’s mailing list

at rem-conf@es.net and/or the authors.

Turletti & Huitema Standards Track [Page 1]

RFC 2032 RTP Payload Format for H.261 Video October 1996

2. Purpose of this document

The ITU-T recommendation H.261 [6] specifies the encodings used by

ITU-T compliant video-conference codecs. Although these encodings

were originally specified for fixed data rate ISDN circuits,

experiments [3],[8] have shown that they can also be used over

packet-switched networks such as the Internet.

The purpose of this memo is to specify the RTP payload format for

encapsulating H.261 video streams in RTP [1].

3. Structure of the packet stream

3.1. Overview of the ITU-T recommendation H.261

The H.261 coding is organized as a hierarchy of groupings. The video

stream is composed of a sequence of images, or frames, which are

themselves organized as a set of Groups of Blocks (GOB). Note that

H.261 "pictures" are referred as "frames" in this document. Each GOB

holds a set of 3 lines of 11 macro blocks (MB). Each MB carries

information on a group of 16x16 pixels: luminance information is

specified for 4 blocks of 8x8 pixels, while chrominance information

is given by two "red" and "blue" color difference components at a

resolution of only 8x8 pixels. These components and the codes

representing their sampled values are as defined in the ITU-R

Recommendation 601 [7].

This grouping is used to specify information at each level of the

hierarchy:

- At the frame level, one specifies information such as the

delay from the previous frame, the image format, and

various indicators.

- At the GOB level, one specifies the GOB number and the

default quantifier that will be used for the MBs.

- At the MB level, one specifies which blocks are present

and which did not change, and optionally a quantifier and

motion vectors.

Blocks which have changed are encoded by computing the discrete

cosine transform (DCT) of their coefficients, which are then

quantized and Huffman encoded (Variable Length Codes).

The H.261 Huffman encoding includes a special "GOB start" pattern,

composed of 15 zeroes followed by a single 1, that cannot be imitated

by any other code words. This pattern is included at the beginning of

Turletti & Huitema Standards Track [Page 2]

RFC 2032 RTP Payload Format for H.261 Video October 1996

each GOB header (and also at the beginning of each frame header) to

mark the separation between two GOBs, and is in fact used as an

indicator that the current GOB is terminated. The encoding also

includes a stuffing pattern, composed of seven zeroes followed by

four ones; that stuffing pattern can only be entered between the

encoding of MBs, or just before the GOB separator.

3.2. Considerations for packetization

H.261 codecs designed for operation over ISDN circuits produce a bit

stream composed of several levels of encoding specified by H.261 and

companion recommendations. The bits resulting from the Huffman

encoding are arranged in 512-bit frames, containing 2 bits of

synchronization, 492 bits of data and 18 bits of error correcting

code. The 512-bit frames are then interlaced with an audio stream

and transmitted over px64 kbps circuits according to specification

H.221 [5].

When transmitting over the Internet, we will directly consider the

output of the Huffman encoding. All the bits produced by the Huffman

encoding stage will be included in the packet. We will not carry the

512-bit frames, as protection against bit errors can be obtained by

other means. Similarly, we will not attempt to multiplex audio and

video signals in the same packets, as UDP and RTP provide a much more

efficient way to achieve multiplexing.

Directly transmitting the result of the Huffman encoding over an

unreliable stream of UDP datagrams would, however, have poor error

resistance characteristics. The result of the hierachical structure

of H.261 bit stream is that one needs to receive the information

present in the frame header to decode the GOBs, as well as the

information present in the GOB header to decode the MBs. Without

precautions, this would mean that one has to receive all the packets

that carry an image in order to properly decode its components.

If each image could be carried in a single packet, this requirement

would not create a problem. However, a video image or even one GOB by

itself can sometimes be too large to fit in a single packet.

Therefore, the MB is taken as the unit of fragmentation. Packets

must start and end on a MB boundary, i.e. a MB cannot be split across

multiple packets. Multiple MBs may be carried in a single packet

when they will fit within the maximal packet size allowed. This

practice is recommended to reduce the packet send rate and packet

overhead.

To allow each packet to be processed independently for efficient

resynchronization in the presence of packet losses, some state

information from the frame header and GOB header is carried with each

Turletti & Huitema Standards Track [Page 3]

剩余10页未读，继续阅读

评论收藏

内容反馈

毕加索解锁

粉丝: 2139
资源: 24

RFC-2032 RTP Payload Format for H.261 Video Streams (FIR)

最新资源

RFC-2032 RTP Payload Format for H.261 Video Streams (FIR)

RFC-7741 RTP Payload Format for VP8 Video (VP8)

RFC-6184 RTP Payload Format for H.264 Video (H.264)

RFC-7798 RTP Payload Format for High Efficiency Video Coding

RFC 3984 - RTP Payload Format for H_264 Video

RFC-5404 RTP Payload Format for G.719 (G.719)

RFC-7655 RTP Payload Format for G.711.0 (G.711)

RFC-4749 RTP Payload Format for the G.729.1 Audio Codec (G.729)

RFC-3640 RTP Payload Format for Transport of MPEG-4 Elementary S

RFC-7587 RTP Payload Format for the Opus Speech and Audio Codec

RFC3984 RTP Payload Format for H264 Video

H.264的RTP打包格式中文版

RFC-2543---SIP Session Initiation Protocol.doc

H.264 over RTP(rfc3984)

RFC-3550-RTP协议-中文版.pdf

RTP中文版 by 51TalkAM.pdf

Python库 | certbot-dns-rfc2136-1.17.0.tar.gz

RTP发送H265(HEVC) RFC文档

RFC-3550 RTP中英文版

落雪音乐-六音音源 sixyin-music-source-v1.1.0.js

markdown配套文件，使用前先解压

喜马拉雅xm文件解密工具

OCPP协议解析 代码+代码含义详解

mpp_demo.rar

m3u8的下载转换工具

ubuntu下安装ffmpeg必备软件包合集

音频转码，无限制的享受音乐吧！

OPENCV函数手册（中文）.zip

ev4转mp4小工具（无视授权密码）

最新资源

OCPP协议解析代码+代码含义详解