home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-avt-rtp-payload-02.txt < prev    next >
Text File  |  1996-11-26  |  24KB  |  640 lines
  1.  
  2.  
  3.  
  4. Internet Engineering Task Force                Audio-Video Transport WG
  5. INTERNET-DRAFT                                                   C. Zhu
  6.                                                             Intel Corp.
  7.                                                       November 25, 1996
  8.                                                   Expires: May 25, 1997
  9.  
  10.  
  11.                RTP Payload Format for H.263 Video Stream
  12.  
  13.  
  14. Status of This Memo
  15.  
  16. This document is an Internet-Draft.  Internet-Drafts are working
  17. documents of the Internet Engineering Task Force (IETF), its
  18. areas, and its working groups.  Note that other groups may also
  19. distribute working documents as Internet-Drafts.
  20.  
  21. Internet-Drafts are draft documents valid for a maximum of six
  22. months and may be updated, replaced, or obsoleted by other
  23. documents at any time.  It is inappropriate to use Internet-
  24. Drafts as reference material or to cite them other than as
  25. ``work in progress.''
  26.  
  27. To learn the current status of any Internet-Draft, please check
  28. the ``1id-abstracts.txt'' listing contained in the Internet-
  29. Drafts Shadow Directories on ftp.is.co.za (Africa),
  30. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  31. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  32.  
  33.  
  34. Distribution of this document is unlimited.
  35.  
  36.  
  37.  
  38.  
  39. Abstract 
  40.  
  41. This document specifies the RTP payload format for encapsulating H.263 
  42. bitstreams in the Real-Time Transport Protocol (RTP). Three modes are
  43. defined for RTP H.263 payload header. An RTP packet can use one of the 
  44. three modes for H.263 video streams depending on the desired 
  45. performance characteristics and H.263 encoding options employed. 
  46. The shortest header mode (Mode A) supports fragmentation 
  47. at Group of Block (GOB) boundaries. The long header modes 
  48. (Mode B and C) support fragmentation at Macroblock (MB) boundaries.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Zhu                                                             [Page 1]
  59.  
  60.  
  61. Internet Draft        RTP Payload for H.263            November 25, 1996
  62.  
  63.  
  64. 1. Introduction
  65.  
  66. This document describes a scheme to packetize an H.263 video stream for 
  67. transport using RTP [1]. H.263 video stream is defined by ITU-T
  68. Recommendation H.263 (referred to as H.263 in this document) [4] for 
  69. video coding at very low bit rate. RTP is defined by the Internet 
  70. Engineering Task Force (IETF) to provide end-to-end network transport 
  71. functions suitable for applications transmitting real-time data over 
  72. multicast or unicast network services.
  73.  
  74. The complete specification of RTP for a particular application will 
  75. require a profile specification document [3], a payload format 
  76. specification, and an RTP protocol document [1]. This document is 
  77. intended to serve as the payload format specification for H.263 video 
  78. streams.
  79.  
  80. 2. Definitions
  81.  
  82. For the purpose of this document, the following definitions apply:
  83.  
  84. CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x 288 
  85. pixels for luminance, and 176 x 144 pixels for chrominance.
  86.  
  87. QCIF: Quarter CIF source format with 176 x 144 pixels for luminance and
  88. 88 x 72 pixels for chrominance.
  89.  
  90. sub-QCIF:  picture source format with 128 x 96 pixels for luminance and
  91. 64 x 48 pixels for chrominance.
  92.  
  93. 4CIF: picture source format with 704 x 576 pixels for luminance and
  94. 352 x 288 pixels for chrominance.
  95.  
  96. 16CIF: picture source format with 1408 x 1152 pixels for luminance and 
  97. 704 x 576 pixels for chrominance.
  98.  
  99. GOB: for H.263, a Group of Blocks (GOB) comprises of  k*16 lines, 
  100. depending on the picture format (k=1 for QCIF, CIF and sub-QCIF, k=2 
  101. for 4CIF and k=3 for 16CIF).
  102.  
  103. MB: a macroblock (MB) relates to four blocks of luminance and the 
  104. spatially corresponding two blocks of chrominance. Each block consists 
  105. of 8x8 pixels.
  106.  
  107. 3. Design Issues for Packetizing H.263 Bitstream
  108.  
  109. H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as 
  110. H.261 in this document). Although it employs similar techniques to 
  111. reduce both temporal and spatial redundancy, there are several major 
  112. differences between the two algorithms that impact the design of 
  113. packetization schemes significantly. This section summarizes those 
  114. differences.
  115.  
  116. Zhu                                                             [Page 2]
  117.  
  118.  
  119. Internet Draft         RTP Payload for H.263           November 25, 1996
  120.  
  121. 3.1 Optional Features of H.263
  122.  
  123. In addition to the basic source coding algorithms, H.263 supports four 
  124. negotiable features to improve performance: Advanced Prediction, PB 
  125. frames, Syntax-based Arithmetic Coding, and Unrestricted Motion Vectors.
  126. They can be used in any combination. 
  127.  
  128. Advanced Prediction(AP): four motion vectors instead of one can be used 
  129. for some macroblocks in the frame. This feature makes recovery from 
  130. packet loss harder, because more redundant information has to be 
  131. preserved at the beginning of the packet when fragmenting at macroblock 
  132. boundaries.
  133.  
  134. PB frames:  two frames ( P frame and B frame) are coded into one 
  135. bitstream with macroblocks from the two frames interleaved. From a 
  136. packetization point of view, a MB from the P frame and a MB from the B 
  137. frame must be treated together because each MB for the B frame are coded 
  138. based on the corresponding MB for the P frame. A means must be provided 
  139. to ensure proper rendering of two frames in the right order. Also if 
  140. part of this combined bitstream is lost, it will effect the two frames, 
  141. and possibly more.
  142.  
  143. Syntax-based Arithmetic Coding (SAC): Huffman codes are not the only 
  144. choice for variable length coding. When the SAC option is on, the 
  145. resultant run value pair after quantization of Discrete Cosine 
  146. Transform (DCT) coefficients will be coded differently from Huffman 
  147. codes, but the macroblock hierarchy will be preserved. Since context 
  148. variables are only synchronized before fixed length codes in the 
  149. bitstream, any fragmentation at variable length codes will result in 
  150. difficulty in decoding in the presence of packet loss without carrying 
  151. the values of all the context variables in each packet header.  
  152.  
  153. Unrestricted motion vector feature also has impact on packetization 
  154. because of larger range of motion vector than normal. 
  155.  
  156. To enable proper decoding of packets received without dependency on 
  157. previous packets, the use of these optional features is signaled in the 
  158. H.263 payload header, as described in section 5.
  159.  
  160. 3.2 GOB Numbering
  161.  
  162. In H.263, each picture is divided into groups of blocks (GOB). GOBs are 
  163. numbered by vertical scan of the GOBs, starting with the upper GOB and 
  164. ending with the lower GOB. In contrast, a GOB in  H.261 is composed of 
  165. three rows of 16x16 MB for QCIF, and three half rows of MB for CIF 
  166. format. Like H.261, a GOB is divided into macroblocks in H.263. The 
  167. definition of a macroblock in H.263 is the same as in H.261. 
  168.  
  169. Each GOB in H.263 can have a fixed GOB header, but unlike H.261 the use 
  170. of the header is optional. If the GOB header is present, it may or may 
  171. not start on a byte boundary. Byte alignment can be achieved by proper 
  172. bit stuffing by the encoder, but it is not required.
  173.  
  174. Zhu                                                             [Page 3]
  175.  
  176.  
  177. Internet Draft         RTP Payload for H.263           November 25, 1996
  178.  
  179.  
  180. In summary, a GOB in H.263 is defined and coded with finer granularity 
  181. with the same source format, thus resulting in more flexibility for 
  182. packetization than with H.261.
  183.  
  184.  
  185.  
  186. 3.3 Motion Vectors Encoding
  187.  
  188. Differential coding is used to code motion vectors as variable length 
  189. codes. Unlike in H.261, where each motion vector is predicted from the 
  190. previous MB in the GOB, H.263 employs a more flexible prediction scheme,
  191. where three candidate predictors are used instead of one. It is done 
  192. differently depending on the presence of GOB header. 
  193.  
  194. If the GOB header is included for a GOB, motion vectors are coded with 
  195. reference to MBs in the current GOB only. But if the GOB header is not 
  196. present for the current GOB, three motion vectors must be available to 
  197. decode one macroblock, where two of them are from the previous GOB. To 
  198. decode the whole inter-coded GOB, all the motion vectors must be 
  199. available from the previous GOB. This can be a major problem for a 
  200. packetization scheme like the one defined for H.261 when packetizing 
  201. at MB boundaries. 
  202.  
  203. Let's assume a packet starts with one MB but the GOB header is not 
  204. coded. If the previous packet is lost, then all the motion vectors 
  205. to predict the motion vector for the MBs in this GOB are not available. 
  206. In order to decode the received MBs correctly, all the motion vectors 
  207. for the previous GOB would have to be saved at the beginning of the 
  208. packet. This would be very expensive and unacceptable in terms of 
  209. bandwidth overhead.
  210.  
  211. The encoding strategy of each H.263 codec implementation is beyond 
  212. the scope of this document, even though it has very significant impact 
  213. on visual quality in the presence of packet loss. However, we strongly
  214. recommend use of the GOB header for every GOB at the beginning of 
  215. a packet to address these problems. 
  216.  
  217.  
  218. 3.4 Macroblock Address
  219.  
  220. As specified by H.261, macroblock address (MBA) is encoded with a 
  221. variable length code to indicate the position of a macroblock within 
  222. a group of blocks in the H.261 bitstream. H.263 does not code the MBA 
  223. explicitly, but the macroblock address within a GOB is necessary to 
  224. recover the decoder state in the presence of packet loss when 
  225. fragmenting at MB boundaries. Therefore, this information must be 
  226. included in the H.263 payload header for two of the modes 
  227. (Mode B and Mode C as described in section 5) that allow packetization 
  228. at MB boundaries. 
  229.  
  230.  
  231.  
  232.  
  233. Zhu                                                             [Page 4]
  234.  
  235.  
  236. Internet Draft        RTP Payload for H.263            November 25, 1996
  237.  
  238. 4. Usage of RTP
  239.  
  240. When transmitting H.263 video streams over the Internet, we will 
  241. directly packetize the output of the encoder. All the bits resulting 
  242. from the bitstream including the fixed length codes and  variable 
  243. length codes (Huffman codes, or SAC if SAC is used) will be included 
  244. in the packet. Also we do not intend to multiplex audio and video 
  245. signals in the same packets, as UDP and RTP provide a much more 
  246. efficient way to achieve multiplexing.
  247.  
  248. RTP does not guarantee a reliable and orderly data delivery service, 
  249. so a packet might get lost in the network. To achieve a best-effort 
  250. recovery from packet loss, the decoder needs assistance to proceed with 
  251. decoding of other packets that are received. Thus it is desirable to 
  252. be able to process each packet independent of other packets. 
  253. Some frame level information is included in each packet, such as source 
  254. format and flags for optional features to assist the decoder in 
  255. operating correctly and efficiently in presence of packet loss. The 
  256. flags for H.263 optional features also provide information about 
  257. coding options used in the H.263 video streams that can be used by 
  258. session management tools.
  259.  
  260. The H.263 video stream will be carried as payload data within the RTP 
  261. packets. A new H.263 payload header is defined in section 5, H.263 
  262. payload header. This section defines the usage of RTP fixed header 
  263. and H.263 video packet structure. 
  264.  
  265. 4.1 RTP Header usage
  266.  
  267. Each RTP packet starts with a fixed RTP header. The following fields of 
  268. the RTP fixed header are used for H.263 video stream:
  269.  
  270. Marker bit (M bit): The Marker bit of the RTP header  is set to 1 
  271. when the current packet carries the end of current frame. 0 otherwise.
  272.  
  273. Payload Type (PT): The Payload Type shall specify H.263 video payload 
  274. format.
  275.  
  276. Timestamp: The RTP Timestamp encodes the sampling instance of the first 
  277. video frame contained in the RTP data packet. The RTP timestamp may be 
  278. the same  on successive packets if a video frame occupies more than one 
  279. packet. For H.263 video stream, the RTP timestamp is based on a 90 kHz 
  280. clock, the same as that of RTP payload for H.261 stream. 
  281.  
  282. 4.2 Video Packet Structure
  283.  
  284. H.263 compressed bitstream is carried as payload within each RTP packet.
  285. For each RTP packet, the RTP header is followed by the H.263 payload 
  286. header, which is followed by the standard H.263 compressed bitstream. 
  287. The size of the H.263 payload header is variable depending on modes 
  288. used as detailed in the next section. The layout of the RTP H.263 
  289. video packet is shown as:
  290.  
  291. Zhu                                                             [Page 5]
  292.  
  293.  
  294. Internet Draft        RTP Payload for H.263            November 25, 1996
  295.  
  296.  
  297.  0                   1                   2                   3
  298.  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
  299. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  300. |                 RTP Header                                    |
  301. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  302. |                 H.263 Payload Header                          |
  303. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  304. |                 H.263 stream                                  |
  305. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  306.  
  307.  
  308.  
  309. 5. H.263 Payload Header
  310.  
  311. For H.263 video streams, each RTP packet carries only one H.263 video
  312. packet. The H.263 payload header is always present for each H.263 video 
  313. packet. 
  314.  
  315. Three formats (Mode A, Mode B and Mode C) are defined for RTP H.263 
  316. payload header. In Mode A, a H.263 payload header of four bytes is 
  317. present before actual compressed H.263 video bitstream in the packet. 
  318. It allows fragmentation at GOB boundaries. In Mode B, a eight byte H.263
  319. payload header is used and each packet starts at MB boundaries with the 
  320. PB frame option off. Finally, Mode C with a 12 bytes header is provided 
  321. to support fragmentation at MB boundaries for frames that are coded with
  322. the PB frame option on. The mode is indicated by the F field and P field
  323. in the first two bits of the header. The three modes can be intermixed 
  324. for one compressed frame. All the client application are required to 
  325. be able to receive packets in all three modes, but decoding of Mode C 
  326. packets is optional because PB-frame is an optional feature of H.263  
  327. decoder.
  328.  
  329. In this section, the H.263 payload format is shown as rows of 32-bit 
  330. word. Each word is transmitted in network byte order with the most 
  331. significant byte shown at the left in the following diagrams.
  332.  
  333. 5.1 Mode A
  334.  
  335. In this mode, H.263 bitstream will be packetized at GOB boundaries. 
  336. In other words, each packet will start at the beginning of a GOB, and it 
  337. can carry one or more MBs or GOBs. Only four bytes are used for the 
  338. header. Mode A can be used with or without PB frame option. For those
  339. GOBs that are smaller than network packet size, this mode is 
  340. recommended. The H.263 payload header definition for Mode A is shown 
  341. as follows with F=0.
  342.  
  343.  0                   1                   2                   3
  344.  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
  345. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  346. |V  |F|P|I|SBIT |EBIT | SRC |U|A|S|R  |DBQ| TRB |    TR         |
  347. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  348.  
  349. Zhu                                                             [Page 6]
  350.  
  351.  
  352. Internet Draft         RTP Payload for H.263           November 25, 1996
  353.  
  354. V: 2 bit
  355. Version number, set to 0 for this version of RTP H.263 payload header.
  356.  
  357. F: 1 bit
  358. The flag bit indicates the format of the header. F=0, Mode A, F=1, 
  359. Mode B or Mode C.
  360.  
  361. P: 1 bit
  362. Optional PB-frame mode as defined by the H.263 [4]. "0" implies normal 
  363. I or P frame, "1" PB-frame. When F=1, P also indicates modes. Mode B 
  364. if P=0, Mode C if P=1.
  365.  
  366. I:  1 bit. 
  367. Set to 1 if current picture is intra-coded. Otherwise 0. Notice this is 
  368. opposite to the picture coding type in PTYPE as defined within the H.263
  369. bitstream [4].
  370.  
  371. SBIT: 3 bits
  372. Start bit position specifies number of bits that should be ignored in 
  373. the first data byte.
  374.  
  375. EBIT: 3 bits
  376. End bit position indicates number of bits that should be ignored in the 
  377. last data byte.
  378.  
  379. SRC : 3 bits
  380. Source format specifies the resolution of the frames contained as 
  381. defined by the H.263 [4].
  382.  
  383. U: 1 bit
  384. Unrestricted Motion Vector mode as defined by H.263 [4]. "0" off, 
  385. "1" on.
  386.  
  387. A: 1 bit
  388. Optional Advanced Prediction mode as defined by H.263 [4]. "0" off, 
  389. "1" on.
  390.  
  391. S: 1 bit
  392. Optional Syntax-based Arithmetic Code mode as defined by the H.263 [4]. 
  393. 0" off, "1" on.
  394.  
  395. R: 2 bits
  396. Reserved, must be set to zero.
  397.  
  398. DBQ: 2 bits
  399. Differential quantization parameter to calculate quantizer for the B 
  400. frame based on quantizer for the P frame, when PB frame option is on. 
  401. The value should be the same as DBQUANT defined by the H.263 [4]. Set 
  402. to zero if PB frame option is off.
  403.  
  404.  
  405.  
  406.  
  407. Zhu                                                             [Page 7]
  408.  
  409.  
  410. Internet Draft         RTP Payload for H.263           November 25, 1996
  411.  
  412. TRB: 3 bits
  413. Temporal Reference for the B frame as defined by the H.263 [4]. Set to 
  414. zero if PB frame option is off.
  415.  
  416. TR: 8 bits
  417. Temporal Reference for the P frame as defined by the H.263 [4]. Set to 
  418. zero if the PB frame option is off.
  419.  
  420. 5.2 Mode B
  421.  
  422. In this mode, the H.263 stream can be fragmented at MB boundaries. Thus 
  423. necessary information is needed at the start of a packet to recover 
  424. the decoder internal state in the presence of packet loss. It is 
  425. intended for those GOBs whose sizes are larger than the maximum packet 
  426. size allowed in the underlying protocol. This mode can only 
  427. be used with PB frame option off. Mode C as defined in the next section 
  428. can be used to fragment at MB boundaries with PB frame option on. The 
  429. H.263 payload header definition for Mode B is shown as follows with 
  430. F=1 and P=0:
  431.  
  432.  
  433.  0                   1                   2                   3
  434.  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
  435. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  436. |V  |F|P|I|SBIT |EBIT | SRC | QUANT   |  GOBN   |   MBA         |
  437. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  438. |U|A|S|R| HMV1        | VMV1        | HMV2        | VMV2        |
  439. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  440.  
  441.  
  442.  
  443. The following fields are defined the same as in Mode A: F, P, SBIT, 
  444. EBIT, SRC, I, A, S, V and U. Other fields are defined as follows:
  445.  
  446. QUANT: 5 bits
  447. Quantization value for the first MB coded at the starting of the packet.  
  448. Set to 0 if the packet begins with a GOB header. This is the equivalent 
  449. of GQUANT defined by the H.263 [4].
  450.  
  451. GOBN: 5 bits
  452. GOB number in effect at the start of the packet. GOB number is specified
  453. differently for different resolutions. See H.263 [4] for details.
  454.  
  455. MBA: 8 bits
  456. The absolute address of the first MB within its GOB, counting from 0.
  457.  
  458. HMV1, VMV1: 7 bits each.
  459. Horizontal and vertical motion vector predictors for the first MB coded 
  460. in this packet from the MB on the left. The same as MV1 defined by 
  461. H.263 [4]. 
  462.  
  463.  
  464.  
  465. Zhu                                                             [Page 8]
  466.  
  467.  
  468. Internet Draft        RTP Payload for H.263            November 25, 1996
  469.  
  470. HMV2, VMV2, 7 bits each.
  471. Horizontal and vertical motion vector predictors from the block or MB 
  472. on the left of block number 3 in the current MB when advanced prediction
  473. option is on. They are the same as MV1 defined for block number 3 in 
  474. H.263 [4]. This is needed because block number 3 in the first MB needs 
  475. the motion vector predictor from the block to its left, as block number 
  476. 1. These two fields are not used when advanced prediction is off and 
  477. must be set to 0. See the H.263 [4] for block organization in a frame.
  478.  
  479. R: 1 bit                      
  480. Reserved, must set to zero.
  481.  
  482. 5.3 Mode C
  483.                 
  484. In this mode, H.263 stream can be fragmented at MB boundaries of P 
  485. frames when the PB frame option is on. It is intended for those GOBs 
  486. whose sizes are larger than the maximum packet size allowed in the 
  487. underlying protocol. H.263 payload header definition for 
  488. Mode C is shown as follows with F=1 and P=1:
  489.  
  490.  0                   1                   2                   3
  491.  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
  492. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  493. |V  |F|P|I|SBIT |EBIT | SRC | QUANT   |  GOBN   |   MBA         |
  494. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  495. |U|A|S|R| HMV1        | VMV1        | HMV2        | VMV2        |
  496. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  497. | RR                                  |DBQ| TRB |    TR         | 
  498. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  499.  
  500.  
  501.  
  502. The following fields are defined the same as in Mode A: F, P, SBIT, 
  503. EBIT, SRC, I, A, S, U, V, R, TR, DBQ, TRB, and the rest of the fields 
  504. are defined the same as in Mode B, except field RR of 19 bits is 
  505. reserved and its value must be zero.
  506.  
  507. 5.4 Selection of Modes for the H.263 Payload Header
  508.  
  509. Packets with different modes can be intermixed. The modes shall be 
  510. selected carefully based on performance characteristics, H.263 coding 
  511. modes and underlying network protocols.
  512.  
  513. We strongly recommend use of Mode A whenever possible. The major 
  514. advantage of Mode A over Mode B and C is its simplicity. The header is 
  515. one half and one third of the size of Mode B and C respectively. 
  516. Transmission overhead is reduced and the savings may be very 
  517. significant when working with very low bit rates, especially when low 
  518. latency is desired.
  519.  
  520.  
  521.  
  522.  
  523. Zhu                                                             [Page 9]
  524.  
  525.  
  526. Internet Draft         RTP Payload for H.263           November 25, 1996
  527.  
  528.  
  529. Another advantage of Mode A is that it simplifies error recovery in the
  530. presence of packet loss. The internal state of the decoder can be 
  531. recovered at GOB boundaries instead of having to synchronize with MBs 
  532. as in Mode B and C. The GOB headers and the picture start code are 
  533. easy to identify,  and their presence will normally cause the H.263 
  534. decoder to re-synchronize its internal states. Requiring the decoder to 
  535. synchronize its internal states at MBs introduces extra overhead and 
  536. complexity for the decoder.
  537.  
  538. Mode A shall be used for packets starting with a GOB of size smaller 
  539. than the network packet size. The major disadvantage of Mode A is lack 
  540. of flexibility in packetization when a GOB can not fit in a network 
  541. packet. 
  542.  
  543. Mode B has the advantage of flexibility with fragmentation at MB 
  544. boundaries with PB frame option off. This mode is necessary when a 
  545. GOB is larger than the network packet size. It has the disadvantage of 
  546. higher overhead with a long header of 8 bytes. For small packets, this 
  547. may not be desirable. Mode C is the same as B, except it allows 
  548. fragmentation with PB option on at the price of 4 additional bytes.
  549.  
  550. Finally, we would like to emphasize that recovery from packet loss 
  551. will depend on the decoder's ability to use the information provided 
  552. in the H.263 payload header within the RTP packets.
  553.  
  554. 6. References
  555.  
  556. [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 
  557.     RTP : A Transport Protocol for Real-Time Applications, RFC 1889. 
  558.      
  559.  
  560. [2] Video Codec for Audiovisual Services at  px64 kbits/s, ITU-T 
  561.     Recommendation H.261, 1993
  562.  
  563. [3] RTP Profile for Audio and Video Conference with Minimal Control, 
  564.     RFC 1890.
  565.  
  566. [4] Video Coding for Low Bitrate Communication, ITU-T Recommendation 
  567.     H.263, 1995
  568.  
  569. [5] T. Turletti, C. Huitema, RTP Payload Format for H.261 Video Stream. 
  570.     RFC 2032. 
  571.  
  572. 7. Author's Address
  573.  
  574. Chunrong "Chad"  Zhu
  575. Mail Stop: JF2-78
  576. Intel Corporation
  577. 2111 N.E. 25th Avenue
  578. Hillsboro, OR 97124
  579. USA
  580.  
  581. Zhu                                                            [Page 10]
  582.  
  583.  
  584. Internet Draft         RTP Payload for H.263           November 25, 1996
  585.  
  586.  
  587. Email: czhu@ibeam.intel.com 
  588. Tel: (503) 264-8849
  589. Fax: (503) 264-6067
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638. Zhu                                                            [Page 11]
  639.  
  640.