Network Working Group M. Civanlar
Request for Comments: 2448 G. Cash
Category: Informational B. Haskell
AT&T Labs-Research
November 1998
Network Working Group M. Civanlar
Request for Comments: 2448 G. Cash
Category: Informational B. Haskell
AT&T Labs-Research
November 1998
AT&T's Error Resilient Video Transmission Technique
AT&T的容错视频传输技术
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. The described techniques can be used over packet networks without packet prioritization. These techniques are related to AT&T/Lucent patents [1, 2].
本文档描述了一组基于重要信息承载段的可靠传输的压缩视频比特流的分组丢失弹性传输技术。所描述的技术可以在分组网络上使用，而无需分组优先级。这些技术与AT&T/Lucent专利有关[1,2]。
It is well known that every bit in a compressed video bitstream is not equal. Some bits belong to segments defining vital information such as picture types, quantization values, parameter ranges, average intensity values for image blocks, etc. When transporting compressed video bitstreams over packet networks, packet losses from such segments cause a much longer lasting and severe degradation on the output of a decoder than that caused by packet losses from other segments. We will call the vital information-carrying segments "High Priority (HP)" segments. The rest of the bitstream consists of "Low Priority (LP)" segments. Clearly, the video outputs resulting from transport techniques that protect the HP segments against packet losses are more resilient to packet losses in general.
众所周知，压缩视频比特流中的每一位都是不相等的。当通过分组网络传输压缩视频比特流时，一些比特属于定义重要信息的段，例如图片类型、量化值、参数范围、图像块的平均强度值等，与来自其他段的分组丢失相比，来自这些段的分组丢失对解码器的输出造成更持久和严重的退化。我们将重要信息承载部分称为“高优先级（HP）”部分。比特流的其余部分由“低优先级（LP）”段组成。显然，由保护HP段免受数据包丢失的传输技术产生的视频输出通常对数据包丢失更具弹性。
Protection of the HP segments can be accomplished in many ways. These include:
HP段的保护可以通过多种方式实现。这些措施包括：
- redundant transmission of the HP segments as described in [3] for MPEG RTP payloads
- [3]中所述的MPEG RTP有效载荷的HP段冗余传输
- using forward error correction (FEC) techniques - transmitting HP segments over reserved channels or using differentiated services.
- 使用前向纠错（FEC）技术-通过保留信道或使用区分服务传输HP段。
Both redundant transmission and FEC techniques increase the bandwidth needed to transmit the compressed video bitstream. FEC techniques increase the effectiveness of this additional bandwidth for packet loss protection at the expense of increased processing at the receiver and the transmitter ends and increased overall delay. Using channel reservations or differentiated services based approaches may be the best solutions for protecting the HP segments but, they require network infrastructure changes.
冗余传输和FEC技术都增加了传输压缩视频比特流所需的带宽。FEC技术增加了用于分组丢失保护的该额外带宽的有效性，代价是增加了接收机和发射机端的处理以及增加了总延迟。使用渠道预订或基于差异化服务的方法可能是保护HP细分市场的最佳解决方案，但它们需要更改网络基础架构。
This document outlines another set of HP segment protection techniques based on AT&T/Lucent patents [1, 2] that can be used for reliable video transmission over packet networks without a built-in prioritization mechanism. These techniques use reliable transport protocols and "out-of-band" delivery approaches. In this context, the term "out-of-band" is used to imply information transmission means other than those used for transmitting the main video stream. The details of these techniques are discussed in the following sections. An implementation of these, as applied to MPEG-2 video transmission over IP networks, is described in [4].
本文档概述了另一套基于AT&T/Lucent专利[1,2]的HP段保护技术，该技术可用于通过分组网络进行可靠的视频传输，而无需内置优先级机制。这些技术使用可靠的传输协议和“带外”交付方法。在该上下文中，术语“带外”用于暗示除用于传输主视频流的那些之外的信息传输装置。这些技术的细节将在以下章节中讨论。[4]中描述了这些应用于IP网络上的MPEG-2视频传输的实现。
The IESG/IETF take no position regarding the validity or scope of any intellectual property right or other rights that might be claimed to pertain to the implementation or use of the technology, or the extent to which any license under such rights might or might not be available. See the IETF IPR web page at http://www.ietf.org/ipr.html for any additional information that has been forwarded to the IETF.
IESG/IETF对可能声称与技术实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场。参见IETF IPR网页，网址为http://www.ietf.org/ipr.html 对于已转发给IETF的任何附加信息。
The classification of a part of a video bitstream as an HP segment depends on two factors. The first one is the encoding algorithm used in compressing the video data. It is impossible to segment a compressed video bitstream without knowing the syntax and the semantics of the encoding algorithm. The second factor is the determination of a compromise between the HP segment size and the corresponding loss resilience. As the segment size increases, so does the loss resilience. On the other hand, it may not be feasible to deliver large HP segments reliably.
将视频比特流的一部分分类为HP段取决于两个因素。第一种是用于压缩视频数据的编码算法。在不了解编码算法的语法和语义的情况下，不可能分割压缩视频比特流。第二个因素是确定惠普细分市场规模与相应损失恢复能力之间的折衷。随着细分市场规模的增加，损失弹性也随之增加。另一方面，可靠地提供大型HP细分市场可能不可行。
As an example, the "data partitioning" method of the MPEG-2 standard [5] defines the syntax and semantics for one particular way of partitioning an MPEG-2 encoded video bitstream into HP and LP segments. In data partitioning, the smallest useful HP segment can be selected to contain only the header information, which is usually
例如，MPEG-2标准[5]的“数据划分”方法定义了将MPEG-2编码的视频比特流划分为HP和LP段的一种特定方法的语法和语义。在数据分区中，可以选择最小的有用HP段，以仅包含标题信息，通常是
less than two percent of the video data. HP segments defined this way contain vital information including picture type, quantization factor, motion vector ranges, etc. without which the rest of the bitstream is not decodable. As an alternative, the DC coefficients (the average values) for each picture macroblock may be included in the HP segment increasing its size to about 40% of the bitstream. This way HP segments can be made to carry somewhat usable video information also; however, their reliable transmission may become a demanding task.
少于视频数据的百分之二。以这种方式定义的HP段包含重要信息，包括图片类型、量化因子、运动矢量范围等。如果没有这些信息，比特流的其余部分将无法解码。作为替代方案，每个图片宏块的DC系数（平均值）可以包括在HP段中，将其大小增加到比特流的约40%。通过这种方式，HP片段也可以携带一些有用的视频信息；然而，它们的可靠传输可能成为一项艰巨的任务。
Since it is not possible to formulate a general technique that can be used for identifying the HP segments in any encoded video bitstream, we will assume that such segments are identified some way prior to the transmission. For example, some encoders can generate HP and LP segments separately, a stored bitstream can be in the partitioned format, etc. Also, consistent with most of the popular coding techniques, we assume that the HP segments (HP1, HP2, ...) are dispersed on the entire bitstream over time as shown in Fig. 1.
由于不可能制定可用于识别任何编码视频比特流中的HP段的一般技术，因此我们将假设在传输之前以某种方式识别这些段。例如，一些编码器可以分别生成HP和LP段，存储的比特流可以是分区格式，等等。此外，与大多数流行的编码技术一致，我们假设HP段（HP1、HP2，…）随着时间的推移分散在整个比特流上，如图1所示。
+---+----------------+---+----------------------+---+-----
|HP1| LP1 |HP2| LP2 |HP3| ...
+---+----------------+---+----------------------+---+-----
Figure 1
HP segments dispersed on an encoded video bitstream over time
+---+----------------+---+----------------------+---+-----
|HP1| LP1 |HP2| LP2 |HP3| ...
+---+----------------+---+----------------------+---+-----
Figure 1
HP segments dispersed on an encoded video bitstream over time
In this approach, one or more of the HP segments are transmitted using a reliable transport protocol prior to starting the transmission of the LP segments. For point-to-point applications, TCP, for multipoint applications, an appropriate reliable multicast protocol [6] may be used for transporting the HP segments. The number of HP segments to be sent before starting the transmission of the LP segments depends on the application's tolerance to the start-up delay. Depending on the HP segment size and the path-MTU [7], one or more HP segments can be put in each packet carrying the HP data.
在该方法中，在开始传输LP段之前，使用可靠传输协议传输一个或多个HP段。对于点对点应用，TCP，对于多点应用，可以使用适当的可靠多播协议[6]来传输HP段。在开始传输LP段之前要发送的HP段的数量取决于应用程序对启动延迟的容忍度。根据HP段大小和路径MTU[7]，可以在每个携带HP数据的数据包中放入一个或多个HP段。
HP segments can be packetized using RTP with the following definitions for the header fields:
HP段可以使用RTP进行打包，标题字段的定义如下：
Payload Type: A distinct payload type number, which may be dynamic, should be assigned to HP segments of each video payload.
有效负载类型：应为每个视频有效负载的HP段分配一个不同的有效负载类型编号，该编号可能是动态的。
M Bit: Set for packets containing HP data for key pictures.
M位：为包含关键图片HP数据的数据包设置。
timestamp: Uses the same format as that of the video payload. Shows the sampling time for the video data following the first HP segment in the packet.
时间戳：使用与视频有效负载相同的格式。显示数据包中第一个HP段之后的视频数据的采样时间。
The SSRC field may be defined following the rules developed for the transmission of layered media streams in [8]. That is:
SSRC字段可以按照[8]中为传输分层媒体流而制定的规则定义。即:
- A single SSRC space is used for the HP segment packets and the main video stream. Only the latter is used for SSRC allocation and conflict resolution. When a source discovers that it has collided, it transmits an RTCP BYE message on only the main video stream.
- 单个SSRC空间用于HP段数据包和主视频流。只有后者用于SSRC分配和冲突解决。当源发现冲突时，它仅在主视频流上传输RTCP BYE消息。
- A participant sends sender identification (SDES) on only the main video stream.
- 参与者仅在主视频流上发送发送者标识（SDES）。
Most HP segments are self-identifying and can be packed without any additional headers. For others, techniques used for packetizing generic payload types may be used or special payload types may be defined.
大多数HP段都是自识别的，可以打包而无需任何附加标题。对于其他情况，可以使用用于将通用有效载荷类型打包的技术，或者可以定义特殊有效载荷类型。
It is possible to send the HP data along with the LP data (i.e., the original, unpartitioned bitstream) in addition to sending the HP segments separately. This way, the separately transmitted HP segments are needed only when packet losses occur.
除了单独发送HP段外，还可以将HP数据与LP数据（即原始的未分割比特流）一起发送。这样，仅当发生数据包丢失时才需要单独传输的HP段。
In cases where a certain sequence of HP segments is used periodically for the entire duration of the video bitstream, this sequence may be transmitted once before the start of video transmission using a reliable transport protocol. The receiver can save this information and use it to recover lost HP segments during the main video transmission.
在视频比特流的整个持续时间内周期性地使用特定HP段序列的情况下，可以使用可靠传输协议在视频传输开始之前发送该序列一次。接收器可以保存此信息，并使用它恢复主视频传输期间丢失的HP片段。
In this approach, the timestamps are not meaningful for the HP data and they may not be included in the transmitted HP segment sequence. In most cases, the synchronization between the stored HP segments and the LP data stream can be accomplished using the key-frames because the HP data sequence usually cover the video segment between two key-frames (e.g. a group-of-pictures (GOP) in MPEG). If the sequence of HP segments covers a video sequence with more than one key-frame, some indicator, e.g. if available the M-bit may be used to indicate a packet which carries the beginning of LP data that follows the first stored HP segment.
在这种方法中，时间戳对于HP数据没有意义，并且它们可能不包括在传输的HP段序列中。在大多数情况下，存储的HP段和LP数据流之间的同步可以使用关键帧来实现，因为HP数据序列通常覆盖两个关键帧（例如MPEG中的一组图片（GOP））之间的视频段。如果HP段序列包括具有多个关键帧的视频序列，则某些指示符（例如，如果可用）可用于指示在第一个存储的HP段之后携带LP数据开头的数据包。
RTP packets transmitted according to the techniques outlined in this document are subject to the security considerations discussed in the RTP specification [9]. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used is applied end-to-end, encryption may be performed after compression
根据本文件中概述的技术传输的RTP数据包受RTP规范[9]中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的。因为所使用的数据压缩是端到端应用的，所以可以在压缩之后执行加密
so there is no conflict between the two operations. For certain coding techniques and applications, encrypting only the HP segments may provide sufficent confidentiality.
因此，这两个操作之间没有冲突。对于某些编码技术和应用程序，仅加密HP段可能提供足够的保密性。
The described techniques do not introduce any significant additional non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat.
所描述的技术不会在用于分组处理的接收器侧计算复杂性中引入任何显著的额外非均匀性，从而导致潜在的拒绝服务威胁。
References
工具书类
[1] Glenn L. Cash, Mehmet R. Civanlar, "Method Of And Apparatus For The Transmission Of High And Low Priority Segments Of A Video Bitstream Over Packet Networks," United States Patent Number: 5,481,312, Jan. 2, 1996.
[1] Glenn L.Cash，Mehmet R.Civanlar，“通过分组网络传输视频比特流的高优先级和低优先级段的方法和装置”，美国专利号：5481312，1996年1月2日。
[2] Glenn L. Cash, Mehmet R. Civanlar, "Video Bitstream Regeneration Using Previously Agreed To High Priority Segments," United States Patent Number: 5,510,844, April 23, 1996.
[2] Glenn L.Cash，Mehmet R.Civanlar，“使用先前同意的高优先级段的视频比特流再生”，美国专利号：55108441996年4月23日。
[3] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, April 1997.
[3] Hoffman，D.，Fernando，G.，Goyal，V.和M.Civanlar，“MPEG1/MPEG2视频的RTP有效载荷格式”，RFC 2250，1997年4月。
[4] M. R. Civanlar, G. L. Cash, "A practical system for MPEG-2 based video-on-demand over ATM packet networks and the WWW," Signal Processing: Image Communication, no. 8, pp. 221-227, Elsevier, 1996.
[4] M.R.Civanlar，G.L.Cash，“ATM分组网络和WWW上基于MPEG-2的视频点播实用系统”，信号处理：图像通信，第8期，第221-227页，Elsevier，1996年。
[5] ISO/IEC International Standard 13818; "Generic coding of moving pictures and associated audio information," November 1994.
[5] ISO/IEC国际标准13818；“运动图像和相关音频信息的通用编码”，1994年11月。
[6] Overview of Reliable Multicast Protocols Web Page, URL http://gaia.cs.umass.edu/sigcomm_mcast/talk1.html.
[6] 可靠多播协议概述网页、URLhttp://gaia.cs.umass.edu/sigcomm_mcast/talk1.html.
[7] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[7] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[8] M. F. Speer, S. McCanne, "RTP Usage with Layered Multimedia Streams", Work in Progress.
[8] M.F.Speer，S.McCanne，“分层多媒体流的RTP使用”，正在进行中。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[9] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
Authors' Addresses
作者地址
M. Reha Civanlar AT&T Labs-Research 100 Schultz Drive Red Bank, NJ 07701 USA
M.Reha Civanlar AT&T实验室研究中心，美国新泽西州红银行舒尔茨大道100号，邮编：07701
EMail: civanlar@research.att.com
EMail: civanlar@research.att.com
Glenn L. Cash AT&T Labs-Research 100 Schultz Drive Red Bank, NJ 07701 USA
美国新泽西州红银行舒尔茨大道100号Glenn L.Cash AT&T实验室研究中心07701
EMail: glenn@research.att.com
EMail: glenn@research.att.com
Barry G. Haskell AT&T Labs-Research 100 Schultz Drive Red Bank, NJ 07701 USA
Barry G.Haskell AT&T实验室研究所，美国新泽西州红银行舒尔茨大道100号，邮编：07701
EMail: bgh@research.att.com
EMail: bgh@research.att.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。