rfc2032.txt

RFC 的详细文档！

     packet was not MC. HMVD is encoded as a 2's complement
     number, and `10000' corresponding to the value -16 is
     forbidden (motion vector fields range from +/-15).

   Vertical motion vector data (VMVD): 5 bits
     Reference vertical motion vector data (MVD). Set to 0 if
     V flag is 0 or if the packet begins with a GOB header, or
     when the MTYPE of the last MB encoded in the previous
     packet was not MC. VMVD is encoded as a 2's complement
     number, and `10000' corresponding to the value -16 is
     forbidden (motion vector fields range from +/-15).

   Note that the I and V flags are hint flags, i.e. they can be inferred
   from the bit stream. They are included to allow decoders to make
   optimizations that would not be possible if these hints were not
   provided before bit stream was decoded.  Therefore, these bits cannot
   change for the duration of the stream. A conformant implementation
   can always set V=1 and I=0.

4.2.  Recommendations for operation with hardware codecs

   Packetizers for hardware codecs can trivially figure out GOB
   boundaries using the GOB-start pattern included in the H.261 data.
   (Note that software encoders already know the boundaries.) The



Turletti & Huitema          Standards Track                     [Page 6]

RFC 2032           RTP Payload Format for H.261 Video       October 1996


   cheapest packetization implementation is to packetize at the GOB
   level all the GOBs that fit in a packet.  But when a GOB is too
   large, the packetizer has to parse it to do MB fragmentation. (Note
   that only the Huffman encoding must be parsed and that it is not
   necessary to fully decompress the stream, so this requires relatively
   little processing; example implementations can be found in some
   public H.261 codecs such as IVS [4] and VIC [9].) It is recommended
   that MB level fragmentation be used when feasible in order to obtain
   more efficient packetization. Using this fragmentation scheme reduces
   the output packet rate and therefore reduces the overhead.

   At the receiver, the data stream can be depacketized and directed to
   a hardware codec's input.  If the hardware decoder operates at a
   fixed bit rate, synchronization may be maintained by inserting the
   stuffing pattern between MBs (i.e., between packets) when the packet
   arrival rate is slower than the bit rate.

5.  Packet loss issues

   On the Internet, most packet losses are due to network congestion
   rather than transmission errors. Using UDP, no mechanism is available
   at the sender to know if a packet has been successfully received. It
   is up to the application, i.e.  coder and decoder, to handle the
   packet loss. Each RTP packet includes a a sequence number field which
   can be used to detect packet loss.

   H.261 uses the temporal redundancy of video to perform compression.
   This differential coding (or INTER-frame coding) is sensitive to
   packet loss. After a packet loss, parts of the image may remain
   corrupt until all corresponding MBs have been encoded in INTRA-frame
   mode (i.e. encoded independently of past frames). There are several
   ways to mitigate packet loss:

   (1)  One way is to use only INTRA-frame encoding and MB level
        conditional replenishment. That is, only MBs that change
        (beyond some threshold) are transmitted.

   (2)  Another way is to adjust the INTRA-frame encoding
        refreshment rate according to the packet loss observed by
        the receivers. The H.261 recommendation specifies that a
        MB is INTRA-frame encoded at least every 132 times it is
        transmitted. However, the INTRA-frame refreshment rate
        can be raised in order to speed the recovery when the
        measured loss rate is significant.

   (3)  The fastest way to repair a corrupted image is to request
        an INTRA-frame coded image refreshment after a packet
        loss is detected. One means to accomplish this is for the



Turletti & Huitema          Standards Track                     [Page 7]

RFC 2032           RTP Payload Format for H.261 Video       October 1996


        decoder to send to the coder a list of packets lost. The
        coder can decide to encode every MB of every GOB of the
        following video frame in INTRA-frame mode (i.e. Full
        INTRA-frame encoded), or if the coder can deduce from the
        packet sequence numbers which MBs were affected by the
        loss, it can save bandwidth by sending only those MBs in
        INTRA-frame mode. This mode is particularly efficient in
        point-to-point connection or when the number of decoders
        is low.  The next section specifies how the refresh
        function may be implemented.

   Note that the method (1) is currently implemented in the VIC
   videoconferencing software [9]. Methods (2) and (3) are currently
   implemented in the IVS videoconferencing software [4].

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

   This specification defines two H.261-specific RTCP control packets,
   "Full INTRA-frame Request" and "Negative Acknowledgement", described
   in the next section.  Their purpose is to speed up refreshment of the
   video in those situations where their use is feasible.  Support of
   these H.261-specific control packets 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, these control packets should be used with caution.

   The H.261-specific control packets differ from normal RTCP packets in
   that they are not transmitted to the normal RTCP destination
   transport address for the RTP session (which is often a multicast
   address).  Instead, these control packets are sent directly via
   unicast from the decoder to the coder.  The destination port for
   these control packets is the same port that the coder uses as a
   source port for transmitting RTP (data) packets.  Therefore, these
   packets may be considered "reverse" control packets.

   As a consequence, these control packets may only be used when no RTP
   mixers or translators intervene in the path from the coder to the
   decoder.  If such intermediate systems do intervene, the address of
   the coder would no longer be present as the network-level source
   address in packets received by the decoder, and in fact, it might not
   be possible for the decoder to send packets directly to the coder.

   Some reliable multicast protocols use similar NACK control packets
   transmitted over the normal multicast distribution channel, but they
   typically use random delays to prevent a NACK implosion problem [2].
   The goal of such protocols is to provide reliable multicast packet
   delivery at the expense of delay, which is appropriate for
   applications such as a shared whiteboard.



Turletti & Huitema          Standards Track                     [Page 8]

RFC 2032           RTP Payload Format for H.261 Video       October 1996


   On the other hand, interactive video transmission is more sensitive
   to delay and does not require full reliability.  For video
   applications it is more effective to send the NACK control packets as
   soon as possible, i.e. as soon as a loss is detected, without adding
   any random delays. In this case, multicasting the NACK control
   packets would generate useless traffic between receivers since only
   the coder will use them.  But this method is only effective when the
   number of receivers is small. e.g. in IVS [4] the H.261 specific
   control packets are used only in point-to-point connections or in
   point-to-multipoint connections when there are less than 10
   participants in the conference.

5.2.  H.261 control packets definition

5.2.1.  Full INTRA-frame Request (FIR) packet

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|   MBZ   |  PT=RTCP_FIR  |           length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              SSRC                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This packet indicates that a receiver requires a full encoded image
   in order to either start decoding with an entire image or to refresh
   its image and speed the recovery after a burst of lost packets. The
   receiver requests the source to force the next image in full "INTRA-
   frame" coding mode, i.e. without using differential coding. The
   various fields are defined in the RTP specification [1]. SSRC is the
   synchronization source identifier for the sender of this packet. The
   value of the packet type (PT) identifier is the constant RTCP_FIR
   (192).

5.2.2.  Negative ACKnowledgements (NACK) packet

   The format of the NACK packet 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|   MBZ   | PT=RTCP_NACK  |           length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              SSRC                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              FSN              |              BLP              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Turletti & Huitema          Standards Track                     [Page 9]

RFC 2032           RTP Payload Format for H.261 Video       October 1996


   The various fields T, P, PT, length and SSRC are defined in the RTP
   specification [1]. The value of the packet type (PT) identifier is
   the constant RTCP_NACK (193). SSRC is the synchronization source
   identifier for the sender of this packet.

   The two remaining fields have the following meanings:

   First Sequence Number (FSN): 16 bits
     Identifies the first sequence number lost.

   Bitmask of following lost packets (BLP): 16 bits
     A bit is set to 1 if the corresponding packet has been lost,
     and set to 0 otherwise. BLP is set to 0 only if no packet
     other than that being NACKed (using the FSN field) has been
     lost. BLP is set to 0x00001 if the packet corresponding to
     the FSN and the following packet have been lost, etc.

6.  Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Thierry Turletti
   INRIA - RODEO Project
   2004 route des Lucioles
   BP 93, 06902 Sophia Antipolis
   FRANCE

   EMail: [e-mail]


   Christian Huitema
   MCC 1J236B Bellcore
   445 South Street
   Morristown, NJ 07960-6438

   EMail: [e-mail]

Acknowledgements

   This memo is based on discussion within the AVT working group chaired
   by Stephen Casner. Steve McCanne, Stephen Casner, Ronan Flood, Mark
   Handley, Van Jacobson, Henning G.  Schulzrinne and John Wroclawski
   provided valuable comments.  Stephen Casner and Steve McCanne also
   helped greatly with getting this document into readable form.





Turletti & Huitema          Standards Track                    [Page 10]

RFC 2032           RTP Payload Format for H.261 Video       October 1996


References

   [1]  Schulzrinne, H., Casner, S., Frederick, R., and
        V. Jacobson, "RTP: A Transport Protocol for Real-Time
        Applications", RFC 1889, January 1996.

   [2]  Sridhar Pingali, Don Towsley and James F. Kurose, A
        comparison of sender-initiated and receiver-initiated
        reliable multicast protocols, IEEE GLOBECOM '94.

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

   [4]  Thierry Turletti, INRIA Videoconferencing tool (IVS),
        available by anonymous ftp from zenon.inria.fr in the
        "rodeo/ivs/last_version" directory. See also URL
        <http://www.inria.fr/rodeo/ivs.html>.

   [5]  Frame structure for Audiovisual Services for a 64 to 1920
        kbps Channel in Audiovisual Services ITU-T (International
        Telecommunication Union - Telecommunication
        Standardisation Sector) Recommendation H.221, 1990.

   [6]  Video codec for audiovisual services at p x 64 kbit/s
        ITU-T (International Telecommunication Union -
        Telecommunication Standardisation Sector) Recommendation
        H.261, 1993.

   [7]  Digital Methods of Transmitting Television Information
        ITU-R (International Telecommunication Union -
        Radiocommunication Standardisation Sector) Recommendation
        601, 1986.

   [8]  M.A Sasse, U. Bilting, C-D Schulz, T. Turletti, Remote
        Seminars through MultiMedia Conferencing: Experiences
        from the MICE project, Proc. INET'94/JENC5, Prague, June
        1994, pp. 251/1-251/8.

   [9]  Steve MacCanne, Van Jacobson, VIC Videoconferencing tool,
        available by anonymous ftp from ee.lbl.gov in the
        "conferencing/vic" directory.









Turletti & Huitema          Standards Track                    [Page 11]