RFC 8331 - RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8331
タイトル : RFC 8331 - Society of Motion Picture and Television Engineers（SMPTE）ST 291-1 Ancillary DataのRTPペイロード
翻訳編集 : 自動生成

[要約] RFC 8331は、SMPTE ST 291-1の補助データをRTPペイロードとして扱うための仕様です。目的は、ビデオやオーディオの補助データをRTPパケットに組み込んで転送することで、補助データの効率的な伝送を実現することです。

Internet Engineering Task Force (IETF)                        T. Edwards
Request for Comments: 8331                                           FOX
Category: Standards Track                                  February 2018
ISSN: 2070-1721

RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data

Society of Motion Picture and Television Engineers（SMPTE）ST 291-1 Ancillary DataのRTPペイロード

Abstract

概要

This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1. SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD).

このメモは、SMPTE ST 291-1で定義されている、Society of Motion Picture and Television Engineers（SMPTE）の補助空間（ANC）データのリアルタイム転送プロトコル（RTP）ペイロード形式について説明しています。 SMPTE ANCデータは一般に、タイムコード、クローズドキャプション、アクティブフォーマット記述（AFD）など、さまざまな補助データタイプを伝送するためにプロのビデオフォーマットと共に使用されます。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8331.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8331で入手できます。

著作権表示

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  RTP Payload Format for SMPTE ST 291 Ancillary Data  . . . . .   4
     2.1.  Payload Header Definitions  . . . . . . . . . . . . . . .   5
   3.  Payload Format Parameters . . . . . . . . . . . . . . . . . .  11
     3.1.  Media Type Definition . . . . . . . . . . . . . . . . . .  11
   4.  SDP Considerations  . . . . . . . . . . . . . . . . . . . . .  13
     4.1.  Grouping ANC Data Streams with Other Media Streams  . . .  15
   5.  Offer/Answer Model and Declarative Considerations . . . . . .  15
     5.1.  Offer/Answer Model  . . . . . . . . . . . . . . . . . . .  15
     5.2.  Declarative SDP Considerations  . . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction

1. はじめに

This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1 [ST291]. ANC data is transmitted in the ancillary space of serial digital video interfaces, the space outside of the active video region of images intended for users to view. Ancillary space roughly corresponds to vertical and horizontal blanking periods of cathode ray tube type displays. ANC data can carry a range of data types, including time code, Closed Captioning, and the Active Format Description (AFD).

このメモは、SMPTE ST 291-1 [ST291]で定義されている、Society of Motion Picture and Television Engineers（SMPTE）の補助空間（ANC）データのリアルタイム転送プロトコル（RTP）ペイロード形式について説明しています。 ANCデータは、シリアルデジタルビデオインターフェイスの補助スペース、つまりユーザーが表示することを目的とした画像のアクティブビデオ領域の外側のスペースで送信されます。補助スペースは、おおよそブラウン管型ディスプレイの垂直および水平ブランキング期間に対応します。 ANCデータは、タイムコード、クローズドキャプション、アクティブフォーマット記述（AFD）など、さまざまなデータタイプを伝送できます。

ANC data is generally associated with the carriage of metadata within the bit stream of a Serial Digital Interface (SDI), such as the standard definition (SD) Serial Digital Interface, the 1.5 Gb/s Serial Digital Interface for high definition (HD) television applications, or the 3 Gb/s Signal/Data Serial Interface (SMPTE ST 259 [ST259], SMPTE ST 292-1 [ST292], and SMPTE ST 424 [ST424]).

ANCデータは一般に、標準解像度（SD）シリアルデジタルインターフェイス、高解像度（HD）テレビ用の1.5 Gb / sシリアルデジタルインターフェイスなど、シリアルデジタルインターフェイス（SDI）のビットストリーム内のメタデータの搬送に関連付けられています。アプリケーション、または3 Gb / s信号/データシリアルインターフェイス（SMPTE ST 259 [ST259]、SMPTE ST 292-1 [ST292]、およびSMPTE ST 424 [ST424]）。

ANC data packet payload definitions for a specific application are specified by a SMPTE Standard, Recommended Practice, Registered Disclosure Document, or by a document generated by another organization, a company, or an individual (an entity). When a payload format is registered with SMPTE, it is identified by a registered data identification word.

特定のアプリケーションのANCデータパケットペイロード定義は、SMPTE標準、推奨プラクティス、登録開示文書、または別の組織、会社、または個人（エンティティ）によって生成された文書によって指定されます。ペイロードのフォーマットがSMPTEに登録されると、登録されたデータ識別ワードによって識別されます。

This memo describes an RTP payload that supports carriage of ANC data packets that originate from any location within any SMPTE-defined SDI signal. This payload also supports the carriage of ANC data packets that did not originate from an SDI signal. Sufficient information is provided to enable the ANC data packets at the output of the decoder to be restored to their original locations in the serial digital video signal raster (if that is desired). An optional media type parameter allows for the signaling of carriage of one or more types of ANC data as specified by data identification (DID) and secondary data identification (SDID) words. Another optional media type parameter allows for the identification of the Video Payload ID (VPID) code of the source interface of ANC data packets.

このメモは、SMPTE定義のSDI信号内の任意の場所から発信されるANCデータパケットの搬送をサポートするRTPペイロードについて説明しています。このペイロードは、SDI信号から発信されなかったANCデータパケットの搬送もサポートします。デコーダーの出力でANCデータパケットをシリアルデジタルビデオ信号ラスターの元の場所に復元できるようにするために十分な情報が提供されます（必要な場合）。オプションのメディアタイプパラメータを使用すると、データ識別（DID）ワードとセカンダリデータ識別（SDID）ワードで指定された1つ以上のタイプのANCデータの搬送を通知できます。別のオプションのメディアタイプパラメータを使用すると、ANCデータパケットのソースインターフェイスのビデオペイロードID（VPID）コードを識別できます。

Note that the Ancillary Data Flag (ADF) word is not specifically carried in this RTP payload. The ADF might be specified in a document defining an interconnecting digital video interface; otherwise, a default ADF is specified by SMPTE ST 291-1 [ST291].

補助データフラグ（ADF）ワードは、このRTPペイロードでは特に実行されないことに注意してください。 ADFは、相互接続するデジタルビデオインターフェイスを定義するドキュメントで指定される場合があります。それ以外の場合、デフォルトのADFはSMPTE ST 291-1 [ST291]で指定されます。

This ANC data payload can be used by itself or used along with a range of RTP video formats. In particular, it has been designed so that it could be used along with "RTP Payload Format for Uncompressed Video" [RFC4175] or "RTP Payload Format for JPEG 2000 Video Streams" [RFC5371].

このANCデータペイロードは、単独で使用することも、さまざまなRTPビデオ形式と共に使用することもできます。特に、「非圧縮ビデオのRTPペイロード形式」[RFC4175]または「JPEG 2000ビデオストリームのRTPペイロード形式」[RFC5371]と一緒に使用できるように設計されています。

The data model in this document for the ANC data RTP payload is based on the data model of SMPTE ST 2038 [ST2038], which standardizes the carriage of ANC data packets in an MPEG-2 Transport Stream.

このドキュメントのANCデータRTPペイロードのデータモデルは、SMPTE ST 2038 [ST2038]のデータモデルに基づいています。これは、MPEG-2トランスポートストリームでのANCデータパケットの搬送を標準化しています。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

2. RTP Payload Format for SMPTE ST 291 Ancillary Data

2. SMPTE ST 291補助データのRTPペイロード形式

An example of the format of an RTP packet containing SMPTE ST 291 ANC data is shown below:

SMPTE ST 291 ANCデータを含むRTPパケットのフォーマットの例を以下に示します。

       0                   1                   2                   3
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |V=2|P|X| CC    |M|    PT       |        sequence number        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           timestamp                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           synchronization source (SSRC) identifier            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Extended Sequence Number    |           Length=32           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | ANC_Count=2   | F |                reserved                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |C|   Line_Number=9     |   Horizontal_Offset   |S| StreamNum=0 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DID       |        SDID       |  Data_Count=0x84  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                User_Data_Words...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |   Checksum_Word   |         word_align            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |C|   Line_Number=10    |   Horizontal_Offset   |S| StreamNum=0 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         DID       |        SDID       |  Data_Count=0x105 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                User_Data_Words...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |   Checksum_Word   |word_align |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: SMPTE Ancillary Data RTP Packet Format

図1：SMPTE補助データRTPパケット形式

In this example, two ANC data packets are present. The first has four 10-bit User_Data_Words, and the second has five 10-bit User_Data_Words (note that few ANC data packets are this small; thus, this example does not reflect actual defined ANC data packets and does not specifically call out the DIDs and SDIDs). The ANC data packets are located on lines 9 and 10 of the SDI raster.

この例では、2つのANCデータパケットが存在します。 1つ目は4つの10ビットUser_Data_Wordsを持ち、2つ目は5つの10ビットUser_Data_Wordsを持っています（このANCデータパケットはこれほど小さいことに注意してください。したがって、この例は実際に定義されたANCデータパケットを反映せず、DIDとSDID）。 ANCデータパケットは、SDIラスターのライン9および10にあります。

The term "network byte order" in the payload format SHALL refer to the Data Transmission Order as defined in Appendix B of RFC 791 [RFC0791].

ペイロード形式の「ネットワークバイトオーダー」という用語は、RFC 791 [RFC0791]の付録Bで定義されているデータ転送順序を指します。

RTP packet header fields SHALL be interpreted as per RFC 3550 [RFC3550], with the following specifics:

RTPパケットヘッダーフィールドは、RFC 3550 [RFC3550]に従って次のように解釈される必要があります。

Timestamp: 32 bits The timestamp field is interpreted in a similar fashion to RFC 4175 [RFC4175]:

タイムスタンプ：32ビットタイムスタンプフィールドは、RFC 4175 [RFC4175]と同様の方法で解釈されます。

For progressive scan video, the timestamp denotes the sampling instant of the frame to which the ANC data in the RTP packet belongs. RTP packets MUST NOT include ANC data from multiple frames, and all RTP packets with ANC data belonging to the same frame MUST have the same timestamp.

プログレッシブスキャンビデオの場合、タイムスタンプは、RTPパケットのANCデータが属するフレームのサンプリングの瞬間を示します。 RTPパケットには複数のフレームからのANCデータを含めてはならず（MUST NOT）、同じフレームに属するANCデータを持つすべてのRTPパケットは同じタイムスタンプを持つ必要があります。

For interlaced video, the timestamp denotes the sampling instant of the field to which the ANC data in the RTP packet belongs. RTP packets MUST NOT include ANC data packets from multiple fields, and all RTP packets belonging to the same field MUST have the same timestamp.

インターレースビデオの場合、タイムスタンプは、RTPパケットのANCデータが属するフィールドのサンプリングインスタントを示します。 RTPパケットには複数のフィールドからのANCデータパケットを含めてはならず（MUST NOT）、同じフィールドに属するすべてのRTPパケットは同じタイムスタンプを持つ必要があります。

If the sampling instant does not correspond to an integer value of the clock, the value SHALL be truncated to the next lowest integer with no ambiguity. Section 3.1 describes timestamp clock rates.

サンプリングの瞬間がクロックの整数値に対応しない場合、値は曖昧さのない次の最も低い整数に切り捨てられる必要があります（SHALL）。セクション3.1では、タイムスタンプクロックレートについて説明します。

Marker bit (M): 1 bit The marker bit set to "1" indicates the last ANC data RTP packet for a frame (for progressive scan video) or the last ANC data RTP packet for a field (for interlaced video).

マーカービット（M）：1ビットマーカービットを「1」に設定すると、フレームの最後のANCデータRTPパケット（プログレッシブスキャンビデオの場合）またはフィールドの最後のANCデータRTPパケット（インターレースビデオの場合）を示します。

2.1. Payload Header Definitions

2.1. ペイロードヘッダーの定義

The ANC data RTP payload header fields are defined as:

ANCデータRTPペイロードヘッダーフィールドは次のように定義されます。

Extended Sequence Number: 16 bits The high-order bits of the extended 32-bit sequence number, in network byte order. This is the same as the Extended Sequence Number field in RFC 4175 [RFC4175].

拡張シーケンス番号：16ビット拡張32ビットシーケンス番号の上位ビット（ネットワークバイト順）。これはRFC 4175 [RFC4175]の拡張シーケンス番号フィールドと同じです。

Length: 16 bits Number of octets of the ANC data RTP payload, beginning with the "C" bit of the first ANC packet data header, as an unsigned integer in network byte order. Note that all word_align fields contribute to the calculation of the Length field.

長さ：16ビットANCデータRTPペイロードのオクテット数。最初のANCパケットデータヘッダーの「C」ビットから始まり、ネットワークバイトオーダーの符号なし整数として。すべてのword_alignフィールドは、長さフィールドの計算に寄与することに注意してください。

ANC_Count: 8 bits This field is the count of the total number of ANC data packets carried in the RTP payload, as an unsigned integer. A single ANC data RTP packet payload cannot carry more than 255 ANC data packets.

ANC_Count：8ビットこのフィールドは、RTPペイロードで運ばれるANCデータパケットの総数を、符号なし整数としてカウントしたものです。 1つのANCデータRTPパケットペイロードは、255を超えるANCデータパケットを伝送できません。

If more than 255 ANC data packets need to be carried in a field or frame, additional RTP packets carrying ANC data MAY be sent with the same RTP timestamp but with different sequence numbers. ANC_Count of 0 indicates that there are no ANC data packets in the payload (for example, an RTP packet that carries no actual ANC data packets even though its marker bit indicates the last ANC data RTP packet in a field/ frame). If the ANC_Count is 0, the Length will also be 0.

255を超えるANCデータパケットをフィールドまたはフレームで伝送する必要がある場合は、ANCデータを伝送する追加のRTPパケットを、同じRTPタイムスタンプで、異なるシーケンス番号で送信できます。 ANC_Countが0の場合、ペイロードにANCデータパケットがないことを示します（たとえば、マーカービットがフィールド/フレーム内の最後のANCデータRTPパケットを示していても、実際のANCデータパケットを伝送しないRTPパケット）。 ANC_Countが0の場合、長さも0になります。

F: 2 bits These two bits relate to signaling the field specified by the RTP timestamp in an interlaced SDI raster. A value of 0b00 indicates that either the video format is progressive or that no field is specified. A value of 0b10 indicates that the timestamp refers to the first field of an interlaced video signal. A value of 0b11 indicates that the timestamp refers to the second field of an interlaced video signal. The value 0b01 is not valid. Receivers SHOULD ignore an ANC data packet with an F field value of 0b01 and SHOULD process any other ANC data packets with valid F field values that are present in the RTP payload.

F：2ビットこれらの2ビットは、インターレースSDIラスタのRTPタイムスタンプで指定されたフィールドのシグナリングに関連しています。値0b00は、ビデオ形式がプログレッシブであるか、フィールドが指定されていないことを示します。値0b10は、タイムスタンプがインターレースビデオ信号の最初のフィールドを参照することを示します。値0b11は、タイムスタンプがインターレースビデオ信号の2番目のフィールドを参照することを示します。値0b01は無効です。受信者は、Fフィールド値が0b01のANCデータパケットを無視する必要があり（SHOULD）、RTPペイロードに存在する有効なFフィールド値を持つ他のANCデータパケットを処理する必要があります（SHOULD）。

Note that some multi-stream SDI interfaces might use multiple interlaced signal streams to transmit progressive images, in which case the "F" bits would refer to the field of the interlaced stream used for transport of the ANC data packet.

一部のマルチストリームSDIインターフェイスは、複数のインターレース信号ストリームを使用してプログレッシブ画像を送信する場合があります。その場合、「F」ビットは、ANCデータパケットの転送に使用されるインターレースストリームのフィールドを参照します。

reserved: 22 bits The 22 reserved bits of value "0" follow the F field to ensure that the first ANC data packet header field in the payload begins 32-bit word-aligned with the start of the RTP header to ease implementation.

予約済み：22ビット値「0」の予約済み22ビットはFフィールドの後に続き、ペイロードの最初のANCデータパケットヘッダーフィールドが、RTPヘッダーの開始と32ビットワードで整列され、実装を容易にします。

For each ANC data packet in the payload, the following ANC data packet header fields MUST be present:

ペイロードの各ANCデータパケットには、次のANCデータパケットヘッダーフィールドが存在しなければなりません：

C: 1 bit This flag, when set to "1", indicates that the ANC data corresponds to the color-difference data channel (C). When set to "0", this flag indicates either that the ANC data corresponds to the luma (Y) data channel, that the ANC data source is from an SD signal, or that the ANC data source has no specific luma or color-difference data channels. For ANC data from a multi-stream interface source, the C flag SHALL refer to the channel of the stream used to transport the ANC data packet. For situations where there is no SDI source, if the ANC data type definition specifically requires the use of the C or Y data channel, the C flag SHALL reflect that requirement.

C：1ビットこのフラグは、「1」に設定されると、ANCデータが色差データチャネル（C）に対応することを示します。「0」に設定すると、このフラグは、ANCデータが輝度（Y）データチャネルに対応すること、ANCデータソースがSD信号からのものであること、またはANCデータソースに特定の輝度または色差がないことを示します。データチャネル。マルチストリームインターフェイスソースからのANCデータの場合、Cフラグは、ANCデータパケットの転送に使用されるストリームのチャネルを参照する必要があります。 SDIソースがない状況で、ANCデータタイプの定義でCまたはYデータチャネルの使用が特に必要な場合、Cフラグはその要件を反映する必要があります（SHALL）。

Line_Number: 11 bits This field contains the digital interface line number that corresponds to the location of the ANC data packet as an unsigned integer in network byte order.

Line_Number：11ビットこのフィールドには、ANCデータパケットの場所に対応するデジタルインターフェイスライン番号が、ネットワークバイトオーダーの符号なし整数として含まれます。

The following special Line_Number values indicate that the location of the ANC data packet is in certain generic vertical regions of the SDI raster:

次の特別なLine_Number値は、ANCデータパケットの場所がSDIラスターの特定の汎用垂直領域にあることを示しています。

+-------------+--------------------------------------------------------+
| Line_Number | ANC data packet generic vertical location              |
+-------------+--------------------------------------------------------+
|   0x7FF     | Without specific line location within the field or     |
|             | frame                                                  |
|             |                                                        |
|   0x7FE     | On any line in the range from the second line after    |
|             | the line specified for switching, as defined in SMPTE  |
|             | RP 168 [RP168], to the last line before active video,  |
|             | inclusive                                              |
|             |                                                        |
|   0x7FD     | On a line number larger than can be represented in 11  |
|             | bits of this field (if needed for future formats)      |
+-------------+--------------------------------------------------------+

Note that the lines that are available to convey ANC data are as defined in the applicable sample structure specification (e.g., SMPTE ST 274 [ST274], SMPTE ST 296 [ST296], ITU-R BT.656 [BT656]) and are possibly further restricted per SMPTE RP 168 [RP168].

ANCデータを伝達するために利用できるラインは、該当するサンプル構造仕様（SMPTE ST 274 [ST274]、SMPTE ST 296 [ST296]、ITU-R BT.656 [BT656]など）で定義されているとおりであり、 SMPTE RP 168 [RP168]によりさらに制限されます。

In multi-stream interfaces, this field refers to the line number that an ANC data packet is carried on within a particular data stream in the interface.

マルチストリームインターフェイスでは、このフィールドは、ANCデータパケットがインターフェイスの特定のデータストリーム内で伝送される回線番号を指します。

Horizontal_Offset: 12 bits This field defines the location of the ANC data packet in an SDI raster relative to the start of active video (SAV; a digital synchronizing signal present in SDI interfaces) as an unsigned integer in network byte order. A value of 0 means that the ADF of the ANC data packet begins immediately following SAV. The horizontal offset from SAV is measured in terms of 10-bit words of the indicated data stream and data channel.

Horizontal_Offset：12ビットこのフィールドは、アクティブビデオ（SAV; SDIインターフェイスに存在するデジタル同期信号）の開始に関連するSDIラスタ内のANCデータパケットの位置を、ネットワークバイトオーダーの符号なし整数として定義します。値0は、ANCデータパケットのADFがSAVの直後に始まることを意味します。 SAVからの水平オフセットは、示されたデータストリームとデータチャネルの10ビットワードで測定されます。

The following special Horizontal_Offset values indicate that the location of the ANC data packet is in certain generic horizontal regions of the SDI raster:

次の特別なHorizontal_Offset値は、ANCデータパケットの場所がSDIラスタの特定の一般的な水平領域にあることを示しています。

+-------------+--------------------------------------------------------+
| Horizontal_ | ANC data packet generic horizontal location            |
| Offset      |                                                        |
+-------------+--------------------------------------------------------+
|   0xFFF     | Without specific horizontal location                   |
|             |                                                        |
|   0xFFE     | Within horizontal ancillary data space (HANC) as       |
|             | defined in SMPTE ST 291-1 [ST291]                      |
|             |                                                        |
|   0xFFD     | Within the ancillary data space located between SAV    |
|             | (Start of Active Video) and EAV (End of Active Video)  |
|             | markers of the serial digital interface                |
|             |                                                        |
|   0xFFC     | Horizontal offset is larger than can be represented in |
|             | the 12 bits of this field (if needed for future        |
|             | formats or for certain low frame rate 720p formats)    |
+-------------+--------------------------------------------------------+

In multi-stream interfaces, this field refers to the horizontal location where an ANC data packet is placed on a line carried within a particular data stream in the interface.

マルチストリームインターフェイスでは、このフィールドは、インターフェイスの特定のデータストリーム内で伝送されるライン上にANCデータパケットが配置される水平方向の場所を指します。

Note that HANC data space will generally have higher luma sample numbers than any samples in the active digital line. Also note that SMPTE ST 296 [ST296] (1280 x 720 progressive active images) image sampling systems 7 and 8 (1280 x 720 progressive @ 24 fps and 1280 x 720 progressive @ 23.98 fps respectively) have a luma sample number maximum of 4124. It is unlikely that an actual implementation would have an ANC data packet begin at a Horizontal_Offset beyond 4091 (0xFFB) in these formats; should that occur, the Horizontal_Offset value 0xFFC can be used to signal a horizontal offset larger than can be represented in the field. Further note that the 12-bit field of Horizontal_Offset is kept that size in this memo to maintain easy conversion to/from SMPTE ST 2038 [ST2038], which also has a 12-bit Horizontal_Offset field.

HANCデータスペースは、通常、アクティブなデジタルラインのどのサンプルよりも高い輝度サンプル数を持っていることに注意してください。また、SMPTE ST 296 [ST296]（1280 x 720プログレッシブアクティブイメージ）画像サンプリングシステム7および8（それぞれ1280 x 720プログレッシブ@ 24 fpsおよび1280 x 720プログレッシブ@ 23.98 fps）の最大サンプル数は4124です。実際の実装では、これらの形式で4091（0xFFB）を超えるHorizontal_OffsetからANCデータパケットを開始することはほとんどありません。その場合は、Horizontal_Offset値0xFFCを使用して、フィールドで表すことができるよりも大きい水平オフセットを通知できます。さらに、Horizontal_Offsetの12ビットフィールドは、このメモではそのサイズが保持され、SMPTE ST 2038 [ST2038]との間の容易な変換を維持します。これには、12ビットHorizontal_Offsetフィールドもあります。

S (Data Stream Flag): 1 bit This field indicates whether the data stream number of a multi-stream data mapping used to transport the ANC data packet is specified. If the S bit is '0', then the StreamNum field provides no guidance regarding the source data stream number of the ANC data packet. If the S bit is '1', then the StreamNum field carries information regarding the source data stream number of the ANC data packet.

S（データストリームフラグ）：1ビットこのフィールドは、ANCデータパケットの転送に使用されるマルチストリームデータマッピングのデータストリーム番号が指定されているかどうかを示します。 Sビットが「0」の場合、StreamNumフィールドは、ANCデータパケットのソースデータストリーム番号に関するガイダンスを提供しません。 Sビットが「1」の場合、StreamNumフィールドには、ANCデータパケットのソースデータストリーム番号に関する情報が含まれます。

StreamNum: 7 bits If the S bit (Data Stream Flag) is '1', then the StreamNum field MUST carry identification of the source data stream number of the ANC data packet. If the data stream is numbered, then the StreamNum field SHALL carry the number of the source data stream minus one. If the source multi-stream interface does not have numbered data streams, the following numbers SHALL be used in this field: '0' for link A data stream and '1' for link B data stream. For stereoscopic multi-stream interface formats that do not have numbered streams, the following numbers SHALL be used in this field: '0' for left eye stream and '1' for right eye stream.

StreamNum：7ビットSビット（データストリームフラグ）が「1」の場合、StreamNumフィールドは、ANCデータパケットのソースデータストリーム番号の識別情報を運ぶ必要があります。データストリームに番号が付けられている場合、StreamNumフィールドはソースデータストリームの番号から1を引いた値を運ぶものとします（SHALL）。ソースマルチストリームインターフェイスに番号付きデータストリームがない場合は、このフィールドで次の番号を使用する必要があります（SHALL）。リンクAデータストリームの場合は「0」、リンクBデータストリームの場合は「1」。番号付きストリームを持たないステレオスコピックマルチストリームインターフェイスフォーマットの場合、このフィールドでは次の番号を使用する必要があります（SHALL）。左目ストリームの場合は「0」、右目ストリームの場合は「1」。

Note that in multi-link SDI connections, the physical link that a particular stream utilizes is typically specified by the interface standard. Also note that numbering of data streams is across the interface as a whole. For example, in the SMPTE ST 425-3 dual-link 3 Gb/s interface, the data streams are numbered 1-4 with data streams 1 and 2 on link 1 and data streams 3 and 4 on link 2.

マルチリンクSDI接続では、特定のストリームが使用する物理リンクは、通常、インターフェイス標準で指定されていることに注意してください。また、データストリームの番号付けは、全体としてインターフェイス全体に適用されることに注意してください。たとえば、SMPTE ST 425-3デュアルリンク3 Gb / sインターフェイスでは、データストリームには1〜4の番号が付けられ、リンク1のデータストリーム1および2、リンク2のデータストリーム3および4が使用されます。

An ANC data packet with the header fields Line_Number of 0x7FF and Horizontal_Offset of 0xFFF SHALL be considered to be carried without any specific location within the field or frame.

ヘッダーフィールドLine_Numberが0x7FFでHorizontal_Offsetが0xFFFのANCデータパケットは、フィールドまたはフレーム内の特定の場所なしで伝送されると見なされます。

For each ANC data packet in the payload, immediately after the ANC data packet header fields, the following data fields MUST be present with the fields DID, SDID, Data_Count, User_Data_Words, and Checksum_Word representing the 10-bit words carried in the ANC data packet, as per SMPTE ST 291-1 [ST291]:

ペイロード内の各ANCデータパケットについて、ANCデータパケットヘッダーフィールドの直後に、次のデータフィールドが、ANCデータパケットで運ばれる10ビットワードを表すフィールドDID、SDID、Data_Count、User_Data_Words、およびChecksum_Wordとともに存在する必要があります。、SMPTE ST 291-1 [ST291]に従って：

DID: 10 bits Data identification word

DID：10ビットのデータ識別ワード

SDID: 10 bits Secondary data identification word. Used only for a "Type 2" ANC data packet. Note that in a "Type 1" ANC data packet, this word will actually carry the data block number (DBN).

SDID：10ビットのセカンダリデータ識別ワード。「タイプ2」のANCデータパケットにのみ使用されます。「タイプ1」のANCデータパケットでは、このワードは実際にはデータブロック番号（DBN）を運ぶことに注意してください。

Data_Count: 10 bits The lower 8 bits of Data_Count, corresponding to bits b7 (MSB; most significant bit) through b0 (LSB; least significant bit) of the 10-bit Data_Count word, contain the actual count of 10-bit words in User_Data_Words. Bit b8 is the even parity for bits b7 through b0, and bit b9 is the inverse (logical NOT) of bit b8.

Data_Count：10ビットData_Countの下位8ビットは、10ビットのData_Countワードのビットb7（MSB;最上位ビット）からb0（LSB;最下位ビット）に対応し、User_Data_Wordsの10ビットワードの実際のカウントを含みます。。ビットb8はビットb7〜b0の偶数パリティで、ビットb9はビットb8の反転（論理否定）です。

User_Data_Words: integer number of 10-bit words User_Data_Words (UDW) are used to convey information of a type as identified by the DID word or the DID and SDID words. The number of 10-bit words in the UDW is defined by the Data_Count field. The 10-bit words are carried in order starting with the most significant bit and ending with the least significant bit.

User_Data_Words：10ビットワードの整数User_Data_Words（UDW）は、DIDワードまたはDIDおよびSDIDワードで識別されるタイプの情報を伝達するために使用されます。 UDWの10ビットワードの数は、Data_Countフィールドで定義されます。 10ビットのワードは、最上位ビットで始まり、最下位ビットで終わる順序で運ばれます。

Checksum_Word: 10 bits The Checksum_Word can be used to determine the validity of the ANC data packet from the DID word through the UDW. It consists of 10 bits, where bits b8 (MSB) through b0 (LSB) define the checksum value and bit b9 is the inverse (logical NOT) of bit b8. The checksum value is equal to the nine least significant bits of the sum of the nine least significant bits of the DID word, the SDID word, the Data_Count word, and all User_Data_Words in the ANC data packet. The checksum is initialized to zero before calculation, and any "end carry" resulting from the checksum calculation is ignored.

Checksum_Word：10ビットChecksum_Wordを使用して、DIDワードからUDWを経由するANCデータパケットの有効性を判断できます。これは10ビットで構成され、ビットb8（MSB）からb0（LSB）はチェックサム値を定義し、ビットb9はビットb8の逆（論理NOT）です。チェックサム値は、DIDワード、SDIDワード、Data_Countワード、およびANCデータパケット内のすべてのUser_Data_Wordの最下位9ビットの合計の最下位9ビットに等しい。チェックサムは計算前にゼロに初期化され、チェックサム計算の結果生じる「終了キャリー」は無視されます。

At the end of each ANC data packet in the payload:

ペイロードの各ANCデータパケットの終わりに、

word_align: bits as needed to complete 32-bit word Word_align contains enough "0" bits as needed to complete the last 32-bit word of an ANC data packet in the RTP payload. If an ANC data packet in the RTP payload ends and is aligned with a word boundary, there is no need to add any word alignment bits. Word align SHALL be used even for the last ANC data packet in an RTP packet. Word align SHALL NOT be used if there are zero ANC data packets being carried in the RTP packet.

word_align：32ビットワードを完了するために必要なビットWord_alignには、RTPペイロードのANCデータパケットの最後の32ビットワードを完了するために必要な十分な「0」ビットが含まれています。 RTPペイロードのANCデータパケットが終了し、ワード境界に揃えられている場合、ワードアライメントビットを追加する必要はありません。ワードアラインは、RTPパケットの最後のANCデータパケットに対しても使用する必要があります。 RTPパケットでANCデータパケットが伝送されていない場合、ワードアラインは使用しないでください。

When reconstructing an SDI signal based on this payload, it is important to place ANC data packets into the locations indicated by the ANC data packet header fields C, Line_Number and Horizontal_Offset, and also to follow the requirements of Section 7 of SMPTE ST 291-1 [ST291], "Ancillary Data Space Formatting (Component or Composite Interface)", which includes rules on the placement of initial ANC data into allowed spaces as well as the contiguity of ANC data packet sequences within those spaces in order to assure that the resulting ANC data packets in the SDI signal are valid. The optional media type parameter VPID_Code can inform receivers of the type of originating SDI interface. For multi-stream originating interfaces, the StreamNum field can provide information regarding which stream an ANC data packet can be placed in to match the ANC data location in the originating SDI interface.

このペイロードに基づいてSDI信号を再構築する場合、ANCデータパケットをANCデータパケットヘッダーフィールドC、Line_Number、Horizontal_Offsetで示される場所に配置し、SMPTE ST 291-1のセクション7の要件に従うことも重要です。 [ST291]、「Ancillary Data Space Formatting（Component or Composite Interface）」。これには、許可されたスペースへの初期ANCデータの配置に関するルールと、これらのスペース内のANCデータパケットシーケンスの連続性が含まれ、結果として生じるSDI信号のANCデータパケットは有効です。オプションのメディアタイプパラメータVPID_Codeは、元のSDIインターフェイスのタイプをレシーバーに通知できます。マルチストリームの発信元インターフェイスの場合、StreamNumフィールドは、発信元のSDIインターフェイスのANCデータの場所と一致するようにANCデータパケットを配置できるストリームに関する情報を提供できます。

Senders of this payload SHOULD transmit available ANC data packets as soon as practical to reduce end-to-end latency, especially if the receivers will be embedding the received ANC data packet into an SDI signal emission. One millisecond is a reasonable upper bound for the amount of time between when an ANC data packet becomes available to a sender and the emission of an RTP payload containing that ANC data packet.

このペイロードの送信者は、特に受信者が受信したANCデータパケットをSDI信号エミッションに埋め込む場合は、エンドツーエンドのレイテンシを削減するために、できるだけ早く利用可能なANCデータパケットを送信する必要があります。 1ミリ秒は、ANCデータパケットが送信者に利用可能になってから、そのANCデータパケットを含むRTPペイロードが送信されるまでの時間の妥当な上限です。

ANC data packets with headers that indicate specific location within a field or frame SHOULD be sent in raster scan order, both in terms of packing position within an RTP packet and in terms of transmission time of RTP packets.

フィールドまたはフレーム内の特定の場所を示すヘッダーを持つANCデータパケットは、RTPパケット内のパッキング位置とRTPパケットの送信時間の両方の観点から、ラスタスキャン順に送信する必要があります。

3. Payload Format Parameters

3. ペイロード形式パラメータ

This RTP payload format is identified using the "video/smpte291" media type, which is registered in accordance with RFC 4855 [RFC4855]; the template defined in RFC 6838 [RFC6838] is used.

このRTPペイロード形式は、「video / smpte291」メディアタイプを使用して識別されます。これは、RFC 4855 [RFC4855]に従って登録されています。 RFC 6838 [RFC6838]で定義されているテンプレートが使用されます。

Note that the media type definition is in the "video" tree due to the expected use of SMPTE ST 291 Ancillary Data along with video formats.

SMPTE ST 291 Ancillary Dataとビデオ形式の使用が予想されるため、メディアタイプの定義は「ビデオ」ツリーにあることに注意してください。

3.1. Media Type Definition

3.1. メディアタイプの定義

Type name: video

タイプ名：ビデオ

Subtype name: smpte291

サブタイプ名：smpte291

Required parameters:

必須パラメーター：

Rate: RTP timestamp clock rate.

レート：RTPタイムスタンプクロックレート。

When an ANC data RTP stream is to be associated with an RTP video stream, the RTP timestamp rates SHOULD be the same to ensure that ANC data packets can be associated with the appropriate frame or field. Otherwise, a 90 kHz rate SHOULD be used.

ANCデータRTPストリームをRTPビデオストリームに関連付ける場合、RTCタイムスタンプレートを同じにして、ANCデータパケットを適切なフレームまたはフィールドに関連付けることができるようにする必要があります。それ以外の場合は、90 kHzレートを使用する必要があります。

Note that techniques described in RFC 7273 [RFC7273] can provide a common reference clock for multiple RTP streams intended for synchronized presentation.

RFC 7273 [RFC7273]で説明されている手法は、同期されたプレゼンテーションを目的とした複数のRTPストリームに共通の基準クロックを提供できることに注意してください。

Optional parameters:

オプションのパラメーター：

DID_SDID: Data identification and secondary data identification words.

DID_SDID：データ識別および2次データ識別ワード。

The presence of the DID_SDID parameters signals that all ANC data packets of this stream are of a particular type or types, i.e., labeled with particular DIDs and SDIDs. DID and SDID values of SMPTE-registered ANC data packet types can be found in the SMPTE Registry for Data Identification Word Assignments [SMPTE-RA].

DID_SDIDパラメータの存在は、このストリームのすべてのANCデータパケットが特定のタイプ、つまり特定のDIDおよびSDIDでラベル付けされていることを示します。 SMPTEに登録されたANCデータパケットタイプのDIDおよびSDID値は、データ識別ワード割り当てのSMPTEレジストリ[SMPTE-RA]にあります。

"Type 1" ANC data packets (which do not have SDIDs defined) SHALL be labeled with SDID=0x00.

「タイプ1」のANCデータパケット（SDIDが定義されていない）は、SDID = 0x00でラベル付けする必要があります。

DID and SDID values can be registered with SMPTE as per SMPTE ST 291-1 [ST291].

DIDおよびSDID値は、SMPTE ST 291-1 [ST291]に従ってSMPTEに登録できます。

The absence of the DID_SDID parameter signals that determination of the DID and SDID of ANC data packets in the payload can only be achieved through direct inspection of the ANC data packet fields.

DID_SDIDパラメータがないことは、ペイロード内のANCデータパケットのDIDおよびSDIDの決定は、ANCデータパケットフィールドを直接検査することによってのみ達成できることを示しています。

The ABNF description of the DID_SDID parameter is described in Section 4.

DID_SDIDパラメータのABNFの説明については、セクション4で説明します。

VPID_Code: This integer parameter specifies the Video Payload ID (VPID) code of the source interface of ANC data packets using the value from byte 1 of the VPID as defined in SMPTE ST 352 [ST352]. The integer SHALL be made with bit 7 of VPID byte 1 being the most significant bit and bit 0 of VPID byte 1 being the least significant bit. For example, 132 refers to SMPTE ST 292-1, 720-line video payloads on a 1.5 Gb/s (nominal) serial digital interface.

VPID_Code：この整数パラメーターは、SMPTE ST 352 [ST352]で定義されているVPIDのバイト1からの値を使用して、ANCデータパケットのソースインターフェイスのビデオペイロードID（VPID）コードを指定します。整数は、VPIDバイト1のビット7を最上位ビット、VPIDバイト1のビット0を最下位ビットとして作成する必要があります。たとえば、132はSMPTE ST 292-1、1.5 Gb / s（公称）シリアルデジタルインターフェイス上の720ラインビデオペイロードを指します。

Encoding considerations: This media type is framed and binary; see Section 4.8 of RFC 6838 [RFC6838].

エンコーディングに関する考慮事項：このメディアタイプはフレーム付きでバイナリです。 RFC 6838 [RFC6838]のセクション4.8をご覧ください。

Security considerations: See Section 7.

セキュリティに関する考慮事項：セクション7を参照してください。

Interoperability considerations: Data items in smpte291 can be very diverse. Receivers might only be capable of interpreting a subset of the possible data items. Some implementations might care about the location of the ANC data packets in the SDI raster, but other implementations might not care.

相互運用性に関する考慮事項：smpte291のデータ項目は非常に多様である可能性があります。レシーバーは、可能なデータ項目のサブセットを解釈することしかできない場合があります。一部の実装では、SDIラスタ内のANCデータパケットの場所を考慮しますが、他の実装では考慮しない場合があります。

Published specification: RFC 8331

公開された仕様：RFC 8331

Applications that use this media type: Devices that stream real-time professional video, especially those that interoperate with legacy serial digital interfaces (SDI).

このメディアタイプを使用するアプリケーション：リアルタイムのプロフェッショナルビデオをストリーミングするデバイス、特にレガシーシリアルデジタルインターフェイス（SDI）と相互運用するデバイス。

Additional Information:

追加情報：

Deprecated alias names for this type: N/A

このタイプの非推奨のエイリアス名：N / A

      Magic number(s): N/A

      File extension(s): N/A

      Macintosh file type code(s): N/A

Person & email address to contact for further information:

詳細について連絡する人とメールアドレス：

      T. Edwards <thomas.edwards@fox.com>
      IETF Payload Working Group <payload@ietf.org>

Intended usage: COMMON

使用目的：COMMON

Restrictions on usage: This media type depends on RTP framing and hence is only defined for transfer via RTP RFC 3550 [RFC3550]. Transport within other framing protocols is not defined at this time.

使用の制限：このメディアタイプはRTPフレーミングに依存するため、RTP RFC 3550 [RFC3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。

   Author: T. Edwards <thomas.edwards@fox.com>

Change controller: The IETF PAYLOAD Working Group, or other party as designated by the IESG.

変更管理者：IETF PAYLOADワーキンググループ、またはIESGによって指定された他の当事者。

4. SDP Considerations

4. SDPに関する考慮事項

The mapping of the above-defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855 [RFC4855].

上記で定義されたペイロード形式のメディアタイプとそのパラメータのマッピングは、RFC 4855 [RFC4855]のセクション3に従って行う必要があります。

o The type name ("video") goes in SDP "m=" as the media name.

o タイプ名（「ビデオ」）は、メディア名としてSDP「m =」に入ります。

o The subtype name ("smpte291") goes in SDP "a=rtpmap" as the encoding name, followed by a slash ("/") and the rate parameter.

o サブタイプ名（ "smpte291"）は、エンコード名としてSDP "a = rtpmap"になり、その後にスラッシュ（ "/"）とrateパラメーターが続きます。

o The optional parameters VPID_Code and DID_SDID, when present, are included in the "a=fmtp" attribute line of SDP as a semicolon-separated list of parameter=value pairs.

o オプションのパラメーターVPID_CodeおよびDID_SDID（存在する場合）は、parameter = valueペアのセミコロン区切りリストとしてSDPの「a = fmtp」属性行に含まれています。

DID and SDID values SHALL be specified in hexadecimal with a "0x" prefix (such as "0x61"). The ABNF as per RFC 5234 [RFC5234] of the DID_SDID optional parameter SHALL be:

DID値とSDID値は、「0x」プレフィックス付きの16進数で指定する必要があります（「0x61」など）。 DID_SDIDオプションパラメータのRFC 5234 [RFC5234]によるABNFは、

           TwoHex = "0x" 1*2(HEXDIG)
           DidSdid = "DID_SDID={" TwoHex "," TwoHex "}"

For example, EIA 608 Closed Caption data would be signaled with the parameter DID_SDID={0x61,0x02}. If a DID_SDID parameter is not specified, then the ANC data stream might potentially contain ANC data packets of any type.

たとえば、EIA 608クローズドキャプションデータは、パラメーターDID_SDID = {0x61,0x02}で通知されます。 DID_SDIDパラメータが指定されていない場合、ANCデータストリームには、任意のタイプのANCデータパケットが含まれる可能性があります。

Multiple DID_SDID parameters can be specified (separated by semicolons) to signal the presence of multiple types of ANC data in the stream. DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}, for example, signals the presence of EIA 608 Closed Captions as well as AFD/Bar Data. Multiple DID_SDID parameters do not imply any particular ordering of the different types of ANC data packets in the stream.

複数のDID_SDIDパラメーターを（セミコロンで区切って）指定して、ストリーム内に複数のタイプのANCデータが存在することを示すことができます。たとえば、DID_SDID = {0x61,0x02}; DID_SDID = {0x41,0x05}は、EIA 608クローズドキャプションとAFD /バーデータの存在を示します。複数のDID_SDIDパラメータは、ストリーム内のさまざまなタイプのANCデータパケットの特定の順序を意味するものではありません。

If the optional parameter VPID_Code is present, it SHALL be present only once in the semicolon-separated list, taking a single integer value.

オプションのパラメータVPID_Codeが存在する場合、セミコロンで区切られたリストに1つだけ存在し、単一の整数値を取ります。

A sample SDP mapping for ANC data is as follows:

ANCデータのサンプルSDPマッピングは次のとおりです。

      m=video 30000 RTP/AVP 112
      a=rtpmap:112 smpte291/90000
      a=fmtp:112 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05};VPID_Code=132

In this example, a dynamic payload type 112 is used for ANC data. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line after the subtype. In the "a=fmtp:" line, DID 0x61 and SDID 0x02 are specified (registered to EIA 608 Closed Caption Data by SMPTE), and also DID 0x41 and SDID 0x05 (registered to AFD/Bar Data). The VPID_Code is 132 (referring to SMPTE ST 292-1, 720-line video payloads on a 1.5 Gb/s serial digital interface).

この例では、ダイナミックペイロードタイプ112がANCデータに使用されます。 90 kHz RTPタイムスタンプレートは、サブタイプの後の "a = rtpmap"行で指定されます。「a = fmtp：」行では、DID 0x61およびSDID 0x02が指定され（SMPTEによってEIA 608クローズドキャプションデータに登録されています）、さらにDID 0x41およびSDID 0x05（AFD / Barデータに登録されています）が指定されています。 VPID_Codeは132です（SMPTE ST 292-1、1.5 Gb / sシリアルデジタルインターフェイスの720ラインビデオペイロードを参照）。

4.1. Grouping ANC Data Streams with Other Media Streams

4.1. ANCデータストリームと他のメディアストリームのグループ化

To indicate the association of an ANC data stream with a particular video stream, implementers MAY group the "m" lines together using Flow Identification ("FID") semantics as defined in RFC 5888 [RFC5888].

ANCデータストリームと特定のビデオストリームの関連付けを示すために、RFC 5888 [RFC5888]で定義されているように、実装者はFlow Identification（ "FID"）セマンティクスを使用して "m"行をグループ化できます（MAY）。

A sample SDP mapping for grouping ANC data with video as described in RFC 4175 [RFC4175] is as follows:

RFC 4175 [RFC4175]で説明されている、ビデオとANCデータをグループ化するためのサンプルSDPマッピングは次のとおりです。

        v=0
        o=Al 123456 11 IN IP4 host.example.com
        s=Professional Networked Media Test
        i=A test of synchronized video and ANC data
        t=0 0
        a=group:FID V1 M1
        m=video 50000 RTP/AVP 96
        c=IN IP4 233.252.0.1/255
        a=rtpmap:96 raw/90000
        a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
        a=mid:V1
        m=video 50010 RTP/AVP 97
        c=IN IP4 233.252.0.2/255
        a=rtpmap:97 smpte291/90000
        a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
        a=mid:M1

5. Offer/Answer Model and Declarative Considerations

5. オファー/アンサーモデルと宣言に関する考慮事項

5.1. Offer/Answer Model

5.1. オファー/アンサーモデル

Receivers might wish to receive ANC data streams with specific DID_SDID parameters. Thus, when offering ANC data streams using the Session Description Protocol (SDP) in an Offer/Answer model [RFC3264], the offerer MAY provide a list of ANC data streams available with specific DID_SDID parameters in the fmtp line. The answerer MAY (1) respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered, (2) set the corresponding port number to 0 to decline the smpte291 stream if not in the same media section as a corresponding video stream, or (3) remove the corresponding payload type if the smpte291 stream is in the same media section as a corresponding video stream. There are no restrictions on updating DID_SDID parameters in a subsequent offer.

レシーバーは、特定のDID_SDIDパラメーターを使用してANCデータストリームを受信する場合があります。したがって、オファー/アンサーモデル[RFC3264]でセッション記述プロトコル（SDP）を使用してANCデータストリームを提供する場合、提供者は、fmtp行の特定のDID_SDIDパラメーターで使用可能なANCデータストリームのリストを提供できます（MAY）。アンサーは、（1）提供されたDID_SDIDパラメータのすべてまたはサブセットを備えたfmtp行とともに提供されたストリームのすべてまたはサブセットで応答する可能性があります（2）対応するポート番号を0に設定して、smpte291ストリームが拒否された場合は拒否します対応するビデオストリームと同じメディアセクション、または（3）smpte291ストリームが対応するビデオストリームと同じメディアセクションにある場合は、対応するペイロードタイプを削除します。後続のオファーでのDID_SDIDパラメーターの更新に制限はありません。

5.2. Declarative SDP Considerations

5.2. 宣言的なSDPの考慮事項

For declarative use of SDP, nothing specific is defined for this payload format. The configuration given by the SDP MUST be used when sending and/or receiving media in the session.

SDPを宣言的に使用する場合、このペイロード形式には何も定義されていません。セッションでメディアを送信および/または受信するときに、SDPによって指定された構成を使用する必要があります。

6. IANA Considerations

6. IANAに関する考慮事項

The media type "video/smpte291" is defined in Section 3.1. IANA has registered "video/smpte291" in the "Media Types" registry.

メディアタイプ「video / smpte291」はセクション3.1で定義されています。 IANAは、「Media Types」レジストリに「video / smpte291」を登録しました。

7. Security Considerations

7. セキュリティに関する考慮事項

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not the responsibility of an RTP payload format to discuss or mandate what solutions are to be used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriately strong security mechanisms. The rest of this section discusses the security impacting properties of the payload format itself.

この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]およびRTP / AVP [RFC3551]、RTP / AVPF [RFC4585]、RTP / SAVP [ RFC3711]、またはRTP / SAVPF [RFC5124]。ただし、「RTPプロトコルフレームワークのセキュリティ保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]が説明しているように、基本的な要件を満たすために使用するソリューションを検討または義務付けることは、RTPペイロード形式の責任ではありません。一般的なRTPの機密性、整合性、ソースの信頼性などのセキュリティ目標。この責任は、アプリケーションでRTPを使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「RTPセッションを保護するためのオプション」[RFC7201]にあります。アプリケーションは、1つ以上の適切に強力なセキュリティメカニズムを使用する必要があります（SHOULD）。このセクションの残りの部分では、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。

To avoid potential buffer overflow attacks, receivers SHOULD validate that the ANC data packets in the RTP payload are of the appropriate length (using the Data_Count field) for the ANC data type specified by DID and SDID. Also, the Checksum_Word SHOULD be checked against the ANC data packet to ensure that its data has not been damaged in transit; note that the Checksum_Word is unlikely to provide a payload integrity check in case of a directed attack.

潜在的なバッファオーバーフロー攻撃を回避するために、受信者は、RTPペイロードのANCデータパケットが、DIDおよびSDIDで指定されたANCデータタイプに適切な長さであることを検証する必要があります（Data_Countフィールドを使用）。また、Checksum_WordはANCデータパケットに対してチェックして、転送中にデータが破損していないことを確認する必要があります（SHOULD）。 Checksum_Wordが直接攻撃の場合にペイロードの整合性チェックを提供する可能性は低いことに注意してください。

Some receivers will simply move the ANC data packet bits from the RTP payload into SDI. It might still be a good idea for these "re-embedders" to perform the above-mentioned validity tests to avoid downstream SDI systems from becoming confused by bad ANC data packets, which could be used for a denial-of-service attack.

一部のレシーバーは、ANCデータパケットビットをRTPペイロードからSDIに単純に移動します。これらの「再埋め込み」が上記の有効性テストを実行して、ダウンストリームSDIシステムがサービス拒否攻撃に使用される可能性のある不正なANCデータパケットによって混乱することを回避することは、依然として良い考えです。

"Re-embedders" into SDI SHOULD also double check that the Line_Number and Horizontal_Offset lead to the ANC data packet being inserted into a legal area to carry ANC data in the SDI video bit stream of the output video format.

SDIへの「再埋め込み」は、Line_NumberとHorizontal_OffsetがANCデータパケットを正当な領域に挿入し、出力ビデオ形式のSDIビデオビットストリームでANCデータを伝送することを再確認する必要もあります。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.

[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org / info / rfc3264>。

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/info/rfc3551>.

[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<https：//www.rfc-editor。 org / info / rfc3551>。

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.

[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<https://www.rfc-editor.org/info/rfc3711>。

[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.

[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。

[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.

[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<https://www.rfc-editor.org/info/rfc4855>。

[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <https://www.rfc-editor.org/info/rfc5124>.

[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<https ：//www.rfc-editor.org/info/rfc5124>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。

[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>.

[RFC5888] Camarillo、G。およびH. Schulzrinne、「セッション記述プロトコル（SDP）グループ化フレームワーク」、RFC 5888、DOI 10.17487 / RFC5888、2010年6月、<https://www.rfc-editor.org/info/ rfc5888>。

[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：//www.rfc- editor.org/info/rfc6838>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RP168] SMPTE, "RP 168:2009, Definition of Vertical Interval Switching Point for Synchronous Video Switching", 2009.

[RP168] SMPTE、「RP 168：2009、同期ビデオスイッチングの垂直間隔スイッチングポイントの定義」、2009。

[ST291] SMPTE, "SMPTE Standard - Ancillary Data Packet and Space Formatting", ST 291-1:2011, DOI 10.5594/SMPTE.ST291-1.2011, September 2011, <http://ieeexplore.ieee.org/document/7291794/>.

[ST291] SMPTE、「SMPTE標準-補助データパケットおよびスペースのフォーマット」、ST 291-1：2011、DOI 10.5594 / SMPTE.ST291-1.2011、2011年9月、<http://ieeexplore.ieee.org/document/7291794 />。

[ST352] SMPTE, "SMPTE Standard - Payload Identification Codes for Serial Digital Interfaces", ST 352:2013, DOI 10.5594/SMPTE.ST352.2013, February 2013, <http://ieeexplore.ieee.org/document/7290261/>.

[ST352] SMPTE、「SMPTE標準-シリアルデジタルインターフェイスのペイロード識別コード」、ST 352：2013、DOI 10.5594 / SMPTE.ST352.2013、2013年2月、<http://ieeexplore.ieee.org/document/7290261/ >。

[ST424] SMPTE, "SMPTE Standard - 3 Gb/s Signal/Data Serial Interface", ST 424:2012, DOI 10.5594/SMPTE.ST424.2012, October 2012, <http://ieeexplore.ieee.org/document/7290519/>.

[ST424] SMPTE、「SMPTE標準-3 Gb / s信号/データシリアルインターフェース」、ST 424：2012、DOI 10.5594 / SMPTE.ST424.2012、2012年10月、<http://ieeexplore.ieee.org/document/ 7290519 />。

8.2. Informative References

8.2. 参考引用

[BT656] ITU-R, "Interfaces for Digital Component Video Signals in 525-Line and 625-Line Television Systems Operating at the 4:2:2 Level of Recommendation ITU-R BT.601", ITU-R Recommendation BT.656-5, December 2007.

[BT656] ITU-R、「4：2：2レベルの勧告ITU-R BT.601で動作する525ラインおよび625ラインテレビシステムにおけるデジタルコンポーネントビデオ信号のインターフェイス」、ITU-R勧告BT.656 -5、2007年12月。

[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, September 2005, <https://www.rfc-editor.org/info/rfc4175>.

[RFC4175] Gharai、L。およびC. Perkins、「非圧縮ビデオのRTPペイロード形式」、RFC 4175、DOI 10.17487 / RFC4175、2005年9月、<https://www.rfc-editor.org/info/rfc4175>。

[RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload Format for JPEG 2000 Video Streams", RFC 5371, DOI 10.17487/RFC5371, October 2008, <https://www.rfc-editor.org/info/rfc5371>.

[RFC5371] Futemma、S.、Itakura、E.、A。Leung、「RTP Payload Format for JPEG 2000 Video Streams」、RFC 5371、DOI 10.17487 / RFC5371、2008年10月、<https：//www.rfc-editor .org / info / rfc5371>。

[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.

[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。

[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <https://www.rfc-editor.org/info/rfc7202>.

[RFC7202]パーキンス、C。およびM.ウェスターランド、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<https：//www.rfc- editor.org/info/rfc7202>。

[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, DOI 10.17487/RFC7273, June 2014, <https://www.rfc-editor.org/info/rfc7273>.

[RFC7273]ウィリアムズ、A。、グロス、K。、ファンブランデンブルク、R。、およびH.ストキング、「RTPクロックソースシグナリング」、RFC 7273、DOI 10.17487 / RFC7273、2014年6月、<https：//www.rfc -editor.org/info/rfc7273>。

[SMPTE-RA] SMPTE Registration Authority, LLC, "SMPTE Ancillary Data SMPTE ST 291", <https://smpte-ra.org/smpte-ancillary-data-smpte-st-291>.

[SMPTE-RA] SMPTE Registration Authority、LLC、「SMPTE Ancillary Data SMPTE ST 291」、<https://smpte-ra.org/smpte-ancillary-data-smpte-st-291>。

[ST2038] SMPTE, "SMPTE Standard - Carriage of Ancillary Data Packets in an MPEG-2 Transport Stream", ST 2038:2008, DOI 10.5594/SMPTE.ST2038.2008, September 2008, <http://ieeexplore.ieee.org/document/7290549/>.

[ST2038] SMPTE、「SMPTE標準-MPEG-2トランスポートストリームでの補助データパケットのキャリッジ」、ST 2038：2008、DOI 10.5594 / SMPTE.ST2038.2008、2008年9月、<http://ieeexplore.ieee.org / document / 7290549 />。

[ST259] SMPTE, "SMPTE Standard - For Television - SDTV Digital Signal/Data - Serial Digital Interface", ST 259:2008, DOI 10.5594/SMPTE.ST259.2008, January 2008, <http://ieeexplore.ieee.org/document/7292109/>.

[ST259] SMPTE、「SMPTE標準-テレビ-SDTVデジタル信号/データ-シリアルデジタルインターフェイス」、ST 259：2008、DOI 10.5594 / SMPTE.ST259.2008、2008年1月、<http://ieeexplore.ieee.org / document / 7292109 />。

[ST274] SMPTE, "SMPTE Standard - For Television - 1920 x 1080 Image Sample Structure, Digital Representation and Digital Timing Reference Sequences for Multiple Picture Rates", ST 274:2008, DOI 10.5594/SMPTE.ST274.2008, January 2008, <http://ieeexplore.ieee.org/document/7290129/>.

[ST274] SMPTE、「SMPTE標準-テレビ用-1920 x 1080画像サンプル構造、デジタル表現、および複数の画像レート用のデジタルタイミング参照シーケンス」、ST 274：2008、DOI 10.5594 / SMPTE.ST274.2008、2008年1月、< http://ieeexplore.ieee.org/document/7290129/>。

[ST292] SMPTE, "SMPTE Standard - 1.5 Gb/s Signal/Data Serial Interface", ST 292-1:2012, DOI 10.5594/SMPTE.ST292-1.2012, January 2012, <http://ieeexplore.ieee.org/document/7291770/>.

[ST292] SMPTE、「SMPTE標準-1.5 Gb / s信号/データシリアルインターフェース」、ST 292-1：2012、DOI 10.5594 / SMPTE.ST292-1.2012、2012年1月、<http://ieeexplore.ieee.org/ document / 7291770 />。

[ST296] SMPTE, "SMPTE Standard - 1280 x 720 Progressive Image 4:2:2 and 4:4:4 Sample Structure - Analog and Digital Representation and Analog Interface", ST 296:2012, DOI 10.5594/SMPTE.ST296.2012, May 2012, <http://ieeexplore.ieee.org/document/7291722/>.

[ST296] SMPTE、「SMPTE標準-1280 x 720プログレッシブイメージ4：2：2および4：4：4サンプル構造-アナログおよびデジタル表現とアナログインターフェイス」、ST 296：2012、DOI 10.5594 / SMPTE.ST296.2012 、2012年5月、<http://ieeexplore.ieee.org/document/7291722/>。

Author's Address

著者のアドレス

Thomas G. Edwards FOX 10201 W. Pico Blvd. Los Angeles, CA 90035 United States of America

トーマスG.エドワーズFOX 10201 W.ピコブルバード。ロサンゼルス、カリフォルニア州90035アメリカ合衆国

   Phone: +1 310 369 6696
   Email: thomas.edwards@fox.com