[要約] RFC 9134は、JPEG XS画像圧縮標準をリアルタイム通信プロトコルであるRTPで送信するためのペイロード形式を定義します。この文書の目的は、高品質で低遅延のビデオストリーミングやビデオ会議システムでJPEG XSを効率的に使用する方法を提供することです。主に放送、ライブイベントのストリーミング、リアルタイムビデオ通信などの分野で利用されます。
Internet Engineering Task Force (IETF) T. Bruylants
Request for Comments: 9134 intoPIX
Category: Standards Track A. Descampe
ISSN: 2070-1721 UCLouvain
C. Damman
intoPIX
T. Richter
Fraunhofer IIS
October 2021
RTP Payload Format for ISO/IEC 21122 (JPEG XS)
ISO / IEC 21122のRTPペイロードフォーマット（JPEG XS）
Abstract
概要
This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting video encoded with JPEG XS (ISO/ IEC 21122). JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and video frame rates while offering visually lossless quality, reduced power consumption, and encoding-decoding latency confined to a fraction of a video frame.
このドキュメントは、JPEG XS（ISO / IEC 21122）で符号化されたビデオを転送するために使用されるリアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットを指定します。JPEG XSは、低遅延軽量画像符号化システムである。非圧縮ビデオユースケースと比較して、視覚的に無損失の品質、消費電力の減少、およびビデオフレームの端数に限定された符号化復号レイテンシを提供しながら、より高い解像度およびビデオフレームレートを可能にする。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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/rfc9134.
この文書の現在のステータス、任意のエラータ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9134で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions, Definitions, and Abbreviations
3. Media Format Description
3.1. Image Data Structures
3.2. Codestream
3.3. Video Support Box and Color Specification Box
3.4. JPEG XS Frame
4. RTP Payload Format
4.1. RTP Packetization
4.2. RTP Header Usage
4.3. Payload Header Usage
4.4. Payload Data
5. Traffic Shaping and Delivery Timing
6. Congestion Control Considerations
7. Payload Format Parameters
7.1. Media Type Registration
8. SDP Parameters
8.1. Mapping of Payload Type Parameters to SDP
8.2. Usage with SDP Offer/Answer Model
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
This document specifies a payload format for packetization of video signals encoded with JPEG XS [ISO21122-1] into the Real-time Transport Protocol (RTP) [RFC3550].
このドキュメントは、JPEG XS [ISO21122-1]で符号化されたビデオ信号のパケット化のためのペイロードフォーマット（RFC3550]を指定します。
The JPEG XS coding system offers compression and recompression of image sequences with very moderate computational resources while remaining robust under multiple compression and decompression cycles as well as mixing of content sources, e.g., embedding of subtitles, overlays, or logos. Typical target compression ratios ensuring visually lossless quality are in the range of 2:1 to 10:1 depending on the nature of the source material. The latency that is introduced by the encoding-decoding process can be confined to a fraction of a video frame, typically between a small number of lines down to below a single line.
JPEG XS符号化システムは、多重圧縮および解凍サイクルの下でロバストに残っている間、およびコンテンツ源の混合、例えば字幕、オーバーレイ、またはロゴの混合を有する、非常に適度な計算リソースを有する画像シーケンスの圧縮および再圧縮を提供する。視覚的に無損失品質を確保する典型的な目標圧縮比は、原料の性質に応じて2：1から10：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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Application Data Unit (ADU): The unit of source data provided as payload to the transport layer. In this RTP payload definition, it corresponds to a single JPEG XS video frame.
アプリケーションデータユニット（ADU）：搬送層へのペイロードとして提供されるソースデータの単位。このRTPペイロード定義では、それは単一のJPEG XSビデオフレームに対応します。
Color Specification (CS) box: An ISO color specification box defined in [ISO21122-3] (JPEG XS Part 3) that includes color-related metadata required to correctly display JPEG XS video frames, such as color primaries, transfer characteristics, and matrix coefficients.
カラー仕様（CS）ボックス：カラープライマリ、転送特性、行列などのJPEG XSビデオフレームを正しく表示するために必要な色関連メタデータを含む[ISO21122-3]（JPEG XS部3）で定義されているISOカラー指定ボックス。係数
End of Codestream (EOC) marker: A marker that consists of the two bytes 0xff11 indicating the end of a JPEG XS codestream.
CodeStream（EOC）マーカー：JPEG XS CodeStreamの終わりを示す2バイト0xFF11からなるマーカー。
JPEG XS codestream: A sequence of bytes representing a compressed image formatted according to [ISO21122-1] (JPEG XS Part 1).
JPEG XS CODESTREAM：[ISO21122-1]（JPEG XS部1）に従ってフォーマットされた圧縮画像を表すバイトのシーケンス。
JPEG XS codestream header: A sequence of bytes, starting with an SOC marker, at the beginning of each JPEG XS codestream encoded in multiple markers and marker segments that does not carry entropy coded data, but metadata such as the video frame dimension and component precision.
JPEG XS Codestreamヘッダ：SoCマーカーから始めて、SoCマーカーから始めて、エントロピー符号化データを伝送しない複数のマーカーとマーカーセグメントでエンコードされていますが、ビデオフレームのディメンションやコンポーネントの精度などのメタデータが符号化されています。。
JPEG XS frame: In the case of progressive video, a single JPEG XS picture segment. In the case of interlaced video, the concatenation of two JPEG XS picture segments.
JPEG XSフレーム：プログレッシブビデオの場合は、単一のJPEG XSピクチャセグメントです。インターレースビデオの場合、2つのJPEG XSピクチャセグメントの連結。
JPEG XS header segment: The concatenation of a video support box [ISO21122-3], a color specification box [ISO21122-3], and a JPEG XS codestream header.
JPEG XSヘッダーセグメント：ビデオサポートボックス[ISO21122-3]、色指定ボックス[ISO21122-3]、およびJPEG XS Codestreamヘッダーの連結。
JPEG XS picture segment: The concatenation of a video support box [ISO21122-3], a color specification box [ISO21122-3], and a JPEG XS codestream.
JPEG XSピクチャセグメント：ビデオサポートボックス[ISO21122-3]、カラー指定ボックス[ISO21122-3]、およびJPEG XS CodeStreamの連結。
JPEG XS stream: A sequence of JPEG XS frames.
JPEG XSストリーム：JPEG XSフレームのシーケンス。
Marker: A two-byte functional sequence that is part of a JPEG XS codestream starting with a 0xff byte and a subsequent byte defining its function.
Marker：0xFFバイトから始まるJPEG XS CodeStreamの一部である2バイトの機能シーケンスとその関数を定義する次のバイト。
Marker segment: A marker along with a 16-bit marker size and payload data following the size.
マーカーセグメント：サイズに続く16ビットマーカーサイズとペイロードデータと共にマーカー。
Packetization unit: A portion of an ADU whose boundaries coincide with boundaries of RTP packet payloads (excluding payload header), i.e., the first (or respectively, last) byte of a packetization unit is the first (or respectively, last) byte of an RTP packet payload (excluding its payload header).
パケット化単位：境界がRTPパケットペイロードの境界（ペイロードヘッダを除く）、すなわちパケット化ユニットの最初の（またはそれぞれ最後の）バイトの境界と一致するADUの一部は、RTPパケットペイロード（ペイロードヘッダーを除く）
SLH (SLice Header) marker: A marker that represents a slice header, as defined in [ISO21122-1].
SLH（スライスヘッダー）マーカー：[ISO21122-1]で定義されているスライスヘッダーを表すマーカー。
Slice: The smallest independently decodable unit of a JPEG XS codestream, bearing in mind that it decodes to wavelet coefficients, which still require inverse wavelet filtering to give an image.
スライス：JPEG XS Codestreamの最小の独立して復号可能なユニットは、それがウェーブレット係数に復号することを留めており、それでも逆ウェーブレットフィルタリングを必要とし、画像を与えるために逆ウェーブレットフィルタリングを必要とします。
Start of a Codestream (SOC) marker: A marker that consists of the two bytes 0xff10 indicating the start of a JPEG XS codestream. The SOC marker is considered an integral part of the JPEG XS codestream header.
CodeStream（SoC）マーカーの開始：JPEG XS CodeStreamの開始を示す2バイト0xFF10からなるマーカー。SOCマーカーは、JPEG XS Codestreamヘッダーの不可欠な部分と見なされます。
Video Support (VS) box: An ISO video support box, as defined in [ISO21122-3], that includes metadata required to play back a JPEG XS stream; such metadata could include its maximum bit rate, its subsampling structure, its buffer model, and its frame rate.
ビデオサポート（VS）ボックス：[ISO21122-3]で定義されているISOビデオサポートボックス.JPEG XSストリームを再生するために必要なメタデータ。そのようなメタデータは、その最大ビットレート、そのサブサンプリング構造、そのバッファモデル、およびそのフレームレートを含み得る。
This section explains the terminology and concepts used in this memo specific to JPEG XS as specified in [ISO21122-1], [ISO21122-2], and [ISO21122-3].
このセクションでは、[ISO21122-1]、[ISO21122-2]、[ISO21122-3]で指定されているJPEG XSに固有のJPEG XSに固有のメモと概念について説明します。
JPEG XS is a low-latency, lightweight image coding system for coding continuous-tone grayscale or continuous-tone color digital images.
JPEG XSは、連続トーングレースケールまたは連続トーンカラーデジタル画像を符号化するための低遅延軽量画像符号化システムである。
This coding system provides an efficient representation of image signals through the mathematical tool of wavelet analysis. The wavelet filter process separates each component into multiple bands, where each band consists of multiple coefficients describing the image signal of a given component within a frequency domain specific to the wavelet filter type, i.e., the particular filter corresponding to the band.
このコーディングシステムは、ウェーブレット分析の数学的ツールを通して画像信号の効率的な表現を提供する。ウェーブレットフィルタプロセスは、各コンポーネントを複数のバンドに分離します。そこで、各バンドは、ウェーブレットフィルタタイプ、すなわち帯域に対応する特定のフィルタの周波数領域内の所与のコンポーネントの画像信号を記述する複数の係数からなる。
Wavelet coefficients are grouped into precincts, where each precinct includes all coefficients over all bands that contribute to a spatial region of the image.
ウェーブレット係数はプレシンクトに分類され、各区画は画像の空間領域に寄与するすべてのバンドにわたるすべての係数を含む。
One or multiple precincts are furthermore combined into slices consisting of an integer number of precincts. Precincts do not cross slice boundaries, and wavelet coefficients in precincts that are part of different slices can be decoded independently of each other. However, note that the wavelet transformation runs across slice boundaries. A slice always extends over the full width of the image but may only cover parts of its height.
1つまたは複数のプレシンクトはさらに、整数の境界線からなるスライスに組み合わされます。プレシンクトはスライス境界を渡さないため、異なるスライスの一部であるプレシンクトのウェーブレット係数を互いに独立して復号することができます。ただし、ウェーブレット変換はスライス境界を越えて実行されます。スライスは常に画像の全幅にわたって延びていますが、その高さの一部をカバーするだけです。
A JPEG XS codestream is formed by (in the given order):
JPEG XS Codestreamが（指定された順序で）形成されます。
* a JPEG XS codestream header, which starts with a Start of Codestream (SOC) marker,
* Codestream（SoC）マーカーの開始から始まるJPEG XS Codestreamヘッダー
* one or more slices,
* 1つ以上のスライス、
* an EOC marker to signal the end of the codestream.
* コードストリームの終わりを通知するためのEOCマーカー。
The JPEG XS codestream format, including the definition of all markers, is further defined in [ISO21122-1]. It represents sample values of a single image, without any interpretation relative to a color space.
すべてのマーカーの定義を含むJPEG XS Codestreamフォーマットは、[ISO21122-1]でさらに定義されています。色空間に対する解釈なしに、単一の画像のサンプル値を表します。
While the information defined in the codestream is sufficient to reconstruct the sample values of one image, the interpretation of the samples remains undefined by the codestream itself. This interpretation is given by the video support box and the color specification box, which contain significant information to correctly play the JPEG XS stream. The layout and syntax of these boxes, together with their content, are defined in [ISO21122-3].
コードストリームで定義されている情報は1つの画像のサンプル値を再構築するのに十分であるが、サンプルの解釈はコードストリーム自体によって未定義のままである。この解釈は、JPEG XSストリームを正しく再生するための重要な情報を含むビデオサポートボックスとカラー指定ボックスによって与えられます。これらのボックスのレイアウトと構文は、それらのコンテンツとともに[ISO21122-3]で定義されています。
The video support box provides information on the maximum bit rate, the frame rate, the interlaced mode (progressive or interlaced), the subsampling image format, the informative timecode of the current JPEG XS frame, the profile, the level/sublevel used, and optionally the buffer model and the mastering display metadata.
ビデオサポートボックスは、最大ビットレート、フレームレート、インターレースモード（プログレッシブまたはインターレース）、サブサンプリング画像フォーマット、現在のJPEG XSフレームの有益なタイムコード、プロファイル、使用されるレベル/ SUBLEVELに関する情報を提供する。オプションでバッファモデルとマスタリング表示メタデータ。
Note that the profile and level/sublevel, specified respectively by the Ppih and Plev fields [ISO21122-2], specify limits on the capabilities needed to decode the codestream and handle the output. Profiles represent a limit on the required algorithmic features and parameter ranges used in the codestream. The combination of level and sublevel defines a lower bound on the required throughput for a decoder in the image (or decoded) domain and the codestream (or coded) domain, respectively. The actual defined profiles and levels/ sublevels, along with the associated values for the Ppih and Plev fields, are defined in [ISO21122-2].
PPIHフィールドとPLEVフィールド[ISO21122-2]でそれぞれ指定されたプロファイルとレベル/ SUBLEVELは、CODESTREAMをデコードして出力を処理するために必要な機能の制限を指定します。プロファイルは、コードストリームで使用される必要なアルゴリズム機能とパラメータ範囲の制限を表します。LEVELとSUBLEVELの組み合わせは、画像（または復号化された）ドメイン内のデコーダの必要なスループットとCodeStream（またはコード化された）ドメインの下限を定義します。実際に定義されたプロファイルとレベル/ SUbleVelは、PPIHフィールドとPLEVフィールドの関連値とともに、[ISO21122-2]で定義されています。
The color specification box indicates the color primaries, transfer characteristics, matrix coefficients, and video full range flag needed to specify the color space of the video stream.
色指定ボックスは、ビデオストリームの色空間を指定するために必要な色の原色、伝達特性、行列係数、およびビデオ全範囲のフラグを示す。
The concatenation of a video support box, a color specification box, and a JPEG XS codestream forms a JPEG XS picture segment.
ビデオサポートボックス、カラー指定ボックス、およびJPEG XSコードストリームの連結は、JPEG XSピクチャセグメントを形成します。
In the case of a progressive video stream, each JPEG XS frame consists of one single JPEG XS picture segment.
プログレッシブビデオストリームの場合、各JPEG XSフレームは1つの単一のJPEG XSピクチャセグメントからなる。
In the case of an interlaced video stream, each JPEG XS frame is made of two concatenated JPEG XS picture segments. The codestream of each picture segment corresponds exclusively to one of the two fields of the interlaced frame. Both picture segments SHALL contain identical boxes (i.e., the byte sequence that contains the concatenation of the video support box and the color specification box is exactly the same in both picture segments of the frame).
インターレースビデオストリームの場合、各JPEG XSフレームは2つの連結JPEG XSピクチャセグメントでできています。各ピクチャセグメントのコードストリームは、インターレースフレームの2つのフィールドのうちの1つに排他的に対応する。両方の写真セグメントには同一のボックス（すなわち、ビデオサポートボックスの連結を含むバイトシーケンス、およびカラー仕様ボックスがフレームの両方のピクチャセグメントにおいて全く同じ）を含むものとする。
Note that the interlaced mode, as signaled by the frat field [ISO21122-3] in the video support box, indicates either progressive interlaced top-field-first or interlaced bottom-field-first mode. Thus, in the case of interlaced content, its value SHALL also be identical in both picture segments.
ビデオサポートボックスのFRATフィールド[ISO21122-3]によってシグナリングされたインターレースモードは、プログレッシブインターレーストップフィールド1またはインターレースボトムフィールド初のモードのいずれかを示しています。したがって、インターレースコンテンツの場合、その値も両方のピクチャセグメントで同じでなければならない。
This section specifies the payload format for JPEG XS streams over the Real-time Transport Protocol (RTP) [RFC3550].
このセクションでは、Real-Time Transport Protocol（RTP）[RFC3550]を介したJPEG XSストリームのペイロード形式を指定します。
In order to be transported over RTP, each JPEG XS stream is transported in a distinct RTP stream, identified by a distinct synchronization source (SSRC) [RFC3550].
RTPを介して輸送されるために、各JPEG XSストリームは、異なる同期ソース（SSRC）[RFC3550]によって識別される異なるRTPストリームで転送されます。
A JPEG XS stream is divided into Application Data Units (ADUs), each ADU corresponding to a single JPEG XS frame.
JPEG XSストリームはアプリケーションデータユニット（ADU）に分割され、各ADUは単一のJPEG XSフレームに対応する。
An ADU is made of several packetization units. If a packetization unit is bigger than the maximum size of an RTP packet payload, the unit is split into multiple RTP packet payloads, as illustrated in Figure 1. As seen there, each packet SHALL contain (part of) one, and only one, packetization unit. A packetization unit may extend over multiple packets. The payload of every packet SHALL have the same size (based, e.g., on the Maximum Transfer Unit of the network) with the possible exception of the last packet of a packetization unit. The boundaries of a packetization unit SHALL coincide with the boundaries of the payload of a packet (excluding the payload header), i.e., the first (or, respectively, last) byte of the packetization unit SHALL be the first (or, respectively, last) byte of the payload (excluding its header).
ADUは複数のパケット化単位でできています。パケット化単位がRTPパケットペイロードの最大サイズより大きい場合、図1に示すように、ユニットは複数のRTPパケットペイロードに分割されます。パケット化単位パケット化ユニットは複数のパケットを介して延びることができる。すべてのパケットのペイロードは、パケット化ユニットの最後のパケットを除いて、同じサイズ（例えば、ネットワークの最大転送単位に基づいて）を有するものとする。パケット化ユニットの境界は、パケットのペイロードの境界（ペイロードヘッダを除く）、すなわちパケット化ユニットの最初の（またはそれぞれ最後の）バイトと一致しなければならない（それぞれ最後のもの）。）ペイロードのバイト（そのヘッダを除く）。
RTP +-----+------------------------+
Packet #1 | Hdr | Packetization unit #1 |
+-----+------------------------+
RTP +-----+--------------------------------------+
Packet #2 | Hdr | Packetization unit #2 |
+-----+--------------------------------------+
RTP +-----+--------------------------------------------------+
Packet #3 | Hdr | Packetization unit #3 (part 1/3) |
+-----+--------------------------------------------------+
RTP +-----+--------------------------------------------------+
Packet #4 | Hdr | Packetization unit #3 (part 2/3) |
+-----+--------------------------------------------------+
RTP +-----+----------------------------------------------+
Packet #5 | Hdr | Packetization unit #3 (part 3/3) |
+-----+----------------------------------------------+
...
RTP +-----+-----------------------------------------+
Packet #P | Hdr | Packetization unit #N (part q/q) |
+-----+-----------------------------------------+
Figure 1: Example of ADU Packetization
図1：ADUパケット化の例
There are two different packetization modes defined for this RTP payload format.
このRTPペイロード形式に対して2つの異なるパケット化モードが定義されています。
Codestream packetization mode: In this mode, the packetization unit SHALL be the entire JPEG XS picture segment (i.e., codestream preceded by boxes). This means that a progressive frame will have a single packetization unit, while an interlaced frame will have two. The progressive case is illustrated in Figure 2.
CodeStreamパケット化モード：このモードでは、パケット化ユニットはJPEG XSピクセルセグメント全体（すなわち、ボックスが先行する符号ストリーム）とする。これは、プログレッシブフレームが単一のパケット化ユニットを持ち、インターレースフレームは2つを持つことを意味します。プログレッシブケースを図2に示します。
Slice packetization mode: In this mode, the packetization unit SHALL be the slice, i.e., there SHALL be data from no more than one slice per RTP packet. The first packetization unit SHALL be made of the JPEG XS header segment (i.e., the concatenation of the VS box, the CS box, and the JPEG XS codestream header). This first unit is then followed by successive units, each containing one and only one slice. The packetization unit containing the last slice of a JPEG XS codestream SHALL also contain the EOC marker immediately following this last slice. This is illustrated in Figure 3. In the case of an interlaced frame, the JPEG XS header segment of the second field SHALL be in its own packetization unit.
スライスパケット化モード：このモードでは、パケット化ユニットはスライス、すなわちRTPパケットごとに複数のスライスからのデータがあるものとする。第1のパケット化ユニットは、JPEG XSヘッダセグメント（すなわち、VSボックス、CSボックス、およびJPEG XSコードストリームヘッダの連結）で構成されなければならない。この第1のユニットの後に続く連続した単位が続き、それぞれが1つだけのスライスを含む。JPEG XS Codestreamの最後のスライスを含むパケット化ユニットはまた、この最後のスライスの直後のEOCマーカーを含みます。これは図3に示されている。インターレースフレームの場合、第2のフィールドのJPEG XSヘッダセグメントはそれ自身のパケット化ユニットになければならない。
RTP +-----+--------------------------------------------------+
Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) |
+-----+--------------------------------------------------+
RTP +-----+--------------------------------------------------+
Packet #2 | Hdr | JPEG XS codestream (part 2/q) |
+-----+--------------------------------------------------+
...
RTP +-----+--------------------------------------+
Packet #P | Hdr | JPEG XS codestream (part q/q) |
+-----+--------------------------------------+
Figure 2: Example of Codestream Packetization Mode
図2：CodeStreamパケット化モードの例
RTP +-----+----------------------------+
Packet #1 | Hdr | JPEG XS header segment |
+-----+----------------------------+
RTP +-----+--------------------------------------------------+
Packet #2 | Hdr | Slice #1 (part 1/2) |
+-----+--------------------------------------------------+
RTP +-----+-------------------------------------------+
Packet #3 | Hdr | Slice #1 (part 2/2) |
+-----+-------------------------------------------+
RTP +-----+--------------------------------------------------+
Packet #4 | Hdr | Slice #2 (part 1/3) |
+-----+--------------------------------------------------+
...
RTP +-----+---------------------------------------+
Packet #P | Hdr | Slice #N (part q/q) + EOC marker |
+-----+---------------------------------------+
Figure 3: Example of Slice Packetization Mode
図3：スライスパケット化モードの例
In a constant bitrate (CBR) scenario of JPEG XS, the codestream packetization mode guarantees that a JPEG XS RTP stream will produce both a constant number of bytes per video frame and a constant number of RTP packets per video frame. However, to provide similar guarantees with JPEG XS in a variable bitrate (VBR) mode or when using the slice packetization mode (for either CBR or VBR), additional mechanisms are needed. This can involve a constraint at the rate allocation stage in the JPEG XS encoder to impose a CBR at the slice level, the usage of padding data, or the insertion of empty RTP packets (i.e., an RTP packet whose payload data is empty). But, management of the amount of produced packets per video frame is application dependent and not a strict requirement of this RTP payload specification.
JPEG XSの一定のビットレート（CBR）シナリオでは、CodeStreamパケット化モードは、JPEG XS RTPストリームがビデオフレームごとに一定のバイト数とビデオフレームごとに一定の数のRTPパケットの両方を生成することを保証します。ただし、可変ビットレート（VBR）モードでのJPEG XSを類似した保証を提供するために、またはスライスパケット化モード（CBRまたはVBRのいずれか）を使用する場合は、追加のメカニズムが必要です。これは、JPEG XSエンコーダ内のレート割り当て段階での制約を含み、スライスレベル、パディングデータの使用、または空のRTPパケットの挿入（すなわち、ペイロードデータが空のRTPパケット）にCBRを課すことを含み得る。しかし、ビデオフレームごとの生成されたパケットの管理の管理はアプリケーションに依存し、このRTPペイロード仕様の厳密な要件ではありません。
The format of the RTP header is specified in [RFC3550] and reprinted in Figure 4 for convenience. This RTP payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーのフォーマットは[RFC3550]で指定され、便宜上、図4で再印刷されています。このRTPペイロードフォーマットは、その仕様と一致する方法でヘッダーのフィールドを使用します。
The RTP payload (and the settings for some RTP header bits) for packetization units are specified in Section 4.3.
パケット化単位のRTPペイロード（および一部のRTPヘッダビットの設定）はセクション4.3で指定されています。
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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTP Header According to RFC 3550
図4：RFC 3550によるRTPヘッダー
The version (V), padding (P), extension (X), CSRC count (CC), sequence number, synchronization source (SSRC), and contributing source (CSRC) fields follow their respective definitions in [RFC3550].
バージョン（v）、パディング（P）、拡張子（x）、CSRC Count（CC）、シーケンス番号、同期ソース（SSRC）、およびCOMPLENT SOURCE（CSRC）フィールドは、[RFC3550]のそれぞれの定義に従います。
The remaining RTP header information to be set according to this RTP payload format is set as follows:
このRTPペイロード形式に従って設定される残りのRTPヘッダ情報は次のように設定されています。
Marker (M) [1 bit]: If progressive scan video is being transmitted, the marker bit denotes the end of a video frame. If interlaced video is being transmitted, it denotes the end of the field. The marker bit SHALL be set to 1 for the last packet of the video frame/field. It SHALL be set to 0 for all other packets.
マーカー（M）[1ビット]：プログレッシブスキャンビデオが送信されている場合、マーカービットはビデオフレームの終了を表します。インターレースビデオが送信されている場合、それはフィールドの終わりを表します。マーカービットは、ビデオフレーム/フィールドの最後のパケットに対して1に設定されなければならない。他のすべてのパケットの場合は0に設定されます。
Payload Type (PT) [7 bits]: The payload type is a dynamically allocated payload type field that designates the payload as JPEG XS video.
ペイロードタイプ（PT）[7ビット]：ペイロードタイプは、JPEG XSビデオとしてペイロードを指定する動的に割り当てられたペイロードタイプフィールドです。
Timestamp [32 bits]: The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz clock rate SHALL be used.
TIMESTAMP [32ビット]：RTPタイムスタンプは、コンテンツのサンプリングタイムスタンプに設定されています。90 kHzのクロックレートを使用します。
As specified in [RFC3550] and [RFC4175], the RTP timestamp designates the sampling instant of the first octet of the video frame to which the RTP packet belongs. Packets SHALL NOT include data from multiple video frames, and all packets belonging to the same video frame SHALL have the same timestamp. Several successive RTP packets will consequently have equal timestamps if they belong to the same video frame (that is until the marker bit is set to 1, marking the last packet of the video frame), and the timestamp is only increased when a new video frame begins.
[RFC3550]と[RFC4175]で指定されているように、RTPタイムスタンプは、RTPパケットが属するビデオフレームの最初のオクテットのサンプリング瞬間を指定します。パケットは複数のビデオフレームからのデータを含めてはならず、同じビデオフレームに属するすべてのパケットは同じタイムスタンプを持つものとします。その結果、同じビデオフレームに属している場合（マーカービットが1に設定され、ビデオフレームの最後のパケットをマークするまで）、いくつかの連続した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.
サンプリングインスタントがクロックの整数値に対応していない場合、値はあいまいさなしで次の最低整数に切り捨てられます。
The first four bytes of the payload of an RTP packet in this RTP payload format are referred to as the "payload header". Figure 5 illustrates the structure of this payload header.
このRTPペイロード形式のRTPパケットのペイロードの最初の4バイトを「ペイロードヘッダ」と呼ぶ。図5は、このペイロードヘッダの構造を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|K|L| I |F counter| SEP counter | P counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Payload Header
図5：ペイロードヘッダー
The payload header consists of the following fields:
ペイロードヘッダーは、次のフィールドで構成されています。
Transmission mode (T) [1 bit]: The T bit is set to indicate that packets are sent sequentially by the transmitter. This information allows a receiver to dimension its input buffer(s) accordingly. If T=0, nothing can be assumed about the transmission order and packets may be sent out of order by the transmitter. If T=1, packets SHALL be sent sequentially by the transmitter. The T-bit value SHALL be identical for all packets of the RTP stream.
送信モード（T）[1ビット]：Tビットは、送信機によってパケットが順次送信されることを示すために設定されます。この情報により、受信側はそれに応じてその入力バッファを寸法設定することができます。T = 0の場合、伝送順序については何も想定できず、パケットは送信機によって順序から順序で送信され得る。T = 1の場合、パケットは送信機によって順次送信されなければならない。Tビット値は、RTPストリームのすべてのパケットごとに同じでなければならない。
pacKetization mode (K) [1 bit]: The K bit is set to indicate which packetization mode is used. K=0 indicates codestream packetization mode, while K=1 indicates slice packetization mode. In the case that the Transmission mode (T) is set to 0 (out of order), the slice packetization mode SHALL be used and K SHALL be set to 1. This is required because only the slice packetization mode supports out-of-order packet transmission. The K-bit value SHALL be identical for all packets of the RTP stream.
パケット化モード（k）[1ビット]：kビットはどのパケット化モードを使用するかを示すために設定されます。k = 0はコードストリームパケット化モードを示し、k = 1はスライスパケット化モードを示す。送信モード（t）が0に設定されている場合は、スライスパケット化モードを使用し、スライスパケット化モードのみが順番をサポートするため、これは1に設定されなければならない。パケット送信kビット値は、RTPストリームのすべてのパケットごとに同じでなければならない。
Last (L) [1 bit]: The L bit is set to indicate the last packet of a packetization unit. As the end of the video frame also ends the packet containing the last unit of the video frame, the L bit is set whenever the M bit is set. In the codestream packetization mode, the L bit and M bit get an equivalent meaning, so they SHALL have identical values in each packet.
Last（L）[1ビット]：Lビットは、パケット化単位の最後のパケットを示すために設定されます。ビデオフレームの終わりがビデオフレームの最後のユニットを含むパケットも終了すると、Mビットが設定されるたびにLビットが設定されます。コードストリームパケット化モードでは、LビットとMビットは同等の意味を得るので、それらは各パケットに同じ値を持つものとします。
Interlaced information (I) [2 bits]: These two I bits are used to indicate how the JPEG XS frame is scanned (progressive or interlaced). In case of an interlaced frame, they also indicate which JPEG XS picture segment the payload is part of (first or second).
インターレース情報（i）[2ビット]：これら2つのビットは、JPEG XSフレームがどのようにスキャンされるか（プログレッシブまたはインターレース）を示すために使用されます。インターレースフレームの場合、それらはどのJPEG XSピクチャセグメントがペイロードの一部（1または2秒）かを示しています。
00: The payload is progressively scanned.
00：ペイロードは次第にスキャンされます。
01: This value is reserved for future use.
01：この値は将来の使用のために予約されています。
10: The payload is part of the first JPEG XS picture segment of an interlaced video frame. The height specified in the included JPEG XS codestream header is half of the height of the entire displayed image.
10：ペイロードは、インターレースビデオフレームの最初のJPEG XSピクチャセグメントの一部です。含まれているJPEG XS Codestreamヘッダーに指定されている高さは、表示されている画像全体の高さの半分です。
11: The payload is part of the second JPEG XS picture segment of an interlaced video frame. The height specified in the included JPEG XS codestream header is half of the height of the entire displayed image.
11：ペイロードは、インターレースビデオフレームの第2のJPEG XS画像セグメントの一部である。含まれているJPEG XS Codestreamヘッダーに指定されている高さは、表示されている画像全体の高さの半分です。
F counter [5 bits]: The Frame (F) counter identifies the video frame number modulo 32 to which a packet belongs. Frame numbers are incremented by 1 for each video frame transmitted. The frame number, in addition to the timestamp, may help the decoder manage its input buffer and bring packets back into their natural order.
Fカウンタ[5ビット]：フレーム（F）カウンタは、パケットが属するビデオフレーム番号モジュロ32を識別します。送信された各ビデオフレームに対して、フレーム番号は1だけインクリメントされます。タイムスタンプに加えて、フレーム番号は、デコーダがその入力バッファを管理し、パケットを自然な順序に戻すのに役立ちます。
Slice and Extended Packet (SEP) counter [11 bits]: The SEP counter is used differently depending on the packetization mode.
スライスと拡張パケット（SEP）カウンタ[11ビット]：SEPカウンタはパケット化モードによって異なります。
* In the case of codestream packetization mode (K=0), this counter resets whenever the Packet counter resets (see Section 4.4) and increments by 1 whenever the Packet counter overruns.
* CODESTREAMパケット化モード（k = 0）の場合、このカウンタはパケットカウンタがリセットされるたびにリセットされます（セクション4.4）、パケットカウンタがオーバーランするたびに1だけインクリメントします。
* In the case of slice packetization mode (K=1), this counter identifies the slice modulo 2047 to which the packet contributes. If the data belongs to the JPEG XS header segment, this field SHALL have its maximal value, namely 2047 = 0x07ff. Otherwise, it is the slice index modulo 2047. Slice indices are counted from 0 (corresponding to the top of the video frame).
* スライスパケット化モード（k = 1）の場合、このカウンタは、パケットが寄与するスライスモジュロ2047を識別する。データがJPEG XSヘッダーセグメントに属している場合、このフィールドは最大値、すなわち2047 = 0x07FFを持つものとします。それ以外の場合は、スライスインデックスモジュロ2047です。スライスインデックスは0からカウントされます（ビデオフレームの上部に対応）。
P counter [11 bits]: The Packet (P) counter identifies the packet number modulo 2048 within the current packetization unit. It is set to 0 at the start of the packetization unit and incremented by 1 for every subsequent packet (if any) belonging to the same unit. Practically, if codestream packetization mode is enabled, this field counts the packets within a JPEG XS picture segment and is extended by the SEP counter when it overruns. If slice packetization mode is enabled, this field counts the packets within a slice or within the JPEG XS header segment.
Pカウンタ[11ビット]：パケット（P）カウンタは、現在のパケット化ユニット内のパケット番号モジュロ2048を識別する。パケット化単位の開始時に0に設定され、同じユニットに属する後続のパケットごとに1だけインクリメントされます。実際には、CODESTREAMパケット化モードが有効になっている場合、このフィールドはJPEG XSピクチャセグメント内のパケットをカウントし、オーバーランしたときにSEPカウンタによって拡張されます。スライスパケット化モードが有効になっている場合、このフィールドはスライス内またはJPEG XSヘッダーセグメント内のパケットをカウントします。
The payload data of a JPEG XS RTP stream consists of a concatenation of multiple JPEG XS frames. Within the RTP stream, all of the video support boxes and all of the color specification boxes SHALL retain their respective layouts for each JPEG XS frame. Thus, each video support box in the RTP stream SHALL define the same sub boxes. The effective values in the boxes are allowed to change under the condition that their relative byte offsets SHALL NOT change.
JPEG XS RTPストリームのペイロードデータは、複数のJPEG XSフレームの連結で構成されています。RTPストリーム内では、すべてのビデオサポートボックスとすべての色指定ボックスが各JPEG XSフレームに対してそれぞれのレイアウトを保持しなければならない。したがって、RTPストリーム内の各ビデオサポートボックスは同じサブボックスを定義するものとします。ボックス内の実効値は、相対バイトオフセットが変更されない状態で変更できます。
Each JPEG XS frame is the concatenation of one or more packetization unit(s), as explained in Section 4.1. Figure 6 depicts this layout for a progressive video frame in the codestream packetization mode, Figure 7 depicts this layout for an interlaced video frame in the codestream packetization mode, Figure 8 depicts this layout for a progressive video frame in the slice packetization mode, and Figure 9 depicts this layout for an interlaced video frame in the slice packetization mode. The Frame counter value is not indicated because the value is constant for all packetization units of a given video frame.
各JPEG XSフレームは、セクション4.1で説明されているように、1つまたは複数のパケット化単位の連結である。図6は、コードストリームパケット化モードでのプログレッシブビデオフレームのこのレイアウトを示しており、図7はCodeStreamパケット化モードでのインターレースビデオフレームのこのレイアウトを示し、図8はスライスパケット化モードのプログレッシブビデオフレームのこのレイアウトを示し、図8は、スライスパケット化モードでのプログレッシブビデオフレームのこのレイアウトを示しています。図9は、スライスパケット化モードにおけるインターレースビデオフレームに対するこのレイアウトを示す。フレームカウンタ値は、所与のビデオフレームの全てのパケット化単位に対して値が一定であるため表示されない。
+=====[ Packetization unit (PU) #1 ]====+
| Video support box | SEP counter=0
| +---------------------------------+ | P counter=0
| : Sub boxes of the VS box : |
| +---------------------------------+ |
+- - - - - - - - - - - - - - - - - - - -+
| Color specification box |
| +---------------------------------+ |
| : Fields of the CS box : |
| +---------------------------------+ |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream |
: (part 1/q) : M=0, K=0, L=0, I=00
+---------------------------------------+
| JPEG XS codestream | SEP counter=0
| (part 2/q) | P counter=1
: : M=0, K=0, L=0, I=00
+---------------------------------------+
| JPEG XS codestream | SEP counter=0
| (part 3/q) | P counter=2
: : M=0, K=0, L=0, I=00
+---------------------------------------+
: :
+---------------------------------------+
| JPEG XS codestream | SEP counter=1
| (part 2049/q) | P counter=0
: : M=0, K=0, L=0, I=00
+---------------------------------------+
: :
+---------------------------------------+
| JPEG XS codestream | SEP counter=(q-1) div 2048
| (part q/q) | P counter=(q-1) mod 2048
: : M=1, K=0, L=1, I=00
+=======================================+
Figure 6: Example of JPEG XS Payload Data (Codestream Packetization Mode, Progressive Video Frame)
図6：JPEG XSペイロードデータの例（CodeStream Packetization Mode、プログレッシブビデオフレーム）
+=====[ Packetization unit (PU) #1 ]====+
| Video support box | SEP counter=0
+- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream (1st field) |
: (part 1/q) : M=0, K=0, L=0, I=10
+---------------------------------------+
| JPEG XS codestream (1st field) | SEP counter=0
| (part 2/q) | P counter=1
: : M=0, K=0, L=0, I=10
+---------------------------------------+
: :
+---------------------------------------+
| JPEG XS codestream (1st field) | SEP counter=1
| (part 2049/q) | P counter=0
: : M=0, K=0, L=0, I=10
+---------------------------------------+
: :
+---------------------------------------+
| JPEG XS codestream (1st field) | SEP counter=(q-1) div 2048
| (part q/q) | P counter=(q-1) mod 2048
: : M=1, K=0, L=1, I=10
+===============[ PU #2 ]===============+
| Video support box | SEP counter=0
+- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream (2nd field) |
| (part 1/q) |
: : M=0, K=0, L=0, I=11
+---------------------------------------+
| JPEG XS codestream (2nd field) | SEP counter=0
| (part 2/q) | P counter=1
: : M=0, K=0, L=0, I=11
+---------------------------------------+
: :
+---------------------------------------+
| JPEG XS codestream (2nd field) | SEP counter=(q-1) div 2048
| (part q/q) | P counter=(q-1) mod 2048
: : M=1, K=0, L=1, I=11
+=======================================+
Figure 7: Example of JPEG XS Payload Data (Codestream Packetization Mode, Interlaced Video Frame)
図7：JPEG XSペイロードデータの例（コードストリームパケット化モード、インターレースビデオフレーム）
+===[ PU #1: JPEG XS Header segment ]===+
| Video support box | SEP counter=0x07FF
+- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header |
| +---------------------------------+ |
| : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=00
+==========[ PU #2: Slice #1 ]==========+
| +---------------------------------+ | SEP counter=0
| | SLH Marker | | P counter=0
| +---------------------------------+ |
| : Entropy Coded Data : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=00
+==========[ PU #3: Slice #2 ]==========+
| Slice #2 | SEP counter=1
| (part 1/q) | P counter=0
: : M=0, T=0, K=1, L=0, I=00
+---------------------------------------+
| Slice #2 | SEP counter=1
| (part 2/q) | P counter=1
: : M=0, T=0, K=1, L=0, I=00
+---------------------------------------+
: :
+---------------------------------------+
| Slice #2 | SEP counter=1
| (part q/q) | P counter=q-1
: : M=0, T=0, K=1, L=1, I=00
+=======================================+
: :
+========[ PU #N: Slice #(N-1) ]========+
| Slice #(N-1) | SEP counter=N-2
| (part 1/r) | P counter=0
: : M=0, T=0, K=1, L=0, I=00
+---------------------------------------+
: :
+---------------------------------------+
| Slice #(N-1) | SEP counter=N-2
| (part r/r) | P counter=r-1
: + EOC marker : M=1, T=0, K=1, L=1, I=00
+=======================================+
Figure 8: Example of JPEG XS Payload Data (Slice Packetization Mode, Progressive Video Frame)
図8：JPEG XSペイロードデータの例（スライスパケット化モード、プログレッシブビデオフレーム）
+====[ PU #1: JPEG XS Hdr segment 1 ]===+
| Video support box | SEP counter=0x07FF
+- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header 1 |
| +---------------------------------+ |
| : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=10
+====[ PU #2: Slice #1 (1st field) ]====+
| +---------------------------------+ | SEP counter=0
| | SLH Marker | | P counter=0
| +---------------------------------+ |
| : Entropy Coded Data : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=10
+====[ PU #3: Slice #2 (1st field) ]====+
| Slice #2 | SEP counter=1
| (part 1/q) | P counter=0
: : M=0, T=0, K=1, L=0, I=10
+---------------------------------------+
| Slice #2 | SEP counter=1
| (part 2/q) | P counter=1
: : M=0, T=0, K=1, L=0, I=10
+---------------------------------------+
: :
+---------------------------------------+
| Slice #2 | SEP counter=1
| (part q/q) | P counter=q-1
: : M=0, T=0, K=1, L=1, I=10
+=======================================+
: :
+==[ PU #N: Slice #(N-1) (1st field) ]==+
| Slice #(N-1) | SEP counter=N-2
| (part 1/r) | P counter=0
: : M=0, T=0, K=1, L=0, I=10
+---------------------------------------+
: :
+---------------------------------------+
| Slice #(N-1) | SEP counter=N-2
| (part r/r) | P counter=r-1
: + EOC marker : M=1, T=0, K=1, L=1, I=10
+=======================================+
+===[ PU #N+1: JPEG XS Hdr segment 2 ]==+
| Video support box | SEP counter=0x07FF
+- - - - - - - - - - - - - - - - - - - -+ P counter=0
| Color specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header 2 |
| +---------------------------------+ |
| : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=11
+===[ PU #N+2: Slice #1 (2nd field) ]===+
| +---------------------------------+ | SEP counter=0
| | SLH Marker | | P counter=0
| +---------------------------------+ |
| : Entropy Coded Data : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=11
+===[ PU #N+3: Slice #2 (2nd field) ]===+
| Slice #2 | SEP counter=1
| (part 1/s) | P counter=0
: : M=0, T=0, K=1, L=0, I=11
+---------------------------------------+
| Slice #2 | SEP counter=1
| (part 2/s) | P counter=1
: : M=0, T=0, K=1, L=0, I=11
+---------------------------------------+
: :
+---------------------------------------+
| Slice #2 | SEP counter=1
| (part s/s) | P counter=s-1
: : M=0, T=0, K=1, L=1, I=11
+=======================================+
: :
+==[ PU #2N: Slice #(N-1) (2nd field) ]=+
| Slice #(N-1) | SEP counter=N-2
| (part 1/t) | P counter=0
: : M=0, T=0, K=1, L=0, I=11
+---------------------------------------+
: :
+---------------------------------------+
| Slice #(N-1) | SEP counter=N-2
| (part t/t) | P counter=t-1
: + EOC marker : M=1, T=0, K=1, L=1, I=11
+=======================================+
Figure 9: Example of JPEG XS Payload Data (Slice Packetization Mode, Interlaced Video Frame)
図9：JPEG XSペイロードデータの例（スライスパケット化モード、インターレースビデオフレーム）
In order to facilitate proper synchronization between senders and receivers, it is RECOMMENDED to implement traffic shaping and delivery timing in accordance with the Network Compatibility Model compliance definitions specified in [SMPTE2110-21]. In such a case, the session description SHALL signal the compliance with the media type parameter TP. The actual applied traffic shaping and timing delivery mechanism is outside the scope of this memo and does not influence the payload packetization.
送信者と受信者との間の適切な同期を容易にするために、[SMPTE2110-21]で指定されたネットワーク互換モデルコンプライアンス定義に従って、トラフィックシェーピングおよび配信タイミングを実装することをお勧めします。そのような場合、セッションの説明はメディアタイプのパラメータTPへの準拠を知らなければならない。実際の応用されたトラフィックシェーピングとタイミング配信メカニズムはこのメモの範囲外であり、ペイロードのパケット化には影響しません。
Congestion control for RTP SHALL be used in accordance with [RFC3550] and with any applicable RTP profile, e.g., RTP/AVP [RFC3551] or RTP/ AVPF [RFC4585].
RTPの輻輳制御は、[RFC3550]に従って、任意の適用可能なRTPプロファイル、例えばRTP / AVP [RFC3551]またはRTP / AVPF [RFC4585]に従って使用されます。
While JPEG XS is mainly designed to be used in controlled network environments, it can also be employed in best-effort network environments, like the Internet. However, in this case, the users of this payload format SHALL monitor packet loss to ensure that the packet loss rate is within acceptable parameters. This can be achieved, for example, by means of RTP Control Protocol (RTCP) Feedback for Congestion Control [RFC8888].
JPEG XSは主に制御ネットワーク環境で使用されるように設計されていますが、インターネットのようにベストエフォートネットワーク環境でも使用できます。ただし、この場合、このペイロードフォーマットのユーザーはパケット損失率を監視して、パケット損失率が許容できるパラメータ内にあることを確認します。これは、例えば、輻輳制御のためのRTP制御プロトコル（RTCP）フィードバックによって達成することができる[RFC8888]。
In addition, [RFC8083] is an update to [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams and for when applications implementing this standard SHALL comply with it.
また、[RFC8083]は、RTPパケットストリームの送信を停止するために必要な場合の基準を定義し、この規格を実装するときの基準を定義する[RFC3550]の更新です。
[RFC8085] provides additional information on the best practices for applying congestion control to UDP streams.
[RFC8085] UDPストリームに輻輳制御を適用するためのベストプラクティスに関する追加情報を提供します。
This section specifies the required and optional parameters of the payload format and/or the RTP stream. All parameters are declarative, meaning that the information signaled by the parameters is also present in the payload data, namely in the payload header (see Section 4.3) or in the JPEG XS header segment [ISO21122-1] [ISO21122-3]. When provided, their respective values SHALL be consistent with the payload.
このセクションでは、ペイロード形式および/またはRTPストリームの必要なパラメータとオプションのパラメータを指定します。すべてのパラメータは宣言的です。つまり、パラメータによってシグナリングされた情報もペイロードデータ、すなわちペイロードヘッダー（セクション4.3）またはJPEG XSヘッダーセグメント[ISO21122-1] [ISO21122-3]にも存在します。提供されると、それらのそれぞれの値はペイロードと一致しなければならない。
This registration is done using the template defined in [RFC6838] and following [RFC4855].
この登録は[RFC6838]で定義されているテンプレートを使用して[RFC4855]を使用して行われます。
The receiver SHALL ignore any unrecognized parameter.
受信者は認識されないパラメータを無視するものとします。
Type name: video
タイプ名：ビデオ
Subtype name: jxsv
サブタイプ名：JXSV.
Required parameters: rate: The RTP timestamp clock rate. Applications using this payload format SHALL use a value of 90000.
必要なパラメータ：レート：RTPタイムスタンプクロックレート。このペイロードフォーマットを使用するアプリケーションは、90000の値を使用します。
packetmode: This parameter specifies the configured packetization mode as defined by the pacKetization mode (K) bit in the payload header of Section 4.3. This value SHALL be equal to the K-bit value configured in the RTP stream (i.e., 0 for codestream or 1 for slice).
packetMode：このパラメータは、セクション4.3のペイロードヘッダーのパケット化モード（k）ビットで定義されているような設定されたパケット化モードを指定します。この値は、RTPストリームで設定されているKビット値と等しくなります（すなわち、CodeStreamまたはスライスの場合は1の場合は0の場合）。
Optional parameters: transmode: This parameter specifies the configured transmission mode as defined by the Transmission mode (T) bit in the payload header of Section 4.3. If specified, this value SHALL be equal to the T-bit value configured in the RTP stream (i.e., 0 for out-of-order-allowed or 1 for sequential-only). If not specified, a value 1 (sequential-only) SHALL be assumed and the T bit SHALL be set to 1.
オプションのパラメータ：Transmode：このパラメータは、セクション4.3のペイロードヘッダーの送信モード（T）ビットで定義されているような設定された送信モードを指定します。指定されている場合、この値は、RTPストリームで設定されているTビット値（すなわち、順不同または順次の場合は1の場合は0）に等しくなります。指定しない場合は、値1（順次専用）を想定し、Tビットは1に設定されます。
profile: The JPEG XS profile [ISO21122-2] in use. Any white space Unicode character in the profile name SHALL be omitted. Examples of valid profile names are 'Main444.12' or 'High444.12'.
プロファイル：使用中のJPEG XSプロファイル[ISO21122-2]。プロファイル名にあるホワイトスペースのUnicode文字は省略されます。有効なプロファイル名の例は 'main444.12'または 'high444.12'です。
level: The JPEG XS level [ISO21122-2] in use. Any white space Unicode character in the level name SHALL be omitted. Examples of valid levels are '2k-1' or '4k-2'.
レベル：使用中のJPEG XSレベル[ISO21122-2]。レベル名の空白のUnicode文字は省略されます。有効なレベルの例は「2K-1」または「4K-2」です。
sublevel: The JPEG XS sublevel [ISO21122-2] in use. Any white space Unicode character in the sublevel name SHALL be omitted. Examples of valid sublevels are 'Sublev3bpp' or 'Sublev6bpp'.
SubleVel：使用中のJPEG XS SubleVel [ISO21122-2]。SubleVel名の白い空間のUnicode文字は省略されます。有効なサブレベルの例は、 'SubleV3BPP'または 'SubleV6bpp'です。
depth: Determines the number of bits per sample. This is an integer with typical values including 8, 10, 12, and 16.
深さ：サンプルごとのビット数を決定します。これは、8,10,12、および16を含む典型的な値を持つ整数です。
width: Determines the number of pixels per line. This is an integer between 1 and 32767, inclusive.
幅：1行あたりのピクセル数を決定します。これは1から32767の整数です。
height: Determines the number of lines per video frame. This is an integer between 1 and 32767, inclusive.
高さ：ビデオフレームごとの行数を決定します。これは1から32767の整数です。
exactframerate: Signals the video frame rate in frames per second. Integer frame rates SHALL be signaled as a single decimal number (e.g., "25") whilst non-integer frame rates SHALL be signaled as a ratio of two integer decimal numbers separated by a "forward-slash" character (e.g., "30000/1001"), utilizing the numerically smallest numerator value possible.
exactframetrate：毎秒フレームでビデオフレームレートをシグナリングします。整数フレームレートは、単一の10進数（例えば、「25」）としてシグナリングされ、非整数フレームレートは、「前方スラッシュ」文字（例えば、30000 /）で区切られた2つの整数10進数の比としてシグナリングされるものとする。可能な数字の最小の分子値を利用して1001 "）。
interlace: If this parameter name is present, it indicates that the video is interlaced, or that the video is Progressive segmented Frame (PsF). If this parameter name is not present, the progressive video format SHALL be assumed.
インターレース：このパラメータ名が存在する場合、ビデオがインターレースされているか、ビデオがプログレッシブセグメントフレーム（PSF）であることを示します。このパラメータ名が存在しない場合は、プログレッシブビデオフォーマットを想定します。
segmented: If this parameter name is present, and the interlace parameter name is also present, then the video is a Progressive segmented Frame (PsF). Signaling of this parameter without the interlace parameter is forbidden.
セグメント化：このパラメータ名が存在する場合、インターレースパラメータ名も存在する場合、ビデオはプログレッシブセグメント化フレーム（PSF）です。インターレースパラメータなしでこのパラメータのシグナリングは禁止されています。
sampling: Signals the color difference signal sub-sampling structure.
サンプリング：色差信号サブサンプリング構造をシグナリングします。
Signals utilizing the non-constant luminance Y'C'B C'R signal format of [BT.601-7], [BT.709-6], [BT.2020-2], or [BT.2100-2] SHALL use the appropriate one of the following values for the Media Type Parameter "sampling":
[BT.601-7]、[BT.709-6]、[BT.2020-2]、[BT.2100-2]の非定数輝度Y'C'B C'R信号フォーマットを利用した信号メディアタイプパラメータ「サンプリング」には、以下の値のいずれかを使用します。
YCbCr-4:4:4 (4:4:4 sampling)
YCbCr-4:2:2 (4:2:2 sampling)
YCbCr-4:2:0 (4:2:0 sampling)
Signals utilizing the Constant Luminance Y'C C'BC C'RC signal format of [BT.2020-2] SHALL use the appropriate one of the following values for the Media Type Parameter "sampling":
[BT.2020-2]の定数輝度Y'C C'BC C'RC信号フォーマットを利用する信号は、メディアタイプパラメータ「サンプリング」について以下の値のうちの適切なものを使用しなければならない。
CLYCbCr-4:4:4 (4:4:4 sampling)
CLYCbCr-4:2:2 (4:2:2 sampling)
CLYCbCr-4:2:0 (4:2:0 sampling)
Signals utilizing the constant intensity I CT CP signal format of [BT.2100-2] SHALL use the appropriate one of the following values for the Media Type Parameter "sampling":
[BT.2100-2]の一定強度I CT CP信号フォーマットを利用する信号は、メディアタイプパラメータ「サンプリング」には、以下の値のうちの適切なものを使用しなければならない。
ICtCp-4:4:4 (4:4:4 sampling)
ICtCp-4:2:2 (4:2:2 sampling)
ICtCp-4:2:0 (4:2:0 sampling)
Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such as that of [BT.601-7], [BT.709-6], [BT.2020-2], [BT.2100-2], [SMPTE2065-1], or [SMPTE2065-3]) SHALL use the following value for the Media Type Parameter "sampling":
4：4：4のR 'g' B 'またはRGB信号フォーマット（例えば、[BT.709-6]、[BT.7020-2]など）を利用した信号、[BT。2100-2]、[SMPTE2065-1]、または[SMPTE2065-3]）は、メディアタイプパラメータ「サンプリング」に次の値を使用します。
RGB (RGB or R' G' B' samples)
RGB（RGBまたはR 'G' B 'サンプル）
Signals utilizing the 4:4:4 X' Y' Z' signal format (such as defined in [SMPTE428-1]) SHALL use the following value for the Media Type Parameter "sampling":
4：4：4：4 x 'y' z '信号フォーマット（SMPTE428-1で定義されているような）を利用する信号は、メディアタイプパラメータ「サンプリング」に次の値を使用しなければならない。
XYZ (X' Y' Z' samples)
XYZ（X 'Y' Z 'サンプル）
Key signals as defined in [SMPTE157] SHALL use the value key for the Media Type Parameter "sampling". The key signal is represented as a single component:
[SMPTE157]で定義されているキー信号は、メディアタイプパラメータ「サンプリング」の値キーを使用します。キー信号は単一のコンポーネントとして表されます。
KEY (Samples of the key signal)
キー（キー信号のサンプル）
Signals utilizing a color sub-sampling other than what is defined here SHALL use the following value for the Media Type Parameter "sampling":
ここで定義されているもの以外の色サブサンプリングを利用する信号は、メディアタイプパラメータ「サンプリング」に次の値を使用します。
UNSPECIFIED (Sampling signaled by the payload)
指定されていない（ペイロードによってシグナリングされたサンプリング）
colorimetry: Specifies the system colorimetry used by the image samples. Valid values and their specification are the following:
比色：画像サンプルによって使用されるシステム比色を指定します。有効な値とその仕様は次のとおりです。
BT601-5: [BT.601-5].
BT601-5：[BT.601-5]。
BT709-2: [BT.709-2].
BT709-2：[BT.709-2]。
SMPTE240M: [SMPTE240M].
SMPTE240M：[SMPTE240M]。
BT601: [BT.601-7].
BT601：[BT.601-7]。
BT709: [BT.709-6].
BT709：[BT.709-6]。
BT2020: [BT.2020-2].
BT2020：[BT.2020-2]。
BT2100: [BT.2100-2], Table 2 titled "System colorimetry".
BT2100：[BT.2100-2]、表2は「システムの測色」と表現されます。
ST2065-1: Academy Color Encoding Specification (ACES) [SMPTE2065-1].
ST2065-1：アカデミーカラーエンコーディング仕様（ACES）[SMPTE2065-1]。
ST2065-3: Academy Density Exchange Encoding (ADX) [SMPTE2065-3].
ST2065-3：アカデミー密度Exchange Encoding（ADX）[SMPTE2065-3]。
XYZ: [ISO11664-1], section titled "1931 Observer".
XYZ：[ISO11664-1]、「1931 Observer」という欄。
UNSPECIFIED: Colorimetry is signaled in the payload by the color specification box of [ISO21122-3], or it must be manually coordinated between sender and receiver.
指定されていない：測色は[ISO21122-3]の色指定ボックスによってペイロードでシグナリングされるか、またはそれは送信者と受信機の間で手動で調整されなければなりません。
Signals utilizing the [BT.2100-2] colorimetry SHOULD also signal the representational range using the optional parameter RANGE defined below. Signals utilizing the UNSPECIFIED colorimetry might require manual coordination between the sender and the receiver.
[BT.2100-2]の比色を利用する信号も、以下に定義されているオプションのパラメータ範囲を使用して表現範囲を通知する必要があります。不特定の測色を利用する信号は、送信者と受信機との間の手動調整を必要とするかもしれない。
TCS: Transfer Characteristic System. This parameter specifies the transfer characteristic system of the image samples. Valid values and their specification are the following:
TCS：伝達特性システムこのパラメータは、画像サンプルの伝達特性システムを指定します。有効な値とその仕様は次のとおりです。
SDR: Standard Dynamic Range video streams that utilize the Optical Electrical Transfer Function (OETF) of [BT.709-6] or [BT.2020-2]. Such streams SHALL be assumed to target the Electro-Optical Transfer Function (EOTF) specified in [BT.1886-0].
SDR：[BT.709-6]または[BT.2020-2]の光伝導機能（OETF）を利用する標準ダイナミックレンジビデオストリーム。そのような流れは、[BT.1886-0]で指定された電気光伝達関数（EOTF）をターゲットにすると仮定しなければならない。
PQ: High dynamic range video streams that utilize the Perceptual Quantization system of [BT.2100-2].
PQ：[BT.2100-2]の知覚量子化システムを利用する高ダイナミックレンジビデオストリーム。
HLG: High dynamic range video streams that utilize the Hybrid Log-Gamma system of [BT.2100-2].
HLG：[BT.2100-2]のハイブリッドログガンマシステムを利用する高ダイナミックレンジビデオストリーム。
UNSPECIFIED: Video streams whose transfer characteristics are signaled by the payload as specified in [ISO21122-3], or that must be manually coordinated between sender and receiver.
指定されていない：[ISO21122-3]で指定されているように、転送特性がペイロードによってシグナリングされるビデオストリーム、または送信者と受信機との間で手動で調整されなければなりません。
RANGE: This parameter SHOULD be used to signal the encoding range of the sample values within the stream. When paired with [BT.2100-2] colorimetry, this parameter has two allowed values, NARROW and FULL, corresponding to the ranges specified in TABLE 9 of [BT.2100-2]. In any other context, this parameter has three allowed values: NARROW, FULLPROTECT, and FULL, which correspond to the ranges specified in [SMPTE2077]. In the absence of this parameter, and for all but the UNSPECIFIED colorimetry, NARROW SHALL be the assumed value. When paired with the UNSPECIFIED colorimetry, FULL SHALL be the default assumed value.
範囲：このパラメータは、ストリーム内のサンプル値の符号化範囲を通知するために使用する必要があります。[BT.2100-2]測色測定値とペアになっている場合、このパラメータには、[BT.2100-2]の表9に指定されている範囲に対応して、2つの許容値、狭くていっぱいです。他のどのコンテキストでは、このパラメータには3つの許容値があります。[SMPTE2077]で指定された範囲に対応しています。このパラメータがない場合、および不特定の測色のすべての場合、狭い値とする。不特定の測色測定値とペアになっている場合は、デフォルトの想定値になります。
Encoding considerations: This media type is framed in RTP and contains binary data; see Section 4.8 of [RFC6838].
エンコードに関する考慮事項：このメディアタイプはRTPで囲まれており、バイナリデータが含まれています。[RFC6838]のセクション4.8を参照してください。
Security considerations: See the Security Considerations section of RFC 9134.
セキュリティ上の考慮事項：RFC 9134の「セキュリティ上の考慮事項」セクションを参照してください。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: See the References section of RFC 9134.
公開仕様：RFC 9134の参照セクションを参照してください。
Applications that use this media type: Any application that transmits video over RTP (like SMPTE ST 2110).
このメディアタイプを使用するアプリケーション：RTPを介してビデオを送信するアプリケーション（SMPTE ST 2110など）。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information: None
追加情報：なし
Person & email address to contact for further information: T. Bruylants <rtp@intopix.com> and T. Richter <jpeg-xs-techsupport@iis.fraunhofer.de>.
詳細については、お問い合わせ先：T. Bruylants <rtp@intopix.com>とT.Richter <jpeg-xs-techsupport @ iis.fraunhofer.de>。
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: This media type depends on RTP framing; hence, it is only defined for transfer via RTP [RFC3550].
使用制限：このメディアタイプはRTPフレーミングによって異なります。したがって、それはRTP [RFC3550]を介した転送に対してのみ定義されます。
Author: See the Authors' Addresses section of RFC 9134.
著者：RFC 9134の「作者の住所」セクションを参照してください。
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
変更コントローラ：IESGから委任されたIETFオーディオ/ビデオトランスポートワーキンググループ。
A mapping of the parameters into the Session Description Protocol (SDP) [RFC8866] is provided for applications that use SDP.
セッション記述プロトコル（SDP）[RFC8866]へのパラメータのマッピングは、SDPを使用するアプリケーションに提供されます。
The media type video/jxsv string is mapped to fields in the Session Description Protocol (SDP) [RFC8866] as follows:
次のように、メディアタイプVIDEO / JXSV文字列はセッション記述プロトコル（SDP）[RFC8866]のフィールドにマッピングされています。
The media type ("video") goes in SDP "m=" as the media name.
メディアタイプ（「ビデオ」）は、メディア名としてSDP "M ="になります。
The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding name, followed by a slash ("/") and the required parameter "rate" corresponding to the RTP timestamp clock rate (which for the payload format defined in this document SHALL be 90000).
メディアサブタイプ（ "jxsv"）は、SDP "A = rtpmap"でエンコーディング名として "A = RTPMap"になり、その後にSLASH（ "/"）とRTPタイムスタンプクロックレート（ペイロードフォーマットのために）この文書で定義されていると定義されています90000）。
The required parameter "packetmode" and any of the additional optional parameters, as described in Section 7.1, go in the SDP media format description, being the "a=fmtp" attribute (Format Parameters), by copying them directly from the media type string as a semicolon-separated list of parameter=value pairs.
必要なパラメータ "packetMode"と追加のオプションパラメータのいずれかは、セクション7.1で説明されているように、SDPメディアフォーマットの説明で、 "A = fmtp"属性（フォーマットパラメータ）で、メディアタイプの文字列から直接コピーすることによって行く。パラメータ=値のペアのセミコロン区切りリストとして。
All parameters of the media format SHALL correspond to the parameters of the payload. In case of discrepancies between payload parameter values and SDP fields, the values from the payload data SHALL prevail.
メディアフォーマットのすべてのパラメータは、ペイロードのパラメータに対応しなければならない。ペイロードパラメータ値とSDPフィールドの間の不一致の場合、ペイロードデータの値は優先されます。
The receiver SHALL ignore any parameter that is not defined in Section 7.1.
受信者はセクション7.1で定義されていないパラメータを無視するものとします。
An example SDP mapping for JPEG XS video is as follows:
JPEG XSビデオのSDPマッピング例は次のとおりです。
m=video 30000 RTP/AVP 112
a=rtpmap:112 jxsv/90000
a=fmtp:112 packetmode=0;sampling=YCbCr-4:2:2;
width=1920;height=1080;depth=10;
colorimetry=BT709;TCS=SDR;RANGE=FULL;TP=2110TPNL
In this example, a JPEG XS RTP stream is to be sent to UDP destination port 30000, with an RTP dynamic payload type of 112 and a media clock rate of 90000 Hz. Note that the "a=fmtp:" line has been wrapped to fit this page and will be a single long line in the SDP file. This example includes the TP parameter (as specified in Section 5).
この例では、JPEG XS RTPストリームは、RTP動的ペイロードタイプ112および90000Hzのメディアクロックレートを備えたUDP宛先ポート30000に送信されるべきである。"a = fmtp："行はこのページに合うようにラップされ、SDPファイルの単一の長い行になります。この例には、（セクション5で指定されているように）TPパラメータが含まれています。
When JPEG XS is offered over RTP using SDP in an offer/answer model [RFC3264] for negotiation for unicast usage, the following limitations and rules apply:
オファー/アンサーモデルでSDPを使用してJPEG XSを介してRTPを介して提供されている場合、ユニキャスト使用のためのネゴシエーションのためのネゴシエーションのために、次の制限と規則が適用されます。
The "a=fmtp" attribute SHALL be present specifying the required parameter "packetmode" and MAY specify any of the optional parameters, as described in Section 7.1.
"a = fmtp"属性は、必要なパラメータ "packetMode"を指定し、セクション7.1で説明されているように、オプションのパラメータのいずれかを指定できます。
All parameters in the "a=fmtp" attribute indicate sending capabilities (i.e., properties of the payload).
"a = fmtp"属性のすべてのパラメータは、送信機能（すなわち、ペイロードのプロパティ）を示します。
An answerer of the SDP is required to support all parameters and values of the parameters provided by the offerer; otherwise, the answerer SHALL reject the session. It falls on the offerer to use values that are expected to be supported by the answerer. If the answerer accepts the session, it SHALL reply with the exact same parameter values in the "a=fmtp" attribute as they were initially offered.
SDPの回答者は、オファーによって提供されるパラメータのすべてのパラメータと値をサポートするために必要です。そうでなければ、回答者はセッションを拒否しなければならない。それは答え者によって支持されると予想される値を使用するために提供者に落ちる。回答者がセッションを受け入れる場合は、最初に提供されたときに「a = fmtp」属性にまったく同じパラメータ値を返信します。
The same RTP payload type number used in the offer SHOULD be used in the answer, as specified in [RFC3264].
オファーで使用されているのと同じRTPペイロードタイプ番号を[RFC3264]に指定されているように、答えで使用する必要があります。
IANA has registered the media type registration "video/jxsv" as specified in Section 7.1. The media type has also been added to the IANA registry for "RTP Payload Format Media Types" <https://www.iana.org/assignments/rtp-parameters>.
IANAはセクション7.1で指定されているように、メディアタイプ登録「VIDEO / JXSV」を登録しています。メディアタイプも "RTPペイロードフォーマットメディアタイプ" <https：//www.iana.org/ashignments/rtp-parameters>のIANAレジストリに追加されました。
RTP packets using the payload format defined in this memo are subject to the security considerations discussed in [RFC3550] and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. This implies that confidentiality of the media streams is achieved by encryption.
このメモに定義されているペイロード形式を使用したRTPパケットは、[RFC3550]で説明したセキュリティ上の考慮事項に従います.RTP / AVP [RFC3551]、RTP / AVPF [RFC4585]、RTP / SAVP [RFC3711]、またはRTP / SAVPF [RFC5124]。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。
However, as "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lies 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 appropriate strong security mechanisms.
ただし、「RTPフレームワークの保護：RTPは、RFC7202」について説明します。一般的にRTPのための整合性、およびソースの信頼性。この責任はアプリケーションでRTPを使用している人にあります。彼らは利用可能なセキュリティメカニズムに関するガイダンスと「RTPセッションを保護するためのオプション」[RFC7201]での重要な考慮事項を見つけることができます。アプリケーションは1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。
Implementations of this RTP payload format need to take appropriate security considerations into account. It is important for the decoder to be robust against malicious or malformed payloads and ensure that they do not cause the decoder to overrun its allocated memory or otherwise misbehave. An overrun in allocated memory could lead to arbitrary code execution by an attacker. The same applies to the encoder, even though problems in encoders are typically rarer.
このRTPペイロードフォーマットの実装は、適切なセキュリティ上の考慮事項を考慮に入れる必要があります。デコーダが悪意のあるまたは不正なペイロードに対して堅牢であり、それらがデコーダに割り当てられたメモリをオーバーランしたり、そうでなければ不正行為を引き起こさないようにすることが重要です。割り当てられたメモリのオーバーランは、攻撃者による任意のコード実行につながる可能性があります。エンコーダの問題は通常rarerであっても、エンコーダにも当てはまります。
This payload format and the JPEG XS encoding do not exhibit any substantial non-uniformity, either in output or in complexity to perform the decoding operation; thus, they are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams.
このペイロードフォーマットおよびJPEG XSエンコーディングは、復号化動作を実行するために出力または複雑さのいずれかで、かなりの不均一性を示さない。したがって、彼らは病理学的データグラムの受領によりサービス拒否の脅威をもたらす可能性は低いです。
This payload format and the JPEG XS encoding do not contain code that is executable.
このペイロード形式とJPEG XSエンコーディングには、実行可能ファイルが含まれていません。
It is important to note that high-definition (HD) or ultra-high-definition (UHD) video that is encoded with JPEG XS can have significant bandwidth requirements (typically more than 1 Gbps for UHD video, especially if using high framerate). This is sufficient to cause potential for denial of service if transmitted onto most currently available Internet paths.
JPEG XSで符号化されている高精細（HD）または超高精細（UHD）ビデオには、大きな帯域幅の要件（通常は高フレームレートを使用する場合はUHDビデオ用に1 Gbps以上）があることに注意することが重要です。これは、現在利用可能なインターネットパスに送信された場合、サービス拒否の可能性を引き起こすのに十分です。
Accordingly, if best-effort service is being used, users of this payload format SHALL monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, and experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session) or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
したがって、ベストエフォートサービスが使用されている場合、このペイロードフォーマットのユーザはパケット損失を監視して、パケット損失率が許容パラメータ内にあることを確実にする。パケットの損失は、同じネットワークパスにわたってTCPフローを流し、同じネットワーク状態を経験している場合、RTPフロー以上の妥当なタイムスケールで測定された平均スループットを達成します。この状態は、伝送速度（または階層化マルチキャストセッションに加入している層の数）を適合させるために、または損失率が許容できないほど高い場合に受信機を脱退させることによって、輻輳制御メカニズムを実装することによって満足することができる。
This payload format may also be used in networks that provide quality-of-service guarantees. If enhanced service is being used, receivers SHOULD monitor packet loss to ensure that the service that was requested is actually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behave accordingly.
このペイロード形式は、サービス品質保証を提供するネットワークでも使用できます。強化されたサービスが使用されている場合、受信者は、要求されたサービスが実際に配信されていることを確認するためにパケット損失を監視する必要があります。そうでなければ、彼らは彼らがベストエフォートサービスを受けていると仮定し、それに応じて振る舞います。
[ISO21122-1] ISO/IEC, "Information technology - JPEG XS low-latency lightweight image coding system - Part 1: Core coding system", ISO/IEC IS 21122-1.
[ISO21122-1] ISO / IEC、「情報技術 - JPEG XS低遅延ライトウェイト画像符号化システム - 第1部：コア符号化システム」、ISO / IECは21122-1です。
[ISO21122-2] ISO/IEC, "Information technology - JPEG XS low-latency lightweight image coding system - Part 2: Profiles and buffer models", ISO/IEC IS 21122-2.
[ISO21122-2] ISO / IEC、「情報技術 - JPEG XS低レイテンシ軽量画像符号化システム - 第2部：プロファイルとバッファモデル」、ISO / IECは21122-2です。
[ISO21122-3] ISO/IEC, "Information technology - JPEG XS low-latency lightweight image coding system - Part 3: Transport and container formats", ISO/IEC IS 21122-3.
[ISO21122-3] ISO / IEC、「情報技術 - JPEG XS低遅延ライトウェイトイメージシステム - 第3部：トランスポートおよびコンテナフォーマット」、ISO / IECは21122-3です。
[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://ww.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：リアルタイムアプリケーション用輸送プロトコル」、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、STD 65、RFC 3551、DOI 10.17487 / RFC3551、<https：///www.rfc-編集者。ORG / INFO / RFC3551>。
[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>。
[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>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C、V.Singh、「マルチメディア輻輳制御：ユニキャストRTPセッション用サーキットブレーカー」、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<https：//www.rfc-editor.org/info/ RFC8083>。
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8085] eggert、L.、Fairhurst、G.、G.Shepherd、 "UDP使用ガイドライン"、BCP 145、RFC 8085、DOI 10.17487 / RFC8085、2017年3月、<https：//www.rfc-editor.org/ info / rfc8085>。
[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>。
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", RFC 8866, DOI 10.17487/RFC8866, January 2021, <https://www.rfc-editor.org/info/rfc8866>.
[RFC8866] Begen、A.、Kyzivat、P.、Perkins、C、およびM.ハンドリー、「SDP：セッション記述プロトコル」、RFC 8866、DOI 10.17487 / RFC8866、2021年1月、<https：//www.rfc-editor.org/info/rfc8866>。
[BT.1886-0] ITU-R, "Reference electro-optical transfer function for flat panel displays used in HDTV studio production", ITU-R Recommendation BT.1886-0, March 2011, <https://www.itu.int/rec/R-REC-BT.1886-0-201103-I/en>.
[BT.1886-0] ITU-R、「HDTVスタジオ生産に使用されるフラットパネルディスプレイのための基準電気光伝達関数」、ITU-R勧告BT.1886-0、2011年3月、<https：//www.itu.int / rec / r-rec-bt.1886-0-201103-i / en>。
[BT.2020-2] ITU-R, "Parameter values for ultra-high definition television systems for production and international programme exchange", ITU-R Recommendation BT.2020-2, October 2015, <https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en>.
[BT.2020-2] ITU-R、「生産・国際番組交換のための超高精細テレビシステムのパラメータ値」、ITU-R勧告BT.2020-2、2015年10月、<https：//www.itu.int / rec / r-rec-bt.2020-2-201510-I / EN>。
[BT.2100-2] ITU-R, "Image parameter values for high dynamic range television for use in production and international programme exchange", ITU-R Recommendation BT.2100-2, July 2018, <https://www.itu.int/rec/R-REC-BT.2100-2-201807-I/en>.
[BT.2100-2] ITU-R、「生産および国際プログラム交換における高ダイナミックレンジテレビの画像パラメータ値」、2018年7月、2018年7月、<https：// www。itu.int/rec/r-rec-t.2100-2-201807-i / en>。
[BT.601-5] ITU-R, "Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios", ITU-R Recommendation BT.601-5, October 1995, <https://www.itu.int/rec/R-REC-BT.601-5-199510-S/en>.
[BT.601-5] ITU-R、「スタジアルテレビのスタジオの符号化パラメータ4：3とワイドスクリーン16：9アスペクト比」、ITU-R勧告BT.601-5、1995年10月、<https：//www.itu.int/rec/r-rec-bt.601-5-199510-s / en>。
[BT.601-7] ITU-R, "Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios", ITU-R Recommendation BT.601-7, March 2011, <https://www.itu.int/rec/R-REC-BT.601-7-201103-I/en>.
[BT.601-7] ITU-R、「スタジアルテレビのスタジオの符号化パラメータ4：3とワイドスクリーン16：9縦横比」、ITU-R勧告BT.601-7、2011年3月、<https：//www.itu.int/rec/r-rec-bt.601-7-201103--2/201103-。
[BT.709-2] ITU-R, "Parameter values for the HDTV standards for production and international programme exchange", ITU-R Recommendation BT.709-2, October 1995, <https://www.itu.int/rec/R-REC-BT.709-2-199510-S/en>.
[BT.709-2] ITU-R、「生産・国際プログラム交換のためのHDTV規格のパラメータ値」、1995年10月2日、<https：//www.itu.int/REC / R REC-BT.709-2-199510-S / EN>。
[BT.709-6] ITU-R, "Parameter values for the HDTV standards for production and international programme exchange", ITU-R Recommendation BT.709-6, June 2015, <https://www.itu.int/rec/R-REC-BT.709-6-201506-I/en>.
[BT.709-6] ITU-R、「生産・国際番組交換のためのHDTV規格のパラメータ値」、ITU-R勧告BT.709-6、2015年6月、<https：//www.itu.int/REC / R REC-BT.709-6-201506-I / E>。
[ISO11664-1] ISO/CIE, "Colorimetry - Part 1: CIE standard colorimetric observers", ISO/CIE IS 11664-1:2019, June 2019, <https://www.iso.org/standard/74164.html>.
[ISO11664-1] ISO / CIE、「測色 - パート1：CIE標準測色オブザーバー」、ISO / CIEは11664-1：2019年6月、2019年6月、<https：//www.iso.org/standard/74164.html>。
[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] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[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]ガライ、L.およびC. Perkins、「非圧縮ビデオのRTPペイロードフォーマット」、RFC 4175、DOI 10.17487 / RFC4175、2005年9月、<https：//www.rfc-editor.org/info/rfc4175>。
[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、「リアルタイムトランスポート制御プロトコルのための拡張RTPプロファイル（RTCP）ベースのフィードバック（RTP / AVPF）"、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<https://www.rfc-editor.org/info/rfc4585>。
[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 / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<HTTPS//www.rfc-editor.org/info/rfc5124>。
[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、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] Perkins、CおよびM.Westerlund「RTPフレームワークの保護：なぜRTPは、なぜ1つのメディアセキュリティソリューションを義務付けないのか」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<https：//www.rfc-Editor.org/info/rfc7202>。
[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Control Protocol (RTCP) Feedback for Congestion Control", RFC 8888, DOI 10.17487/RFC8888, January 2021, <https://www.rfc-editor.org/info/rfc8888>.
[RFC8888] Sarker、Z.、Perkins、C、Singh、V.、およびM. Ramalho、「RTP制御プロトコル（RTCP）フィードバック、RFC 8888、DOI 10.17487 / RFC8888、2021年1月、<https：//www.rfc-editor.org/info/rfc8888>。
[SMPTE157] SMPTE, "SMPTE Recommended Practice - Key and Alpha Signals", SMPTE RP 157:2012, DOI 10.1109/ICPST.1998.729044, November 2012, <https://ieeexplore.ieee.org/document/7290447>.
[SMPTE157] SMPTE、「SMPTE推奨練習 - キーおよびアルファシグナル」、SMPTE RP 157：2012、DOI 10.1109 / ICPST.1998.729044、<https://ieeexplore.ieee.org/document/7290447>。
[SMPTE2065-1] SMPTE, "SMPTE Standard - Academy Color Encoding Specification (ACES)", SMPTE ST 2065-1:2021, DOI 10.5594/SMPTE.ST2065-1.2021, January 2021, <https://ieeexplore.ieee.org/document/9343931>.
[SMPTE2065-1] SMPTE、「SMPTE標準 - アカデミーカラーエンコーディング仕様（ACES）」、SMPTE ST 2065-1：2021、DOI 10.5594 / SMPTE.ST2065-1.2021、<https：//ieeexplore.ieee.org/ Document / 9343931>。
[SMPTE2065-3] SMPTE, "SMPTE Standard - Academy Density Exchange Encoding (ADX) - Encoding Academy Printing Density (APD) Values", SMPTE ST 2065-3:2020, DOI 10.5594/SMPTE.ST2065-3.2020, November 2020, <https://ieeexplore.ieee.org/document/9286953>.
[SMPTE2065-3] SMPTE、「SMPTE標準 - アカデミー密度Encoving（ADX） - エンコーディングアカデミー印刷密度（APD）値」、SMPTE ST 2065-3：2020、DOI 10.5594 / SMPTE.ST2065-3.2020、2020年11月、<https://ieeexplore.ieee.org/document/9286953>。
[SMPTE2077] SMPTE, "SMPTE Recommended Practice - Full-Range Image Mapping", SMPTE RP 2077:2013, DOI 10.5594/SMPTE.RP2077.2013, November 2013, <https://ieeexplore.ieee.org/document/7290588>.
[SMPTE2077] SMPTE、「SMPTE推奨練習 - フルレンジ画像マッピング」、SMPTE RP 2077：2013、DOI 10.5594 / SMPTE.RP2077.2013、2013年11月、<https://ieeexplore.ieee.org/document/7290588>。
[SMPTE2110-21] SMPTE, "SMPTE Standard - Professional Media Over Managed IP Networks: Traffic Shaping and Delivery Timing for Video", SMPTE ST 2110-21:2017, DOI 10.5594/SMPTE.ST2110-21.2017, November 2017, <https://ieeexplore.ieee.org/document/8165971>.
[SMPTE2110-21] SMPTE、「SMPTE標準 - 管理対象IPネットワーク上のプロフェッショナルメディア：ビデオのトラフィックシェーピングと配信タイミング」、SMPTE ST 2110-21：2017、DOI 10.5594 / SMPTE.ST2110-21.2017、2017年11月、<https：///ieeexplore.ieee.org/document/8165971>。
[SMPTE240M] SMPTE, "SMPTE Standard - For Television - 1125-Line High-Definition Production Systems - Signal Parameters", SMPTE ST 240M:1999, DOI 10.5594/SMPTE.ST240.1999, November 1999, <https://ieeexplore.ieee.org/ document/7291461?arnumber=7291461>.
[SMPTE240M] SMPTE、「SMPTE標準 - テレビ用 - 1125ライン高精細生産システム - シグナルパラメータ」、SMPTE ST 240M：1999、DOI 10.5594 / SMPTE.ST240.1999、1999年11月、<https：// ieeexplore。ieee.org/ document / 7291461？arnumber = 7291461>。
[SMPTE428-1] SMPTE, "SMPTE Standard - D-Cinema Distribution Master - Image Characteristics", SMPTE ST 428-1:2019, DOI 10.5594/SMPTE.ST428-1.2019, March 2019, <https://ieeexplore.ieee.org/document/8709077>.
[SMPTE428-1] SMPTE、「SMPTE標準 - D-シネマ分布マスター - イメージ特性」、SMPTE ST 428-1：2019、DOI 10.5594 / SMPTE.ST428-1.2019、2019年3月、<https：//ieeexplore.ieee。ORG / Document / 8709077>。
Acknowledgments
謝辞
The authors would like to thank the following people for their valuable contributions to this memo: Sébastien Lugan, Arnaud Germain, Alexandre Willème, Gaël Rouvroy, Siegfried Foessel, and Jean-Baptise Lorent.
著者らは、このメモへの貴重な貢献のために以下の人々に感謝します：SébastienLugan、Arnaud Germain、AlexandreWillème、GaëlRouvroy、Siegfried foesesel、そしてJean-Baptise Lorent。
Authors' Addresses
著者の住所
Tim Bruylants intoPIX S.A. Rue Emile Francqui, 9 1435 Mont-Saint-Guibert Belgium
TIM BRUYLANTS INTOPIX S.A.Rue Emile Francqui、9 1435 Mont-Saint-Guibert Belgium
Phone: +32 10 23 84 70
Email: t.bruylants@intopix.com
URI: https://www.intopix.com/
Antonin Descampe Université catholique de Louvain bte L2.03.02 Ruelle de la Lanterne Magique, 14 1348 Louvain-la-Neuve Belgium
Antonin DescampeUniversitéCatholiqueDe Louvain Bte L2.03.02 Ruelle de La Lanterne Magique、14 1348 Louvain-La-Neuve Belgium
Phone: +32 10 47 27 87
Email: antonin.descampe@uclouvain.be
URI: https://uclouvain.be/antonin.descampe
Corentin Damman intoPIX S.A. Rue Emile Francqui, 9 1435 Mont-Saint-Guibert Belgium
Corentin Damman Intopix S.A. Rue Emile Francqui、9 1435 Mont-Saint-Guibert Belgium
Phone: +32 10 23 84 70
Email: c.damman@intopix.com
URI: https://www.intopix.com/
Thomas Richter Fraunhofer IIS Am Wolfsmantel 33 91048 Erlangen Germany
Thomas Richter Fraunhofer Iis am Wolfsmantel 33 91048 Erlangenドイツ
Phone: +49 9131 776 5126
Email: thomas.richter@iis.fraunhofer.de
URI: https://www.iis.fraunhofer.de/