[要約] 要約:RFC 2448は、AT&Tのエラー耐性ビデオ伝送技術に関する規格であり、ビデオストリームの品質を向上させるための手法を提案しています。目的:このRFCの目的は、ビデオ伝送中のエラーに対処するための効果的な技術を提供し、ビデオストリームの信頼性と品質を向上させることです。

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.

Copyright(C)The Internet Society(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 /ルーセントの特許に関連しています[1、2]。

1. Introduction
1. はじめに

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

- MPEG RTPペイロードの[3]で説明されている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 /ルーセントの特許に基づくHPセグメント保護技術の別のセットについて概説します[1、2]。これは、組み込みの優先順位付けメカニズムなしで、パケットネットワークを介した信頼性の高いビデオ伝送に使用できます。これらの技術は、信頼性の高いトランスポートプロトコルと「帯域外」配信アプローチを使用します。この文脈では、「帯域外」という用語は、メインビデオストリームの送信に使用されるもの以外の情報送信手段を意味するために使用されます。これらの手法の詳細については、次のセクションで説明します。 IPネットワークを介したMPEG-2ビデオ伝送に適用されるこれらの実装は、[4]で説明されています。

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に転送された追加情報については、http://www.ietf.org/ipr.htmlのIETF IPR Webページを参照してください。

2. Identification of the HP segments
2. HPセグメントの識別

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セグメントとして分類することは、2つの要因に依存します。 1つ目は、ビデオデータの圧縮に使用されるエンコードアルゴリズムです。エンコードアルゴリズムの構文とセマンティクスを知らずに、圧縮されたビデオビットストリームをセグメント化することは不可能です。 2番目の要因は、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 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.

例として、MPEG-2標準[5]の「データ分割」方法は、MPEG-2エンコードビデオビットストリームをHPセグメントとLPセグメントに分割する特定の方法の構文とセマンティクスを定義します。データ分割では、最小の有用なHPセグメントを選択して、通常はビデオデータの2%未満であるヘッダー情報のみを含めることができます。この方法で定義された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
        
3. Transmission of HP data using a reliable transport protocol [1]
3. 信頼性の高いトランスポートプロトコルを使用したHPデータの送信[1]

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セグメントの送信を開始する前に、1つ以上のHPセグメントが信頼できるトランスポートプロトコルを使用して送信されます。ポイントツーポイントアプリケーションの場合、TCP、マルチポイントアプリケーションの場合、HPセグメントの転送に適切な信頼性の高いマルチキャストプロトコル[6]を使用できます。 LPセグメントの送信を開始する前に送信されるHPセグメントの数は、起動遅延に対するアプリケーションの許容度によって異なります。 HPセグメントサイズとパスMTU [7]に応じて、HPデータを運ぶ各パケットに1つ以上の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.

- HPセグメントパケットとメインビデオストリームには、単一のSSRCスペースが使用されます。後者のみが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セグメントを個別に送信することに加えて、LPデータ(つまり、元のパーティション化されていないビットストリーム)とともにHPデータを送信することが可能です。このように、個別に送信されたHPセグメントは、パケット損失が発生した場合にのみ必要です。

4. Out-of-band transmission of the HP information [2]
4. HP情報の帯域外送信[2]

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ビットセグメントの特定のシーケンスがビデオビットストリームの全期間にわたって定期的に使用される場合、このシーケンスは、信頼性の高いトランスポートプロトコルを使用してビデオ送信の開始前に1回送信されます。レシーバーはこの情報を保存し、メインビデオ伝送中に失われた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データシーケンスは通常2つのキーフレーム間のビデオセグメントをカバーするため、保存されたHPセグメントとLPデータストリーム間の同期はキーフレームを使用して実行できます(たとえば、グループオブピクチャー(GOP)。 MPEG)。 HPセグメントのシーケンスが複数のキーフレームを持つビデオシーケンスをカバーする場合、いくつかのインジケーター(例:利用可能な場合、Mビットは、最初に保存されたHPセグメントに続くLPデータの始まりを運ぶパケットを示すために使用できます。

5. Security Considerations
5. セキュリティに関する考慮事項

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 so there is no conflict between the two operations. For certain coding techniques and applications, encrypting only the HP segments may provide sufficent confidentiality.

このドキュメントで概説されている手法に従って送信されたRTPパケットは、RTP仕様[9]で説明されているセキュリティ上の考慮事項の対象となります。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。使用されるデータ圧縮はエンドツーエンドで適用されるため、2つの操作の間に競合が発生しないように、圧縮後に暗号化を実行できます。特定のコーディング手法とアプリケーションでは、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、「パケットネットワークを介したビデオビットストリームの高優先度セグメントと低優先度セグメントの伝送のための方法と装置」、米国特許番号:5,481,312、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、「以前に合意された高優先度セグメントを使用したビデオビットストリーム再生」、米国特許番号:5,510,844、1996年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、「RTP Payload Format for MPEG1 / MPEG2 Video」、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ベースのビデオオンデマンドのための実用的なシステム」、信号処理:画像通信、No。 8、pp.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] Reliable Multicast Protocols Webページの概要、URL http://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、「Path MTU Discovery」、RFC 1191、1990年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:A Transport Protocol for Real-Time Applications」、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 Labs-Research 100 Schultz Drive Red Bank、NJ 07701 USA

   EMail: civanlar@research.att.com
        

Glenn L. Cash AT&T Labs-Research 100 Schultz Drive Red Bank, NJ 07701 USA

Glenn L. Cash AT&T Labs-Research 100 Schultz Drive Red Bank、NJ 07701 USA

   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 Labs-Research 100 Schultz Drive Red Bank、NJ 07701 USA

   EMail: bgh@research.att.com
        

Full Copyright Statement

完全な著作権表示

Copyright (C) The Internet Society (1998). All Rights Reserved.

Copyright(C)The Internet Society(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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。