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