WebRTC のためのスケーラブル映像符号化（SVC）拡張

規範的ではないと明記されたセクションに加えて、この仕様のすべてのオーサリングガイドライン、図、例、および注記は規範的ではありません。この仕様のそれ以外のすべては規範的です。

この文書におけるキーワード してもよい、しなければならない、および するべきである は、 BCP 14 [RFC2119] [RFC8174] に記載されているとおり、ここに示すようにすべて大文字で表記されている場合に限って解釈されます。

この仕様は、単一の製品、すなわち、この仕様に含まれるインターフェイスを実装するユーザーエージェントに適用される適合基準を定義します。

アルゴリズムまたは特定の手順として記述された適合要件は、最終結果が同等である限り、どのような方法でも実装できます。特に、この仕様で定義されるアルゴリズムは理解しやすいことを意図したものであり、高い性能を意図したものではありません。

この仕様で定義される API を ECMAScript を使用して実装する実装は、 Web IDL 仕様 [WEBIDL] で定義される ECMAScript バインディングと整合する方法で実装しなければなりません。これは、この仕様がその仕様および用語を使用しているためです。

「simulcast envelope」という用語は、[WEBRTC] セクション 5.4.1 で定義されています。

この仕様は、[WEBRTC] で定義されるオブジェクト、メソッド、内部スロットおよび辞書を参照します。

スケーラブル映像符号化 (SVC) について、「single-session transmission」 (SST) および「multi-session transmission」(MST) という用語は、 [RFC6190] で定義されています。この仕様は SST のみをサポートし、 MST はサポートしません。

「Single Real-time Transport Protocol stream Single Transport」という用語 (SRST) は、 [RFC7656] セクション 3.7 で定義され、単一のトランスポート内ですべてのレイヤーを送信し、単一のリアルタイムトランスポートプロトコル (RTP) ストリームと同期ソース (SSRC) を使用する SVC 実装を指します。「Multiple RTP stream Single Transport」(MRST) という用語も、 [RFC7656] セクション 3.7 で定義され、単一のトランスポート内ですべてのレイヤーを送信し、各レイヤーに個別の SSRC を持つ複数の RTP ストリームを使用する実装を指します。この仕様は SRST のみをサポートし、MRST はサポートしません。SRST をサポートする RTP ペイロード仕様を持つコーデックには VP8 [RFC7741]、VP9 [VP9-PAYLOAD]、AV1 [AV1-RTP-SPEC]、H.264 [RFC6184] および H.265 [RFC7798] が含まれます。

「S モード」という用語は、複数のエンコードが同じ SSRC 上で送信されるスケーラビリティモードを指します。これには、"S2T1"、"S2T1h"、 "S2T2"、 "S2T2h"、"S2T3"、"S2T3h"、"S3T1"、"S3T1h"、"S3T2"、"S3T2h"、 "S3T3" および "S3T3h" の scalabilityMode 値が含まれます。

選択的転送ミドルボックス (SFM) という用語は、[RFC7667] のセクション 3.7 で定義されています。

この仕様は、RTCRtpEncodingParameters 辞書を拡張することで、SVC のエンコードパラメーターを構成できるようにします。

WebIDLpartial dictionary RTCRtpEncodingParameters {
             DOMString scalabilityMode;
};

scalabilityMode、型は DOMString: このメンバーは、送信側の kind が "video" の場合にのみ存在できます。存在する場合、このストリームで使用されるスケーラビリティモードの大文字と小文字を区別する識別子を示します。スケーラビリティモードはセクション 5 で定義されています。

[WEBRTC] は、 addTransceiver() (セクション 5.1) および setParameters() (セクション 5.2) におけるエラー処理について説明しており、サポートされていないエンコードパラメーターによる「hardware-encoder-error」を示すための RTCError の使用や、その他のエラーを含みます。無効な scalabilityMode 値が setParameters() または addTransceiver() に提供された場合、実装は規定された方法で RTCError およびその他のエラーを使用します。

[WEBRTC] セクション 5.1 は、 addTransceiver() 内の sendEncodings の検証について説明しています。 scalabilityMode を検証するには、 addTransceiver sendEncodings 検証手順の手順 3 の後に、次の手順を追加します:

sendEncodings が、codec 値 codec が存在し、かつ同じエンコードの scalabilityMode 値が codec でサポートされていないエンコードをいずれか含む場合、OperationError を throw します。
そうでなく、sendEncodings が、 scalabilityMode 値が kind の実装済み送信コーデックのリスト内のどのコーデックによってもサポートされていないエンコードをいずれか含む場合、OperationError を throw します。
sendEncodings に格納されている RTCRtpEncodingParameters が、値 true の active メンバーを持つエンコードを 1 個より多く含み、かつ sendEncodings が、 scalabilityMode 値が「S モード」を表し、かつ active メンバーの値が true であるエンコードをいずれか含む場合、 OperationError を throw します。

addTransceiver() および setCodecPreferences() メソッドが Offer/Answer ネゴシエーションの完了前に呼び出された場合、ネゴシエートされるコーデックおよびその能力は不明な場合があります。この状況では、 sendEncodings で構成された scalabilityMode 値は、最終的にネゴシエートされたコーデックでサポートされない場合があります。ただし、要求された scalabilityMode 値がサポートされているすべてのコーデックに対して無効である場合、または混合サイマルキャストトランスポートが要求された場合にのみエラーになります。

目的の scalabilityMode 値を適用できるようにするため、setCodecPreferences() を使用して、目的の構成をサポートするコーデックを優先するか、それらのコーデックのみを含めることができます。たとえば、空間サイマルキャストとともに時間スケーラビリティが必要な場合、 addTransceiver() が呼び出されるとき、 sendEncodings を、異なる解像度の複数のサイマルキャストストリームを送信し、それぞれのストリームが時間スケーラビリティを利用するように構成できます。VP8、VP9、AV1 コーデック実装のみが時間スケーラビリティをサポートしている場合、setCodecPreferences() を使用して H.264/AVC コーデックを Offer から削除でき、時間スケーラビリティをサポートするコーデックがネゴシエートされる可能性を高められます。

sendEncodings を使用して addTransceiver() により複数のサイマルキャストストリームの送信を要求する場合、「S モード」を要求することはできません。ブラウザーは、複数の SSRC と RID を持つサイマルキャストエンコードを送信するか、あるいは、すべてのサイマルキャストエンコードを単一の RTP ストリーム上で送信するようにのみ構成できます。両方のサイマルキャストトランスポート技術を同時に使用することは許可されません。

[WEBRTC] セクション 5.2 は、 setParameters() 内の parameters の検証について説明しています。操作が InvalidModificationError で拒否された promise を生じさせる条件のリスト (setParameters 検証手順の手順 6) に、次の条件を挿入します:

encodings が、codec 値 codec が存在する encoding をいずれか含み、その encoding の scalabilityMode 値が codec によってサポートされていない。
sender.[[SendCodecs]] が空であり、 encodings が、 scalabilityMode 値が kind の実装済み送信コーデックのリスト内のどのコーデックによってもサポートされていないエンコードをいずれか含む。
sender.[[SendCodecs]] が空ではなく、 encodings が、 scalabilityMode 値を sender.[[SendCodecs]] 内のどのコーデックでも満たせないエンコードをいずれか含む。
encodings が、値 true の active メンバーを持つエンコードを 1 個より多く含み、かつ encodings が、 scalabilityMode 値が「S モード」を表し、かつ active メンバーの値が true であるエンコードをいずれか含む。

"L1T1" スケーラビリティモードでは、setParameters() を使用して SVC エンコードをオフにできます。 "L1T1" が setParameters() を使用して設定された場合、 getParameters() への応答で返されます。

初回ネゴシエーションが完了する前は、 getParameters() は、addTransceiver() または setParameters() によって最後に設定されたとおり、 encodings 内の各エンコードの scalabilityMode 値を返します。 encodings 内のエンコードに scalabilityMode 値が提供されていなかった場合、または値が正常に設定されなかった場合、 getParameters() はそのエンコードについて scalabilityMode 値を返しません。

初回ネゴシエーションが完了した後、getParameters() は、初回ネゴシエーション前に値を持っていた encodings 内の各エンコードについて、現在構成されている scalabilityMode 値を返します。これは、 addTransceiver() または setParameters() で要求された値とは異なっていてもよいです。たとえば、ネゴシエーション中に選択されたコーデックに、目的の scalabilityMode 値をサポートするエンコーダーが含まれていない場合、ユーザーエージェントは別の値を選択してもよいです。構成が満足できるものでない場合、setParameters() を使用して変更できます。

addTransceiver() または setParameters() が encodings 内のエンコードについて scalabilityMode 値を提供しなかった場合、初回ネゴシエーションが完了した後、getParameters() は scalabilityMode 値を返さず、エンコーダーはそのエンコードの RTP ストリームについて、コーデックの既定の scalabilityMode を使用します。各コーデックの既定の scalabilityMode は実装依存です。既定の scalabilityMode は、時間スケーラビリティモードのいずれか (例: "L1T1"、"L1T2"、"L1T3" など) であるべきです。

このセクションは規範的ではありません。

SVC は、SFM などの会議サーバーが、参加者のデバイス特性および利用可能な帯域幅に基づいてレイヤーを選択的に転送するビデオ会議で最も頻繁に使用されます。このような環境では、アプリケーションは会議サーバーと送受信するコーデックをネゴシエートします。しかし、スケーラビリティモードは Offer/Answer ではネゴシエートされないため、アプリケーションはブラウザーおよび会議サーバーがどのスケーラビリティモードをサポートしているかを別の手段で判断する必要があります。

[Media-Capabilities] API により、スケーラブル映像符号化に対するエンコーダーおよびデコーダーのサポートを検出できます。scalabilityMode は、エンコーダーが scalabilityMode 値をサポートしているかどうかを照会するために使用され、それが「サポートされている」、「滑らかである」、および「電力効率が高い」かどうかを示します。

[Media-Capabilities] API は、空間スケーラビリティモードに対するデコーダーのサポートに関する情報も提供します。spatialScalability は、デコーダーが空間予測をサポートする能力を持つかどうかを示します。これには、現在の解像度とは異なる解像度のフレームを依存関係として使用する能力が必要です。spatialScalability が true に設定されている場合、デコーダーは、エンコーダーがサポートする任意の scalabilityMode 値をデコードできます。 spatialScalability が false に設定されているか存在しない場合、デコーダーは空間スケーラビリティモードをデコードできませんが、エンコーダーがサポートするそれ以外のすべての scalabilityMode 値をデコードできます。

アプリケーションが、使用可能なコーデックと scalabilityMode 値の組み合わせを特定したら、次に、これらの組み合わせのうちどれが SFM によってサポートされているかを判断する必要があります。これを処理する方法の 1 つは、SFM が転送できるコーデックとスケーラビリティモードの組み合わせを受信能力の形式で示すことです。 SFM の能力を受信した後、アプリケーションは、ブラウザーの RTCRtpSender と SFM の受信側がサポートするコーデックと scalabilityMode 値の積集合を計算できます。これは、ブラウザーの addTransceiver() および setParameters() メソッドに渡される引数を決定するために使用できます。

以下にいくつかの例を示します:

コーデックペイロードを解析する SFM は、スケーラビリティなしの H.264/AVC コーデックと、時間スケーラビリティを持つ VP8 コーデックのみをサポートする場合があります。一方、ブラウザーは、時間スケーラビリティを持つ VP8、時間および空間スケーラビリティを持つ VP9 と AV1、および時間スケーラビリティを持つ H.264/AVC をエンコードできる場合があります。この例では、SVC を使用しようとするアプリケーションは、時間スケーラビリティを持つ VP8 のみをエンコードできます。
SFM は、AV1 コーデックで "S2T1" および "S2T1h" スケーラビリティモードを使用する単一ストリームサイマルキャストのみをサポートする一方、ブラウザーは、 VP9 および AV1 の両方のコーデックで "S2T1"、"S2T1h"、"S3T1" および "S3T1h" モードを使用する単一ストリームサイマルキャストのエンコードをサポートする場合があります。この例では、アプリケーションは AV1 コーデックで最大 2 レイヤーの単一ストリームサイマルキャストのみを使用できます。アプリケーションが 3 レイヤーを利用することを望む場合、単一ストリームサイマルキャストの使用を断念し、代わりにマルチストリームサイマルキャストをネゴシエートすることを選択できます。

ブラウザーと SFM の能力の積集合を計算する際に、RTP ヘッダー拡張を考慮する必要がある状況があります。 SFM がコーデックペイロードを解析できない場合 (そのように設計されていないため、またはペイロードが暗号化されているため)、 RTP ヘッダー拡張 ([AV1-RTP-SPEC] の付録 A で定義される AV1 Dependency Descriptor など) のネゴシエーションが、 SFM が特定のコーデックを転送するために必要になる場合があります。これを考慮するため、コーデックの転送に必要な RTP ヘッダー拡張を SFM の受信能力に追加できます。その後、アプリケーションは、ブラウザーの RTCRtpSender と SFM の受信側によってサポートされるコーデック、ヘッダー拡張、および scalabilityMode 値の積集合を計算できます。

この仕様でサポートされる scalabilityMode 値と、それらに関連する識別子および特性を、以下の表に示します。 scalabilityMode 値の名前（大文字と小文字を区別します）が、 [AV1] セクション 6.7.5 で割り当てられたスケーラビリティモード識別子、およびセクション 9 で提供される依存関係図へのリンクとともに示されています。

[AV1] および VP9 [VP9] 仕様は、表で定義されているすべての scalabilityMode 値をサポートしていますが、他のコーデック仕様はそうではありません。たとえば、VP8 [RFC6386]、H.264 [RFC6184] および H.265 [RFC7798] は、時間スケーラビリティ（例: "L1T2"、"L1T3"）のみをサポートします。また、VP8 [RFC6386]、H.264 [RFC6184] および H.265 [RFC7798] では、異なる SSRC 上でのサイマルキャストの転送のみが許可されるため、「S」モード（複数のエンコードが単一の RTP ストリーム上で転送されるモード）はサポートされません。

スケーラビリティモード識別子	空間レイヤー	解像度比	時間レイヤー	レイヤー間依存関係	AV1 scalability_mode_idc
"L1T1"	1		1		該当なし
"L1T2"	1		2		SCALABILITY_L1T2
"L1T3"	1		3		SCALABILITY_L1T3
"L2T1"	2	2:1	1	はい	SCALABILITY_L2T1
"L2T2"	2	2:1	2	はい	SCALABILITY_L2T2
"L2T3"	2	2:1	3	はい	SCALABILITY_L2T3
"L3T1"	3	2:1	1	はい	SCALABILITY_L3T1
"L3T2"	3	2:1	2	はい	SCALABILITY_L3T2
"L3T3"	3	2:1	3	はい	SCALABILITY_L3T3
"L2T1h"	2	1.5:1	1	はい	SCALABILITY_L2T1h
"L2T2h"	2	1.5:1	2	はい	SCALABILITY_L2T2h
"L2T3h"	2	1.5:1	3	はい	SCALABILITY_L2T3h
"L3T1h"	3	1.5:1	1	はい
"L3T2h"	3	1.5:1	2	はい
"L3T3h"	3	1.5:1	3	はい
"S2T1"	2	2:1	1	いいえ	SCALABILITY_S2T1
"S2T2"	2	2:1	2	いいえ	SCALABILITY_S2T2
"S2T3"	2	2:1	3	いいえ	SCALABILITY_S2T3
"S2T1h"	2	1.5:1	1	いいえ	SCALABILITY_S2T1h
"S2T2h"	2	1.5:1	2	いいえ	SCALABILITY_S2T2h
"S2T3h"	2	1.5:1	3	いいえ	SCALABILITY_S2T3h
"S3T1"	3	2:1	1	いいえ	SCALABILITY_S3T1
"S3T2"	3	2:1	2	いいえ	SCALABILITY_S3T2
"S3T3"	3	2:1	3	いいえ	SCALABILITY_S3T3
"S3T1h"	3	1.5:1	1	いいえ	SCALABILITY_S3T1h
"S3T2h"	3	1.5:1	2	いいえ	SCALABILITY_S3T2h
"S3T3h"	3	1.5:1	3	いいえ	SCALABILITY_S3T3h
"L2T2_KEY"	2	2:1	2	はい	SCALABILITY_L3T2_KEY
"L2T2_KEY_SHIFT"	2	2:1	2	はい	SCALABILITY_L3T2_KEY_SHIFT
"L2T3_KEY"	2	2:1	3	はい	SCALABILITY_L3T3_KEY
"L2T3_KEY_SHIFT"	2	2:1	3	はい	SCALABILITY_L3T3_KEY_SHIFT
"L3T1_KEY"	3	2:1	1	はい
"L3T2_KEY"	3	2:1	2	はい	SCALABILITY_L4T5_KEY
"L3T2_KEY_SHIFT"	3	2:1	2	はい	SCALABILITY_L4T5_KEY_SHIFT
"L3T3_KEY"	3	2:1	3	はい	SCALABILITY_L4T7_KEY
"L3T3_KEY_SHIFT"	3	2:1	3	はい	SCALABILITY_L4T7_KEY_SHIFT

scalabilityMode 値を提案する場合、次の原則に従うべきです:

提案される scalabilityMode は、セクション 5 の表に対する項目を定義しなければならず、スケーラビリティモード識別子、空間および時間レイヤー、解像度比、レイヤー間依存関係、および対応する AV1 scalability_mode_idc 値（割り当てられている場合）の値を含めなければなりません。
スケーラビリティモード識別子は、既存の命名方式と一貫しているべきです。この方式では、 2:1 の解像度比を使用する x 個の空間レイヤーと y 個の時間レイヤーを持つ scalabilityMode を表すために LxTy を使用します。 LxTyh は、1.5:1 の解像度比を持つ x 個の空間レイヤーと y 個の時間レイヤーを表します。SxTy は、 2:1 の解像度比を持つ x 個のサイマルキャストエンコードを持ち、それぞれのサイマルキャストエンコードに y 個の時間レイヤーを含む scalabilityMode を表します。SxTyh は 1.5:1 の解像度比を表します。LxTy_KEY は、 2:1 の解像度比を使用する x 個の空間レイヤーと y 個の時間レイヤーを持ち、空間レイヤーがキーフレームでのみ下位の空間レイヤーに依存する scalabilityMode を表します。LxTy_KEY_SHIFT モードは、 2:1 の解像度比を使用する x 個の空間レイヤーと y 個の時間レイヤーを持ち、空間レイヤーがキーフレームでのみ下位の空間レイヤーに依存し、後続のフレームでは時間識別子が上方向にシフトされる scalabilityMode を表します。
セクション 9 で提供される形式で、依存関係図を提供しなければなりません。

このセクションは規範的ではありません。

この例では、[WEBRTC] セクション 7.1（例 1）を拡張し、それぞれ 3 個の時間レイヤーを持つ 3 個の空間サイマルキャストレイヤーを、各サイマルキャストレイヤーに SSRC と RID を使用して送信する方法を示します。元の例から変更されているのは "sendEncodings" 属性のみです。

例 1

const signaling = new SignalingChannel(); // JSON.stringify/parse を処理する
const constraints = {audio: true, video: true};
const configuration = {'iceServers': [{'urls': 'stun:stun.example.org'}]};
let pc;

// start() を呼び出して開始する
async function start() {
  pc = new RTCPeerConnection(configuration);

  // "negotiationneeded" イベントによって Offer の生成をトリガーする
  pc.onnegotiationneeded = async () => {
    try {
      await pc.setLocalDescription();
      // Offer を相手のピアに送信する
      signaling.send({description: pc.localDescription});
    } catch (err) {
      console.error(err);
    }
  };

  try {
    // ローカルストリームを取得し、セルフビューに表示して送信対象として追加する
    const stream = await navigator.mediaDevices.getUserMedia(constraints);
    selfView.srcObject = stream;
    pc.addTransceiver(stream.getAudioTracks()[0], {direction: 'sendonly'});
    pc.addTransceiver(stream.getVideoTracks()[0], {
      direction: 'sendonly',
      sendEncodings: [
        {rid: 'q', scaleResolutionDownBy: 4.0, scalabilityMode: 'L1T3'},
        {rid: 'h', scaleResolutionDownBy: 2.0, scalabilityMode: 'L1T3'},
        {rid: 'f', scalabilityMode: 'L1T3'}
      ]
    });
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({data: {description, candidate}}) => {
  try {
    if (description) {
      await pc.setRemoteDescription(description);
      // Offer を受信した場合は Answer で応答する必要がある
      if (description.type == 'offer') {
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

これは、2 個の空間レイヤー（2:1 の比率）と 3 個の時間レイヤーを持つ例です。

例 2

let sendEncodings = [
  {scalabilityMode: 'L2T3'}
];

これは、各サイマルキャストレイヤーが 3 個の時間レイヤーを持つ、混合コーデックサイマルキャストの例です。

例 3

let sendEncodings = [
  {rid: 'q', codec: {clockRate: 90000, mimeType: 'video/AV1'}, scaleResolutionDownBy: 4.0, scalabilityMode: 'L1T3'},
  {rid: 'h', codec: {clockRate: 90000, mimeType: 'video/VP8'}, scaleResolutionDownBy: 2.0, scalabilityMode: 'L1T3'},
  {rid: 'f', codec: {clockRate: 90000, mimeType: 'video/VP8'}, scalabilityMode: 'L1T3'}
];

これは、単一の SSRC 上で、それぞれ 3 個の時間レイヤーを持つ 3 個の空間サイマルキャストレイヤーの例です。

例 4

let sendEncodings = [
  {scalabilityMode: 'S3T3'}
]

このセクションは規範的ではありません。

これは、[WEBRTC] および [Media-Capabilities] を実装するブラウザーによって返される encodingInfo(configuration) の例です。

例 5

const contentType = 'video/VP9';

const configuration = {
  type: 'webrtc',
  video: {
    contentType,
    width: 640,
    height: 480,
    bitrate: 10000,
    framerate: 29.97,
    scalabilityMode: 'L3T3_KEY'
  }
};

try {
  const info = await navigator.mediaCapabilities.encodingInfo(configuration);

  if (!info.supported) {
    console.log(`${contentType} はサポートされていません。`);
    return;
  }
  console.log(`${contentType} は ${info.smooth || '非'}スムーズであり、` +
              `${info.powerEfficient || '非'}電力効率的です`);
} catch (err) {
  console.error(err, ' が encodingInfo の失敗を引き起こしました');
}

このセクションは規範的ではありません。

これは、VP8、VP9、および AV1 の時間スケーラビリティモードの転送のみをサポートする SFM によって返される受信能力の例です。

例 6

 "codecs": [
    {
      "clockRate": 90000,
      "mimeType": "video/VP8",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    },
    {
      "clockRate": 90000,
      "mimeType": "video/VP9",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    },
    {
      "clockRate": 90000,
      "mimeType": "video/AV1",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    }
]

WebRTC では、スケーラブル符号化ツールの使用はピア間でネゴシエートされないため、サポートされている scalabilityMode 値も、空間予測に対するデコーダーのサポートも SDP には公開されません。

setParameters() API を使用して各コーデックに scalabilityMode 値を設定しようとすることで、アプリケーションは、どの構成の試行が成功し、どれが失敗するかを確認して、エンコーダーがサポートする値を判断できます。ただし、これによって scalabilityMode 値がハードウェアまたはソフトウェアのエンコーダー（あるいはその両方）でサポートされているかどうかは分かりません。setParameters() は RTCRtpReceiver ではサポートされていないため、デコーダーのサポートを判断するための同等の実験を行うことはできません。

ソフトウェアエンコーダーによってサポートされる scalabilityMode 値は通常、ハードウェアでサポートされる値のスーパーセットであるため、これらの実験から得られる情報は、 Web ページですでに利用可能な、使用中のブラウザーとの高い相関があります。メディアの送受信が開始された後は、パフォーマンス特性、または使用中のコーデックについて scalabilityMode 値をデコードできるかどうかに関する情報を取得でき、ハードウェア能力についてより多くの情報が得られます。

[Media-Capabilities] セクション 3.1 で述べられているように、Media Capabilities API は、この仕様から得られる情報よりも「より正確で一貫した情報を提供する可能性があります」。また、 [Media-Capabilities] セクション 3.1 で述べられているように、「特定のクラスのデバイスは非常によく似たデコード/エンコード能力を持つことが予想されるため、この情報は Web ページですでに利用可能な他の情報と高い相関を持つことが予想されます。」