From uhorn@nt.e-technik.uni-erlangen.de Wed Feb  5 17:05 MET 1997
Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by immd4.informatik.uni-erlangen.de with ESMTP
	id RAA28821 (8.7.6/7.5b-FAU); for <jnweiger@immd4.informatik.uni-erlangen.de>; Wed, 5 Feb 1997 17:05:10 +0100 (MET)
Received: from nt.e-technik.uni-erlangen.de (nt1.e-technik.uni-erlangen.de [131.188.130.2]) by uni-erlangen.de with ESMTP
	id RAA09435 (8.7.6/7.5c-FAU); for <jnweiger%informatik.uni-erlangen.de@smtp.gate.uni-erlangen.de>; Wed, 5 Feb 1997 17:05:06 +0100 (MET)
Received: from nt34 (nt34.e-technik.uni-erlangen.de) by nt.e-technik.uni-erlangen.de with ESMTP;
	id AA177768694 ($Revision: 1.1.1.1 $/7.4h-FAU); Wed, 5 Feb 1997 17:04:54 +0100
From: Uwe Horn <uhorn@nt.e-technik.uni-erlangen.de>
Message-Id: <199702051604.AA177768694@nt.e-technik.uni-erlangen.de>
Date: Wed, 5 Feb 1997 16:01:44 GMT
Apparently-To: jnweiger@informatik.uni-erlangen.de
Content-Type: text
Content-Length: 28352
Status: RO

Internet Engineering Task Force       Audio-Video Transport WG
INTERNET-DRAFT                          T.Turletti, C. Huitema
<draft-ietf-avt-video-packet-02.txt>                     INRIA
                                                   December 93
                                              Expires: May. 94

                        Packetization
                             of
                     H.261 video streams



                      December 10, 1993

             Thierry Turletti, Christian Huitema
                            INRIA

              Christian.Huitema@sophia.inria.fr
               Thierry.Turletti@sophia.inria.fr






1.  Status of this Memo

This document is an Internet draft. Internet drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts).

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress".

Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.

Distribution of this document is unlimited.












INTERNET-DRAFT                    Packetization of H.261


2.  Abstract

This draft describes a packetization scheme of H.261 video
stream.  The scheme proposed can be used to transport such a
video flow over the protocols used by 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.

3.  Purpose of this document

The CCITT recommendation H.261 [1] specifies the encodings
used by CCITT compliant video-conference codecs. Although
these encodings were originally specified for fixed data rate
ISDN circuits, experimentations [2]  have shown that they can
also be used over the internet.

The purpose of this memo is to specify how H.261 video streams
can be carried over the protocols used by RTP [3], such as
UDP, ST-II, etc.


4.  Structure of the packet stream

H.261 codecs produce a bit stream. In fact, H.261 and
companion recommendations specify several levels of encoding:

(1)  Images are first separated in blocks of 8x8 pixels.
     Blocks which have moved are encoded by computing the
     discrete cosine transform (DCT) of their coefficients,
     which are then quantized and Huffman encoded.

(2)  The bits resulting of the Huffman encoding are then
     arranged in 512 bits frames, containing 2 bits of
     synchronization, 492 bits of data and 18 bits of error
     correcting code.

(3)  The 512 bits frames are then interlaced with an audio
     stream and transmitted over px64 kbps circuits according
     to specification H.221.







Turletti, Huitema                                     [Page 2]





INTERNET-DRAFT                    Packetization of H.261


When transmitting over the Internet, we will directly consider
the output of the Huffman encoding. We will not carry the 512
bits frames, as protection against 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 very
poor error resistance characteristics. The H.261 coding is in
fact organized as a sequence of images, or frames, which are
themselves organized as a set of Groups of Blocks (GOB). 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 only given by two color difference
components 8x8 "red" and "blue" blocks. These components and
the codes representing their sampled values are as defined in
the CCIR Recommendation 601.

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, as
     well as precisions on the codings such as distance
     vectors.

The result of this structure 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. In fact, the experience has
shown that:

(1)  It would be unrealistic to carry an image in a single
     packet: video images can sometimes be very large.





Turletti, Huitema                                     [Page 3]





INTERNET-DRAFT                    Packetization of H.261


(2)  GOB information typically fits in a packet. In fact,
     several GOBs can often be grouped in a packet.

Once we have take the decision to correlate GOB
synchronization and packetization, a number of decisions
remain to be taken, due to the following conditions:

(1)  The algorithm should be easy to implement when
     packetizing the output stream of a hardware codec.

(2)  The algorithm should not induce rendition delays -- we
     should not have to wait for a following packet to display
     an image.

(3)  The algorithm should allow for efficient
     resynchronization in case of packet losses.

(4)  It should be easy to depacketize the data stream and
     direct it to an hardware codec's input.

(5)  When the hardware decoder operates at a fixed bit rate,
     one should be able to maintain synchronization, e.g. by
     adding padding bits when the packet arrival rate is
     slower than the bit rate.

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. That pattern marks
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.

The first conclusion of the analysis is that the packets
should contain all the GOB data, including the "GOB start"
pattern that separate the current block from its follower.
Actually, as this pattern is well known, we could as well use
a single bit in the data header to indicate that a GOB-start
pattern must be added at the decoder side.


Not encoding the GOB-start pattern has two advantages:






Turletti, Huitema                                     [Page 4]





INTERNET-DRAFT                    Packetization of H.261


(1)  It reduces the number of bits in the packets, and avoids
     the possibility of splitting packets in the middle of a
     GOB separator.

(2)  It authorizes gateways to hardware decoders to insert the
     stuffing pattern in front of the GOB, in order to meet
     the fixed bit rate requirement.

Another problem posed by the specificities of the H.261
compression is that the GOB data have no particular reason to
fit in an integer number of octets.  The data header will thus
contain two three-bits integers, EBIT and SBIT:

SBIT indicates the number of bits that should be ignored in
     the first (start) data octet.

EBIT indicates the number of bits that should be ignored in
     the last (end) data octet.

Although only the EBIT counter would really be needed for
software coders, the SBIT counter was inserted to ease the
packetization of hardware coders output.  A sample
packetization procedure is found in annex A.

At the receiving sites, the GOB synchronization can be used in
conjunction with the synchronization service of the RTP
protocol. In case of losses, the decoders could become
desynchronized. The "S" bit of the H.261 option field will be
set to indicate that the packet includes the beginning of the
encoding of a GOB, i.e. the quantifier common to all macro
blocks. The receiver will detect losses by looking at the RTP
sequence numbers. The receiver is recommended to resequence
out of order packets in order to limit the packet loss effect.
Some misordering of packets in the network seems likely, even
when there is no loss, and one would not want to drop a frame
because of that. In case of losses, it will ignore all packets
whose "S" bit is null. Once an S bit packet has been received,
it will prepend the GOB start code to that packet, and resume
decoding.

An example packetization program is given in Appendix A.









Turletti, Huitema                                     [Page 5]





INTERNET-DRAFT                    Packetization of H.261


5.  Usage of RTP

The H.261 information are carried as data within the RTP
protocol, using the following information:

        _____________________________________________
       | Ver       |   Protocol version (1).        |
       |___________|________________________________|
       | Channel   |   Identifies one particular    |
       |           |   video stream.                |
       |___________|________________________________|
       | Content   |   H.261 encoded video (31).    |
       |___________|________________________________|
       | Sequence  |   Identifies the packet within |
       | number    |   a stream                     |
       |___________|________________________________|
       | Sync      |   Set if the packet            |
       |           |   includes the end of an image.|
       |___________|________________________________|
       | Timestamp |   The date at which the        |
       |           |   image was grabbed.           |
       |___________|________________________________|


The very definition of this settings implies that the
beginning of an image shall always be synchronized with a
packet. The RTP sequence number can be used to detect missing
packets. In this case, one shall ignore all incoming packets
until the next synchronization mark is received ("S" bit set
in the H.261 header). The "Sync" bit can be used as a flag to
trigger display the new image on the screen.  The H.261 data
will follow the RTP options, as in:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .              RTP header + RTP options (optional)              .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        H.261  options         |         H.261 stream...       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The H.261 options field is defined as following:






Turletti, Huitema                                     [Page 6]





INTERNET-DRAFT                    Packetization of H.261


  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |S|SBIT |E|EBIT |C|I|V|F|Q|SIZE |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

___________________________________________________________________
|S (1 bit)     |   Start of GOB. Set if the packet is a           |
|              |   start of GOB.                                  |
|______________|__________________________________________________|
|SBIT (3 bits) |   Start bit position number of bits              |
|              |   that should be ignored in the first data octet.|
|______________|__________________________________________________|
|E (1 bit)     |   End of GOB. Set if the packet is an            |
|              |   end of GOB.                                    |
|______________|__________________________________________________|
|EBIT (3 bits) |   End bit position number of bits                |
|              |   that should be ignored in the last data octet. |
|______________|__________________________________________________|
|C (1 bit)     |   Color flag. Set if color is encoded.           |
|______________|__________________________________________________|
|I (1 bit)     |   Full Intra Image flag. Set if it is            |
|              |   the first packet of a full intra image.        |
|______________|__________________________________________________|
|V (1 bit)     |   movement Vector flag. Set if movement          |
|              |   vectors are encoded.                           |
|______________|__________________________________________________|
|F (1 bit)     |   Feedback flag. Set if FIR and NACK             |
|              |   packets are enabled.                           |
|______________|__________________________________________________|
|Q             |   QoS feedback flag. Set if QoS packets are      |
|              |   requested.                                     |
|______________|__________________________________________________|
|SIZE (3 bits) |   Image format:                                  |
|              |   QCIF, CIF or number of CIF in SCIF.            |
|______________|__________________________________________________|


The image format (3 bits) is defined as following:











Turletti, Huitema                                     [Page 7]





INTERNET-DRAFT                    Packetization of H.261


                 ____________________________
                | QCIF               |   000|
                |____________________|______|
                | CIF                |   001|
                |____________________|______|
                | SCIF 0             |      |
                | upper left corner  |   100|
                | CIF in SCIF image  |      |
                |____________________|______|
                | SCIF 1             |      |
                | upper right corner |   101|
                | CIF in SCIF image  |      |
                |____________________|______|
                | SCIF 2             |      |
                | lower left corner  |   110|
                | CIF in SCIF image  |      |
                |____________________|______|
                | SCIF 3             |      |
                | lower right corner |   111|
                | CIF in SCIF image  |      |
                |____________________|______|


With:

-    CIF: Common interchange format for video images with 352
     x 288 pixels.

-    QCIF: Quarter CIF with 176 x 144 pixels.

-    SCIF: Super CIF with 704 x 576 pixels.

6.  Usage of RTP parameters

When sending or receiving H.261 streams through the RTP
protocol, the stations should be ready to:

(1)  process or ignore all generic RTP parameters,

(2)  send or receive H.261 specific "Reverse Application Data"
     parameters, to request a video resynchronization.

This memo describes two Reverse Application Data item types,
"Full Intra Request" and "Negative Acknowledge".






Turletti, Huitema                                     [Page 8]





INTERNET-DRAFT                    Packetization of H.261


6.1.  Controlling the reverse flow

Support of the reverse application data by the H.261 sender is
optional; in particular, early experiments have shown that the
usage of this feature could have very negative effects when
the number of sites is very large. Thus, reverse RTP packet
should be used with care in conjunction with response rate
limiting and random delays to spread out the simultaneous
delivery.

Reverse RTP packets travel through the same translators as
forward RTP packets. A site may distinguish reverse RTP
packets from forward RTP packets by their arrival port.
Reverse RTP packets arrive on the same port that the site uses
as a source port for forward (data) RTP packets.

A site shall never send a reverse application data if feedback
packets are not requested by the source (F and Q flags in the
RTP header).

6.2.  Full Intra Request

The "Full Intra Request" items are identified by the item Type
"FIR" (96).

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|   FIR=96    |  length = 1   |           reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

These packets indicate that a site has lost all video
synchronization, and requests the source to send the next
image in "Intra" coding mode, i.e.  without using differential
coding to speed the recovery. The various fields are defined
as follows:














Turletti, Huitema                                     [Page 9]





INTERNET-DRAFT                    Packetization of H.261


       ________________________________________________
      | F      |   Last option bit, as defined by RTP.|
      |________|______________________________________|
      | FIR    |   Full INTRA Request (96)            |
      |________|______________________________________|
      | Length |   In 32-bits word.                   |
      |________|______________________________________|


6.3.  Negative Acknowledgements

Packets lost are detected using the RTP sequence number. After
a packet loss, the receiver will resynchronize on the next
GOB. However, as H.261 uses differential encoding, parts of
the images may remain blurred as long as all corresponding MBs
are not encoded in INTRA mode; i.e. absolute encoding without
relation to previous frame. There are several ways to put it
right.

The fastest way is to request a refreshment. As all GOB
belonging to a given video image carry the same time stamp,
the receiver can determine a list of GOBs which were really
received for that time stamp, and thus identify the "missing
blocks". Requesting a specific reinitialization of these
missing blocks is more efficient than requesting a complete
reinitialization of the image through the "Full Intra Request"
item. But this method can cause congestion in case of numerous
participants. Another method consists to periodically force
INTRA encoding each MB. The INTRA refreshment rate can be
raised in order to speed the recovering when the loss rate
measured is important.

The format of the NACK option is as follow:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|  NACK=97    |  Length = 3   |           reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     FGOBL     |     LGOBL     |         reserved        |SIZE |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      timestamp (seconds)      |     timestamp (fraction)      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Turletti, Huitema                                    [Page 10]





INTERNET-DRAFT                    Packetization of H.261


The different fields have the following values:

    _____________________________________________________
   | F         |   Last option bit, as defined by RTP.  |
   |___________|________________________________________|
   | NACK      |   Negative Acknowledgement (97)        |
   |___________|________________________________________|
   | Length    |   Three 32 bits word.                  |
   |___________|________________________________________|
   | FGOBL     |   First GOB Lost:                      |
   |           |   Identifies the first GOB lost number.|
   |___________|________________________________________|
   | LGOBL     |   Last GOB Lost:                       |
   |           |   Identifies the last GOB lost number. |
   |___________|________________________________________|
   | R         |   Reserved.                            |
   |___________|________________________________________|
   | SIZE      |   Repeat the format indicator of the   |
   |           |   received image, including the number |
   |           |   of the SCIF subimage if present.     |
   |___________|________________________________________|
   | Timestamp |   The RTP timestamp of the             |
   |           |   original image                       |
   |___________|________________________________________|


























Turletti, Huitema                                    [Page 11]





INTERNET-DRAFT                    Packetization of H.261


Appendix A

The following code can be used to packetize the output of an
H.261 codec:

#include <stdio.h>

#define BUFFER_MAX 512

int right[] = {
   /* Number of successives zeroes starting at the MSB for
each octet */
   8,7,6,6,5,5,5,5,4,4,4,4,4,4,4,4,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
   2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
   1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
   1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
   0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
   0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
   0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
   0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

int left[] = {
   /* Number of successives zeroes starting at the LSB for
each octet */
   8,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,
   5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,
   6,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,
   5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,
   7,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,
   5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,
   6,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,
   5,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,0,1,0,2,0,1,0,3,0,1,0,2,0,1,0};

h261_sync(F)
   FILE *F;
{
   int  i, ebit, sbit, start_of_group, end_of_group,
         c, nz;
   unsigned char buf[BUFFER_MAX];
   int *left, *right;

   i = 0;
   ebit = 0;
   sbit = 0;
   start_of_group = 1;





Turletti, Huitema                                    [Page 12]





INTERNET-DRAFT                    Packetization of H.261


   nz = 0;
   while (c = getc(F)) {
      buf[i++] = c;
      if (c == 0) {
         nz += 8;
      } else {
         nz += right[c];
         end_of_group = 1;
         if (nz >= 15) {
            if (right[c] == 7) {
               ebit = 0;
               send_message(buf, i - 2, sbit, ebit,
                  end_of_group, start_of_group);
               sbit = 0;
               i = 0;
            } else {
               ebit = 7 - right[c];
               send_message(buf, i - 2, sbit, ebit,
                  end_of_group, start_of_group);
               i = 0;
               buf[i++] = c;
               sbit = right[c] + 1;
            }
            start_of_group = 1;
         } else {
            nz = left[c];
            if (i >= BUFFER_MAX) {
               ebit = 0;
               end_of_group = 0;
               send_message(buf, i - 2, sbit, ebit,
                  end_of_group, start_of_group);
               buf[0] = buf[i - 2];
               buf[1] = buf[i - 1];
               i = 2;
               sbit = 0;
               start_of_group = 0;
            }
         }
      }
   }
}









Turletti, Huitema                                    [Page 13]





INTERNET-DRAFT                    Packetization of H.261


Appendix B

An early implementation of this protocol is provided in the
IVS software, available by anonymous ftp fom zenon.inria.fr in
the directory rodeo/ivs.

In addition to the generic parameters described in the memo,
IVS uses an application specific option to transmit
audio/video encoding flags and for "flow control" experiments:

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |F|  APP=127    |  Length = 3   |          subtype = 0          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         name = 'IVS '                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     version   |A|V|     R     |            probaQoS           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The different fields have the following values:

_________________________________________________________________
|F        |   Last option bit, as defined by RTP.               |
|_________|_____________________________________________________|
|APP      |   Application-specific option (127)                 |
|_________|_____________________________________________________|
|Length   |   Three 32 bits word.                               |
|_________|_____________________________________________________|
|name     |   "IVS ". Others programs may use this option       |
|         |   to interoperate with IVS.                         |
|_________|_____________________________________________________|
|version  |   IVS version (e.g. 0x33 for 3.3 version).          |
|_________|_____________________________________________________|
|A        |   Audio flag. Set if audio encoding is in progress. |
|_________|_____________________________________________________|
|V        |   Video flag. Set if video encoding is in progress. |
|_________|_____________________________________________________|
|R        |   reserved.                                         |
|_________|_____________________________________________________|
|probaQoS |   This value, function of the number of participants|
|         |   in a session is computed by the each coder site.  |
|_________|_____________________________________________________|







Turletti, Huitema                                    [Page 14]





INTERNET-DRAFT                    Packetization of H.261


Note that this is experimental.

Acknowledgements

This draft is based on discussion within the AVT working group
chaired by Stephen Casner. Stephen Casner, Mark Handley and
Henning G.Schulzrinne provided valuable comments.


References

[1]  Video codec for audiovisual services at p x 64 kbit/s
     CCITT Recommendation H.261, 1990.

[2]  Thierry Turletti. H.261 software codec for
     videoconferencing over the Internet INRIA Research Report
     no 1834, January 1993.

[3]  Henning Schulzrinne, Stephen Casner RTP: A Transport
     Protocol for Real-Time Applications INTERNET-DRAFT,
     October 20, 1993.





























Turletti, Huitema                                    [Page 15]





INTERNET-DRAFT                    Packetization of H.261


Table of Contents


1 Status of this Memo ...................................    1
2 Abstract ..............................................    2
3 Purpose of this document ..............................    2
4 Structure of the packet stream ........................    2
5 Usage of RTP ..........................................    6
6 Usage of RTP parameters ...............................    8
6.1 Controlling the reverse flow ........................    9
6.2 Full Intra Request ..................................    9
6.3 Negative Acknowledgements ...........................   10
 Appendix A .............................................   12
 Appendix B .............................................   14
 Acknowledgements .......................................   15
 References .............................................   15


































Turletti, Huitema                                    [Page 16]








