idnits 2.17.1 draft-civanlar-hplp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 201 looks like a reference -- Missing reference section? '2' on line 206 looks like a reference -- Missing reference section? '3' on line 210 looks like a reference -- Missing reference section? '4' on line 213 looks like a reference -- Missing reference section? '5' on line 217 looks like a reference -- Missing reference section? '6' on line 220 looks like a reference -- Missing reference section? '7' on line 223 looks like a reference -- Missing reference section? '8' on line 225 looks like a reference -- Missing reference section? '9' on line 229 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Reha Civanlar 3 INTERNET-DRAFT Glenn L. Cash 4 File: draft-civanlar-hplp-00.txt Barry G. Haskell 6 AT&T Labs-Research 8 July, 1998 10 AT&T's Error Resilient Video Transmission Technique 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 27 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 28 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Distribution of this memo is unlimited. 32 Abstract 34 This document describes a set of techniques for packet loss resilient 35 transmission of compressed video bitstreams based on reliable delivery 36 of their vital information-carrying segments. The described techniques 37 can be used over packet networks without packet prioritization. These 38 techniques are related to AT&T/Lucent patents [1, 2]. 40 1. Introduction 42 It is well known that every bit in a compressed video bitstream is not 43 equal. Some bits belong to segments defining vital information such as 44 picture types, quantization values, parameter ranges, average 45 intensity values for image blocks, etc. When transporting compressed 46 video bitstreams over packet networks, packet losses from such 47 segments cause a much longer lasting and severe degradation on the 48 output of a decoder than that caused by packet losses from other 49 segments. We will call the vital information-carrying segments "High 50 Priority (HP)" segments. The rest of the bitstream consists of "Low 51 Priority (LP)" segments. Clearly, the video outputs resulting from 52 transport techniques that protect the HP segments against packet 53 losses are more resilient to packet losses in general. 55 Protection of the HP segments can be accomplished in many ways. These 56 include: 57 - redundant transmission of the HP segments as described 58 in [3] for MPEG RTP payloads 59 - using forward error correction (FEC) techniques 60 - transmitting HP segments over reserved channels or using 61 differentiated services. 62 Both redundant transmission and FEC techniques increase the bandwidth 63 needed to transmit the compressed video bitstream. FEC techniques 64 increase the effectiveness of this additional bandwidth for packet loss 65 protection at the expense of increased processing at the receiver and 66 the transmitter ends and increased overall delay. Using channel 67 reservations or differentiated services based approaches may be the 68 best solutions for protecting the HP segments but, they require network 69 infrastructure changes. 71 This document outlines another set of HP segment protection techniques 72 based on AT&T/Lucent patents [1, 2] that can be used for reliable video 73 transmission over packet networks without a built-in prioritization 74 mechanism. These techniques use reliable transport protocols and "out- 75 of-band" delivery approaches. In this context, the term "out-of-band" 76 is used to imply information transmission means other than those used 77 for transmitting the main video stream. The details of these 78 techniques are discussed in the following sections. An implementation 79 of these, as applied to MPEG-2 video transmission over IP networks, is 80 described in [4]. 82 2. Identification of the HP segments 84 The classification of a part of a video bitstream as an HP segment 85 depends on two factors. The first one is the encoding algorithm used 86 in compressing the video data. It is impossible to segment a compressed 87 video bitstream without knowing the syntax and the semantics of the 88 encoding algorithm. The second factor is the determination of a 89 compromise between the HP segment size and the corresponding loss 90 resilience. As the segment size increases, so does the loss resilience. 91 On the other hand, it may not be feasible to deliver large HP segments 92 reliably. 94 As an example, the "data partitioning" method of the MPEG-2 standard 95 [5] defines the syntax and semantics for one particular way of 96 partitioning an MPEG-2 encoded video bitstream into HP and LP segments. 97 In data partitioning, the smallest useful HP segment can be selected to 98 contain only the header information, which is usually less than two 99 percent of the video data. HP segments defined this way contain vital 100 information including picture type, quantization factor, motion vector 101 ranges, etc. without which the rest of the bitstream is not decodable. 102 As an alternative, the DC coefficients (the average values) for each 103 picture macroblock may be included in the HP segment increasing its 104 size to about 40% of the bitstream. This way HP segments can be made 105 to carry somewhat usable video information also; however, their 106 reliable transmission may become a demanding task. 108 Since it is not possible to formulate a general technique that can be 109 used for identifying the HP segments in any encoded video bitstream, we 110 will assume that such segments are identified some way prior to the 111 transmission. For example, some encoders can generate HP and LP 112 segments separately, a stored bitstream can be in the partitioned 113 format, etc. Also, consistent with most of the popular coding 114 techniques, we assume that the HP segments (HP1, HP2, ...) are 115 dispersed on the entire bitstream over time as shown in Fig. 1. 117 +---+----------------+---+----------------------+---+----- 118 |HP1| LP1 |HP2| LP2 |HP3| ... 119 +---+----------------+---+----------------------+---+----- 121 Figure 1 - HP segments dispersed on an encoded video bitstream over time 123 3. Transmission of HP data using a reliable transport protocol [1] 125 In this approach, one or more of the HP segments are transmitted using 126 a reliable transport protocol prior to starting the transmission of the 127 LP segments. For point-to-point applications, TCP, for multipoint 128 applications, an appropriate reliable multicast protocol [6] may be 129 used for transporting the HP segments. The number of HP segments to be 130 sent before starting the transmission of the LP segments depends on the 131 application's tolerance to the start-up delay. Depending on the HP 132 segment size and the path-MTU [7], one or more HP segments can be put 133 in each packet carrying the HP data. 135 HP segments can be packetized using RTP with the following definitions 136 for the header fields: 138 Payload Type: A distinct payload type number, which may be dynamic, 139 should be assigned to HP segments of each video payload. 141 M Bit: Set for packets containing HP data for key pictures. 143 timestamp: Uses the same format as that of the video payload. Shows 144 the sampling time for the video data following the first HP segment 145 in the packet. 147 The SSRC field may be defined following the rules developed for the 148 transmission of layered media streams in [8]. That is: 149 - A single SSRC space is used for the HP segment packets and the main 150 video stream. Only the latter is used for SSRC allocation and conflict 151 resolution. When a source discovers that it has collided, it transmits 152 an RTCP BYE message on only the main video stream. 154 - A participant sends sender identification (SDES) on only the main 155 video stream. 157 Most HP segments are self-identifying and can be packed without any 158 additional headers. For others, techniques used for packetizing generic 159 payload types may be used or special payload types may be defined. 161 It is possible to send the HP data along with the LP data (i.e., the 162 original, unpartitioned bitstream) in addition to sending the HP 163 segments separately. This way, the separately transmitted HP segments 164 are needed only when packet losses occur. 166 4. Out-of-band transmission of the HP information [2] 168 In cases where a certain sequence of HP segments is used periodically 169 for the entire duration of the video bitstream, this sequence may be 170 transmitted once before the start of video transmission using a reliable 171 transport protocol. The receiver can save this information and use it to 172 recover lost HP segments during the main video transmission. 174 In this approach, the timestamps are not meaningful for the HP data and 175 they may not be included in the transmitted HP segment sequence. In most 176 cases, the synchronization between the stored HP segments and the LP 177 data stream can be accomplished using the key-frames because the HP data 178 sequence usually cover the video segment between two key-frames (e.g. a 179 group-of-pictures (GOP) in MPEG). If the sequence of HP segments covers 180 a video sequence with more than one key-frame, some indicator, e.g. if 181 available the M-bit may be used to indicate a packet which carries the 182 beginning of LP data that follows the first stored HP segment. 184 5. Security considerations 186 RTP packets transmitted according to the techniques outlined in this 187 document are subject to the security considerations discussed in the RTP 188 specification [9]. This implies that confidentiality of the media 189 streams is achieved by encryption. Because the data compression used is 190 applied end-to-end, encryption may be performed after compression so 191 there is no conflict between the two operations. For certain coding 192 techniques and applications, encrypting only the HP segments may provide 193 sufficent confidentiality. 195 The described techniques do not introduce any significant additional 196 non-uniformity in the receiver side computational complexity for packet 197 processing to cause a potential denial-of-service threat. 199 References: 201 [1] Glenn L. Cash, Mehmet R. Civanlar, "Method Of And Apparatus For 202 The Transmission Of High And Low Priority Segments Of A Video 203 Bitstream Over Packet Networks," United States Patent Number: 204 5,481,312, Jan. 2, 1996. 206 [2] Glenn L. Cash, Mehmet R. Civanlar, "Video Bitstream Regeneration 207 Using Previously Agreed To High Priority Segments," United States 208 Patent Number: 5,510,844, April 23, 1996. 210 [3] D.Hoffman, G. Fernando, V. Goyal, M. R. Civanlar, "RTP Payload Format 211 for MPEG1/MPEG2 Video," RFC 2250, April 1997. 213 [4] M. R. Civanlar, G. L. Cash, "A practical system for MPEG-2 based 214 video-on-demand over ATM packet networks and the WWW," Signal 215 Processing: Image Communication, no. 8, pp. 221-227, Elsevier, 1996. 217 [5] ISO/IEC International Standard 13818; "Generic coding of moving 218 pictures and associated audio information," November 1994. 220 [6] Overview of Reliable Multicast Protocols Web Page, 221 URL http://gaia.cs.umass.edu/sigcomm_mcast/talk1.html. 223 [7] J. Mogul, S. Deering, "Path MTU Discovery," RFC 1191, November 1990. 225 [8] M. F. Speer, S. McCanne, "RTP Usage with Layered Multimedia 226 Streams," Internet Draft, draft-speer-avt-layered-video-02.txt, 227 December 1996. 229 [9] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, 230 "RTP: A Transport Protocol for Real-Time Applications," 231 RFC 1889, January 1996. 233 Author's Address: 235 M. Reha Civanlar 236 Glenn L. Cash 237 Barry G. Haskell 239 AT&T Labs-Research 240 100 Schultz Drive 241 Red Bank, NJ 07701 242 USA 244 e-mail: civanlar|glenn|bgh@research.att.com