datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

RTP Payload Format for H.261 Video Streams
RFC 2032

Document type: RFC - Proposed Standard (October 1996)
Obsoleted by RFC 4587
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2032 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

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

[include full document text]