RFC 2190 (rfc2190) - Page 4 of 12

RTP Payload Format for H

RFC 2190       RTP Payload Format for H.263 Video Streams September 1997


   If the GOB header is present in a GOB, motion vectors are coded with
   reference to MBs in the current GOB only. If a GOB header is not
   present in the current GOB, three motion vectors must be available to
   decode one macroblock, where two of them might come from the previous
   GOB. To correctly decode a whole inter-coded GOB, all the motion
   vectors for MBs in the previous GOB  must be available to compute the
   predictors or the predictors themselves must be present. The optional
   use of three motion vector predictors can be a major problem for a
   packetization scheme like the one defined for H.261 when packetizing
   at MB boundaries [5].

   Consider the case that a packet starts with a MB but the GOB header
   is not present. If the previous packet is lost, then all the motion
   vectors needed to predict the motion vectors for the MBs in the
   current GOB are not available. In order to decode the received MBs
   correctly, all the motion vectors for the previous GOB or the motion
   vector predictors would have to be duplicated at the beginning of the
   packet. This kind of duplication would be very expensive and
   unacceptable in terms of bandwidth overhead.

   The encoding strategy of each H.263 CODEC (CODer and DECoder)
   implementation is beyond the scope of this document, even though it
   has significant effect on visual quality in the presence of packet
   loss. However, we strongly recommend use of the GOB header for every
   GOB at the beginning of a packet to address this problem.

   Similar problems exist because of cross-GOB data dependency related
   to motion vectors, but they can not be addressed by using the GOB
   header. For 16CIF and 4CIF pictures, a GOB contains more than one row
   of MBs. If a GOB can not fit in one RTP packet, and the first packet
   containing the GOB header is lost, then MBs in the second packet can
   not compute motion vectors correctly, because they are coded relative
   to data in the lost packet. Similarly,  when OBMC (Overlapped Block
   Motion Compensation) [4] in Advanced Prediction mode is used, motion
   compensation for some MBs in one GOB could use motion vectors of MBs
   in previous GOB regardless of the presence of GOB header. When MBs
   that are used to decode received MBs are lost, those received MBs can
   not be decoded correctly. Each implementation of the method described
   in this document should take these limitations into account.












Zhu                         Standards Track