[要約] RFC 4396は、3GPPタイムドテキストのためのRTPペイロード形式に関する仕様です。このRFCの目的は、3GPPタイムドテキストをRTPパケットにエンコードする方法を定義し、リアルタイム通信でのテキストデータの伝送を可能にすることです。
Network Working Group J. Rey
Request for Comments: 4396 Y. Matsui
Category: Standards Track Panasonic
February 2006
RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text
第3世代パートナーシッププロジェクト（3GPP）のタイミングテキストのRTPペイロード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified.
このドキュメントは、3GPP（第3世代パートナーシッププロジェクト）タイミングテキストの送信用のRTPペイロード形式を指定します。3GPPタイムされたテキストは、3GPファイルに定義されたストレージを備えたタイムラインの装飾テキストメディア形式です。時限テキストは、オーディオ/ビデオコンテンツと同期し、キャプション、タイトル、マルチメディアプレゼンテーションなどのアプリケーションで使用できます。以下のセクションでは、ストリーミングタイムテキストの問題に対処し、RTPを介した3GPPタイミングテキストのストリーミングのペイロード形式が指定されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Motivation, Requirements, and Design Rationale ..................3
2.1. Motivation .................................................3
2.2. Basic Components of the 3GPP Timed Text Media Format .......4
2.3. Requirements ...............................................5
2.4. Limitations ................................................6
2.5. Design Rationale ...........................................7
3. Terminology ....................................................10
4. RTP Payload Format for 3GPP Timed Text .........................12
4.1. Payload Header Definitions ................................13
4.1.1. Common Payload Header Fields .......................15
4.1.2. TYPE 1 Header ......................................17
4.1.3. TYPE 2 Header ......................................20
4.1.4. TYPE 3 Header ......................................23
4.1.5. TYPE 4 Header ......................................24
4.1.6. TYPE 5 Header ......................................25
4.2. Buffering of Sample Descriptions ..........................25
4.2.1. Dynamic SIDX Wraparound Mechanism ..................26
4.3. Finding Payload Header Values in 3GP Files ................28
4.4. Fragmentation of Timed Text Samples .......................31
4.5. Reassembling Text Samples at the Receiver .................33
4.6. On Aggregate Payloads .....................................35
4.7. Payload Examples ..........................................39
4.8. Relation to RFC 3640 ......................................43
4.9. Relation to RFC 2793 ......................................44
5. Resilient Transport ............................................45
6. Congestion Control .............................................46
7. Scene Description ..............................................47
7.1. Text Rendering Position and Composition ...................47
7.2. SMIL Usage ................................................48
7.3. Finding Layout Values in a 3GP File .......................48
8. 3GPP Timed Text Media Type .....................................49
9. SDP Usage ......................................................53
9.1. Mapping to SDP ............................................53
9.2. Parameter Usage in the SDP Offer/Answer Model .............53
9.2.1. Unicast Usage ......................................54
9.2.2. Multicast Usage ....................................57
9.3. Offer/Answer Examples .....................................58
9.4. Parameter Usage outside of Offer/Answer ...................60
10. IANA Considerations ...........................................60
11. Security Considerations .......................................60
12. References ....................................................61
12.1. Normative References .....................................61
12.2. Informative References ...................................61
13. Basics of the 3GP File Structure ..............................64
14. Acknowledgements ..............................................65
3GPP timed text is a media format for time-lined, decorated text specified in the 3GPP Technical Specification TS 26.245, "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)" [1]. Besides plain text, the 3GPP timed text format allows the creation of decorated text such as that for karaoke applications, scrolling text for newscasts, or hyperlinked text. These contents may or may not be synchronized with other media, such as audio or video.
3GPPタイミングテキストは、3GPPテクニカル仕様TS 26.245、「透明なエンドツーエンドパケットスイッチ式ストリーミングサービス（PSS）;時限テキスト形式（リリース6）」で指定された時間並べられた装飾テキストのメディア形式です。プレーンテキストに加えて、3GPPタイムタイムテキスト形式では、Karaokeアプリケーションのような装飾されたテキストの作成、ニュースキャストのテキストのスクロール、またはハイパーリンクテキストなどが可能になります。これらのコンテンツは、オーディオやビデオなど、他のメディアと同期している場合と同期している場合とそうでない場合があります。
The purpose of this document is to provide a means to stream 3GPP timed text contents using RTP [3]. This includes the streaming of timed text being read out of a (3GP) file, as well as the streaming of timed text generated in real-time, a.k.a. live streaming.
このドキュメントの目的は、RTP [3]を使用して3GPPタイミングのテキストコンテンツをストリーミングする手段を提供することです。これには、（3GP）ファイルから読み取られているタイミングテキストのストリーミング、およびリアルタイムで生成されたタイミングテキストのストリーミングが含まれます。
Section 2 contains the motivation for this document, an overview of the media format, the requirements, and the design rationale. Section 3 defines the terminology used. Section 4 specifies the payload headers, the fragmentation and re-assembly rules for text samples, the rules for payload aggregation, and the relations of this document to RFC 3640 [12] and RFC 2793 [22]. Section 5 specifies some simple schemes for resilient transport and gives pointers to other possible mechanisms. Section 6 addresses congestion control. Section 7 specifies scene description. Section 8 defines the media type. Section 9 specifies SDP for unicast and multicast sessions, including usage in the Offer/Answer model [13]. Sections 10 and 11 address IANA and security considerations. Section 12 lists references. Basics of the 3GP File Structure are in Section 13.
セクション2には、このドキュメントの動機、メディア形式、要件、および設計の根拠の概要が含まれています。セクション3では、使用される用語を定義します。セクション4では、ペイロードヘッダー、テキストサンプルの断片化と再組み立てルール、ペイロード集約のルール、およびこのドキュメントのRFC 3640 [12]およびRFC 2793 [22]を指定します。セクション5では、回復力のある輸送のためのいくつかの簡単なスキームを指定し、他の可能なメカニズムへのポインターを提供します。セクション6では、混雑制御に対処します。セクション7でシーンの説明を指定します。セクション8では、メディアタイプを定義しています。セクション9では、オファー/回答モデルの使用を含む、ユニキャストおよびマルチキャストセッションのSDPを指定します[13]。セクション10および11は、IANAおよびセキュリティ上の考慮事項に対処します。セクション12に参照を示します。3GPファイル構造の基本はセクション13にあります。
The 3GPP timed text format was developed for use in the services specified in the 3GPP Transparent End-to-end Packet-switched Streaming Services (3GPP PSS) specification [16].
3GPPタイミングテキスト形式は、3GPP透明なエンドツーエンドパケットスイッチストリーミングサービス（3GPP PSS）仕様で指定されたサービスで使用するために開発されました[16]。
As of today, PSS allows downloading 3GPP timed text contents stored in 3GP files. However, due to the lack of a RTP payload format, it is not possible to stream 3GPP timed text contents over RTP.
今日の時点で、PSSでは、3GPファイルに保存されている3GPPタイミングのテキストコンテンツをダウンロードできます。ただし、RTPペイロード形式がないため、RTPを介して3GPPタイミングのテキストコンテンツをストリーミングすることはできません。
This document specifies such a payload format.
このドキュメントは、このようなペイロード形式を指定します。
Before going into the details of the design, it is necessary to know how the media format is constructed. We can identify four differentiated functional components: layout information, default formatting, text strings, and decoration. In the following, we shortly explain these and match them to their designations in a 3GP file:
デザインの詳細に入る前に、メディア形式の構築方法を知る必要があります。レイアウト情報、デフォルトのフォーマット、テキスト文字列、装飾の4つの差別化された機能コンポーネントを特定できます。以下では、これらをまもなく説明し、3GPファイルの指定に一致させます。
o Initial spatial layout information related to the text strings: These are the height and width of the text region where text is displayed, the position of the text region in the display, and the layer or proximity of the text to the user. In 3GP files, this information is contained in the Track Header Box (3GP file designations are capitalized for clarity).
o テキスト文字列に関連する初期の空間レイアウト情報：これらは、テキストが表示されるテキスト領域の高さと幅、ディスプレイ内のテキスト領域の位置、およびテキストのユーザーへのレイヤーまたは近接性です。3GPファイルでは、この情報はトラックヘッダーボックスに含まれています（3GPファイルの指定は明確にするために資本化されています）。
o Default settings for formatting and positioning of text: style (font, size, color,...), background color, horizontal and vertical justification, line width, scrolling, etc. For 3GP files, this corresponds to the Sample Descriptions.
o テキストのフォーマットと位置決めのデフォルト設定：スタイル（フォント、サイズ、色、...）、背景色、水平および垂直の正当化、線幅、スクロールなど。3GPファイルの場合、これはサンプルの説明に対応します。
o The actual text strings: encoded characters using either UTF-8 [18] or UTF-16 [19] encoding.
o 実際のテキスト文字列：UTF-8 [18]またはUTF-16 [19]エンコードを使用したエンコード文字。
o The decoration: If some characters have different style, delay, blink, etc., this needs to be indicated. The decoration is only present in the text samples if it is actually needed. Otherwise, the default settings as above apply. In 3GP files, within each Text Sample, the decoration (i.e., Modifier Boxes) is appended to the text strings, if needed. At the time of writing this payload format, the following modifiers are specified in the 3GPP timed text media format specification [1]:
o 装飾：一部のキャラクターが異なるスタイル、遅延、点滅などを持っている場合、これを示す必要があります。装飾は、実際に必要な場合にのみテキストサンプルに存在します。それ以外の場合、上記のデフォルト設定が適用されます。3GPファイルでは、各テキストサンプル内で、必要に応じて装飾（つまり、モディファイアボックス）がテキスト文字列に追加されます。このペイロード形式を書く時点で、次の修飾子は3GPPタイミングテキストメディア形式の仕様[1]で指定されています。
- text highlight - highlight color - blinking text - karaoke feature - hyperlink - text delay - text style - positioning of the text box - text wrap indication
- テキストハイライト - ハイライトカラー - 視聴テキスト - カラオケ機能 - ハイパーリンク - テキスト遅延 - テキストスタイル - テキストボックスの位置付け - テキストラップ表示
Once the basic components are known, it is necessary to define which requirements the payload format shall fulfill:
基本的なコンポーネントがわかったら、ペイロード形式がどの要件を満たすかを定義する必要があります。
1. It shall enable both live streaming and streaming from a 3GP file.
1. 3GPファイルからのライブストリーミングとストリーミングの両方を有効にする必要があります。
Informative note: For the purpose of this document, the term "live streaming" refers to those scenarios where the timed text stream is sent from a live encoder. Upon reception, the content may or may not be stored in a 3GP file. Typically, in live streaming applications, the sender encapsulates the timed text content in RTP packets following the guidelines given in this document. At the receiving side, a buffer is used to cancel the network delay and delay jitter. If receiver and sender support packet loss resilience mechanisms (see Section 5), it may also be possible to recover from packet losses. Note that how sender and receiver actually manage and dimension the buffers is an implementation design choice.
有益なメモ：このドキュメントの目的のために、「ライブストリーミング」という用語は、タイムされたテキストストリームがライブエンコーダーから送信されるシナリオを指します。レセプション時に、コンテンツは3GPファイルに保存される場合とない場合があります。通常、ライブストリーミングアプリケーションでは、送信者は、このドキュメントに記載されているガイドラインに従って、RTPパケットのタイミングされたテキストコンテンツをカプセル化します。受信側では、ネットワークの遅延をキャンセルしてジッターを遅らせるためにバッファを使用します。受信者と送信者がパケット損失の回復力メカニズムをサポートする場合（セクション5を参照）、パケット損失から回復することも可能かもしれません。送信者とレシーバーが実際に管理および寸法をどのように管理し、バッファーを寸法が実装の設計の選択であることに注意してください。
2. Furthermore, it shall be possible for an RTP receiver using this payload format, and capable of storing in 3GP format, to obtain all necessary information from the RTP packets for storing the received text contents according to the 3GP file format. This file may or may not be the same as the original file.
2. さらに、このペイロード形式を使用し、3GP形式で保存できるRTPレシーバーが、3GPファイル形式に従って受信したテキストコンテンツを保存するためにRTPパケットから必要なすべての情報を取得できるようにすることが可能です。このファイルは、元のファイルと同じである場合と同じ場合があります。
Informative note: The 3GP file format itself is based on the ISO Base Media File Format recommendation [2]. Section 13.1 gives some insight into the 3GP file structure. Further, Sections 4.3 and 7.3 specify where the information needed for filling in payload headers is found in a 3GP file. For live streaming, appropriate values complying with the format and units described in [1] shall be used. Where needed, clarifications on appropriate values are given in this document.
有益なメモ：3GPファイル形式自体は、ISOベースメディアファイル形式の推奨[2]に基づいています。セクション13.1は、3GPファイル構造に関する洞察を示しています。さらに、セクション4.3および7.3では、ペイロードヘッダーの記入に必要な情報が3GPファイルにある場所を指定します。ライブストリーミングの場合、[1]で説明されている形式とユニットに準拠する適切な値を使用するものとします。必要に応じて、このドキュメントでは、適切な値の明確化が示されています。
3. It shall enable efficient and resilient transport of timed text contents over RTP. In particular:
3. RTPを介したタイミングのテキストコンテンツの効率的で回復力のある輸送を可能にします。特に：
a. Enable the transmission of the sample descriptions by both out-of-band and in-band means. Sample descriptions are important information, which potentially apply to several text samples. These default formatting settings are typically transmitted out-of-band (reliably) once at the initialization phase. If additional sample descriptions are needed in the course of a session, these may also be sent out-of-band or in-band. In-band transmission, although unreliable, may be more appropriate for sending sample descriptions if these should be sent frequently, as opposed to establishing an additional communication channel for SDP, for example. It is also useful in cases where an out-of-band channel may not be available and for live streaming, where contents are not known a priori. Thus, the payload format shall enable out-of-band and in-band transmission of sample descriptions. Section 4.1.6 specifies a payload header for transmitting sample descriptions in-band. Section 9 specifies how sample descriptions are mapped to SDP.
a. 帯域外および帯域内の両方の平均によってサンプルの説明の伝達を有効にします。サンプルの説明は重要な情報であり、いくつかのテキストサンプルに適用される可能性があります。これらのデフォルトのフォーマット設定は、通常、初期化フェーズで一度（確実に）帯域外に送信されます。セッションの過程で追加のサンプルの説明が必要な場合は、これらを帯域外または帯域内で送信することもできます。帯域内の伝送は、信頼できませんが、たとえばSDPの追加の通信チャネルを確立するのではなく、これらを頻繁に送信する必要がある場合、サンプルの説明を送信するのに適している場合があります。また、帯域外チャネルが利用できない場合や、内容が先験的に不明なライブストリーミングの場合にも役立ちます。したがって、ペイロード形式は、サンプル記述の帯域外および帯域内の伝送を可能にするものとします。セクション4.1.6は、バンド内のサンプルの説明を送信するためのペイロードヘッダーを指定しています。セクション9では、サンプルの説明がSDPにマッピングされる方法を指定します。
b. Enable the fragmentation of a text sample into several RTP packets in order to cover a wide range of applications and network environments. In general, fragmentation should be a rare event, given the low bit rates and relatively small text sample sizes. However, the 3GPP Timed Text media format does allow for larger text samples. Therefore, the payload format shall take this into account and provide a means for coping with fragmentation and reassembly. Section 4.4 deals with fragmentation.
b. 幅広いアプリケーションとネットワーク環境をカバーするために、テキストサンプルの断片化をいくつかのRTPパケットに有効にします。一般に、断片化は、ビットレートが低く、テキストのサンプルサイズが比較的少ないことを考えると、まれなイベントである必要があります。ただし、3GPPタイムタイムテキストメディア形式では、より大きなテキストサンプルが可能になります。したがって、ペイロード形式はこれを考慮し、断片化と再組み立てに対処する手段を提供するものとします。セクション4.4では、断片化を扱います。
c. Enable the aggregation of units into an RTP packet for making the transport more efficient. In a mobile communication environment, a typical text sample size is around 100-200 bytes. If the available bit rate and the packet size allow it, units should be aggregated into one RTP packet. Section 4.6 deals with aggregation.
c. トランスポートをより効率的にするために、ユニットのRTPパケットへの集約を有効にします。モバイル通信環境では、典型的なテキストサンプルサイズは約100〜200バイトです。使用可能なビットレートとパケットサイズが許可されている場合、ユニットは1つのRTPパケットに集約する必要があります。セクション4.6では、集約を扱います。
d. Enable the use of resilient transport mechanisms, such as repetition, retransmission [11], and FEC [7] (see Section 5). For a more general discussion, refer to RFC 2354 [8], which discusses available mechanisms for stream repair.
d. 繰り返し、再送信[11]、FEC [7]などの回復力のある輸送メカニズムの使用を可能にします（セクション5を参照）。より一般的な議論については、RFC 2354 [8]を参照してください。
The payload headers have been optimized in size for RTP. Instead of using 32-bit (S)LEN, SDUR, and SIDX header fields, which would carry many unused bits much of the time, it has been a design choice to reduce the size of these fields. As a consequence, this payload format has reduced maximum values with respect to sizes and durations of (text) samples and sample descriptions. These maximum values differ from those allowed in 3GP files, where they are expressed using 32-bit (unsigned) integers. In some cases, extension mechanisms are provided to deal with larger values. However, it is noted that the values used here should be enough for the streaming applications targeted.
ペイロードヘッダーは、RTPのサイズが最適化されています。32ビットレン、SDUR、およびSIDXヘッダーフィールドを使用する代わりに、多くの未使用のビットを運ぶことがありますが、これらのフィールドのサイズを縮小するための設計選択肢です。結果として、このペイロード形式は、（テキスト）サンプルのサイズと期間とサンプルの説明に関する最大値を減らしました。これらの最大値は、3GPファイルで許可された値とは異なり、32ビット（符号なし）整数を使用して表されます。場合によっては、より大きな値に対処するために拡張メカニズムが提供されます。ただし、ここで使用される値は、ターゲットを絞ったストリーミングアプリケーションに十分である必要があることに注意してください。
The following limitations apply:
次の制限が適用されます。
1. The maximum size of text samples carried in RTP packets is restricted to be a 16-bit (unsigned) integer (this includes the text strings and modifiers). This means a maximum size for the unit would be about 64 Kbytes. No extension mechanism is provided.
1. RTPパケットで運ばれるテキストサンプルの最大サイズは、16ビット（符号なし）整数に制限されています（これには、テキスト文字列と修飾子が含まれます）。これは、ユニットの最大サイズが約64 kバイトになることを意味します。拡張メカニズムは提供されていません。
2. The sample description index values are restricted to be an 8- bit (unsigned) integer. An extension mechanism is given in Section 4.3.
2. サンプル説明インデックス値は、8ビット（署名されていない）整数に制限されています。セクション4.3に拡張メカニズムが示されています。
3. The text sample duration is restricted to be a 24-bit (unsigned) integer. This yields a maximum duration at a timestamp clockrate of 1000 Hz of about 4.6 hours. Nevertheless, an extension mechanism is provided in Section 4.3.
3. テキストサンプルの期間は、24ビット（署名なし）整数に制限されています。これにより、約4.6時間の1000 Hzのタイムスタンプクロックレートで最大期間が得られます。それにもかかわらず、セクション4.3に拡張メカニズムが提供されています。
4. Sample descriptions are also restricted in size: If the size cannot be expressed as a 16-bit (unsigned) integer, the sample description shall not be conveyed. As in the case of the sample size, no extension mechanism is provided.
4. サンプルの説明もサイズが制限されています。サイズを16ビット（符号なし）整数として表現できない場合、サンプルの説明は伝えられません。サンプルサイズの場合のように、拡張メカニズムは提供されていません。
5. A further limitation concerns the UTF-16 encodings supported: Only transport of text strings following big endian byte order is supported. See Section 4.1.1 for details.
5. さらなる制限は、サポートされているUTF-16エンコーディングに関するものです。ビッグエンディアンバイトの順序に続くテキスト文字列の輸送のみがサポートされています。詳細については、セクション4.1.1を参照してください。
The following design choices were made:
次の設計の選択が行われました。
1. 'Unit' approach: The payload formats specified in this document follow a simple scheme: a 3-byte common header (Common Payload Header) followed by a specific header for each text sample (fragment) type. Following these headers, the text sample contents are placed (Section 4.1.1 and following). This structure is called a 'unit'.
1. 「ユニット」アプローチ：このドキュメントで指定されたペイロード形式は、単純なスキームに従います。3バイト共通ヘッダー（共通ペイロードヘッダー）に続いて、各テキストサンプル（フラグメント）タイプの特定のヘッダーが続きます。これらのヘッダーに続いて、テキストサンプルの内容が配置されます（セクション4.1.1以降）。この構造は「ユニット」と呼ばれます。
The following units have been devised to comply with the requirements mentioned in Section 2.3:
次のユニットは、セクション2.3に記載されている要件に準拠するために考案されています。
a. A TYPE 1 unit that contains one complete text sample,
a. 1つの完全なテキストサンプルを含むタイプ1ユニット、
b. A TYPE 2 unit that contains a complete text string or a fragment thereof,
b. 完全なテキスト文字列またはそのフラグメントを含むタイプ2ユニット、
c. A TYPE 3 unit that contains the complete modifiers or only the first fragment thereof,
c. 完全な修飾子またはその最初のフラグメントのみを含むタイプ3ユニット、
d. A TYPE 4 unit that contains one modifier fragment other than the first, and
d. 最初のモディファイアフラグメントを含むタイプ4ユニットと
e. A TYPE 5 unit that contains one sample description.
e. 1つのサンプルの説明を含むタイプ5ユニット。
This 'unit' approach was motivated by the following reasons:
この「ユニット」アプローチは、次の理由により動機付けられました。
1. Allows a simple classification of the text samples and text sample fragments that can be conveyed by the payload format.
1. ペイロード形式で伝達できるテキストサンプルとテキストサンプルフラグメントの簡単な分類を可能にします。
2. Enables easy interoperability with RFC 3640 [12]. During the development of this payload format, interest was shown from MPEG-4 standardization participants in developing a common payload structure for the transport of 3GPP Timed Text. While interoperability is not strictly necessary for this payload format to work, it has been pursued in this payload format. Section 4.8 explains how this is done.
2. RFC 3640との簡単な相互運用性を有効にします[12]。このペイロード形式の開発中に、3GPPタイミングテキストの輸送のための共通のペイロード構造の開発にMPEG-4標準化参加者から関心が示されました。このペイロード形式が機能するには、相互運用性は厳密に必要ではありませんが、このペイロード形式で追求されています。セクション4.8では、これがどのように行われるかについて説明します。
2. Character count is not implemented. This payload format does detect lost text samples fragments, but it does not enable an RTP receiver to find out the exact number of text characters lost. In fact, the fragment size included in the payload headers does not help in finding the number of lost characters because the UTF-8/UTF-16 [18][19] encodings used yield a variable number of bytes per character.
2. 文字カウントは実装されていません。このペイロード形式は、失われたテキストサンプルフラグメントを検出しますが、RTPレシーバーが失われたテキスト文字の正確な数を見つけることはできません。実際、ペイロードヘッダーに含まれるフラグメントサイズは、UTF-8/UTF-16 [18] [19]エンコーディングを使用したため、失われた文字の数を見つけるのに役立ちません。
For finding the exact number of lost characters, an additional field reflecting the character count (and possibly the character offset) upon fragmentation would be required. This would additionally require that the entity performing fragmentation count the characters included in each text fragment.
失われた文字の正確な数を見つけるには、断片化時に文字カウント（およびおそらくキャラクターのオフセット）を反映する追加のフィールドが必要です。これには、断片化を実行するエンティティが各テキストフラグメントに含まれる文字をカウントする必要があります。
One benefit of having a character count would be that the display application would be able to replace missing characters through some other character representing character loss. For example:
キャラクター数を持つことの利点の1つは、表示アプリケーションが、キャラクターの損失を表す他の文字を介して行方不明の文字を交換できることです。例えば：
If we take the "Some text is lost now" and assume the loss of a packet containing the text in the middle, this could be displayed (with a character count):
「現在、いくつかのテキストが失われた」と撮影し、中央にテキストを含むパケットの損失を想定した場合、これは（文字カウントで）表示される可能性があります。
"Some ############now" As opposed to:
「いくつかの###########今」とは対照的に：
"Some #now"
「いくつかの#now」
which is what this payload format enables ("#" indicates a missing character or packet, respectively).
これは、このペイロード形式が有効にするものです（ "＃"は、それぞれ欠落している文字またはパケットを示します）。
However, it is the consensus of the working group that for applications such as subtitling applications and multimedia presentations that use this payload format, such partial error correction is not worth the cost of including two additional fields; namely, character count and character offset. Instead, it is recommended that some more overhead be invested to provide full error correction by protecting the less text sample fragments using the measures outlined in Section 5.
ただし、このペイロード形式を使用する字幕アプリケーションやマルチメディアプレゼンテーションなどのアプリケーションの場合、このような部分的なエラー修正は、2つの追加フィールドを含めるコストに値しないため、ワーキンググループのコンセンサスです。すなわち、文字カウントと文字のオフセット。代わりに、セクション5で概説した測定値を使用して、より少ないテキストサンプルフラグメントを保護することにより、完全なエラー補正を提供するために、さらにオーバーヘッドを投資することをお勧めします。
3. Fragment re-assembly: In order to re-assemble the text samples, offset information is needed. Instead of a character or byte offset, a single byte, TOTAL/THIS, is used. These two values indicate the total number and current index of fragments of a text sample. This is simpler than having a character offset field in each fragment. Details in Section 4.1.3.
3. フラグメントの再組み立て：テキストサンプルを再組み立てるには、情報が必要です。文字またはバイトのオフセットの代わりに、単一のバイト、合計/これが使用されます。これらの2つの値は、テキストサンプルのフラグメントの総数と現在のインデックスを示しています。これは、各フラグメントに文字オフセットフィールドを持つよりも簡単です。セクション4.1.3の詳細。
4. A length field, LEN, is present in the common header fields. While the length in the RTP payload format is not needed by most RTP applications (typically lower layers, like UDP, provide this information), it does ease interoperability with RFC 3640. This is because the Access Units (AUs) used for carriage of data in RFC 3640 must include a length indication. Details are in Section 4.8.
4. 長さのフィールド、LENは、共通のヘッダーフィールドに存在します。RTPペイロード形式の長さは、ほとんどのRTPアプリケーションでは必要ありませんが（通常はUDPのような低レイヤーはこの情報を提供します）、RFC 3640との相互運用性を容易にします。これは、データのキャリッジに使用されるアクセス単位（AU）が使用されるためですRFCには、3640に長さの表示を含める必要があります。詳細はセクション4.8にあります。
5. The header fields in the specific payload headers (TYPE headers in Sections 4.1.2 to 4.1.6) have been arranged for easy processing on 32-bit machines. For this reason, the fields SIDX and SDUR are swapped in TYPE 1 unit, compared to the other units.
5. 特定のペイロードヘッダーのヘッダーフィールド（セクション4.1.2〜4.1.6のタイプヘッダー）は、32ビットマシンで簡単に処理するために配置されています。このため、Fields SidxとSDURは、他のユニットと比較して、タイプ1ユニットに交換されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [5]に記載されているように解釈される。
Furthermore, the following terms are used and have specific meaning within the context of this document:
さらに、次の用語が使用され、このドキュメントのコンテキスト内で具体的な意味があります。
text sample or whole text sample
テキストサンプルまたはテキスト全体のサンプル
In the 3GPP Timed Text media format [1], these terms refer to a unit of timed text data as contained in the source (3GP) file. This includes the text string byte count, possibly a Byte Order Mark, the text string and any modifiers that may follow. Its equivalent in audio/video would be a frame.
3GPPタイムタイムテキストメディア形式[1]では、これらの用語は、ソース（3GP）ファイルに含まれるタイミングされたテキストデータの単位を指します。これには、テキスト文字列バイトカウント、おそらくバイトの順序マーク、テキスト文字列、および従う可能性のある修飾子が含まれます。オーディオ/ビデオに相当するものはフレームになります。
In this document, however, a text sample contains only text strings followed by zero or more modifiers. This definition of text sample excludes the 16-bit text string byte count and the 16-bit Byte Order Mark (BOM) present in 3GP file text samples (see Section 4.3 and Figure 9). The 16-bit BOM is not transported in RTP, as explained in Section 4.1.1.
ただし、このドキュメントでは、テキストサンプルにはテキスト文字列のみが含まれ、その後にゼロ以上の修飾子が含まれます。このテキストサンプルの定義は、3GPファイルテキストサンプルに存在する16ビットテキスト文字列バイトカウントと16ビットバイトのオーダーマーク（BOM）を除外します（セクション4.3および図9を参照）。セクション4.1.1で説明されているように、16ビットBOMはRTPで輸送されません。
text strings
テキスト文字列
The actual text characters encoded either as UTF-8 or UTF-16. When using this payload format, the text string does not contain any byte order mark (BOM). See Figure 9 for details.
実際のテキスト文字は、UTF-8またはUTF-16としてエンコードされています。このペイロード形式を使用する場合、テキスト文字列にはバイトオーダーマーク（BOM）は含まれません。詳細については、図9を参照してください。
fragment or text sample fragment
フラグメントまたはテキストサンプルフラグメント
A fraction of a text sample. A fragment may contain either text strings or modifier (decoration) contents, but not both at the same time.
テキストサンプルの一部。フラグメントには、テキスト文字列または修飾子（装飾）の内容のいずれかを含む場合がありますが、両方と同時には含まれません。
sample contents
サンプルの内容
General term to identify timed text data transported when using this payload format. Sample contents may be one or several text samples, sample descriptions, and sample fragments (note that, as per Section 4.6, there is only one case in which more than one fragment may be included in a payload).
このペイロード形式を使用するときに輸送されるタイミングされたテキストデータを識別する一般用語。サンプルの内容は、1つまたは複数のテキストサンプル、サンプルの説明、およびサンプルフラグメントである場合があります（セクション4.6によると、複数のフラグメントがペイロードに含まれる可能性のあるケースは1つだけです）。
decoration or modifiers
装飾または修飾子
These terms are used interchangeably throughout the document to denote the contents of the text sample that modify the default text formatting. Modifiers may, for example, specify different font size for a particular sequence of characters or define karaoke timing for the sample.
これらの用語は、ドキュメント全体で同じ意味で使用され、デフォルトのテキストフォーマットを変更するテキストサンプルの内容を示します。たとえば、修飾子は、特定の文字シーケンスに異なるフォントサイズを指定したり、サンプルのカラオケタイミングを定義したりする場合があります。
sample description
サンプル概要
Information that is potentially shared by more than one text sample. In a 3GP file, a sample description is stored in a place where it can be shared. It contains setup and default information such as scrolling direction, text box position, delay value, default font, background color, etc.
複数のテキストサンプルで潜在的に共有される情報。3GPファイルでは、サンプルの説明が共有できる場所に保存されます。スクロール方向、テキストボックスの位置、遅延値、デフォルトフォント、背景色などのセットアップとデフォルト情報が含まれています。
units or transport units
ユニットまたは輸送ユニット
The payload headers specified in this document encapsulate text samples, fragments thereof, and sample descriptions by placing a common header and specific payload header (Sections 4.1.1 to 4.1.6) before them, thus building what is here called a (transport) unit.
このドキュメントで指定されたペイロードヘッダーは、テキストサンプル、そのフラグメント、およびサンプルの説明をカプセル化します。共通のヘッダーと特定のペイロードヘッダー（セクション4.1.1〜4.1.6）を配置し、ここで（輸送）ユニットと呼ばれるものを構築します。
aggregation or aggregate packet
集約または集約パケット
The payload of an aggregate (RTP) packet consists of several (transport) units.
集約（RTP）パケットのペイロードは、いくつかの（輸送）ユニットで構成されています。
track or stream
追跡またはストリーミング
3GP files contain audio/video and text tracks. This document enables streaming of text tracks using RTP. Therefore, these terms are used interchangeably in this document in the context of 3GP files.
3GPファイルには、オーディオ/ビデオとテキストトラックが含まれています。このドキュメントは、RTPを使用してテキストトラックのストリーミングを可能にします。したがって、これらの用語は、3GPファイルのコンテキストでこのドキュメントで同じ意味で使用されます。
Media Header Box / Track Header Box / ...
メディアヘッダーボックス /トラックヘッダーボックス / ...
The 3GP file format makes use of these structures defined in the ISO Base File Format [2]. When referring to these in this document, initials are capitalized for clarity.
3GPファイル形式は、ISOベースファイル形式[2]で定義されているこれらの構造を使用します。このドキュメントでこれらを参照する場合、イニシャルは明確にするために資本化されます。
The format of an RTP packet containing 3GPP timed text is shown below:
3GPPタイミングテキストを含む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 |
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |U| R | TYPE| LEN | :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
U| : (variable header fields depending on TYPE :
N| : :
I< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T| | |
| : SAMPLE CONTENTS :
| | +-+-+-+-+-+-+-+-+
| | |
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. 3GPP Timed Text RTP Packet Format
図1. 3GPPタイムされたテキストRTPパケット形式
Marker bit (M): The marker bit SHALL be set to 1 if the RTP packet includes one or more whole text samples or the last fragment of a text sample; otherwise, it is set to zero (0).
マーカービット（m）：RTPパケットに1つ以上のテキストサンプルまたはテキストサンプルの最後のフラグメントが含まれている場合、マーカービットは1に設定されます。それ以外の場合は、ゼロ（0）に設定されています。
Timestamp: The timestamp MUST indicate the sampling instant of the earliest (or only) unit contained in the RTP packet. The initial value SHOULD be randomly determined, as specified in RTP [3].
タイムスタンプ：タイムスタンプは、RTPパケットに含まれる最も早い（または唯一の）ユニットのサンプリングインスタントを示す必要があります。RTP [3]で指定されているように、初期値をランダムに決定する必要があります。
The timestamp value should provide enough timing resolution for expressing the duration of text samples, for synchronizing text with other media, and for performing RTP Control Protocol (RTCP) measurements such as the interarrival delay jitter or the RTCP Packet Receipt Times Report Block (Section 4.3 of RFC 3611 [20]). This is compliant to RTP, Section 5.1:
タイムスタンプの値は、テキストサンプルの持続時間を表現し、テキストを他のメディアと同期させるため、およびRTPコントロールプロトコル（RTCP）測定を実行するための十分なタイミング解像度を提供する必要があります。RFC 3611 [20]）。これはRTP、セクション5.1に準拠しています。
"The resolution of the clock MUST be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient)".
「クロックの解像度は、目的の同期精度とパケット到着ジッターの測定に十分でなければなりません（ビデオフレームごとに1つのダニは通常十分ではありません）」」
The above observation applies to both timed text tracks included in a 3GP file and live streaming sessions. In the case of a 3GP timed text track, the timestamp clockrate is the value of the "timescale" parameter in the Media Header Box for that text track. Each track in a 3GP file MAY have its own clockrate as specified in the Media Header Box. Likewise, live streaming applications SHALL use an appropriate timestamp clockrate. A default value of 1000 Hz is RECOMMENDED. Other timestamp clockrates MAY be used. In this case, the typical behavior here is to match the 3GPP timed text clockrate to that used by an associated audio or video stream.
上記の観測は、3GPファイルとライブストリーミングセッションに含まれるタイミングされたテキストトラックの両方に適用されます。3GPタイムされたテキストトラックの場合、タイムスタンプクロックレートは、そのテキストトラックのメディアヘッダーボックスの「タイムスケール」パラメーターの値です。3GPファイルの各トラックには、メディアヘッダーボックスで指定されているように、独自のクロックレートがある場合があります。同様に、ライブストリーミングアプリケーションは、適切なタイムスタンプクロックレートを使用するものとします。1000 Hzのデフォルト値が推奨されます。他のタイムスタンプ時計を使用することができます。この場合、ここでの典型的な動作は、3GPPタイムされたテキストクロックレートを、関連するオーディオまたはビデオストリームで使用したものと一致させることです。
In an aggregate payload, units MUST be placed in play-out order, i.e., earliest first in the payload. If TYPE 1 units are aggregated, the timestamp of the subsequent units MUST be obtained by adding the timed text sample duration of previous samples to the RTP timestamp value. There are two exceptions to this rule: TYPE 5 units and an aggregate payload containing two fragments of the same text sample. The details of the timestamp calculation are given in Section 4.6.
総ペイロードでは、ユニットをプレイアウト順に配置する必要があります。つまり、ペイロードで最初に最も早く配置する必要があります。タイプ1ユニットが集約されている場合、以前のサンプルのタイミングテキストサンプル期間をRTPタイムスタンプ値に追加することにより、後続ユニットのタイムスタンプを取得する必要があります。このルールには2つの例外があります。タイプ5ユニットと、同じテキストサンプルの2つのフラグメントを含む集約ペイロードです。タイムスタンプの計算の詳細は、セクション4.6に記載されています。
Finally, timestamp clockrates MUST be signaled by out-of-band means at session setup, e.g., using the media type "rate" parameter in SDP. See Section 9 for details.
最後に、SDPのメディアタイプの「レート」パラメーターを使用して、セッションのセットアップ時に、タイムスタンプの時計類は、セッションのセットアップ時に帯域外の手段によって信号を送る必要があります。詳細については、セクション9を参照してください。
Payload Type (PT): The payload type is set dynamically and sent by out-of-band means.
ペイロードタイプ（PT）：ペイロードタイプは動的に設定され、帯域外の手段によって送信されます。
The usage of the remaining RTP header fields (namely, V, P, X, CC, SN and SSRC) follows the rules of RTP and the profile in use.
残りのRTPヘッダーフィールド（つまり、V、P、X、CC、SN、SSRC）の使用は、RTPのルールと使用中のプロファイルに従います。
The (transport) units specified in this document consist of a set of common fields (U, R, TYPE, LEN), followed by specific header fields (TYPES 1-5) and text sample contents. See Figure 1 and Figure 2.
このドキュメントで指定された（輸送）ユニットは、共通フィールドのセット（U、R、タイプ、レン）で構成され、その後、特定のヘッダーフィールド（タイプ1〜5）とテキストサンプルの内容が続きます。図1と図2を参照してください。
In Figure 2, two example RTP packets are depicted. The first contains an aggregate RTP payload with two complete text samples, and the second contains one text sample fragment. After each unit header is explained, detailed payload examples follow in Section 4.7.
図2に、2つの例RTPパケットが描かれています。1つ目には、2つの完全なテキストサンプルを備えた集約RTPペイロードが含まれ、2番目には1つのテキストサンプルフラグメントが含まれています。各ユニットヘッダーが説明された後、詳細なペイロードの例はセクション4.7に続きます。
+----------------------+
| |
| RTP Header |
| |
---------+----------------------+
| | |
| |COMMON + TYPE 1 Header|
| ........................
UNIT 1 - | |
| | Text Sample |
| | |
|-------\........................
-------/| |
| |COMMON + TYPE 1 Header|
| ........................
UNIT 2 - | |
| | Text Sample |
| | |
| | |
---------+----------------------+
+----------------------+
| |
| RTP Header |
| |
---------+----------------------+
| | COMMON + TYPE 2 |
| | (or 3 or 4) Hdr |
| ........................
UNIT 3 - | |
| | Text Sample Fragment |
| | |
| | |
---------+----------------------+
Figure 2. Example RTP packets
図2.例RTPパケットの例
The fields common to all payload headers have the following format:
すべてのペイロードヘッダーに共通するフィールドには、次の形式があります。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Common payload header fields
図3.一般的なペイロードヘッダーフィールド
Where:
ただし：
o U (1 bit) "UTF Transformation flag": This is used to inform RTP receivers whether UTF-8 (U=0) or UTF-16 (U=1) was used to encode the text string. UTF-16 text strings transported by this payload format MUST be serialized in big endian order, a.k.a. network byte order.
o u（1ビット） "UTF変換フラグ"：これは、UTF-8（U = 0）またはUTF-16（U = 1）がテキスト文字列をエンコードするために使用されたかどうかをRTP受信者に通知するために使用されます。このペイロード形式で輸送されるUTF-16テキスト文字列は、大規模なエンド順、a.k.a。ネットワークバイト順序でシリアル化する必要があります。
Informative note: Timed text clients complying with the 3GPP Timed Text format [1] are only required to understand the big endian serialization. Thus, in order to ease interoperability, the reverse serialization (little endian) is not supported by this payload format.
有益なメモ：3GPPタイムされたテキスト形式[1]に準拠したタイミングされたテキストクライアントは、大きなエンディアンシリアル化を理解するためにのみ必要です。したがって、相互運用性を容易にするために、逆シリアル化（リトルエンディアン）は、このペイロード形式によってサポートされていません。
For the payload formats defined in this document, the U bit is only used in TYPE 1 and TYPE 2 headers. Senders MUST set the U bit to zero in TYPE 3, TYPE 4, and TYPE 5 headers. Consequently, receivers MUST ignore the U bit in TYPE 3, TYPE 4, and TYPE 5 headers.
このドキュメントで定義されているペイロード形式の場合、Uビットはタイプ1およびタイプ2ヘッダーでのみ使用されます。送信者は、タイプ3、タイプ4、およびタイプ5のヘッダーでUビットをゼロに設定する必要があります。したがって、受信機は、タイプ3、タイプ4、およびタイプ5のヘッダーでUビットを無視する必要があります。
o R (4 bits) "Reserved bits": for future extensions. This field MUST be set to zero (0x0) and MUST be ignored by receivers.
o R（4ビット）「予約ビット」：将来の拡張機能。このフィールドはゼロ（0x0）に設定する必要があり、受信機によって無視する必要があります。
o TYPE (3 bits) "Type Field": This field specifies which specific header fields follow. The following TYPE values are defined:
o タイプ（3ビット）「タイプフィールド」：このフィールドは、特定のヘッダーフィールドが次のことを指定します。次のタイプ値が定義されています。
- TYPE 1, for a whole text sample. - TYPE 2, for a text string fragment (without modifiers). - TYPE 3, for a whole modifier box or the first fragment of a modifier box. - TYPE 4, for a modifier fragment other than first. - TYPE 5, for a sample description. Exactly one header per sample description. - TYPE 0, 6, and 7 are reserved for future extensions. Note that future extensions are possible, e.g., a unit that explicitly signals the number of characters present in a fragment (see Section 2.5). In order to guarantee backwards-compatibility, it SHALL be possible that older clients ignore (newer) units they do not understand, without invalidating the timestamp calculation mechanisms or otherwise preventing them from decoding the other units.
- テキストサンプル全体のタイプ1。 - テキスト文字列フラグメントのタイプ2（修飾子なし）。 - モディファイア全体のボックス全体またはモディファイアボックスの最初のフラグメントのタイプ3。 - 最初のもの以外のモディファイアフラグメントのタイプ4。 - サンプルの説明については、タイプ5。サンプルの説明ごとに1つのヘッダーが1つだけです。-0、6、および7は、将来の拡張機能のために予約されています。たとえば、将来の拡張機能が可能であることに注意してください。たとえば、フラグメントに存在する文字の数を明示的に信号するユニットです（セクション2.5を参照）。後方互換性を保証するために、タイムスタンプの計算メカニズムを無効にすることなく、または他のユニットの解読を防ぐことなく、彼らが理解していない（新しい）ユニットを無視する（新しい）ユニットを無視する（新しい）ユニットを無視する可能性があります。
o Finally, the LEN (16 bits) "Length Field": indicates the size (in bytes) of this header field and all the fields following, i.e., the LEN field followed by the unit payload: text strings and modifiers (if any). This definition only excludes the initial U/R/TYPE byte of the common header. The LEN field follows network byte order.
o 最後に、LEN（16ビット）「長さフィールド」：このヘッダーフィールドのサイズ（バイト単位）と、次のすべてのフィールド、つまりレンフィールドに続いてユニットペイロード：テキスト文字列と修飾子（存在する場合）を示します。この定義は、共通ヘッダーの初期u/r/型バイトのみを除外します。LENフィールドは、ネットワークバイトの順序に従います。
The way in which LEN is obtained when streaming out of a 3GP file depends on the particular unit type. This is explained for each unit in the sections below.
3GPファイルからストリーミングするときにLENが取得される方法は、特定のユニットタイプに依存します。これは、以下のセクションの各ユニットについて説明されています。
For live streaming, both sample length and the LEN value for the current fragment MUST be calculated during the sampling process or during fragmentation.
ライブストリーミングの場合、サンプルの長さと現在のフラグメントのレン値の両方を、サンプリングプロセス中または断片化中に計算する必要があります。
In general, LEN may take the following values:
一般に、レンは次の値をとることができます。
- TYPE = 1, LEN >= 8 - TYPE = 2, LEN > 9 - TYPE = 3, LEN > 6 - TYPE = 4, LEN > 6 - TYPE = 5, LEN > 3
- type = 1、len> = 8 -type = 2、len> 9 -type = 3、len> 6 -type = 4、len> 6 -type = 5、len> 3
Receivers MUST discard units that do not comply with these values. However, the RTP header fields and the rest of the units in the payload (if any) are still useful, as guaranteed by the requirement for future extensions above.
受信機は、これらの値に準拠していないユニットを廃棄する必要があります。ただし、RTPヘッダーフィールドとペイロード内の残りのユニット（もしあれば）は、上記の将来の拡張の要件によって保証されているように、依然として有用です。
In the following subsections the different payload headers for the values of TYPE are specified.
次のサブセクションでは、タイプの値の異なるペイロードヘッダーが指定されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN (always >=8) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | TLEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLEN |
+-+-+-+-+-+-+-+-+
Figure 4. TYPE 1 Header Format
図4.タイプ1ヘッダー形式
This header type is used to transport whole text samples. This unit should be the most common case, i.e., the text sample should usually be small enough to be transported in one unit without having to separate text strings from modifiers. In an aggregate (RTP packet) payload containing several text samples, every sample is preceded by its own TYPE 1 header (see Figure 12).
このヘッダータイプは、テキスト全体のサンプルを輸送するために使用されます。このユニットは最も一般的なケースである必要があります。つまり、テキストサンプルは通常、修飾子からテキスト文字列を分離することなく、1つのユニットで輸送するのに十分なほど小さい必要があります。いくつかのテキストサンプルを含む集約（RTPパケット）ペイロードでは、すべてのサンプルの前に独自のタイプ1ヘッダーがあります（図12を参照）。
Informative note: As indicated in Section 3, "Terminology", a text sample is composed of the text strings followed by the modifiers (if any). This is also how text samples are stored in 3GP files. The separation of a text sample into text strings and modifiers is only needed for large samples (or small available IP MTU sizes; see Section 4.4), and it is accomplished with TYPE 2 and TYPE 3 headers, as explained in the sections below.
有益な注意：セクション3「用語」に示されているように、テキストサンプルはテキスト文字列に続く修飾子（存在する場合）で構成されています。これは、テキストサンプルが3GPファイルに保存される方法でもあります。テキストサンプルのテキスト文字列と修飾子への分離は、大規模なサンプル（または利用可能な小さなIP MTUサイズ、セクション4.4を参照）にのみ必要であり、以下のセクションで説明するように、タイプ2とタイプ3のヘッダーで達成されます。
Note also that empty text samples are considered whole text samples, although they do not contain sample contents. Empty text samples may be used to clear the display or to put an end to samples of unknown duration, for example. Units without sample contents SHALL have a LEN field value of 8 (0x0008).
また、空のテキストサンプルはテキストサンプル全体と見なされますが、サンプルの内容は含まれていません。空のテキストサンプルを使用して、ディスプレイをクリアしたり、期間不明のサンプルを終了することもできます。サンプル内容のないユニットには、LENフィールド値は8（0x0008）です。
The fields above have the following meaning:
上記のフィールドには次の意味があります。
o U, R, and TYPE, as defined in Section 4.1.1.
o セクション4.1.1で定義されているように、u、r、およびタイプ。
o LEN, in this case, represents the length of the (complete) text sample plus eight (8) bytes of headers. For finding the length of the text sample in the Sample Size Box of 3GP files, see Section 4.3.
o この場合、レンは（完全な）テキストサンプルの長さと8バイトのヘッダーを表します。3GPファイルのサンプルサイズボックスでテキストサンプルの長さを見つけるについては、セクション4.3を参照してください。
o SIDX (8 bits) "Text Sample Entry Index": This is an index used to identify the sample descriptions.
o SIDX（8ビット）「テキストサンプルエントリインデックス」：これは、サンプルの説明を識別するために使用されるインデックスです。
The SIDX field is used to find the sample description corresponding to the unit's payload. There are two types of SIDX values: static and dynamic.
SIDXフィールドは、ユニットのペイロードに対応するサンプル説明を見つけるために使用されます。SIDX値には、静的と動的な2つのタイプがあります。
Static SIDX values are used to identify sample descriptions that MUST be sent out-of-band and MUST remain active during the whole session. A static SIDX value is unequivocally linked to one particular sample description during the whole session. Carrying many sample descriptions out-of-band SHOULD be avoided, since these may become large and, ultimately, transport is not the goal of the out-of-band channel. Thus, this feature is RECOMMENDED for transporting those sample descriptions that provide a set of minimum default format settings. Static SIDX values MUST fall in the (closed) interval [129,254].
静的SIDX値は、帯域外で送信する必要があり、セッション全体でアクティブを維持する必要があるサンプルの説明を識別するために使用されます。静的SIDX値は、セッション全体で1つの特定のサンプル説明に明確にリンクされています。これらは大きくなり、最終的には輸送が帯域外チャネルの目標ではないため、多くのサンプルの説明を帯域外に携帯する必要があります。したがって、この機能は、最小デフォルト形式の設定のセットを提供するサンプルの説明を輸送するために推奨されます。静的SIDX値は（閉じた）間隔[129,254]に落ちる必要があります。
Dynamic SIDX values are used for sample descriptions sent in-band. Sample descriptions MAY be sent in-band for several reasons: because they are generated in real time, for transport resiliency, or both. A dynamic SIDX value is unequivocally linked to one particular sample description during the period in which this is active in the session, and it SHALL NOT be modified during that period. This period MAY be smaller than or equal to the session duration. This period is not known a priori. A maximum of 64 dynamic simultaneously active SIDX values is allowed at any moment. Dynamic SIDX values MUST fall in the closed interval [0,127]. This should be enough for both recorded content and live streaming applications. Nevertheless, a wraparound mechanism is provided in Section 4.2.1 to handle streaming sessions where more than 64 SIDX values might be needed. Servers MAY make use of dynamic sample descriptions. Clients MUST be able to receive and interpret dynamic sample descriptions.
動的SIDX値は、バンド内で送信されたサンプルの説明に使用されます。サンプルの説明は、いくつかの理由でバンド内で送信される場合があります。それらは、輸送の回復力、またはその両方のためにリアルタイムで生成されるためです。動的なSIDX値は、これがセッションでアクティブである期間中の特定のサンプル説明に明確にリンクされており、その期間中に変更されてはなりません。この期間は、セッション期間以下になる場合があります。この期間はアプリオリではありません。最大64の動的に同時にアクティブなSIDX値がいつでも許可されています。動的SIDX値は、閉じた間隔[0,127]に落ちる必要があります。これは、記録されたコンテンツとライブストリーミングアプリケーションの両方に十分でなければなりません。それにもかかわらず、64を超えるSIDX値が必要になる可能性のあるストリーミングセッションを処理するために、セクション4.2.1にラップアラウンドメカニズムが提供されています。サーバーは、動的なサンプルの説明を利用する場合があります。クライアントは、動的なサンプルの説明を受け取り、解釈できる必要があります。
Finally, SIDX values 128 and 255 are reserved for future use.
最後に、SIDX値128と255は将来の使用のために予約されています。
o SDUR (24 bits) "Text Sample Duration": indicates the sample duration in RTP timestamp units of the text sample. For this field, a length of 3 bytes is preferred to 2 bytes. This is because, for a typical clockrate of 1000 Hz, 16 bits would allow for a maximum duration of just 65 seconds, which might be too short for some streams. On the other hand, 24 bits at 1000 Hz allow for a maximum duration of about 4.6 hours, while for 90 KHz, this value is about 3 minutes. These values should be enough for streaming applications. However, if a larger duration is needed, the extension mechanism specified in Section 4.3 SHALL be used.
o SDUR（24ビット）「テキストサンプル期間」：テキストサンプルのRTPタイムスタンプ単位のサンプル期間を示します。このフィールドでは、2バイトよりも3バイトの長さが推奨されます。これは、1000 Hzの典型的なクロックレートの場合、16ビットがわずか65秒の最大期間を可能にするため、一部のストリームには短すぎる可能性があるためです。一方、1000 Hzで24ビットでは約4.6時間の最大期間がありますが、90 kHzの場合、この値は約3分です。これらの値は、アプリケーションをストリーミングするのに十分なはずです。ただし、より大きな期間が必要な場合、セクション4.3で指定された拡張メカニズムを使用するものとします。
Apart from defining the time period during which the text is displayed, the duration field is also used to find the timestamp of subsequent units within the aggregate RTP packet payload (if any).
テキストが表示される期間を定義することとは別に、持続時間フィールドを使用して、集約RTPパケットペイロード内の後続のユニットのタイムスタンプを見つけます（ある場合）。
This is explained in Section 4.6.
これはセクション4.6で説明されています。
Text samples have generally a known duration at the time of transmission. However, in some cases such as live streaming, the time for which a text piece shall be presented might not be known a priori. Thus, the value zero SDUR=0 (0x000000) is reserved to signal unknown duration. The amount of time that a sample of unknown duration is presented is determined by the timestamp of the next sample that shall be displayed at the receiver: Text samples of unknown duration SHALL be displayed until the next text sample becomes active, as indicated by its timestamp.
テキストサンプルは、通常、送信時に既知の期間があります。ただし、ライブストリーミングなどの場合には、テキストピースが提示される時間が先験的に知られていない場合があります。したがって、値ゼロSDUR = 0（0x000000）は、未知の期間を信号するように予約されています。未知の期間のサンプルが提示される時間の量は、受信機に表示される次のサンプルのタイムスタンプによって決定されます。次のテキストサンプルがアクティブになるまで、未知の期間のテキストサンプルは表示されます。。
The next example illustrates how units of unknown duration MUST be presented. If no text sample following is available, it is an implementation issue what should be displayed. For example, a server could send an empty sample to clear the text box.
次の例は、未知の期間の単位をどのように提示しなければならないかを示しています。テキストサンプルのフォローが利用できない場合、それは実装の問題であるものを表示する必要があります。たとえば、サーバーは空のサンプルを送信してテキストボックスをクリアできます。
Example: Imagine you are in an airport watching the latest news report while you wait for your plane. Airports are loud, so the news report is transcribed in the lower area of the screen. This area displays two lines of text: the headlines and the words spoken by the news speaker. As usual, the headlines are shown for a longer time than the rest. This time is, in principle, unknown to the stream server, which is streaming live. A headline is just replaced when the next headline is received.
例：飛行機を待っている間に最新のニュースレポートを見ている空港にいると想像してください。空港は騒々しいので、ニュースレポートは画面の下部に転写されます。この領域には、2行のテキストが表示されます。見出しとニューススピーカーが話した言葉です。いつものように、見出しは他の人よりも長い時間表示されます。今回は、原則として、ライブでストリーミングしているStream Serverには不明です。次の見出しを受信すると、見出しが交換されます。
However, upon storing a text sample with SDUR=0 in a 3GP file, the SDUR value MUST be changed to the effective duration of the text sample, which MUST be always greater than zero (note that the ISO file format [2] explicitly forbids a sample duration of zero). The effective duration MUST be calculated as the timestamp difference between the current sample (with unknown duration) and the next text sample that is displayed.
ただし、3GPファイルにSDUR = 0のテキストサンプルを保存すると、SDUR値をテキストサンプルの有効期間に変更する必要があります。ゼロのサンプル期間）。有効期間は、現在のサンプル（期間不明）と表示される次のテキストサンプルのタイムスタンプの差として計算する必要があります。
Note that samples of unknown duration SHALL NOT use features, which require knowledge of the duration of the sample up front. Such features are scrolling and karaoke in [1]. This also applies for future extensions of the Timed Text format. Furthermore, only sample descriptions (TYPE 5 units) MAY follow units of unknown duration in the same aggregate payload. Otherwise, it would not be possible to calculate the timestamp of these other units.
期間不明のサンプルは、サンプルの期間の知識を前もって必要とする機能を使用してはならないことに注意してください。このような機能は、[1]のスクロールとカラオケです。これは、時限テキスト形式の将来の拡張にも適用されます。さらに、サンプルの説明（タイプ5ユニット）のみが、同じ集計ペイロードの期間不明の単位に従うことができます。それ以外の場合、これらの他のユニットのタイムスタンプを計算することはできません。
For text contents stored in 3GP files, see Section 4.3 for details on how to extract the duration value. For live streaming, live encoders SHALL assign appropriate values and units according to [1] and later releases.
3GPファイルに保存されているテキストの内容については、期間値を抽出する方法の詳細については、セクション4.3を参照してください。ライブストリーミングの場合、ライブエンコーダーは[1]以降のリリースに従って適切な値とユニットを割り当てるものとします。
o TLEN (16 bits), "Text String Length", is a byte count of the text string. The decoder needs the text string length in order to know where the modifiers in the payload start. TLEN is not present in text string fragments (TYPE 2) since it can be deductively calculated from the LEN values of each fragment.
o Tlen（16ビット）、「テキスト文字列長」は、テキスト文字列のバイトカウントです。デコーダーは、ペイロードの修飾子がどこから始まるかを知るために、テキスト文字列の長さを必要とします。TLENは、各フラグメントのレン値から演ductive的に計算できるため、テキスト文字列フラグメント（タイプ2）に存在しません。
The TLEN value is obtained from the text samples as contained in 3GP files. Refer to Section 4.3. For live content, the TLEN MUST be obtained during the sampling process.
TLEN値は、3GPファイルに含まれるテキストサンプルから取得されます。セクション4.3を参照してください。ライブコンテンツの場合、サンプリングプロセス中にTLENを取得する必要があります。
o Finally, the actual text sample is placed after the TLEN field. As defined in Section 3, a text sample consists of a string of characters encoded using either UTF-8 or UTF-16, followed by zero or more modifiers. Note also that no BOM and no byte count are included in the strings carried in the payload (as opposed to text samples stored in 3GP files [1]).
o 最後に、実際のテキストサンプルはTLENフィールドの後に配置されます。セクション3で定義されているように、テキストサンプルは、UTF-8またはUTF-16のいずれかを使用してエンコードされた一連の文字列で構成され、その後にゼロ以上の修飾子が続きます。また、3GPファイル[1]に保存されているテキストサンプルとは対照的に、ペイロードに掲載された文字列にBOMおよびバイト数が含まれていないことに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN( always >9) | TOTAL | THIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. TYPE 2 Header Format
図5.タイプ2ヘッダー形式
This header type is used to transport either a whole text string or a fragment of it. TYPE 2 units SHALL NOT contain modifiers. In detail:
このヘッダータイプは、テキスト文字列全体またはその断片のいずれかを輸送するために使用されます。タイプ2ユニットには修飾子が含まれていません。詳細に：
o U, R, and TYPE, as defined in Section 4.1.1.
o セクション4.1.1で定義されているように、u、r、およびタイプ。
o SIDX and SDUR, as defined in Section 4.1.2.
o セクション4.1.2で定義されているように、SIDXとSDUR。
Note that the U, SIDX, and SDUR fields are meaningful since partial text strings can also be displayed.
部分的なテキスト文字列も表示できるため、U、SIDX、およびSDURフィールドは意味があることに注意してください。
o The LEN field (16 bits) indicates the length of the text string fragment plus nine (9) bytes of headers. Its value is calculated upon fragmentation. LEN MUST always be greater than nine (0x0009). Otherwise, the unit MUST be discarded.
o LENフィールド（16ビット）は、テキスト文字列フラグメントの長さと9バイトのヘッダーを示します。その値は断片化時に計算されます。LENは常に9（0x0009）を超える必要があります。それ以外の場合、ユニットを破棄する必要があります。
According to the guidelines in Section 4.4, text strings MUST be split at character boundaries for allowing the display of text fragments. Therefore, a text fragment MUST contain at least one character in either UTF-8 or UTF-16. Actually, this is just a formalism since by observing the guidelines, much larger fragments should be created.
セクション4.4のガイドラインによると、テキストフラグメントの表示を許可するために、テキスト文字列を文字境界で分割する必要があります。したがって、テキストフラグメントには、UTF-8またはUTF-16のいずれかに少なくとも1つの文字を含める必要があります。実際、これはガイドラインを観察することで、はるかに大きな断片を作成する必要があるため、これは単なる形式主義です。
Note also that TYPE 2 units do not contain an explicit text string length, TLEN (see TYPE 1). This is because TYPE 2 units do not contain any modifiers after the text string. If needed, the length of the received string can be obtained using the LEN values of the TYPE 2 units.
また、タイプ2ユニットには、明示的なテキスト文字列長TLENが含まれていないことに注意してください（タイプ1を参照）。これは、タイプ2ユニットにテキスト文字列の後に修飾子が含まれていないためです。必要に応じて、受信した文字列の長さは、タイプ2ユニットのLEN値を使用して取得できます。
o The SLEN field (16 bits) indicates the size (in bytes) of the original (whole) text sample to which this fragment belongs. This length comprises the text string plus any modifier boxes present (and includes neither the byte order mark nor the text string length as mentioned in Section 3, "Terminology").
o スレンフィールド（16ビット）は、このフラグメントが属する元の（全体の）テキストサンプルのサイズ（バイト単位）を示します。この長さは、テキスト文字列と存在するモディファイアボックスを含む（また、セクション3「用語」に記載されているように、バイトの順序マークもテキスト文字列の長さも含まれていません）。
Regarding the text sample length: Timed text samples are not generated at regular intervals, nor is there a default sample size. If 3GP files are streamed, the length of the text samples is calculated beforehand and included in the track itself, while for live encoding it is the real time encoder that SHALL choose an appropriate size for each text sample. In this case, the amount of text 'captured' in a sample depends on the text source and the particular application (see examples below). Samples may, e.g., be tailored to match the packet MTU as closely as possible or to provide a given redundancy for the available bit rate. The encoding application MUST also take into account the delay constraints of the real-time session and assess whether FEC, retransmission, or other similar techniques are reasonable options for stream repair.
テキストのサンプルの長さに関して：タイミングされたテキストサンプルは、定期的な間隔で生成されず、デフォルトのサンプルサイズもありません。3GPファイルがストリーミングされている場合、テキストサンプルの長さは事前に計算され、トラック自体に含まれますが、ライブエンコードの場合、各テキストサンプルに適切なサイズを選択するリアルタイムエンコーダーです。この場合、サンプルで「キャプチャされた」テキストの量は、テキストソースと特定のアプリケーションに依存します（以下の例を参照）。サンプルは、たとえば、パケットMTUを可能な限り密接に一致させるため、または利用可能なビットレートの特定の冗長性を提供するように調整することができます。エンコーディングアプリケーションは、リアルタイムセッションの遅延制約も考慮し、FEC、再送信、またはその他の同様の手法がストリーム修理の合理的なオプションであるかどうかを評価する必要があります。
The following examples shall illustrate how a real-time encoder may choose its settings to adapt to the scenario constraints.
次の例は、リアルタイムエンコーダーがシナリオの制約に適応するために設定を選択する方法を説明するものとします。
Example: Imagine a newscast scenario, where the spoken news is transcribed and synchronized with the image and voice of the reporter. We assume that the news speaker talks at an average speed of 5 words per second with an average word length of 5 characters plus one space per word, i.e., 30 characters per second. We assume an available IP MTU of 576 bytes and an available bitrate of 576*8 bits per second = 4.6 Kbps. We assume each character can be encoded using 2 bytes in UTF-16. In this scenario, several constraints may apply; for example: available IP MTU, available bandwidth, allowable delay, and required redundancy. If the target were to minimize the packet overhead, a text sample covering 8 seconds of text would be closest to the IP MTU:
例：音声ニュースが記者の画像と声と同期されているニュースキャストシナリオを想像してください。ニューススピーカーは平均速度5語で、平均単語の長さ5文字と単語ごとに1つのスペース、つまり30文字あたり30文字で話し合うと想定しています。576バイトの利用可能なIP MTUと、576*8ビットあたり576*8ビット= 4.6 kbpsを想定しています。各文字は、UTF-16の2バイトを使用してエンコードできると仮定します。このシナリオでは、いくつかの制約が適用される場合があります。例：利用可能なIP MTU、利用可能な帯域幅、許容遅延、および必要な冗長性。ターゲットがパケットオーバーヘッドを最小化する場合、8秒のテキストをカバーするテキストサンプルがIP MTUに最も近いものになります。
IP/UDP/RTP/TYPE1 Header + (8-second text sample)
= 20 + 8 + 12 + 8 + (~6 chars/word * 5 word/s * 8 s * 2 chars/word)
= 528 bytes < 576 bytes
For other scenarios, like lossy networks, it may happen that just one packet per sample is too low a redundancy. In this case, a choice could be that the encoder 'collects' text every second, thus yielding text samples (TYPE 1 units) of 68 bytes, TYPE 1 header included. We can, e.g., include three contiguous text samples in one RTP payload: the current and last two text samples (see below). This accounts to a total IP packet size of 20 + 8 + 12 + 3*(8 + 60) = 244 bytes. Now, with the same available bitrate of 4.6 Kbps, these 244-byte packets can be sent redundantly up two times per second:
Lossy Networksのような他のシナリオの場合、サンプルごとに1つのパケットだけが冗長性が低すぎることがあります。この場合、選択肢は、エンコーダがテキストを毎秒「収集」し、68バイトのテキストサンプル（タイプ1単位）を生成することです。タイプ1ヘッダーが含まれています。たとえば、1つのRTPペイロードに3つの隣接テキストサンプルを含めることができます。現在と最後の2つのテキストサンプル（以下を参照）です。これは、20 8 12 3*（8 60）= 244バイトの合計IPパケットサイズを説明します。現在、4.6 kbpsの同じ利用可能なビットレートで、これらの244バイトパケットは1秒あたり2回冗長に送信できます。
RTP payload (1,2,3)(1,2,3) (2,3,4)(2,3,4) (3,4,5)(3,4,5) ...
Time: <----1s------> <----1s------> <-----1s-----> ...
This means that each text sample is sent at least six times, which should provide enough redundancy. Although not as bandwidth efficient (488*8 < 528*8 < 576*8 bps) as the previous packetization, this option increases the stream redundancy while still meeting the delay and bandwidth constraints.
これは、各テキストサンプルが少なくとも6回送信されることを意味し、十分な冗長性を提供するはずです。以前のパケット化として帯域幅効率が高く（488*8 <528*8 <576*8 bps）。このオプションは、遅延と帯域幅の制約を満たしながらストリームの冗長性を増加させます。
Another example would be a user sending timed text from a type-in area in the display. In this case, the text sample is created as soon as the user clicks the 'send' button. Depending on the packet length, fragmentation may be needed.
別の例は、ディスプレイ内のタイプイン領域からタイムインテキストを送信するユーザーです。この場合、ユーザーが[送信]ボタンをクリックするとすぐにテキストサンプルが作成されます。パケットの長さに応じて、断片化が必要になる場合があります。
In a video conferencing application, text is synchronized with audio and video. Thus, the text samples shall be displayed long enough to be read by a human, shall fit in the video screen, and shall 'capture' the audio contents rendered during the time the corresponding video and audio is rendered.
ビデオ会議アプリケーションでは、テキストはオーディオとビデオと同期されています。したがって、テキストサンプルは、人間が読むのに十分な長さで表示され、ビデオ画面に収まり、対応するビデオとオーディオがレンダリングされる間にレンダリングされたオーディオコンテンツを「キャプチャ」するものとします。
For stored content, see Section 4.3 for details on how to find the SLEN value in a 3GP file. For live content, the SLEN MUST be obtained during the sampling process.
保存されたコンテンツについては、3GPファイルでスレン値を見つける方法の詳細については、セクション4.3を参照してください。ライブコンテンツの場合、サンプリングプロセス中にスレンを取得する必要があります。
Finally, note that clients MAY use SLEN to buffer space for the remaining fragments of a text sample.
最後に、クライアントはスレンを使用してテキストサンプルの残りの断片のためにスペースをバッファする場合があることに注意してください。
o The fields TOTAL (4 bits) and THIS (4 bits) indicate the total number of fragments in which the original text sample (i.e., the text string and its modifiers) has been fragmented and which order occupies the current fragment in that sequence, respectively. Note that the sequence number alone cannot replace the functionality of the THIS field, since packets (and fragments) may be repeated, e.g., as in repeated transmission (see Section 5). Thus, an indication for "fragment offset" is needed.
o フィールドの合計（4ビット）とこれ（4ビット）は、元のテキストサンプル（つまり、テキスト文字列とその修飾子）が断片化され、そのシーケンス内の現在のフラグメントをそれぞれ占有する断片の総数を示しています。。パケット（およびフラグメント）が繰り返されるように、パケット（およびフラグメント）が繰り返される可能性があるため、シーケンス番号のみがこのフィールドの機能を置き換えることはできないことに注意してください（セクション5を参照）。したがって、「フラグメントオフセット」の兆候が必要です。
The usual "byte offset" field is not used here for two reasons: a) it would take one more byte and b) it does not provide any information on the character offset. UTF-8/UTF-16 text strings have, in general, a variable character length ranging from 1 to 6 bytes. Therefore, the TOTAL/THIS solution is preferred. It could also be argued that the LEN and SLEN fields be used for this purpose, but while they would provide information about the completeness of the text sample, they do not specify the order of the fragments.
通常の「バイトオフセット」フィールドは、2つの理由でここでは使用されません。a）もう1つのバイトが必要で、b）文字オフセットに関する情報は提供されません。UTF-8/UTF-16テキスト文字列には、一般に、1〜6バイトの範囲の可変文字長があります。したがって、合計/このソリューションが推奨されます。また、レンとスレンのフィールドはこの目的に使用されると主張することもできますが、テキストサンプルの完全性に関する情報を提供しますが、フラグメントの順序を指定しません。
In all cases (TYPEs 2, 3 and 4), if the value of THIS is greater than TOTAL or if TOTAL equals zero (0x0), the fragment SHALL be discarded.
すべての場合（タイプ2、3、および4）、この値が合計よりも大きい場合、または合計がゼロ（0x0）に等しい場合、フラグメントは破棄されます。
o Finally, the sample contents following the SLEN field consist of a fragment of the UTF-8/UTF-16 character string; no modifiers follow.
o 最後に、Slenフィールドに続くサンプルの内容は、UTF-8/UTF-16文字弦のフラグメントで構成されています。修飾子は続きません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN( always >6) |TOTAL | THIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. TYPE 3 Header Format
図6.タイプ3ヘッダー形式
This header type is used to transport either the entire modifier contents present in a text sample or just the first fragment of them. This depends on whether the modifier boxes fit in the current RTP payload.
このヘッダータイプは、テキストサンプルに存在する修飾子全体の内容物全体、またはそれらの最初の断片のみを輸送するために使用されます。これは、モディファイアボックスが現在のRTPペイロードに収まるかどうかに依存します。
If a text sample containing modifiers is fragmented, this header MUST be used to transport the first fragment or, if possible, the complete modifiers.
修飾子を含むテキストサンプルが断片化されている場合、このヘッダーを使用して、最初のフラグメント、または可能であれば完全な修飾子を輸送する必要があります。
In detail:
詳細に：
o The U, R, and TYPE fields are defined as in Section 4.1.1.
o u、r、および型フィールドは、セクション4.1.1のように定義されます。
o LEN indicates the length of the modifier contents. Its value is obtained upon fragmentation. Additionally, the LEN field MUST be greater than six (0x0006). Otherwise, the unit MUST be discarded.
o LENは、修飾子の内容の長さを示します。その値は断片化時に得られます。さらに、LENフィールドは6（0x0006）を超える必要があります。それ以外の場合、ユニットを破棄する必要があります。
o The TOTAL/THIS field has the same meaning as for TYPE 2.
o 合計/このフィールドは、タイプ2と同じ意味を持っています。
For TYPE 3 units containing the last (trailing) modifier fragment, the value of TOTAL MUST be equal to that of THIS (TOTAL=THIS). In addition, TOTAL=THIS MUST be greater than one, because the total number of fragments of a text sample is logically always larger than one.
最後の（後続の）修飾子フラグメントを含むタイプ3ユニットの場合、合計の値はこれの値と等しくなければなりません（合計=これ）。さらに、テキストサンプルのフラグメントの総数は常に1よりも常に大きいため、合計=これは1より大きくなければなりません。
Otherwise, if TOTAL is different from THIS in a TYPE 3 unit, this means that the unit contains the first fragment of the modifiers.
それ以外の場合、タイプ3ユニットで合計がこれと異なる場合、これはユニットに修飾子の最初のフラグメントが含まれていることを意味します。
o The SDUR has the same definition for TYPE 1. Since the fragments are always transported in own RTP packets, this field is only needed to know how long this fragment is valid. This may, e.g., be used to determine how long it should be kept in the display buffer.
o SDURにはタイプ1と同じ定義があります。フラグメントは常に独自のRTPパケットで輸送されるため、このフラグメントが有効な期間を知るためにこのフィールドは必要です。これは、たとえば、ディスプレイバッファに保管する時間を決定するために使用される場合があります。
Note that the SLEN and SIDX fields are not present in TYPE 3 unit headers. This is because a) these fragments do not contain text strings and b) these types of fragments are applied over text string fragments, which already contain this information.
SlenおよびSidxフィールドは、タイプ3ユニットヘッダーには存在しないことに注意してください。これは、a）これらのフラグメントにテキスト文字列が含まれておらず、b）これらのタイプのフラグメントがテキスト文字列フラグメントに適用されているためです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN( always >6) |TOTAL | THIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. TYPE 4 Header Format
図7.タイプ4ヘッダー形式
This header type is placed before modifier fragments, other than the first one.
このヘッダータイプは、最初のもの以外のモディファイアフラグメントの前に配置されます。
The U, R, and TYPE fields are used as per Section 4.1.1.
U、R、およびタイプフィールドは、セクション4.1.1に従って使用されます。
LEN indicates as for TYPE 3 the length of the modifier contents and SHALL also be obtained upon fragmentation. The LEN field MUST be greater than six (0x0006). Otherwise, the unit MUST be discarded.
LENは、タイプ3では修飾子の内容の長さを示し、断片化時にも取得するものとします。LENフィールドは6（0x0006）を超える必要があります。それ以外の場合、ユニットを破棄する必要があります。
TOTAL/THIS is used as in TYPE 2.
合計/これはタイプ2のように使用されます。
The SDUR field is defined as in TYPE 1. The reasoning behind the absence of SLEN and SIDX is the same as in TYPE 3 units.
SDURフィールドは、タイプ1のように定義されます。SlenとSIDXの不在の背後にある理由は、タイプ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN( always >3) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. TYPE 5 Header Format
図8.タイプ5ヘッダー形式
This header type is used to transport (dynamic) sample descriptions. Every sample description MUST have its own TYPE 5 header.
このヘッダータイプは、サンプルの説明を輸送するために使用されます。すべてのサンプルの説明には、独自のタイプ5ヘッダーが必要です。
The U, R, and TYPE fields are used as per Section 4.1.1.
U、R、およびタイプフィールドは、セクション4.1.1に従って使用されます。
The LEN field indicates the length of the sample description, plus three units accounting for the SIDX and LEN field itself. Thus, this field MUST be greater than three (0x0003). Otherwise, the unit MUST be discarded.
LENフィールドは、サンプルの説明の長さと、SIDXおよびLENフィールド自体を占める3つのユニットを示します。したがって、このフィールドは3（0x0003）を超える必要があります。それ以外の場合、ユニットを破棄する必要があります。
If the sample is streamed from a 3GP file, the length of the sample description contents (i.e., what comes after SIDX in the unit itself) is obtained from the file (see Section 4.3).
サンプルが3GPファイルからストリーミングされている場合、サンプルの説明内容の長さ（つまり、ユニット自体のSIDXの後に来るもの）がファイルから取得されます（セクション4.3を参照）。
The SIDX field contains a dynamic SIDX value assigned to the sample description carried as sample content of this unit. As only dynamic sample descriptions are carried using TYPE 5, the possible SIDX values are in the (closed) interval [0,127].
SIDXフィールドには、このユニットのサンプルコンテンツとして伝達されたサンプル説明に割り当てられた動的なSIDX値が含まれています。タイプ5を使用して動的なサンプル記述のみが実行されるため、可能なSIDX値は（閉じた）間隔[0,127]にあります。
Senders MAY make use of TYPE 5 units. All receivers MUST implement support for TYPE 5 units, since it adds minimum complexity and may increase the robustness of the streaming session.
送信者は、タイプ5ユニットを使用する場合があります。すべてのレシーバーは、タイプ5ユニットのサポートを実装する必要があります。これは、最小限の複雑さを追加し、ストリーミングセッションの堅牢性を高める可能性があるためです。
The next section specifies how SIDX values are calculated.
次のセクションでは、SIDX値の計算方法を指定します。
The buffering of sample descriptions is a matter of the client's timed text codec implementation. In order to work properly, this payload format requires that:
サンプルの説明のバッファリングは、クライアントのタイミングされたテキストコーデックの実装の問題です。適切に動作するために、このペイロード形式には次のことが必要です。
o Static sample descriptions MUST be buffered at the client, at least, for the duration of the session.
o 少なくともセッションの期間中は、クライアントで静的なサンプルの説明をバッファリングする必要があります。
o If dynamic sample descriptions are used, their buffering and update of the SIDX values MUST follow the mechanism described in the next section.
o 動的なサンプルの説明を使用する場合、SIDX値のバッファリングと更新は、次のセクションで説明したメカニズムに従う必要があります。
The use of dynamic sample descriptions by senders is OPTIONAL. However, if they are used, senders MUST implement this mechanism. Receivers MUST always implement it.
送信者による動的なサンプル説明の使用はオプションです。ただし、それらが使用されている場合、送信者はこのメカニズムを実装する必要があります。受信者は常にそれを実装する必要があります。
Dynamic SIDX values remain active either during the entire duration of the session (if used just once) or in different intervals of it (if used once or more).
動的SIDX値は、セッションの全期間（1回だけ使用される場合）またはそれの異なる間隔（1回以上使用する場合）のいずれかの間、アクティブのままです。
Note: In the following, SIDX means dynamic SIDX.
注：以下では、SIDXは動的SIDXを意味します。
For choosing the wraparound mechanism, the following rationale was used: There are 128 dynamic SIDX values possible, [0..127]. If one chooses to allow a maximum of 127 to be used as dynamic SIDXs, then any reordered packet with a new sample description would make the mechanism fail. For example, if the last packet received is SIDX=5, then all 127 values except SIDX=6 would be "active". Now, if a reordered packet arrives with a new description, SIDX=9, it will be mistakenly discarded, because the SIDX=9 is, at that moment, marked as "active" and active sample descriptions shall not be re-written. Therefore, a "guard interval" is introduced. This guard interval reduces the number of active SIDXs at any point in time to 64. Although most timed text applications will probably need less than 64 sample descriptions during a session (in total), a wraparound mechanism to handle the need for more is described here.
ラップアラウンドメカニズムを選択するために、次の根拠が使用されました。128の動的SIDX値が可能です[0..127]。最大127を動的SIDXとして使用できるようにすることを選択した場合、新しいサンプルの説明を備えた再注文パケットは、メカニズムに障害が発生します。たとえば、受信した最後のパケットがSIDX = 5である場合、SIDX = 6を除くすべての127値は「アクティブ」になります。Sidx = 9は、その時点で「アクティブ」およびアクティブなサンプル記述としてマークされているため、並べ替えられたパケットが新しい説明sidx = 9で到着すると、誤って破棄されます。したがって、「ガード間隔」が導入されます。このガード間隔は、いつでもアクティブなSIDXの数を64に減らします。ほとんどのタイミングのテキストアプリケーションは、セッション中に64未満のサンプルの説明が必要ですが、より多くの必要性を処理するラップアラウンドメカニズムについて説明します。。
Thereby, a sliding window of 64 active SIDX values is used. Values within the window are "active"; all others are marked "inactive". An SIDX value becomes active if at least one sample description identified by that SIDX has been received. Since sample descriptions MAY be sent redundantly, it is possible that a client receives a given SIDX several times. However, active sample descriptions SHALL NOT be overwritten: The receiver SHALL ignore redundant sample descriptions and it MUST use the already cached copy. The "guard interval" of (64) inactive values ensures that the correct association SIDX <-> sample description is always used.
これにより、64のアクティブSIDX値のスライドウィンドウが使用されます。ウィンドウ内の値は「アクティブ」です。他のすべては「非アクティブ」とマークされています。SIDXが識別された少なくとも1つのサンプル説明が受信された場合、SIDX値はアクティブになります。サンプルの説明は冗長に送信される可能性があるため、クライアントが特定のSIDXを数回受信する可能性があります。ただし、アクティブなサンプルの説明は上書きされてはなりません。受信者は、冗長なサンプルの説明を無視し、すでにキャッシュされたコピーを使用する必要があります。（64）の非アクティブ値の「ガード間隔」により、正しい関連付けSIDX <->サンプルの説明が常に使用されることが保証されます。
Informative note: As for the "guard interval" value itself, 64 as 128/2 was considered simple enough while still meeting the expected maximum number of sample descriptions. Besides that, there's no other motivation for choosing 64 or a different value.
有益な注意：「ガード間隔」値自体については、64 AS 128/2は、予想される最大数のサンプル記述数を満たしている間、十分に単純と見なされました。それに加えて、64または異なる値を選択する他の動機はありません。
The following algorithm is used to buffer dynamic sample descriptions and to maintain the dynamic SIDX values:
次のアルゴリズムは、動的なサンプルの説明をバッファリングし、動的なSIDX値を維持するために使用されます。
Let X be the last SIDX received that updated the range of active sample descriptions. Let Y be a value within the allowed range for dynamic SIDX: [0,127], and different from X. Let Z be the SIDX of the last received sample description. Then:
xを、アクティブなサンプルの説明の範囲を更新する最後のSIDXとします。yを動的sidx：[0,127]の許容範囲内の値とし、Xとは異なります。zを最後に受信したサンプル説明のsidxとします。それから：
1. Initialize all dynamic SIDX values as inactive. For stored contents, read the sample description index in the Sample to Chunk box ("stsc") for that sample. For live streaming, the first value MAY be zero or any other value in the interval above. Go to step 2.
1. すべての動的SIDX値を非アクティブとして初期化します。保存されている内容については、サンプルのサンプルのサンプル説明インデックス（ "STSC"）を読み取ります。ライブストリーミングの場合、最初の値は、上記の間隔のゼロまたはその他の値になる場合があります。ステップ2に進みます。
2. First, in-band sample description with SIDX=Z is received and stored; set X=Z. Go to step 3.
2. まず、sidx = zを使用した帯域内サンプルの説明が受信され、保存されます。x = zを設定します。ステップ3に進みます。
3. Any SIDX within the interval [X+1 modulo(128), X+64 modulo(128)] is marked as inactive, and any corresponding sample description is deleted. Any SIDX within the interval [X+65 modulo(128), X] is set active. Go to step 4 (wait state).
3. 間隔[x 1 modulo（128）、x 64 modulo（128）]内のsidxは非アクティブとしてマークされ、対応するサンプルの説明は削除されます。間隔[x 65 modulo（128）、x]内のsidxはアクティブに設定されています。ステップ4（待機状態）に移動します。
4. Wait for next sample description. Once the client is initialized, the interval of active SIDX values MUST change whenever a sample description with an SIDX value in the inactive set is received. That is, upon reception of a sample description with SIDX=Z, do the following:
4. 次のサンプルの説明を待ちます。クライアントが初期化されると、アクティブSIDX値の間隔は、非アクティブセットにSIDX値があるサンプルの説明が受信されるたびに変更する必要があります。つまり、SIDX = Zでサンプルの説明を受信すると、次のことを行います。
a. If Z is in the (closed) interval [X+1 modulo(128), X+64 modulo(128)] then set X=Z, store the sample description, and go to step 3.
a. zが（閉じた）間隔[x 1 modulo（128）、x 64 modulo（128）]にある場合、x = zを設定し、サンプルの説明を保存し、ステップ3に進みます。
b. Else, Z must be in the interval [X+65 modulo(128), X], thus:
b. それ以外の場合、zは間隔[x 65 modulo（128）、x]にある必要があります。
i. If SIDX=Z is not stored, then store the sample description. Go to beginning of step 4 (wait state). ii. Else, go to the beginning of step 4 (wait state).
私。SIDX = zが保存されていない場合は、サンプルの説明を保存します。ステップ4（待機状態）の開始に移動します。ii。それ以外の場合は、ステップ4（待機状態）の開始に進みます。
Informative note: It is allowed that any value of SIDX=X be sent in the interval [0,127]. For example, if [64..127] is the current active set and SIDX=0 is sent, a new sample description is defined (0) and an old one deleted (64); thus [65..127] and [0] are active. Similarly, one could now send SIDX=64, thus inverting the active and inactive sets.
有益な注意：Sidx = xの値は、間隔[0,127]で送信されることが許可されています。たとえば、[64..127]が現在のアクティブセットであり、SIDX = 0が送信される場合、新しいサンプルの説明が定義され、古いものが削除されます（64）。したがって、[65..127]および[0]はアクティブです。同様に、Sidx = 64を送信して、アクティブセットと非アクティブセットを反転させることができます。
Example: If X=4, any SIDX in the interval [5,68] is inactive. Active SIDX values are in the complementary interval [69,127] plus
例：x = 4の場合、間隔[5,68]のsidxは非アクティブです。アクティブなSIDX値は相補的な間隔[69,127]プラスにあります
[0,4]. For example, if the client receives a SIDX=6, then the active interval is now different: [0,6] plus [71,127]. If the received SIDX is in the current active interval, no change SHALL be applied.
[0,4]。たとえば、クライアントがSIDX = 6を受信した場合、アクティブ間隔は今では異なります：[0,6]プラス[71,127]。受信したSIDXが現在のアクティブ間隔にある場合、変更は適用されません。
For the purpose of streaming timed text contents, some values in the boxes contained in a 3GP file are mapped to fields of this payload header. This section explains where to find those values.
タイミングのテキストコンテンツをストリーミングするために、3GPファイルに含まれるボックス内の一部の値が、このペイロードヘッダーのフィールドにマッピングされます。このセクションでは、これらの値を見つける場所について説明します。
Additionally, for the duration and sample description indexes, extension mechanisms are provided. All senders MUST implement the extension mechanisms described herein.
さらに、期間とサンプルの説明インデックスについて、拡張メカニズムが提供されます。すべての送信者は、本明細書に記載されている拡張メカニズムを実装する必要があります。
If the file is streamed out of a 3GP file, the following guidelines SHALL be followed.
ファイルが3GPファイルからストリーミングされている場合、次のガイドラインに従うものとします。
Note: All fields in the objects (boxes) of a 3GP file are found in network byte order.
注：3GPファイルのオブジェクト（ボックス）内のすべてのフィールドは、ネットワークバイトの順序で見つかります。
Information obtained from the Sample Table Box (stbl):
サンプルテーブルボックス（STBL）から取得した情報：
o Sample Descriptions and Sample Description length: The Sample Description box (stsd, inside the stbl) contains the sample descriptions. For timed text media, each element of stsd is a timed text sample entry (type "tx3g").
o サンプルの説明とサンプル説明の長さ：サンプル説明ボックス（STSD、STBL内）には、サンプルの説明が含まれています。タイムされたテキストメディアの場合、STSDの各要素は、タイムされたテキストサンプルエントリ（「TX3G」と入力）です。
The (unsigned) 32 bits of the "size" field in the stsd box represent the length (in bytes) of the sample description, as carried in TYPE 5 units. On the other hand, the LEN field of TYPE 5 units is restricted to 16 bits. Therefore, if the value of "size" is greater than (2^16-1-3)[bytes], then the sample description SHALL NOT be streamed with this payload format. There is no extension mechanism defined in this case, since fragmentation of sample descriptions is not defined (sample descriptions are typically up to some 200 bytes in size). Note: The three (3) accounts for the TYPE 5 header fields included in the LEN value.
STSDボックスの（符号なし）32ビットの「サイズ」フィールドは、タイプ5ユニットで運ばれるサンプル説明の長さ（バイト）を表します。一方、タイプ5ユニットのレンフィールドは16ビットに制限されています。したがって、「サイズ」の値が（2^16-1-3）[バイト]を超える場合、サンプルの説明はこのペイロード形式でストリーミングされません。サンプルの説明の断片化は定義されていないため、この場合は拡張メカニズムはありません（サンプルの説明は通常、最大約200バイトのサイズです）。注：3つのレン値に含まれるタイプ5ヘッダーフィールドを3つ説明します。
o SDUR from the Decoding Time to Sample Box (stts). The (unsigned) 32 bits of the "sample delta" field are used for calculating SDUR. However, since the SDUR field is only 3 bytes long, text samples with duration values larger than (2^24-1)/(timestamp clockrate)[seconds] cannot be streamed directly. The solution is simple: Copies of the corresponding text sample SHALL be sent. Thereby, the timestamp and duration values SHALL be adjusted so that a continuous display is guaranteed as if just one sample would have been sent. That is, a sample with timestamp TS and duration SDUR can be sent as two samples having timestamps TS1 and TS2 and durations SDUR1 and SDUR2, such that TS1=TS, TS2=TS1+SDUR1, and SDUR=SDUR1+SDUR2.
o デコード時間からサンプルボックス（STTS）からsdur。「サンプルデルタ」フィールドの（符号なし）32ビットは、SDURの計算に使用されます。ただし、SDURフィールドの長さはわずか3バイトであるため、（2^24-1）/（Timestamp ClockRate）[秒]よりも大きい持続時間値を持つテキストサンプルは直接ストリーミングできません。解決策は簡単です。対応するテキストサンプルのコピーを送信するものとします。これにより、タイムスタンプと持続時間の値を調整して、1つのサンプルだけが送信されるかのように連続ディスプレイが保証されます。つまり、タイムスタンプTSと期間SDURを備えたサンプルは、TS1 = TS、TS2 = TS1 SDUR1、およびSDUR = SDUR1 SDUR2を含むタイムスタンプTS1およびTS2および期間SDUR1およびSDUR2を備えた2つのサンプルとして送信できます。
o Text sample length from the Sample Size Box (stsz). The (unsigned) 32 bits of the "sample size" or "entry size" (one of them, depending on whether the sample size is fixed or variable) indicate the length (in bytes) of the 3GP text sample. For obtaining the length of the (actual) streamed text sample, the lengths of the text string byte count (2 bytes) and, in case of UTF-16 strings, the length the BOM (also 2 bytes) SHALL be deducted. This is illustrated in Figure 9.
o サンプルサイズボックス（STSZ）からのテキストサンプル長。「サンプルサイズ」または「エントリサイズ」の32ビット（サンプルサイズが固定されているか変数かによって異なります）の32ビットは、3GPテキストサンプルの長さ（バイト）を示しています。（実際の）ストリーミングされたテキストサンプルの長さを取得するには、テキスト文字列バイトカウント（2バイト）の長さとUTF-16文字列の場合、BOM（2バイト）の長さが差し引かれます。これを図9に示します。
Text Sample according to 3GPP TS 26.245
3GPP TS 26.245に従ってテキストサンプル
TEXT SAMPLE (length=stsz)
.--------------------------------------------------.
/ \
TEXT STRING (length=TBC)
.------------------------------------.
/ \
TBC BOM MODIFIERS
+---+---+----------------------------------+-----------+
||
|| TBC BOM -> TLEN field
|| +---+---+ U bit
||
\/
Text Sample according to this Payload Format
このペイロード形式に従ってテキストサンプル
TEXT SAMPLE (length=SLEN w/o TBC,BOM)
.--------------------------------------------.
/ \
TEXT STRING (length=TLEN)
.--------------------------------.
/ \
TEXT STRING MODIFIERS
+----------------------------------+-----------+
KEY: TBC = Text string Byte Count BOM = Byte Order Mark
キー：TBC =テキスト文字列バイトカウントbom = byte order mark
Figure 9. Text sample composition
図9.テキストサンプル構成
Moreover, since the LEN field in TYPE 1 unit header is 16 bits long, larger text sample sizes than (2^16-1-8) [bytes] SHALL NOT be streamed. Also, in this case, no extension mechanism is defined. This is because this maximum is considered enough for the targeted streaming applications. (Note: The eight (8) accounts for the TYPE 1 header fields included in the LEN value).
さらに、タイプ1ユニットヘッダーのレンフィールドは長さ16ビットであるため、（2^16-1-8）[バイト]よりも大きなテキストサンプルサイズはストリーミングされません。また、この場合、拡張メカニズムは定義されていません。これは、この最大値がターゲットを絞ったストリーミングアプリケーションで十分と見なされるためです。（注：8つの（8）は、LEN値に含まれるタイプ1ヘッダーフィールドを説明しています）。
o SIDX from the Sample to Chunk Box (stsc): The stsc Box is used to find samples and their corresponding sample descriptions. These are referenced by the "sample description index", a 32-bit (unsigned) integer. If possible, these indices may be directly mapped to the SIDX field. However, there are several cases where this may not be possible:
o サンプルからチャンクボックス（STSC）からSIDX：STSCボックスは、サンプルとそれらの対応するサンプルの説明を見つけるために使用されます。これらは、32ビット（符号なし）整数である「サンプル説明インデックス」によって参照されます。可能であれば、これらのインデックスはSIDXフィールドに直接マッピングされる場合があります。ただし、これが不可能な場合があります。
a) The total number of indices used is greater than the number of indices available, i.e., if the static sample descriptions are more than 127 or the dynamic ones are more than 64.
a）使用されるインデックスの総数は、利用可能なインデックスの数よりも大きくなります。つまり、静的サンプルの説明が127を超える場合、または動的な記述が64を超える場合。
b) The original SIDX value ranges do not fit in the allowed ranges for static (129-254) or dynamic (0-127) values.
b）元のSIDX値の範囲は、静的（129-254）または動的（0-127）値の許容範囲に適合しません。
Therefore, when assigning SIDX values to the sample descriptions, the following guidelines are provided:
したがって、SIDX値をサンプルの説明に割り当てるとき、次のガイドラインが提供されます。
o Static sample descriptions can simply be assigned consecutive values within the range 129-254 (closed interval). This range should be well enough for static sample descriptions.
o 静的サンプルの説明は、範囲129-254（閉じされた間隔）内に連続した値を単純に割り当てることができます。この範囲は、静的なサンプルの説明には十分です。
o As for dynamic sample descriptions:
o 動的なサンプルの説明については：
a) Streams that use less than 64 dynamic sample descriptions SHOULD use consecutive values for SIDX anywhere in the range 0-127 (closed interval).
a）64未満の動的なサンプルの説明を使用するストリームは、0〜127の範囲（閉じされた間隔）のどこでもSIDXの連続した値を使用する必要があります。
b) For streams with more than 64 sample descriptions, the SIDX values MUST be assigned in usage order, and if any sample description shall be used after it has been set inactive, it will need to be re-sent and assigned a new SIDX value (according to the algorithm in Section 4.2.1).
b）64を超えるサンプルの説明があるストリームの場合、SIDX値は使用順序で割り当てられ、サンプルの説明を非アクティブに設定した後に使用する必要があります。（セクション4.2.1のアルゴリズムによると）。
Information obtained from the Media Data Box:
メディアデータボックスから取得した情報：
o Text strings, TLEN, U bit, and modifiers from the Media Data Box (mdat). Text strings, 16-bit text string byte count, Byte Order Mark (BOM, indicating UTF encoding), and modifier boxes can be found here.
o メディアデータボックス（MDAT）からのテキスト文字列、tlen、uビット、および修飾子。テキスト文字列、16ビットのテキスト文字列バイトカウント、バイトオーダーマーク（BOM、UTFエンコードを示す）、および修飾子ボックスはここにあります。
For TYPE 1 units, the value of TLEN is extracted from the text string byte count that precedes the text string in the text sample, as stored in the 3GP file. If UTF-16 encoding is used, two (2) more bytes have to be deducted from this byte count beforehand, in order to exclude the BOM. See Figure 9.
タイプ1単位の場合、3GPファイルに保存されているように、TLENの値は、テキストサンプルのテキスト文字列の前にあるテキスト文字列バイトカウントから抽出されます。UTF-16エンコーディングを使用する場合、BOMを除外するには、事前にこのバイトカウントから2つのさらに多くのバイトを差し引く必要があります。図9を参照してください。
This section explains why text samples may have to be fragmented and discusses some of the possible approaches to doing it. A solution is proposed together with rules and recommendations for fragmenting and transporting text samples.
このセクションでは、テキストサンプルを断片化する必要がある理由について説明し、それを行うための可能なアプローチのいくつかについて説明します。ソリューションは、テキストサンプルの断片化と輸送に関するルールと推奨事項とともに提案されています。
3GPP Timed Text applications are expected to operate at low bitrates. This fact, added to the small size of timed text samples (typically one or two hundred bytes) makes fragmentation of text samples a rare event. Samples should usually fit into the MTU size of the used network path.
3GPPタイミングテキストアプリケーションは、低ビットレートで動作することが期待されています。この事実は、タイムサイズのテキストサンプル（通常は100バイトまたは200バイト）のサイズに加えて、テキストサンプルの断片化によりまれなイベントになります。サンプルは通常、使用済みのネットワークパスのMTUサイズに適合する必要があります。
Nevertheless, some text strings (e.g., ending roll in a movie) and some modifier boxes (i.e., for hyperlinks, for karaoke, or for styles) may become large. This may also apply for future modifier boxes. In such cases, the first option to consider is whether it is possible to adjust the encoding (e.g., the size of sample) in such a way that fragmentation is avoided. If it is, this is preferred to fragmentation and SHOULD be done.
それにもかかわらず、いくつかのテキスト文字列（例：映画での終わりのロール）といくつかの修飾子ボックス（つまり、ハイパーリンク、カラオケ、またはスタイル用）が大きくなる可能性があります。これは、将来の修飾子ボックスにも適用される場合があります。そのような場合、最初に考慮すべきオプションは、断片化が回避されるようにエンコード（サンプルのサイズなど）を調整できるかどうかです。もしそうなら、これは断片化よりも好まれ、行う必要があります。
Otherwise, if this is not possible or other constraints prevent it, fragmentation MAY be used, and the basic guidelines given in this document MUST be followed:
それ以外の場合、これが不可能または他の制約がそれを妨げている場合、断片化が使用される可能性があり、このドキュメントに記載されている基本的なガイドラインに従う必要があります。
o It is RECOMMENDED that text samples be fragmented as seldom as possible, i.e., the least possible number of fragments is created out of a text sample.
o テキストサンプルをできるだけめったに断片化することはお勧めしません。つまり、テキストサンプルから生成されるフラグメントの最小数が作成されることをお勧めします。
o If there is some bitrate and free space in the payload available, sample descriptions (if at hand) SHOULD be aggregated.
o 利用可能なペイロードにビットレートと自由スペースがある場合、サンプルの説明（手元にある場合）を集計する必要があります。
o Text strings MUST split at character boundaries; see TYPE 2 header. Otherwise, it is not possible to display the text contents of a fragment if a previous fragment was lost. As a consequence, text string fragmentation requires knowledge of the UTF-8/UTF-16 encoding formats to determine character boundaries.
o テキスト文字列は、文字境界で分割する必要があります。タイプ2ヘッダーを参照してください。それ以外の場合、以前のフラグメントが失われた場合、フラグメントのテキストの内容を表示することはできません。結果として、テキスト文字列の断片化には、文字境界を決定するためにUTF-8/UTF-16エンコード形式の知識が必要です。
o Unlike text strings, the modifier boxes are NOT REQUIRED to be split at meaningful boundaries. However, it is RECOMMENDED that this be done whenever possible. This decreases the effects of packet loss. This payload format does not ensure that partially received modifiers are applied to text strings. If only part of the modifiers is received, it is an application issue how to deal with these, i.e., whether or not to use them.
o テキスト文字列とは異なり、修飾子ボックスは意味のある境界で分割する必要はありません。ただし、可能な限りこれを行うことをお勧めします。これにより、パケット損失の影響が減少します。このペイロード形式では、部分的に受信した修飾子がテキスト文字列に適用されることを保証しません。修飾子の一部のみが受信された場合、これらに対処する方法、つまりそれらを使用するかどうかにかかわらず、アプリケーションの問題です。
Informative note: Ensuring that partially received modifiers can be applied to text strings in all cases (for all modifier types and for all fragment loss constellations) would place additional requirements on the payload format. In particular, this would require that: a) senders understand the semantics of the modifier boxes and b) specific fragment headers for each of the modifier boxes are defined, in addition to the payload formats defined below. Understanding the modifiers semantics means knowing, e.g., where each modifier starts and ends, which text fragments are affected, which modifiers may or may not be split, or what the fields indicate. This is necessary to be able to split the modifiers in such a way that each fragment can be applied independently of previous packet losses. This would require a more intelligent fragmentation entity and more complex headers. Given the low probability of fragmentation and the desire to keep the requirements low, it does not seem reasonable to specify such modifier box specific headers.
有益な注意：部分的に受信した修飾子をすべての場合（すべての修飾子タイプとすべてのフラグメント損失星座に対して）テキスト文字列に適用できるようにすると、ペイロード形式に追加の要件があります。特に、これには次のことが必要です。a）送信者は、モディファイアボックスのセマンティクスを理解し、b）以下に定義するペイロード形式に加えて、各モディファイアボックスの特定のフラグメントヘッダーが定義されています。修飾子のセマンティクスを理解すると、たとえば、各修飾子が起動して終了する場所、テキストフラグメントが影響を受けるか、どの修飾子が分割されるか、または分割されない場合があるか、またはフィールドが示すことを知ることを意味します。これは、各フラグメントを以前のパケット損失とは無関係に適用できるように修飾子を分割できるようにするために必要です。これには、よりインテリジェントな断片化エンティティとより複雑なヘッダーが必要です。断片化の可能性が低く、要件を低く抑えたいという欲求を考えると、そのような修飾子ボックス固有のヘッダーを指定することは合理的ではないと思われます。
o Modifier and text string fragments SHOULD be protected against packet losses, i.e., using FEC [7], retransmission [11], repetition (Section 5), or an equivalent technique. This minimizes the effects of packet loss.
o 修飾子およびテキスト文字列フラグメントは、Packetの損失、つまりFEC [7]、再送信[11]、繰り返し（セクション5）、または同等の手法を使用して保護する必要があります。これにより、パケット損失の影響が最小限に抑えられます。
o An additional requirement when fragmenting text samples is that the start of the modifiers MUST be indicated using the payload header defined for that purpose, i.e., a TYPE 3 unit MUST be used (see Section 4.1.4). This enables a receiver to detect the start of the modifiers as long as there are not two or more consecutive packet losses.
o テキストサンプルの断片化の場合の追加要件は、その目的のために定義されたペイロードヘッダーを使用して修飾子の開始を示す必要があること、つまりタイプ3ユニットを使用する必要があることです（セクション4.1.4を参照）。これにより、レシーバーは、2つ以上の連続したパケット損失がない限り、修飾子の開始を検出できます。
o Finally, sample descriptions SHALL NOT be fragmented because they contain important information that may affect several text samples.
o 最後に、サンプルの説明は、いくつかのテキストサンプルに影響を与える可能性のある重要な情報が含まれているため、断片化されてはなりません。
The payload headers defined in this document allow reassembling fragmented text samples. For this purpose, the standard RTP timestamp, the duration field (SDUR), and the fields TOTAL/THIS in the payload headers are used.
このドキュメントで定義されているペイロードヘッダーにより、断片化されたテキストサンプルを再組み立てることができます。この目的のために、標準のRTPタイムスタンプ、持続時間フィールド（SDUR）、およびペイロードヘッダーのフィールド合計/これが使用されます。
Units that belong to the same text sample MUST have the same timestamp. TYPE 5 units do not comply with this rule since they are not part of any particular text sample.
同じテキストサンプルに属するユニットには、同じタイムスタンプが必要です。タイプ5ユニットは、特定のテキストサンプルの一部ではないため、このルールに準拠していません。
The process for collecting the different fragments (units) of a text sample is as follows:
テキストサンプルのさまざまなフラグメント（単位）を収集するプロセスは次のとおりです。
1. Search for units having the same timestamp value, i.e., units that belong to the same text sample or sample descriptions that shall become available at that time instant. If several units of the same sample are repeated, only one of them SHALL be used. Repeated units are those that have the same timestamp and the same values for TOTAL/THIS.
1. 同じタイムスタンプ値を持つユニット、つまり、同じテキストサンプルまたはその時点で利用可能になるサンプルの説明に属するユニットを検索します。同じサンプルのいくつかの単位が繰り返される場合、そのうちの1つだけが使用されます。繰り返されるユニットとは、同じタイムスタンプと合計/これについて同じ値を持っているユニットです。
Note that, as mentioned in Section 4.1.1, the receiver SHALL ignore units with unrecognized TYPE value. However, the RTP header fields and the rest of the units (if any) in the payload are still useful.
セクション4.1.1で述べたように、受信者は認識されていないタイプ値のユニットを無視するものとすることに注意してください。ただし、RTPヘッダーフィールドとペイロード内の残りのユニット（もしあれば）は依然として有用です。
2. Check within this set whether any of the units from the text sample is missing. This is done using the TOTAL and THIS fields; the TOTAL field indicates how many fragments were created out of the text sample, and the THIS field indicates the position of this fragment in the text sample. As result of this operation, two outcomes are possible:
2. このセット内で、テキストサンプルのユニットが欠落しているかどうかを確認してください。これは、合計とこのフィールドを使用して行われます。合計フィールドは、テキストサンプルから作成されたフラグメントの数を示し、このフィールドはテキストサンプルのこのフラグメントの位置を示します。この操作の結果として、2つの結果が可能です。
a. No fragment is missing. Then, the THIS field SHALL be used to order the fragments and reassemble the text sample before forwarding it to the decoding application. Special care SHALL be taken when reassembling the text string as indicated in bullet 4 below.
a. フラグメントはありません。次に、このフィールドを使用して、デコードアプリケーションに転送する前に、フラグメントを注文し、テキストサンプルを再組み立てします。以下の弾丸4に示されているように、テキスト文字列を再組み立てする場合、特別な注意が必要です。
b. One or more fragments are missing: Check whether this fragment belongs to the text string or to the modifiers. TYPE 2 units identify text string fragments, and TYPE 3 and 4 identify modifier fragments:
b. 1つ以上のフラグメントがありません。このフラグメントがテキスト文字列または修飾子に属しているかどうかを確認します。タイプ2ユニットはテキスト文字列フラグメントを識別し、タイプ3と4は修飾子フラグメントを識別します。
i. If the fragment or fragments missing belong to the text string and the modifiers were received complete, then the received text characters may, at least, be displayed as plain text. Some modifiers may only be applied as long as it is possible to identify the character numbers, e.g., if only the last text string fragment is lost. This is the case for modifiers defining specific font styles ('styl'), highlighted characters ('hlit'), karaoke feature ('krok'), and blinking characters ('blnk'). Other modifiers such as 'dlay' or 'tbox' can be applied without the knowledge of the character number. It is an application issue to decide whether or not to apply the modifiers.
i. 欠落しているフラグメントまたはフラグメントがテキスト文字列に属し、修飾子が完全に受信された場合、受信したテキスト文字は少なくともプレーンテキストとして表示される場合があります。一部の修飾子は、文字番号を識別できる限り、たとえば最後のテキスト文字列フラグメントのみが失われた場合にのみ適用される場合があります。これは、特定のフォントスタイル（ 'Styl'）、強調表示された文字（「hlit '）、カラオケ機能（「krok」）、および点滅文字（「blnk」）を定義する修飾子の場合です。「dlay」や「tbox」などの他の修飾子は、文字番号の知識なしに適用できます。修飾子を適用するかどうかを決定することは、アプリケーションの問題です。
ii. If the fragment missing belongs to the modifiers and the text strings were received complete, then the incomplete modifiers may be used. The text string SHOULD at least be displayed as plain text. As mentioned in Section 4.4, modifiers may split without observing meaningful boundaries. Hence, it may not always be possible to make use of partially received modifiers. However, to avoid this, it is RECOMMENDED that the modifiers do split at meaningful boundaries.
ii。欠落しているフラグメントが修飾子に属し、テキスト文字列が完全に受信された場合、不完全な修飾子を使用できます。テキスト文字列は、少なくともプレーンテキストとして表示する必要があります。セクション4.4で述べたように、修飾子は意味のある境界を観察せずに分割する場合があります。したがって、部分的に受信した修飾子を使用することは常に可能ではありません。ただし、これを避けるために、修飾子が意味のある境界で分割することをお勧めします。
iii. A third possibility is that it is not possible to discern whether modifiers or text strings were received complete. For example, if the TYPE 3 unit of a sample plus the following or preceding packet is lost, there is no way for the RTP receiver to know if one or both packets lost belong to the modifiers or if there are also some missing text strings. Repetition, FEC, retransmission, or other protection mechanisms as per section 4.6 are RECOMMENDED to avoid this situation.
iii。3番目の可能性は、修飾子またはテキスト文字列が完了したかどうかを識別することができないことです。たとえば、サンプルのタイプ3ユニットと以前のパケットまたは前のパケットが失われた場合、RTPレシーバーが片方または両方のパケットが修飾子に属しているか、テキスト文字列が欠落しているかどうかを知る方法はありません。この状況を避けるために、セクション4.6に従って、繰り返し、FEC、再送信、またはその他の保護メカニズムが推奨されます。
iv. Finally, if it is sure that neither text strings nor modifiers were received complete, then the text strings and the modifiers may be rendered partially or may be discarded. This is an application choice.
IV。最後に、テキスト文字列も修飾子も完全に受信されないと確信している場合、テキスト文字列と修飾子が部分的にレンダリングされるか、廃棄される可能性があります。これはアプリケーションの選択です。
3. Sample descriptions can be directly associated with the reassembled text samples, via the sample description index (SIDX).
3. サンプルの説明は、サンプル説明インデックス（SIDX）を介して、再組み立てされたテキストサンプルに直接関連付けることができます。
4. Reassembling of text strings: Since the text strings transported in RTP packets MUST NOT include any byte order mark (BOM), the receiver MUST prepend it to the reassembled UTF-16 string before handling it to the timed text decoder (see Figure 9). The value of the BOM is 0xFEFF because only big endian serialization of UTF-16 strings is supported by this payload format.
4. テキスト文字列の再組み立て：RTPパケットで輸送されたテキスト文字列には、バイトオーダーマーク（BOM）が含まれてはならないため、受信者はタイミングされたテキストデコーダーに処理する前に再組み立てされたUTF-16文字列にプレイする必要があります（図9を参照）。UTF-16文字列の大きなエンディアンシリアル化のみがこのペイロード形式によってサポートされているため、BOMの値は0xFeffです。
Units SHOULD be aggregated to avoid overhead, whenever possible. The aggregate payloads MUST comply with one of the following ordered configurations:
可能であれば、頭上を避けるためにユニットを集約する必要があります。集計ペイロードは、次の順序付けられた構成のいずれかに準拠する必要があります。
1. Zero or more sample descriptions (TYPE 5) followed by zero or more whole text samples (TYPE 1 units). At least one unit of either type MUST be present.
1. ゼロ以上のサンプル記述（タイプ5）に続いて、テキストサンプルゼロ（タイプ1単位）以上が続きます。いずれかのタイプの少なくとも1つの単位が存在する必要があります。
2. Zero or more sample descriptions followed by zero or one modifier fragment, either TYPE 3 or TYPE 4. At least one unit MUST be present.
2. ゼロ以上のサンプルの説明に続いて、タイプ3またはタイプ4のゼロまたは1つの修飾子フラグメントが続きます。少なくとも1つのユニットが存在する必要があります。
3. Zero or more sample descriptions, followed by zero or one text string fragment (TYPE 2), followed by zero or one TYPE 3 unit. If a TYPE 2 unit and a TYPE 3 unit are present, then they MUST belong to the same text sample. At least one unit MUST be present.
3. ゼロ以上のサンプルの説明、その後にゼロまたは1つのテキスト文字列フラグメント（タイプ2）が続き、その後にゼロまたはタイプ3ユニットが続きます。タイプ2ユニットとタイプ3ユニットが存在する場合、それらは同じテキストサンプルに属している必要があります。少なくとも1つのユニットが存在する必要があります。
Some observations:
いくつかの観察：
o Different aggregates than the ones listed above SHALL NOT be used.
o 上記の骨材とは異なる骨材を使用してはなりません。
o Sample descriptions MUST be placed in the aggregate payload before the occurrence of any non-TYPE 5 units.
o サンプルの説明は、非タイプ5ユニットの発生前に、総ペイロードに配置する必要があります。
o Correct reception of TYPE 5 units is important since their contents may be referenced by several other units in the stream.
o タイプ5ユニットの正しい受信は、その内容がストリーム内の他のいくつかのユニットによって参照される可能性があるため重要です。
Receivers are unable to use text samples until their corresponding sample descriptions are received. Accordingly, a sender SHOULD send multiple copies of a sample description to ensure reliability (see Section 5). Receivers MAY use payload-specific feedback messages [21] to tell a sender that they have received a particular sample description.
対応するサンプルの説明が受信されるまで、受信機はテキストサンプルを使用できません。したがって、送信者は、信頼性を確保するために、サンプル説明の複数のコピーを送信する必要があります（セクション5を参照）。受信者は、ペイロード固有のフィードバックメッセージ[21]を使用して、特定のサンプルの説明を受け取ったことを送信者に伝えることができます。
o Regarding timestamp calculation: In general, the rules for calculating the timestamp of units in an aggregate payload depend on the type of unit. Based on the possible constellations for aggregate payloads, as above, we have:
o タイムスタンプの計算について：一般に、総ペイロードでのユニットのタイムスタンプを計算するためのルールは、ユニットのタイプによって異なります。上記のように、総ペイロードの可能な星座に基づいて、私たちは次のとおりです。
o Sample descriptions MUST receive the RTP timestamp of the packet in which they are included.
o サンプルの説明には、含まれているパケットのRTPタイムスタンプを受信する必要があります。
Note that for TYPE 5 units, the timestamp actually does not represent the instant when they are played out, but instead the instant at which they become available for use.
タイプ5ユニットの場合、タイムスタンプは実際にプレイされるときのインスタントを表すのではなく、使用できるインスタントを表すことに注意してください。
o For the first configuration: The first TYPE 1 unit receives the RTP timestamp. The timestamp of any subsequent TYPE 1 unit MUST be obtained by adding sample duration and timestamp, both of the preceding TYPE 1 unit.
o 最初の構成の場合：最初のタイプ1ユニットはRTPタイムスタンプを受け取ります。後続のタイプ1ユニットのタイムスタンプは、前述のタイプ1ユニットの両方のサンプル期間とタイムスタンプを追加して取得する必要があります。
o For the second and third configuration, all units, TYPE 2, 3, and 4, MUST receive the RTP timestamp.
o 2番目と3番目の構成の場合、すべてのユニット、タイプ2、3、および4は、RTPタイムスタンプを受信する必要があります。
Refer to detailed examples on the timestamp calculation below.
以下のタイムスタンプの計算の詳細な例を参照してください。
o As per configuration 3 above, a payload MAY contain several fragments of one (and only one) text sample. If it does, then exactly one TYPE 2 unit followed by exactly one TYPE 3 unit is allowed in the same payload. This is in line with RFC 3640 [12], Section 2.4, which explicitly disallows combining fragments of different samples in the same RTP payload. Note that, in this special case, no timestamp calculation is needed. That is, the RTP timestamp of both units is equal to the timestamp in the packet's RTP header.
o 上記の構成3に従って、ペイロードには、1つの（および1つの）テキストサンプルのいくつかのフラグメントが含まれる場合があります。もしそうなら、正確に1つのタイプ2ユニットに続いて、同じペイロードで1つのタイプ3ユニットが許可されます。これは、RFC 3640 [12]、セクション2.4に沿っています。これは、同じRTPペイロード内の異なるサンプルのフラグメントを組み合わせて明示的に許可します。この特別な場合、タイムスタンプの計算は必要ありません。つまり、両方のユニットのRTPタイムスタンプは、パケットのRTPヘッダーのタイムスタンプに等しくなります。
o Finally, note that the use of empty text samples allows for aggregating non-consecutive TYPE 1 units in the same payload. Two text samples, with timestamps TS1 and TS3 and durations SDUR1 and SDUR3, are not consecutive if it holds TS1+SDUR1 < TS3. A solution for this is to include an empty TYPE 1 unit with duration SDUR2 between them, such that TS2+SDUR2 = TS1+SDUR1+SDUR2 = TS3.
o 最後に、空のテキストサンプルを使用すると、同じペイロードで非継続的なタイプ1ユニットを集約できることに注意してください。タイムスタンプTS1およびTS3および期間SDUR1およびSDUR3を備えた2つのテキストサンプルは、TS1 SDUR1 <TS3を保持している場合、連続していません。これの解決策は、TS2 SDUR2 = TS1 SDUR1 SDUR2 = TS3になるように、それらの間に持続時間SDUR2を持つ空のタイプ1ユニットを含めることです。
Some examples of aggregate payloads are illustrated in Figure 10. (Note: The figure is not scaled.)
集約ペイロードの例を図10に示します。（注：図は拡張されていません。）
N/A TS1 TS2 TS3
+------+-----+------+-----+
|TYPE5 |TYPE1|TYPE1 |TYPE1|
+------+-----+------+-----+
N/A sdur1 sdur2 sdur3
N/A TS4
+-----+-------+
|TYPE5| TYPE 1| a)
+-----+-------+
N/A sdur4
TS4 TS4 TS4
+--------------+ +--------------+
| TYPE2 | |TYPE2 |TYPE 3 | b)
+--------------+ +--------------+
sdur4 sdur4 sdur4
TS4 TS4
+--------------+ +--------------+
| TYPE2| TYPE 3| | TYPE4 | c)
+--------------+ +--------------+
sdur4 sdur4 sdur4
|----------PAYLOAD 1------| |--PAYLOAD 2---| |--PAYLOAD 3---|
rtpts1 rtpts2 rtpts3
KEY: TSx = Text Sample x rtptsy = the standard RTP timestamp for PAYLOAD y sdurx = the duration of Text Sample x N/A = not applicable
キー：TSX =テキストサンプルX rtptsy =ペイロードy sdurxの標準RTPタイムスタンプ=テキストの持続時間x n/a =該当なし
Figure 10. Example aggregate payloads
図10.の例の集計ペイロード
In Figure 10, four text samples (TS1 through TS4) are sent using three RTP packets. These configurations have been chosen to show how the 5 TYPE headers are used. Additionally, three different possibilities for the last text sample, TS4, are depicted: a), b), and c).
図10では、3つのRTPパケットを使用して、4つのテキストサンプル（TS1からTS4）が送信されます。これらの構成は、5型ヘッダーの使用方法を示すために選択されています。さらに、最後のテキストサンプルTS4の3つの異なる可能性が描かれています：a）、b）、およびc）。
In Figure 11, option b) from Figure 10 is chosen to illustrate how the timestamp for each unit is found.
図11では、各ユニットのタイムスタンプがどのように見つかったかを示すために、図10のオプションb）を選択します。
N/A TS1 TS2 TS3 TS4 TS4 TS4
+------+-----+------+-----+ +--------------+ +--------------+
|TYPE5 |TYPE1|TYPE1 |TYPE1| | TYPE2 | |TYPE2 |TYPE 3 |
+------+-----+------+-----+ +--------------+ +--------------+
N/A sdur1 sdur2 sdur3 sdur4 sdur4 sdur4
(#1) (#2) (#3) (#4) (#5) (#6) (#7)
|----------PAYLOAD 1------| |--PAYLOAD 2---| |--PAYLOAD 3---|
rtpts1 rtpts2 rtpts3
Figure 11. Selected payloads from Figure 10
図11.図10から選択されたペイロード
Assuming TSx means Text Sample x, rtptsy represents the standard RTP timestamp for PAYLOAD y and sdurx, the duration of Text Sample x, the timestamp for unit #z, ts(#z), can be found as the sum of rtptsy and the cumulative sum of the durations of preceding units in that payload (except in the case of PAYLOAD 3 as per rule 3 above). Thus, we have:
TSXがテキストサンプルXを意味すると仮定すると、RTPTSYはペイロードYおよびSDURXの標準RTPタイムスタンプ、テキストサンプルXの持続時間、ユニット＃Z、TS（#Z）のタイムスタンプはRTPTSYの合計として、累積の合計として見つけることができます。そのペイロードにおける前のユニットの期間の合計（上記のルール3に従ってペイロード3の場合を除く）。したがって、私たちは：
1. for the units in the first aggregate payload, PAYLOAD 1:
1. 最初の集約ペイロードのユニットの場合、ペイロード1：
ts(#1) = rtpts1
ts(#2) = rtpts1
ts(#3) = rtpts1 + sdur1
ts(#4) = rtpts1 + sdur1 + sdur2
Note that the TYPE 5 and the first TYPE 1 unit have both the RTP timestamp.
タイプ5と最初のタイプ1ユニットには、RTPタイムスタンプの両方があることに注意してください。
2. for PAYLOAD 2:
2. ペイロード2：
ts(#5) = rtpts2
3. for PAYLOAD 3:
3. ペイロード3：
ts(#6) = ts(#7) = rtpsts2 = rtpts3
According to configuration 3 above, the TYPE2 and the TYPE 3 units shall belong to the same sample. Hence, rtpts3 must be equal to rtpts2. For the same reason, the value of SDUR is not be used to calculate the timestamp of the next unit.
上記の構成3によると、Type2およびType 3ユニットは同じサンプルに属するものとします。したがって、RTPTS3はRTPTS2に等しくなければなりません。同じ理由で、SDURの値は、次のユニットのタイムスタンプを計算するために使用されません。
Some examples of payloads using the defined headers are shown below:
定義されたヘッダーを使用したペイロードの例を以下に示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE1| LEN (always >=8) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | TLEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLEN | |
+---------------+ |
| text string (no.bytes=TLEN) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modifiers (no.bytes=LEN - 8 - TLEN) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE1| LEN (always >=8) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | TLEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLEN | |
+---------------+ |
| text string (no.bytes=TLEN) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| modifiers (no.bytes=LEN - 8 - TLEN) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12. A payload carrying two TYPE 1 units
図12. 2つのタイプ1ユニットを運ぶペイロード
In Figure 12, an RTP packet carrying two TYPE 1 units is depicted. It can be seen how the length fields LEN and TLEN can be used to find the start of the next unit (LEN), the start of the modifiers (TLEN), and the length of the modifiers (LEN-TLEN).
図12に、2つのタイプ1ユニットを搭載したRTPパケットが描かれています。長さのフィールドLENとTLENを使用して、次のユニット（LEN）の開始、修飾子（TLEN）、および修飾子の長さ（LEN-TLEN）を見つける方法を見ることができます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE5| LEN( always >3) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| sample description (no.bytes=LEN - 3) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE1| LEN (always >=8) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | TLEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLEN | |
+-+-+-+-+-+-+-+-+ |
| text string fragment (no.bytes=TLEN) |
| |
| |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13. An RTP packet carrying a TYPE 5 and a TYPE 1 unit
図13.タイプ5とタイプ1ユニットを運ぶRTPパケット
In Figure 13, a sample description and a TYPE 1 unit are aggregated. The TYPE 1 unit happens to contain only text strings and is small, so an additional TYPE 5 unit is included to take advantage of the available bits in the packet.
図13では、サンプルの説明とタイプ1ユニットが集約されています。タイプ1ユニットにはたまたまテキスト文字列のみが含まれており、小さいため、パケット内の利用可能なビットを利用するために追加のタイプ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE2| LEN( always >9) |TOTAL=4|THIS=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLEN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| text string fragment (no.bytes=LEN - 9) |
| |
: :
: :
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14. Payload with first text string fragment of a sample
図14.サンプルの最初のテキスト文字列フラグメントを使用したペイロード
In Figures 14, 15, and 16, a text sample is split into three RTP packets. In Figure 14, the text string is big and takes the whole packet length. In Figure 15, the only possibility for carrying two fragments of the same text sample is represented (see configuration 3 in Section 4.6). The last packet, shown in Figure 16, carries the last modifier fragment, a TYPE 4.
図14、15、および16では、テキストサンプルが3つのRTPパケットに分割されています。図14では、テキスト文字列は大きく、パケットの長さ全体を取得します。図15では、同じテキストサンプルの2つのフラグメントを運ぶ唯一の可能性が表されています（セクション4.6の構成3を参照）。図16に示す最後のパケットには、最後の修飾子フラグメント、タイプ4が含まれています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE2| LEN( always >9) |TOTAL=4|THIS=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLEN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| text string fragment (no.bytes=LEN - 9) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE3| LEN( always >6) |TOTAL=4|THIS=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| modifiers (no.bytes=LEN - 6) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15. An RTP packet carrying a TYPE 2 unit and a TYPE 3 unit
図15.タイプ2ユニットとタイプ3ユニットを運ぶ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE4| LEN( always >6) |TOTAL=4|THIS=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| modifiers (no.bytes=LEN - 6) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16. An RTP packet carrying last modifiers fragment (TYPE 4)
図16.最後の修飾子断片を運ぶRTPパケット（タイプ4）
RFC 3640 [12] defines a payload format for the transport of any non-multiplexed MPEG-4 elementary stream. One of the various MPEG-4 elementary stream types is MPEG-4 timed text streams, specified in MPEG-4 part 17 [26], also known as ISO/IEC 14496-17. MPEG-4 timed text streams are capable of carrying 3GPP timed text data, as specified in 3GPP TS 26.245 [1].
RFC 3640 [12]は、非倍率のMPEG-4基本ストリームの輸送のペイロード形式を定義します。さまざまなMPEG-4の基本ストリームタイプの1つは、MPEG-4パート17 [26]で指定されたMPEG-4タイミングテキストストリームです。ISO/IEC 14496-17としても知られています。MPEG-4タイム付きテキストストリームは、3GPP TS 26.245 [1]で指定されているように、3GPPタイミングテキストデータを運ぶことができます。
MPEG-4 timed text streams are intentionally constructed so as to guarantee interoperability between RFC 3640 and this payload format. This means that the construction of the RTP packets carrying timed text is the same. That is, the MPEG-4 timed text elementary stream as per ISO/IEC 14496-17 is identical to the (aggregate) payloads constructed using this payload format.
MPEG-4タイミングされたテキストストリームは、RFC 3640とこのペイロード形式間の相互運用性を保証するために意図的に構築されます。これは、時限テキストを運ぶRTPパケットの構築が同じであることを意味します。つまり、ISO/IEC 14496-17に従ってMPEG-4タイミングテキストの基本ストリームは、このペイロード形式を使用して構築された（集計）ペイロードと同一です。
Figure 17 illustrates the process of constructing an RTP packet containing timed text. As can be seen in the partition block, the (transport) units used in this payload format are identical to the Timed Text Units (TTUs) defined in ISO/IEC 14496-17. Likewise, the rules for payload aggregation as per Section 4.6 are identical to those defined in ISO/IEC 14496-17 and are compliant with RFC 3640. As a result, an RTP packet that uses this payload format is identical to an RTP packet using RFC 3640 conveying TTUs according to ISO/IEC 14496-17. In particular, MPEG-4 Part 17 specifies that when using RFC 3640 for transporting timed text streams, the "streamType" parameter value is set to 0x0D, and the value of the "objectTypeIndication" in "config" takes the value 0x08.
図17は、時限テキストを含むRTPパケットを構築するプロセスを示しています。パーティションブロックで見られるように、このペイロード形式で使用される（輸送）ユニットは、ISO/IEC 14496-17で定義されているタイミングされたテキストユニット（TTU）と同じです。同様に、セクション4.6に従ってペイロード集約のルールは、ISO/IEC 14496-17で定義されているルールと同一であり、RFC 3640に準拠しています。その結果、このペイロード形式を使用するRTPパケットは、RFCを使用したRTPパケットと同一です。3640 ISO/IEC 14496-17に従ってTTUを運ぶ。特に、MPEG-4パート17は、タイミングされたテキストストリームを輸送するためにRFC 3640を使用する場合、「StreamType」パラメーター値が0x0Dに設定され、「config」の「ObjectTypeindication」の値が値0x08を取ることを指定します。
+--------------------------------------+
Text samples | +--------------+ +--------------+ |
as per 3GPP | |Text Sample 1 | |Text Sample N | |
TS 26245 | +--------------+ +--------------+ |
+--------------------------------------+
\/
+-------------------------------------------------------------------+
| Partition Text Samples into units. TTU[i]= TYPE i units. |
| |
|[U R TYPE LEN][{TOTAL,THIS}SIDX{SDUR}{TLEN}{SLEN}][SampleContents] |
|{..} means present if applicable, [..] means always present |
+-------------------------------------------------------------------+
\/ \/
+-------------------------------------------------------------------+
| Aggregation (if possible) |
+-------------------------------------------------------------------+
\/ \/
+-------------------------------------------------------------------+
| RTP Entity adds and fills RTP header and Sends RTP packet, where |
| RTP packets according to this Payload Format = |
| RTP packets carrying MPEG-4 Timed Text ES over RFC 3640 |
+-------------------------------------------------------------------+
Figure 17. Relation to RFC 3640
図17. RFC 3640との関係
Note: The use of RFC 3640 for transport of ISO/IEC 14496-17 data does not require any new SDP parameters or any new mode definition.
注：ISO/IEC 14496-17データの輸送にRFC 3640を使用しても、新しいSDPパラメーターまたは新しいモード定義は必要ありません。
RFC 2793 [22] and its revision, RFC 4103 [23], specify a protocol for enabling text conversation. Typical applications of this payload format are text communication terminals and text conferencing tools. Text session contents are specified in ITU-T Recommendation T.140 [24]. T.140 text is UTF-8 coded as specified in T.140 [24] with no extra framing. The T140block contains one or more T.140 code elements as specified in T.140. Code elements are control sequences such as "New Line", "Interrupt", "String Terminator", or "Start of String". Most T.140 code elements are single ISO 10646 [25] characters, but some are multiple character sequences. Each character is UTF-8 encoded [18] into one or more octets.
RFC 2793 [22]およびその改訂版、RFC 4103 [23]は、テキスト会話を有効にするためのプロトコルを指定します。このペイロード形式の典型的なアプリケーションは、テキスト通信端末とテキスト会議ツールです。テキストセッションの内容は、ITU-Tの推奨T.140 [24]で指定されています。T.140テキストは、追加のフレーミングなしでT.140 [24]で指定されているようにUTF-8コード化されています。T140ブロックには、T.140で指定されている1つ以上のT.140コード要素が含まれています。コード要素は、「新しい線」、「割り込み」、「文字列ターミネーター」、「文字列の開始」などの制御シーケンスです。ほとんどのT.140コード要素は単一のISO 10646 [25]文字ですが、複数の文字シーケンスです。各文字は、UTF-8エンコード[18]に1つ以上のオクテットにエンコードされています。
This payload format may also be used for conversational applications (even for instant messaging). However, this is not its main target. The differentiating feature of 3GPP Timed Text media format is that it allows text decoration. This is especially useful in multimedia presentations, karaoke, commercial banners, news tickers, clickable text strings, and captions. T.140 text contents used in RFC 2793 do not allow the use of text decoration.
このペイロード形式は、会話アプリケーションにも使用できます（インスタントメッセージングでも）。ただし、これは主なターゲットではありません。3GPPタイミングテキストメディア形式の差別化機能は、テキストの装飾を許可することです。これは、マルチメディアプレゼンテーション、カラオケ、コマーシャルバナー、ニュースティッカー、クリック可能なテキスト文字列、キャプションで特に役立ちます。RFC 2793で使用されるT.140テキストコンテンツは、テキスト装飾の使用を許可しません。
Furthermore, the conversational text RTP payload format recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. Thereby payloads would include a redundant copy of the last payload sent. This payload format does not describe such a method, but this is also applicable here. As explained in Section 5, packet redundancy SHOULD be used, whenever possible. The aggregation guidelines in Section 4.6 allow redundant payloads.
さらに、会話型テキストRTPペイロード形式では、パケットの損失によって引き起こされるテキスト損失のリスクを減らすために、すでに送信されたパケットから冗長テキストを含める方法を推奨しています。これにより、ペイロードには、送信された最後のペイロードの冗長コピーが含まれます。このペイロード形式では、このような方法は説明されていませんが、これもここにも適用できます。セクション5で説明したように、可能な限りパケット冗長性を使用する必要があります。セクション4.6の集約ガイドラインにより、冗長なペイロードが可能になります。
Apart from the basic fragmentation guidelines described in the section above, the simplest option for packet-loss-resilient transport is packet repetition. This mechanism may consist of a strict window-based repetition mechanism or, simply, a repetition mechanism in a wider sense, where new and old packets are mixed, for example.
上記のセクションで説明した基本的な断片化ガイドラインとは別に、パケット損失装置輸送の最も簡単なオプションはパケットの繰り返しです。このメカニズムは、たとえば、新しい窓に基づいた繰り返しメカニズム、または単純に、より広い意味での繰り返しメカニズムで構成されている場合があります。
A server MAY decide to use repetition as a measure for packet loss resilience. Thereby, a server MAY send the same RTP payloads or just some of the units from the payloads.
サーバーは、パケット損失の回復力の尺度として繰り返しを使用することを決定する場合があります。これにより、サーバーは同じRTPペイロードまたはペイロードからユニットの一部を送信する場合があります。
As for the case of complete payloads, single repeated units MUST exactly match the same units sent in the first transmission; i.e., if fragmentation is needed, it SHALL be performed only once for each text sample. Only then, a receiver can use the already received and the repeated units to reconstruct the original text samples. Since the RTP timestamp is used to group together the fragments of a sample, care must taken to preserve the timing of units when constructing new RTP packets.
完全なペイロードの場合、単一の反復ユニットは、最初の送信で送信された同じユニットと正確に一致する必要があります。つまり、断片化が必要な場合は、各テキストサンプルに対して1回のみ実行されます。その場合にのみ、受信者は、既に受信したユニットと繰り返しユニットを使用して、元のテキストサンプルを再構築できます。RTPタイムスタンプはサンプルの断片をグループ化するために使用されるため、新しいRTPパケットを構築する際にユニットのタイミングを維持するために注意する必要があります。
For example, if a text sample was originally sent as a single non-fragmented text sample (one TYPE 1 unit), a repetition of that sample MUST be sent also as a single non-fragmented text sample in one unit. Likewise, if the original text sample was fragmented and spread over several RTP packets (say, a total of 3 units), then the repeated fragments SHALL also have the same byte boundaries and use the same unit headers and bytes per fragment.
たとえば、テキストサンプルが元々単一の非散乱テキストサンプル（1つのタイプ1ユニット）として送信された場合、そのサンプルの繰り返しは、1つの単位で単一の非フラグメントテキストサンプルとしても送信する必要があります。同様に、元のテキストサンプルが断片化され、いくつかのRTPパケット（たとえば、合計3ユニット）に広がっている場合、繰り返されるフラグメントには同じバイト境界もあり、フラグメントあたり同じユニットヘッダーとバイトを使用します。
With repetition, repeated units resolve to the same timestamp as their originals. Where redundant units are available, only one of them SHALL be used.
繰り返しにより、繰り返されるユニットはオリジナルと同じタイムスタンプに解決します。冗長ユニットが利用可能な場合、そのうちの1つだけが使用されます。
Regarding the RTP header fields:
RTPヘッダーフィールドについて：
o If the whole RTP payload is repeated, all payload-specific fields in the RTP header (the M, TS and PT fields) MUST keep their original values except the sequence number, which MUST be incremented to comply with RTP (the fields TOTAL/THIS enable to re-assemble fragments with different sequence numbers).
o RTPペイロード全体が繰り返される場合、RTPヘッダーのすべてのペイロード固有のフィールド（M、TS、およびPTフィールド）は、RTPに準拠するために増加する必要があるシーケンス番号を除いて元の値を維持する必要があります（これ異なるシーケンス番号でフラグメントを再組み立てできるようにします）。
o In packets containing single repeated units, the general rules in Section 3 for assigning values to the RTP header fields apply. Keeping the value of the RTP timestamp to preserve the timing of the units is particularly relevant here.
o 単一の反復ユニットを含むパケットでは、RTPヘッダーフィールドに値を割り当てるためのセクション3の一般的なルールが適用されます。ここでは、ユニットのタイミングを維持するためにRTPタイムスタンプの価値を維持することが特に関連しています。
Apart from repetition, other mechanisms such as FEC [7], retransmission [11], or similar techniques could be used to cope with packet losses.
繰り返しは別として、FEC [7]、再送信[11]、または同様の手法などの他のメカニズムを使用して、パケット損失に対処できます。
Congestion control for RTP SHALL be implemented in accordance with RTP [3] and the applicable RTP profile, e.g., RTP/AVP [17].
RTPの輻輳制御は、RTP [3]および該当するRTPプロファイル、例えばRTP/AVP [17]に従って実装されるものとします。
When using this payload format, mainly two factors may affect the congestion control:
このペイロード形式を使用する場合、主に2つの要因が混雑制御に影響する可能性があります。
o The use of (unit) aggregation may make the payload format more bandwidth efficient, by avoiding header overhead and thus reducing the used bitrate.
o （ユニット）集約を使用すると、ヘッダーのオーバーヘッドを避けて使用済みのビットレートを削減することにより、ペイロードフォーマットがより効率的になる場合があります。
o The use of resilient transport mechanisms: Although timed text applications typically operate at low bitrates, the increase due to resilient transport shall be considered for congestion control mechanisms. This applies to all mechanisms but especially to less efficient ones like repetition.
o 回復力のある輸送メカニズムの使用：通常、テキストアプリケーションが低いビットレートで動作しますが、回復力のある輸送による増加は、混雑制御メカニズムのために考慮されるものとします。これはすべてのメカニズムに適用されますが、特に繰り返しのような効率の低いメカニズムには当てはまります。
In order to set up a timed text session, regardless of the stream being stored in a 3GP file or streamed live, some initial layout information is needed by the communicating peers.
3GPファイルに保存されているストリームやライブでストリーミングされているストリームに関係なく、タイムされたテキストセッションを設定するには、通信ピアによっていくつかの初期レイアウト情報が必要です。
+-------------------------------------------+
| <-> tx | +-------------+
| +-------------------------------+ |<---|Display Area |
| ^ | | | +-------------+
| : | | |
| :ty| | | +-------------+
| : | |<---------|Video track |
| : | | | +-------------+
| : | | |
| : | | |
| : | | |
| v | | |
| - | x-------------------------+ | | +-------------+
|h ^ | | |<-----------|Text Track |
|e : +---|-------------------------|-+ | +-------------+
|i : | +---------------------+ | |
|g : | | | | | +-------------+
|h : | | |<------------ |Text Box |
|t v | +---------------------+ | | +-------------+
| - +-------------------------+ |
+-------------------------------------------+
<........................>
w i d t h
Figure 18. Illustration of text rendering position and composition
図18.テキストのレンダリング位置と構成の図
The parameters used for negotiating the position and size of the text track in the display area are shown in Figure 18. These are the "width" and "height" of the text track, its translation values, "tx" and "ty", and its "layer" or proximity to the user.
ディスプレイ領域のテキストトラックの位置とサイズの交渉に使用されるパラメーターを図18に示します。これらは、テキストトラックの「幅」と「高さ」、その翻訳値、「TX」と「TY」です。およびその「レイヤー」またはユーザーへの近接性。
At the same time, the sender of the stream needs to know the receiver's capabilities. In this case, the maximum allowable values for the text track height and width: "max-h" and "max-w", for the stream the receiver shall display.
同時に、ストリームの送信者は、受信者の機能を知る必要があります。この場合、テキストトラックの高さと幅の最大許容値「MAX-H」と「MAX-W」、レシーバーが表示するストリームの場合。
This layout information MUST be conveyed in a reliable form before the start of the session, e.g., during session announcement or in an Offer/Answer (O/A) exchange. An example of a reliable transport may be the out-of-band channel used for SDP. Sections 8 and 9 provide details on the mapping of these parameters to SDP descriptions and their usage in O/A.
このレイアウト情報は、セッションの開始前、たとえばセッションの発表中またはオファー/回答（O/A）交換で信頼できるフォームで伝えなければなりません。信頼できる輸送の例は、SDPに使用されるバンド外チャネルです。セクション8および9では、SDP説明へのこれらのパラメーターのマッピングとO/Aでの使用に関する詳細を示します。
For stored content, the layout values expressing stream properties MUST be obtained from the Track Header Box. See Section 7.3.
保存されたコンテンツの場合、ストリームプロパティを表現するレイアウト値をトラックヘッダーボックスから取得する必要があります。セクション7.3を参照してください。
For live streaming, appropriate values as negotiated during session setup shall be used.
ライブストリーミングの場合、セッションのセットアップ中にネゴシエートされた適切な値を使用するものとします。
The attributes contained in the Track Header Boxes of a 3GP file only specify the spatial relationship of the tracks within the given 3GP file.
3GPファイルのトラックヘッダーボックスに含まれる属性は、指定された3GPファイル内のトラックの空間関係のみを指定します。
If multiple 3GP files are sent, they require spatial synchronization. For example, for a text and video stream, the positions of the text and video tracks in Figure 18 shall be determined. For this purpose, SMIL [9] MAY be used.
複数の3GPファイルが送信される場合、空間同期が必要です。たとえば、テキストとビデオのストリームの場合、図18のテキストトラックとビデオトラックの位置を決定します。この目的のために、Smil [9]が使用される場合があります。
SMIL assigns regions in the display to each of those files and places the tracks within those regions. Generally, in SMIL, the position of one track (or stream) is expressed relative to another track. This is different from the 3GP file, where the upper left corner is the reference for all translation offsets. Hence, only if the position in SMIL is relative to the video track origin, then this translation offset has the same value as (tx, ty) in the 3GP file.
Smilはディスプレイ内の領域をそれらの各ファイルに割り当て、それらの地域内にトラックを配置します。一般的に、スミルでは、1つのトラック（またはストリーム）の位置が別のトラックに対して表現されます。これは、3GPファイルとは異なり、左上隅がすべての翻訳オフセットの参照です。したがって、Smilの位置がビデオトラックの起源に関連している場合にのみ、この翻訳オフセットは3GPファイルの（TX、TY）と同じ値を持っています。
Note also that the original track header information is used for each track only within its region, as assigned by SMIL. Therefore, even if SMIL scene description is used, the track header information pieces SHOULD be sent anyway, as they represent the intrinsic media properties. See 3GPP SMIL Language Profile in [27] for details.
また、元のトラックヘッダー情報は、Smilによって割り当てられているように、その領域内の各トラックにのみ使用されることに注意してください。したがって、スマイルシーンの説明が使用されていても、本質的なメディアプロパティを表すため、トラックヘッダー情報のピースをとにかく送信する必要があります。詳細については、[27]の3GPP Smil言語プロファイルを参照してください。
In a 3GP file, within the Track Header Box (tkhd):
トラックヘッダーボックス（TKHD）内の3GPファイルで：
o tx, ty: These values specify the translation offset of the (text) track relative to the upper left corner of the video track, if present. They are the second but last and third but last values in the unity matrix; values are fixed-point 16.16 values, restricted to be (signed) integers (i.e., the lower 16 bits of each value shall be all zeros). Therefore, only the first 16 bits are used for obtaining the value of the media type parameters.
o TX、TY：これらの値は、存在する場合、ビデオトラックの左上隅に比べて（テキスト）トラックの翻訳オフセットを指定します。それらは2番目ですが、最後と3番目ですが、Unityマトリックスの最後の値です。値は固定点16.16値であり、整数に制限されています（つまり、各値の16ビットがすべてゼロでなければなりません）。したがって、メディア型パラメーターの値を取得するために使用される最初の16ビットのみが使用されます。
o width, height: They have the same name in the tkhd box. All (unsigned) 32 bits are meaningful.
o 幅、高さ：TKHDボックスに同じ名前があります。すべて（符号なし）32ビットは意味があります。
o layer: All (signed) 16 bits are used.
o レイヤー：すべて（署名）16ビットが使用されます。
The media subtype for the 3GPP Timed Text codec is allocated from the standards tree. The top-level media type under which this payload format is registered is 'video'. This registration is done using the template defined in [29] and following RFC 3555 [28].
3GPPタイムされたテキストコーデックのメディアサブタイプは、標準ツリーから割り当てられます。このペイロード形式が登録されているトップレベルのメディアタイプは「ビデオ」です。この登録は、[29]で定義されたテンプレートを使用して、RFC 3555 [28]を使用して行われます。
The receiver MUST ignore any unrecognized parameter.
受信者は、認識されていないパラメーターを無視する必要があります。
Media type: video
メディアタイプ：ビデオ
Media subtype: 3gpp-tt
メディアサブタイプ：3GPP-TT
Required parameters
必要なパラメーター
rate: Refer to Section 3 in RFC 4396.
レート：RFC 4396のセクション3を参照してください。
sver: The parameter "sver" contains a list of supported backwards-compatible versions of the timed text format specification (3GPP TS 26.245) that the sender accepts to receive (and that are the same that it would be willing to send). The first value is the value preferred to receive (or preferred to send). The first value MAY be followed by a comma-separated list of versions that SHOULD be used as alternatives. The order is meaningful, being first the most preferred and last the least preferred. Each entry has the format Zi(xi*256+yi), where "Zi" is the number of the Release and "xi" and "yi" are taken from the 3GPP specification version (i.e., vZi.xi.yi). For example, for 3GPP TS 26.245 v6.0.0, Zi(xi*256+yi)=6(0), the version value is "60". (Note that "60" is the concatenation of the values Zi=6 and (xi*256+yi)=0 and not their product.)
SVER：パラメーター「SVER」には、送信者が受信することを受け入れるタイミングテキスト形式仕様（3GPP TS 26.245）のサポートされている後方互換バージョンのリストが含まれています（そして、それは喜んで送信することと同じです）。最初の値は、受信する（または送信するよりも推奨される）が好まれる値です。最初の値の後に、代替として使用する必要があるバージョンのコンマ区切りリストが続く場合があります。順序は意味があり、最初は最も好まれ、最後に最も好まれていません。各エントリにはZi（xi*256 yi）の形式があり、「zi」はリリースの数であり、「xi」と「yi」は3GPP仕様バージョン（つまり、vzi.xi.yi）から取得されます。たとえば、3GPP TS 26.245 V6.0.0、ZI（XI*256 YI）= 6（0）の場合、バージョン値は「60」です。（「60」はZi = 6および（Xi*256 Yi）= 0の値の連結であり、製品ではないことに注意してください。）
If no "sver" value is available, for example, when streaming out of a 3GP file, the default value "60", corresponding to the 3GPP Release 6 version of 3GPP TS 26.245, SHALL be used.
たとえば、3GPファイルからストリーミングするときに「SVER」値が利用できない場合、3GPPリリース6バージョンの3GPP TS 26.245に対応するデフォルト値「60」が使用されます。
Optional parameters:
オプションのパラメーター：
tx: This parameter indicates the horizontal translation offset in pixels of the text track with respect to the origin of the video track. This value is the decimal representation of a 16-bit signed integer. Refer to TS 3GPP 26.245 for an illustration of this parameter.
TX：このパラメーターは、ビデオトラックの起源に関して、テキストトラックのピクセルでの水平変換オフセットを示しています。この値は、16ビットの署名された整数の10進表現です。このパラメーターの図については、TS 3GPP 26.245を参照してください。
ty: This parameter indicates the vertical translation offset in pixels of the text track with respect to the origin of the video track. This value is the decimal representation of a 16-bit signed integer. Refer to TS 3GPP 26.245 for an illustration of this parameter.
TY：このパラメーターは、ビデオトラックの起源に関して、テキストトラックのピクセルの垂直変換オフセットを示しています。この値は、16ビットの署名された整数の10進表現です。このパラメーターの図については、TS 3GPP 26.245を参照してください。
layer: This parameter indicates the proximity of the text track to the viewer. More negative values mean closer to the viewer. This parameter has no units. This value is the decimal representation of a 16-bit signed integer.
レイヤー：このパラメーターは、テキストトラックが視聴者に近接していることを示しています。否定的な値が増えると、視聴者に近いことがわかります。このパラメーターにはユニットがありません。この値は、16ビットの署名された整数の10進表現です。
tx3g: This parameter MUST be used for conveying sample descriptions out-of-band. It contains a comma-separated list of base64-encoded entries. The entries of this list MAY follow any particular order and the list SHALL NOT be empty. Each entry is the result of running base64 encoding over the concatenation of the (static) SIDX value as an 8-bit unsigned integer and the (static) sample description for that SIDX, in that order. The format of a sample description entry can be found in 3GPP TS 26.245 Release 6 and later releases. All servers and clients MUST understand this parameter and MUST be capable of using the sample description(s) contained in it. Please refer to RFC 3548 [6] for details on the base64 encoding.
TX3G：このパラメーターは、サンプルの説明を帯域外で伝えるために使用する必要があります。Base64エンコードされたエントリのコンマ区切りリストが含まれています。このリストのエントリは特定の順序に従うことができ、リストが空になることはありません。各エントリは、（静的）SIDX値の8ビットの符号なし整数とそのsidxの（静的）サンプル記述としての連結をbase64エンコードした結果です。サンプル説明エントリの形式は、3GPP TS 26.245リリース6以降のリリースにあります。すべてのサーバーとクライアントは、このパラメーターを理解する必要があり、含まれるサンプルの説明を使用できる必要があります。Base64エンコーディングの詳細については、RFC 3548 [6]を参照してください。
width: This parameter indicates the width in pixels of the text track or area of the text being sent. This value is the decimal representation of a 32-bit unsigned integer. Refer to TS 3GPP 26.245 for an illustration of this parameter.
幅：このパラメーターは、送信されるテキストのテキストトラックまたは領域のピクセルの幅を示します。この値は、32ビットの符号なし整数の小数表現です。このパラメーターの図については、TS 3GPP 26.245を参照してください。
height: This parameter indicates the height in pixels of the text track being sent. This value is the decimal representation of a 32-bit unsigned integer. Refer to TS 3GPP 26.245 for an illustration of this parameter.
高さ：このパラメーターは、送信されるテキストトラックのピクセルの高さを示します。この値は、32ビットの符号なし整数の小数表現です。このパラメーターの図については、TS 3GPP 26.245を参照してください。
max-w: This parameter indicates display capabilities. This is the maximum "width" value that the sender of this parameter supports. This value is the decimal representation of a 32-bit unsigned integer.
MAX-W：このパラメーターは、表示機能を示しています。これは、このパラメーターの送信者がサポートする最大の「幅」値です。この値は、32ビットの符号なし整数の小数表現です。
max-h: This parameter indicates display capabilities. This is the maximum "height" value that the sender of this parameter supports. This value is the decimal representation of a 32-bit unsigned integer.
MAX-H：このパラメーターは、表示機能を示します。これは、このパラメーターの送信者がサポートする最大の「高さ」値です。この値は、32ビットの符号なし整数の小数表現です。
Encoding considerations:
考慮事項のエンコード：
This media type is framed (see Section 4.8 in [29]) and partially contains binary data.
このメディアタイプはフレーム（[29]のセクション4.8を参照）に囲まれており、部分的にバイナリデータが含まれています。
Restrictions on usage:
使用に関する制限：
This media type depends on RTP framing, and hence is only defined for transfer via RTP [3]. Transport within other framing protocols is not defined at this time.
このメディアタイプはRTPフレーミングに依存するため、RTP [3]を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の輸送は定義されていません。
Security considerations:
セキュリティ上の考慮事項：
Please refer to Section 11 of RFC 4396.
RFC 4396のセクション11を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
The 3GPP Timed Text media format and its file storage is specified in Release 6 of 3GPP TS 26.245, "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)". Note also that 3GPP may in future releases specify extensions or updates to the timed text media format in a backwards-compatible way, e.g., new modifier boxes or extensions to the sample descriptions. The payload format defined in RFC 4396 allows for such extensions. For future 3GPP Releases of the Timed Text Format, the parameter "sver" is used to identify the exact specification used.
3GPPタイミングのテキストメディア形式とそのファイルストレージは、3GPP TS 26.245のリリース6、「透明エンドツーエンドパケットスイッチセットストリーミングサービス（PSS）、タイミングテキスト形式（リリース6）」で指定されています。また、3GPPは、将来のリリースで、サンプルの説明の新しいモディファイアボックスまたは拡張機能など、逆に互換性のある方法で、タイミングされたテキストメディア形式への拡張機能または更新を指定することに注意してください。RFC 4396で定義されているペイロード形式は、このような拡張機能を可能にします。時限テキスト形式の将来の3GPPリリースでは、パラメーター「SVER」を使用して、使用される正確な仕様を識別します。
The defined storage format for 3GPP Timed Text format is the 3GPP File Format (3GP) [30]. 3GP files may be transferred using the media type video/3gpp as registered by RFC 3839 [31]. The 3GPP File Format is a container file that may contain, e.g., audio and video that may be synchronized with the 3GPP Timed Text.
3GPPタイミングテキスト形式の定義されたストレージ形式は、3GPPファイル形式（3GP）[30]です。3GPファイルは、RFC 3839 [31]によって登録されているメディアタイプVideo/3GPPを使用して転送される場合があります。3GPPファイル形式は、3GPPタイムされたテキストと同期する可能性のあるオーディオやビデオを含む可能性のあるコンテナファイルです。
Published specification: RFC 4396
公開された仕様：RFC 4396
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Multimedia streaming applications.
マルチメディアストリーミングアプリケーション。
Additional information:
追加情報：
The 3GPP Timed Text media format is specified in 3GPP TS 26.245, "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)". This document and future extensions to the 3GPP Timed Text format are publicly available at http://www.3gpp.org.
3GPPタイムタイムテキストメディア形式は、3GPP TS 26.245、「透明なエンドツーエンドパケットスイッチストリーミングサービス（PSS）、タイミングテキスト形式（リリース6）」で指定されています。このドキュメントと3GPPタイムされたテキスト形式への将来の拡張機能は、http：//www.3gpp.orgで公開されています。
Magic number(s): None.
マジックナンバー：なし。
File extension(s): None.
ファイル拡張子：なし。
Macintosh File Type Code(s): None.
Macintoshファイルタイプコード：なし。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Jose Rey, jose.rey@eu.panasonic.com Yoshinori Matsui, matsui.yoshinori@jp.panasonic.com Audio/Video Transport Working Group.
Jose Rey、jose.rey@eu.panasonic.com Yoshinori Matsui、matsui.yoshinori@jp.panasonic.com Audio/Video Transport Working Group。
Intended usage: COMMON
意図された使用法：共通
Authors: Jose Rey Yoshinori Matsui
著者：ホセ・レイ・ヨシノリ・マトゥイ
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
Change Controller：IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
The information carried in the media type specification has a specific mapping to fields in SDP [4]. If SDP is used to specify sessions using this payload format, the mapping is done as follows:
メディアタイプの仕様にある情報には、SDPのフィールドへの特定のマッピングがあります[4]。SDPがこのペイロード形式を使用してセッションを指定するために使用される場合、マッピングは次のように行われます。
o The media type ("video") goes in the SDP "m=" as the media name.
o メディアタイプ（「ビデオ」）は、メディア名としてSDP "M ="になります。
m=video <port number> RTP/<RTP profile> <dynamic payload type>
o The media subtype ("3gpp-tt") and the timestamp clockrate "rate" (the RECOMMENDED 1000 Hz or other value) go in SDP "a=rtpmap" line as the encoding name and rate, respectively:
o メディアサブタイプ（ "3GPP-TT"）とタイムスタンプクロックレート「レート」（推奨1000 Hzまたはその他の値）は、それぞれエンコーディング名とレートとしてSDP「a = rtpmap」行になります。
a=rtpmap:<payload type> 3gpp-tt/1000
o The REQUIRED parameter "sver" goes in the SDP "a=fmtp" attribute by copying it directly from the media type string as a semicolon-separated parameter=value pair.
o 必要なパラメーター「SVER」は、SMICOLONで分離されたパラメーター=値ペアとしてメディアタイプの文字列から直接コピーすることにより、SDP "a = fmtp"属性になります。
o The OPTIONAL parameters "tx", "ty", "layer", "tx3g", "width", "height", "max-w" and "max-h" go in the SDP "a=fmtp" attribute by copying them directly from the media type string as a semicolon separated list of parameter=value(s) pairs:
o オプションのパラメーター "Tx"、 "ty"、 "layer"、 "tx3g"、 "width"、 "height"、 "max-w"、 "max-h" go in the sdp "a = fmtp"属性それらはメディアタイプの文字列から直接、パラメーターのセミコロン分離リスト=値（s）ペア：
a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>]
o Any parameter unknown to the device that uses the SDP SHALL be ignored. For example, parameters added to the media format in later specifications MAY be copied into the SDP and SHALL be ignored by receivers that do not understand them.
o SDPを使用するデバイスに不明なパラメーターは無視されます。たとえば、後の仕様でメディア形式に追加されたパラメーターは、SDPにコピーされ、それらを理解していない受信機によって無視される場合があります。
In this section, the meaning of the SDP parameters defined in this document within the Offer/Answer [13] context is explained.
このセクションでは、オファー/回答[13]コンテキスト内のこのドキュメントで定義されているSDPパラメーターの意味について説明します。
In unicast, sender and receiver typically negotiate the streams, i.e., which codecs and parameter values are used in the session. This is also possible in multicast to a lesser extent.
ユニキャストでは、送信者とレシーバーは通常、ストリーム、つまりセッションで使用されるコーデックとパラメーター値をネゴシエートします。これは、マルチキャストでもそれほどではありません。
Additionally, the meaning of the parameters MAY vary depending on which direction is used. In the following sections, a "<directionality> offer" means an offer that contains a stream set to <directionality>. <directionality> may take the values sendrecv, sendonly, and recvonly. Similar considerations apply for answers. For example, an answer to a sendonly offer is a recvonly answer.
さらに、パラメーターの意味は、どの方向を使用するかによって異なる場合があります。次のセクションでは、「<driversity>オファー」とは、<方向性>に設定されたストリームを含むオファーを意味します。<dilectionality>は、値をsendrecv、sendonly、およびrecvonlyに取ることができます。同様の考慮事項が回答に適用されます。たとえば、Sendonlyの申し出への回答は、recvonlyの答えです。
The following types of parameters are used in this payload format:
このタイプのパラメーターは、このペイロード形式で使用されています。
1. Declarative parameters: Offerer and answerer declare the values they will use for the incoming (sendrecv/recvonly) or outgoing (sendonly) stream. Offerer and answerer MAY use different values.
1. 宣言的なパラメーター：オファーと応答者は、受信（sendrecv/recvonly）または発信（sendonly）ストリームに使用する値を宣言します。OffererとResunserは、異なる値を使用する場合があります。
a. "tx", "ty", and "layer": These are parameters describing where the received text track is placed. Depending on the directionality:
a. 「TX」、「Ty」、および「レイヤー」：これらは、受信したテキストトラックが配置されている場所を説明するパラメーターです。方向性に応じて：
i. They MUST appear in all sendrecv offers and answers and in all recvonly offers and answers (thus applying to the incoming stream). In the case of sendrecv offers and answers and in recvonly offers, these values SHOULD be used by the sender of the stream unless it has a particular preference, in which case, it MUST make sure that these different values do not corrupt the presentation. For recvonly answers, the answerer MAY accept the proposed values for the incoming stream (in a sendonly offer; see ii. below) or respond with different ones. The offerer MUST use the returned values.
i. それらは、すべてのSendRecvのオファーと回答、およびすべてのRecvonlyのオファーと回答に表示されなければなりません（したがって、入ってくるストリームに適用されます）。SendRecvのオファーと回答の場合、およびRecvonlyの申し出では、これらの値は、特定の好みがない限り、ストリームの送信者が使用する必要があります。その場合、これらの異なる値がプレゼンテーションを破損しないことを確認する必要があります。Recvonlyの回答については、回答者は、着信ストリームの提案された値（Sendonly Offer;以下を参照）を受け入れるか、異なるもので応答する場合があります。オファーは返された値を使用する必要があります。
ii. They MAY appear in sendonly offers and MUST appear in sendonly answers. In sendonly offers, they specify the values that the offerer proposes for sending (see example in Section 9.3). In sendonly answers, these values SHOULD be copied from the corresponding recvonly offer upon accepting the stream, unless a particular preference by the receiver of the stream exists, as explained in the previous point.
ii。それらはSendonly Offerに登場する可能性があり、Sendonly Answersに表示されなければなりません。Sendonlyの申し出では、オファーが送信するために提案する値を指定します（セクション9.3の例を参照）。Sendonlyの回答では、前のポイントで説明されているように、ストリームの受信者による特定の好みが存在しない限り、これらの値は、ストリームを受け入れると、対応するRecvonlyオファーからコピーする必要があります。
2. Parameters describing the display capabilities, "max-h" and "max-w", which indicate the maximum dimensions of the text track (text display area) for the incoming stream "tx" and "ty" values (see Figure 18). "max-h" and "max-w" MUST be included in all offers and answers where "tx" and "ty" refer to the incoming stream, thus excluding sendonly offers and answers (see example in Section 9.3), where they SHALL NOT be present.
2. ディスプレイ機能「Max-H」と「Max-W」を記述するパラメーター。これは、着信ストリーム「TX」および「TY」値のテキストトラック（テキストディスプレイ領域）の最大寸法（テキストディスプレイ領域）を示しています（図18を参照）。「MAX-H」と「MAX-W」は、「TX」と「TY」が着信ストリームを参照しているため、Sendonlyのオファーと回答を除外するすべてのオファーと回答に含める必要があります（セクション9.3の例を参照）。存在しないでください。
3. Parameters describing the sent stream properties, i.e., the sender of the stream decides upon the values of these:
3. 送信されたストリームプロパティ、つまりストリームの送信者を説明するパラメーターは、これらの値を決定します。
a. "width" and "height" specify the text track dimensions. They SHALL ALWAYS be present in sendrecv and sendonly offers and answers. For recvonly answers, the answerer MUST include the offered parameter values (if any) verbatim in the answer upon accepting the stream.
a. 「幅」と「高さ」は、テキストトラックの寸法を指定します。それらは常にSendrecvおよびSendonlyの申し出と回答に存在するものとします。Recvonlyの回答については、応答者には、ストリームを受け入れると、回答に提供されたパラメーター値（もしあれば）逐語を含める必要があります。
b. "tx3g" contains static sample descriptions. It MAY only be present in sendrecv and sendonly offers and answers. This parameter applies to the stream that offerers or answerers send.
b. 「TX3G」には、静的なサンプルの説明が含まれています。SendRecvとSendonlyの申し出と回答にのみ存在する場合があります。このパラメーターは、オファーまたは応答者が送信するストリームに適用されます。
4. Negotiable parameters, which MUST be agreed on. This is the case of "sver". This parameter MUST be present in every offer and answer. The answerer SHALL choose one supported value from the offerer's list, or else it MUST remove the stream or reject the session.
4. 合意する必要がある交渉可能なパラメーター。これは「sver」の場合です。このパラメーターは、すべてのオファーと回答に存在する必要があります。応答者は、提供者のリストから1つのサポートされた値を選択するか、ストリームを削除するか、セッションを拒否する必要があります。
5. Symmetric parameters: "rate", timestamp clockrate, belongs to this class. Symmetric parameters MUST be echoed verbatim in the answer. Otherwise, the stream MUST be removed or the session rejected.
5. 対称パラメーター：「レート」、タイムスタンプ時計レートは、このクラスに属します。対称パラメーターは、答えに逐語的に反映する必要があります。それ以外の場合、ストリームを削除するか、セッションを拒否する必要があります。
The following table summarizes all options:
次の表には、すべてのオプションがまとめられています。
+..---------------------------+----------+----------+----------+
| ``--..__ Directionality/ | sendrecv | recvonly | sendonly |
+ Type of ``--..__ O or A +----------+----------+----------+
| Parameter ``--..__ | O/A | O/A | O/A |
+--------------+------------``+----------+----------+----------+
| Declarative |tx, ty, layer | M/M | M/M | m/M |
| | | | | |
+--------------+--------------+----------+----------+----------+
| Display |max-h, max-w | M/M | M/M | -/- |
| Capabilities | | | | |
+--------------+--------------+----------+----------+----------+
| Stream |height, width | M/M | -/(M) | M/M |
| properties |tx3g | m/m | -/- | m/m |
| | | | | |
+--------------+--------------+----------+----------+----------+
| Negotiable |sver | M/M | M/M | M/M |
| | | | | |
+--------------+--------------+----------+----------+----------+
| Symmetric |rate | M/M | M/M | M/M |
+--------------+--------------+----------+----------+----------+
Table 1. Parameter usage in Unicast Offer / Answer.
表1.ユニキャストの提供 /回答のパラメーターの使用。
KEY:
o M means MUST be present.
o m means MAY be present (such as proposed values).
o (M) or (m) means MUST or MAY, if applicable.
o a hyphen ("-") means the parameter MUST NOT be present.
Other observations regarding parameter usage:
パラメーターの使用に関するその他の観察結果：
o Translation and transparency values: In sendonly offers, "tx", "ty", and "layer" indicate proposed values. This is useful for visually composed sessions where the different streams occupy different parts of the display, e.g., a video stream and the captions. These are just suggested values; the peer rendering the text ultimately decides where to place the text track.
o 翻訳と透明性の値：Sendonlyのオファーでは、「TX」、「Ty」、および「レイヤー」が提案された値を示しています。これは、異なるストリームがディスプレイのさまざまな部分、たとえばビデオストリームやキャプションを占める視覚的に構成されたセッションに役立ちます。これらは推奨される値です。テキストをレンダリングするピアは、最終的にテキストトラックを配置する場所を決定します。
o Text track (area) dimensions, "height" and "width": In the case of sendonly offers, an answerer accepting the offer MUST be prepared to render the stream using these values. If any of these conditions are not met, the stream MUST be removed or the session rejected.
o テキストトラック（エリア）寸法、「高さ」、「幅」：Sendonlyの申し出の場合、オファーを受け入れる回答者は、これらの値を使用してストリームをレンダリングする準備をする必要があります。これらの条件のいずれかが満たされていない場合、ストリームを削除するか、セッションを拒否する必要があります。
o Display capabilities, "max-h" and "max-w": An answerer sending a stream SHALL ensure that the "height" and "width" values in the answer are compatible with the offerer's signaled capabilities.
o ディスプレイ機能、「MAX-H」および「MAX-W」：ストリームを送信する回答者は、回答の「高さ」と「幅」値が提供者の信号能力と互換性があることを保証するものとします。
o Version handling via "sver": The idea is that offerer and answerer communicate using the same version. This is achieved by letting the answerer choose from a list of supported versions, "sver". For recvonly streams, the first value in the list is the preferred version to receive. Consequently, for sendonly (and sendrecv) streams, the first value is the one preferred for sending (and receiving). The answerer MUST choose one value and return it in the answer. Upon receiving the answer, the offerer SHALL be prepared to send (sendonly and sendrecv) and receive (recvonly and sendrecv) a stream using that version. If none of the versions in the list is supported, the stream MUST be removed or the session rejected. Note that, if alternative non-compatible versions are offered, then this SHALL be done using different payload types.
o 「SVER」を介したバージョンの処理：アイデアは、同じバージョンを使用して提供者と回答者が通信することです。これは、サポートされているバージョン「Sver」のリストから、回答者に選択できるようにすることによって達成されます。Recvonlyストリームの場合、リストの最初の値は受信する優先バージョンです。その結果、Sendonly（およびSendRecv）ストリームの場合、最初の値は、送信（および受信）を好む値です。応答者は1つの値を選択し、回答に返す必要があります。回答を受け取ったとき、提供者はそのバージョンを使用してストリームを送信し（sendonly and sendrecv）送信し（recvonly and sendrecv）準備をしなければなりません。リスト内のバージョンがサポートされていない場合、ストリームを削除するか、セッションを拒否する必要があります。代替の非適合性バージョンが提供されている場合、これは異なるペイロードタイプを使用して行われるものとすることに注意してください。
In multicast, the parameter usage is similar to the unicast case, except as follows:
マルチキャストでは、パラメーターの使用法は、次のようなものを除き、ユニキャストの場合に似ています。
o the parameters "tx", "ty", and "layer" in multicast offers only have meaning for sendrecv and recvonly streams. In order for all clients to have the same vision of the session, they MUST be used symmetrically.
o マルチキャストオファーの「Tx」、「Ty」、および「レイヤー」のパラメーターには、SendRecvおよびRecvonlyストリームのみの意味があります。すべてのクライアントがセッションの同じビジョンを持つためには、対称的に使用する必要があります。
o for "height", "width", and "tx3g" (for sendrecv and sendonly), multicast offers specify which values of these parameters the participants MUST use for sending. Thus, if the stream is accepted, the answerer MUST also include them verbatim in the answer (also "tx3g", if present).
o 「高さ」、「幅」、および「TX3G」（SendRecvおよびSendonlyの場合）の場合、マルチキャストは、参加者が送信に使用する必要があるこれらのパラメーターの値を指定します。したがって、ストリームが受け入れられた場合、回答者は回答に逐語的に含める必要があります（存在する場合は「TX3G」もあります）。
o The capability parameters, "max-h" and "max-w", SHALL NOT be used in multicast. If the offered text track should change in size, a new offer SHALL be used instead.
o 「Max-H」と「Max-W」の機能パラメーターは、マルチキャストでは使用してはなりません。提供されたテキストトラックのサイズが変更される場合、代わりに新しいオファーを使用するものとします。
o Regarding version handling:
o バージョン処理に関して：
In the case of multicast offers, an answerer MAY accept a multicast offer as long as one of the versions listed in the "sver" is supported. Therefore, if the stream is accepted, the answerer MUST choose its preferred version, but, unlike in unicast, the offerer SHALL NOT change the offered stream to this chosen version because there may be other session participants that do support the newer extensions. Consequently, different session participants may end up using different backwards-compatible media format versions. It is RECOMMENDED that the multicast offer contains a limited number of versions, in order for all participants to have the same view of the session. This is a responsibility of the session creator. If none of the offered versions is supported, the stream SHALL be removed or the session rejected. Also in this case, if alternative non-compatible versions are offered, then this SHALL be done using different payload types.
マルチキャストオファーの場合、「SVER」にリストされているバージョンの1つがサポートされている限り、応答者はマルチキャストのオファーを受け入れる場合があります。したがって、ストリームが受け入れられた場合、回答者はその優先バージョンを選択する必要がありますが、ユニキャストとは異なり、提供者は、新しい拡張機能をサポートする他のセッション参加者がいる可能性があるため、提供されたストリームをこの選択したバージョンに変更してはなりません。したがって、異なるセッション参加者は、異なる後方互換のメディア形式バージョンを使用することになります。すべての参加者がセッションについて同じビューを持つために、マルチキャストオファーには限られた数のバージョンが含まれることをお勧めします。これはセッション作成者の責任です。提供されているバージョンのいずれもサポートされていない場合、ストリームは削除されるか、セッションが拒否されます。また、この場合、代替の非適合性バージョンが提供されている場合、これは異なるペイロードタイプを使用して行われます。
In these unicast O/A examples, the long lines are wrapped around. Static sample descriptions are shortened for clarity.
これらのユニキャストo/a例では、長い線が巻き付けられています。静的なサンプルの説明は、明確にするために短縮されます。
For sendrecv:
sendrecvの場合：
O -> A
o-> a
m=video <port> RTP/AVP 98
a=rtpmap:98 3gpp-tt/1000
a=fmtp:98 tx=100; ty=100; layer=0; height=80; width=100; max-h=120;
max-w=160; sver=6256,60; tx3g=81...
a=sendrecv
A -> O
a-> o
m=video <port> RTP/AVP 98..
a=rtpmap:98 3gpp-tt/1000
a=fmtp:98 tx=100; ty=95; layer=0; height=90; width=100; max-h=100;
max-w=160; sver=60; tx3g=82...
a=sendrecv
In this example, the offerer is telling the answerer where it will place the received stream and what is the maximum height and width allowable for the stream that it will receive. Also, it tells the answerer the dimensions of the text track for the stream sent and which sample description it shall use. It offers two versions, 6256 and 60. The answerer responds with an equivalent set of parameters for the stream it receives. In this case, the answerer's "max-h" and "max-w" are compatible with the offerer's "height" and "width". Otherwise, the answerer would have to remove this stream, and the offerer would have to issue a new offer taking the answerer's capabilities into account. This is possible only if multiple payload types are present in the initial offer so that at least one of them matches the answerer's capabilities as expressed by "max-h" and "max-w" in the negative answer. Note also that the answerer's text box dimensions fit within the maximum values signaled in the offer. Finally, the answerer chooses to use version 60 of the timed text format.
この例では、提供者は、受信されたストリームの配置場所と、受け取るストリームの最大高さと幅は何ですか？また、送信されるストリームのテキストトラックの寸法と、使用するサンプルの説明を回答者に伝えます。6256と60の2つのバージョンを提供します。応答者は、受信するストリームのパラメーターの同等のセットで応答します。この場合、応答者の「MAX-H」と「Max-W」は、提供者の「高さ」と「幅」と互換性があります。それ以外の場合は、回答者はこのストリームを削除する必要があり、オファーは、応答者の機能を考慮に入れて新しいオファーを発行する必要があります。これは、複数のペイロードタイプが最初のオファーに存在する場合にのみ可能です。そのため、少なくとも1つは「Max-H」と「Max-W」で表現されているAsherserの機能と一致します。また、応答者のテキストボックスの寸法は、オファーで通知された最大値に適合することに注意してください。最後に、Answererは、タイミングされたテキスト形式のバージョン60を使用することを選択します。
For recvonly:
recvonlyのために：
Offerer -> Answerer
offerer->回答者
m=video <port> RTP/AVP 98
a=rtpmap:98 3gpp-tt/1000
a=fmtp:98 tx=100; ty=100; layer=0; max-h=120; max-w=160; sver=6256,60
a=recvonly
A -> O
a-> o
m=video <port> RTP/AVP 98..
a=rtpmap:98 3gpp-tt/1000
a=fmtp:98 tx=100; ty=100; layer=0; height=90; width=100; sver=60;
tx3g=82...
a=sendonly
In this case, the offer is different from the previous case: It does not include the stream properties "height", "width", and "tx3g". The answerer copies the "tx", "ty", and "layer" values, thus acknowledging these. "max-h" and "max-w" are not present in the answer because the "tx" and "ty" (and "layer") in this special case do not apply to the received stream, but to the sent stream. Also, if offerer and answerer had very different display sizes, it would not be possible to express the answerer's capabilities. In the example above and for an answerer with a 50x50 display, the translation values are already out of range.
この場合、オファーは以前のケースとは異なります。ストリームプロパティ「高さ」、「幅」、「TX3G」は含まれません。Answererは、「Tx」、「Ty」、および「レイヤー」値をコピーして、これらを認めます。この特別なケースの「Tx」と「Ty」（および「レイヤー」）が受信されたストリームではなく、送信されたストリームに適用されるため、「Max-H」と「Max-W」は答えに存在しません。また、OffererとReswersのディスプレイサイズが非常に異なる場合、Answererの機能を表現することはできません。上記の例では、50x50ディスプレイを備えた回答者の場合、翻訳値はすでに範囲外です。
For sendonly:
Sendonlyのために：
O -> A
o-> a
m=video <port> RTP/AVP 98
a=rtpmap:98 3gpp-tt/1000
a=fmtp:98 tx=100; ty=100; layer=0; height=80; width=100;
sver=6256,60; tx3g=81...
a=sendonly
A -> O
a-> o
m=video <port> RTP/AVP 98.. a=rtpmap:98 3gpp-tt/1000 a=fmtp:98 tx=100; ty=100; layer=0; height=80; width=100; max-h=100; max-w=160; sver=60 a=recvonly Note that "max-h" and "max-w" are not present in the offer. Also, with this answer, the answerer would accept the offer as is (thus echoing "tx", "ty", "height", "width", and "layer") and additionally inform the offerer about its capabilities: "max-h" and "max-w".
M = Video <port> rtp/avp 98 .. a = rtpmap：98 3gpp-tt/1000 a = fmtp：98 tx = 100;ty = 100;layer = 0;高さ= 80;幅= 100;max-h = 100;max-w = 160;Sver = 60 a = recvonly「max-h」と「max-w」はオファーには存在しないことに注意してください。また、この回答により、応答者はそのように申し出を受け入れ（したがって、「TX」、「TY」、「高さ」、「幅」、「レイヤー」を反映します）。h "および" max-w "。
Another possible answer for this case would be:
このケースに対する別の可能な答えは、次のとおりです。
A -> O
a-> o
m=video <port> RTP/AVP 98..
a=rtpmap:98 3gpp-tt/1000
a=fmtp:98 tx=120; ty=105; layer=0; max-h=95; max-w=150; sver=60
a=recvonly
In this case, the answerer does not accept the values offered. The offerer MUST use these values or else remove the stream.
この場合、応答者は提供された値を受け入れません。オファーはこれらの値を使用するか、ストリームを削除する必要があります。
SDP may also be employed outside of the Offer/Answer context, for instance for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [14] or streamed through the Real Time Streaming Protocol (RTSP) [15].
SDPは、セッションアナウンスプロトコル（SAP）[14]を介して発表されるマルチメディアセッションで、またはリアルタイムストリーミングプロトコル（RTSP）[15]を介してストリーミングされる場合、オファー/回答のコンテキストの外で採用される場合があります。
In this case, the receiver of a session description is required to support the parameters and given values for the streams, or else it MUST reject the session. It is the responsibility of the sender (or creator) of the session descriptions to define the session parameters so that the probability of unsuccessful session setup is minimized. This is out of the scope of this document.
この場合、セッションの説明の受信者は、パラメーターをサポートし、ストリームの値を指定する必要があります。そうしないと、セッションを拒否する必要があります。セッションの説明の送信者（または作成者）の責任は、セッションのパラメーターを定義して、セッションのセットアップに失敗する可能性が最小化されるようにします。これは、このドキュメントの範囲外です。
IANA has registered the media subtype name "3gpp-tt" for the media type "video" as specified in Section 8 of this document.
IANAは、このドキュメントのセクション8で指定されているように、メディアタイプ「ビデオ」のメディアサブタイプ名「3GPP-TT」を登録しています。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3] and any applicable RTP profile, e.g., AVP [17].
この仕様で定義されているペイロード形式を使用したRTPパケットは、RTP仕様[3]で説明されているセキュリティに関する考慮事項と、該当するRTPプロファイル、例えばAVP [17]の対象となります。
In particular, an attacker may invalidate the current set of active sample descriptions at the client by means of repeating a packet with an old sample description, i.e., replay attack. This would mean that the display of the text would be corrupted, if displayed at all. Another form of attack may consist of sending redundant fragments, whose boundaries do not match the exact boundaries of the originals (as indicated by LEN) or fragments that carry different sample lengths (SLEN). This may cause a decoder to crash.
特に、攻撃者は、古いサンプルの説明、つまりリプレイ攻撃でパケットを繰り返すことにより、クライアントでのアクティブなサンプル説明の現在のセットを無効にする場合があります。これは、テキストの表示が破損することを意味します。別の形式の攻撃は、冗長なフラグメントを送信することで構成されます。境界は、オリジナルの正確な境界（LENで示されているように）または異なるサンプル長（SLEN）を運ぶフラグメントと一致しません。これにより、デコーダーがクラッシュする可能性があります。
These types of attack may easily be avoided by using source authentication and integrity protection.
これらのタイプの攻撃は、ソース認証と整合性保護を使用することにより、簡単に回避できます。
Additionally, peers in a timed text session may desire to retain privacy in their communication, i.e., confidentiality.
さらに、時限テキストセッションのピアは、コミュニケーションのプライバシーを維持したい場合、つまり機密性を希望する場合があります。
This payload format does not provide any mechanisms for achieving these. Confidentiality, integrity protection, and authentication have to be solved by a mechanism external to this payload format, e.g., SRTP [10].
このペイロード形式は、これらを達成するためのメカニズムを提供しません。機密性、整合性保護、および認証は、このペイロード形式の外部のメカニズム、たとえばSRTP [10]によって解決する必要があります。
[1] Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6), TS 26.245 v 6.0.0, June 2004.
[1] 透明なエンドツーエンドパケットスイッチ型ストリーミングサービス（PSS）;時限テキスト形式（リリース6）、TS 26.245 V 6.0.0、2004年6月。
[2] ISO/IEC 14496-12:2004 Information technology - Coding of audio-visual objects - Part 12: ISO base media file format.
[2] ISO/IEC 14496-12：2004情報テクノロジー - オーディオビジュアルオブジェクトのコーディング - パート12：ISOベースメディアファイル形式。
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[3] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[6] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 3548、2003年7月。
[7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[7] Rosenberg、J。およびH. Schulzrinne、「一般的なフォワードエラー補正のためのRTPペイロード形式」、RFC 2733、1999年12月。
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[8] Perkins、C。and O. Hodson、「ストリーミングメディアの修理のオプション」、RFC 2354、1998年6月。
[9] W3C, "Synchronised Multimedia Integration Language (SMIL 2.0)", August, 2001.
[9] W3C、「同期されたマルチメディア統合言語（Smil 2.0）」、2001年8月。
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[10] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[11] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", Work in Progress, September 2005.
[11] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenberg、「RTP再送信ペイロードフォーマット」、2005年9月、進行中の作業。
[12] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and P. Gentric, "RTP Payload Format for Transport of MPEG-4 Elementary Streams", RFC 3640, November 2003.
[12] van der Meer、J.、Mackie、D.、Swaminathan、V.、Singer、D。、およびP. Gentric、「MPEG-4基本ストリームの輸送のためのRTPペイロード形式」、RFC 3640、2003年11月。
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[13] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[14] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[15] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[16] Transparent end-to-end packet switched streaming service (PSS); Protocols and codecs (Release 6), TS 26.234 v 6.1.0, September 2004.
[16] 透明なエンドツーエンドパケットスイッチ型ストリーミングサービス（PSS）;プロトコルとコーデック（リリース6）、TS 26.234 v 6.1.0、2004年9月。
[17] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[17] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[18] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[18] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[19] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[19] Hoffman、P。and F. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[20] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[20] Friedman、T.、Caceres、R。、およびA. Clark、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[21] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", Work in Progress, August 2004.
[21] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「RTCPベースのフィードバックのRTPプロファイル（RTP/AVPF）の拡張プロファイル」、2004年8月の作業。
[22] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, May 2000.
[22] Hellstrom、G。、「テキスト会話のためのRTPペイロード」、RFC 2793、2000年5月。
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[23] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[24] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application, with amendment 1, (2000).
[24] ITU -T推奨T.140（1998） - マルチメディアアプリケーションのテキスト会話プロトコル、修正1、（2000）。
[25] ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded Character Set.
[25] ISO/IEC 10646-1：（1993）、普遍的な複数のオクテットコード化された文字セット。
[26] ISO/IEC FCD 14496-17 Information technology - Coding of audio-visual objects - Part 17: Streaming text format, Work in progress, June 2004.
[26] ISO/IEC FCD 14496-17情報テクノロジー - オーディオビジュアルオブジェクトのコーディング - パート17：ストリーミングテキスト形式、2004年6月、進行中の作業。
[27] Transparent end-to-end Packet-switched Streaming Service (PSS); 3GPP SMIL language profile, (Release 6), TS 26.246 v 6.0.0, June 2004.
[27] 透明なエンドツーエンドパケットスイッチストリーミングサービス（PSS）;3GPP Smil Language Profile、（リリース6）、TS 26.246 V 6.0.0、2004年6月。
[28] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[28] Casner、S。およびP. Hoschka、「RTPペイロードフォーマットのMIMEタイプ登録」、RFC 3555、2003年7月。
[29] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[29] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[30] Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) (Release 6), TS 26.244 V6.3. March 2005.
[30] 透明なエンドツーエンドパケットスイッチ型ストリーミングサービス（PSS）;3GPPファイル形式（3GP）（リリース6）、TS 26.244 V6.3。2005年3月。
[31] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
[31] Castagno、R。およびD. Singer、「第3世代パートナーシッププロジェクト（3GPP）マルチメディアファイルのMIMEタイプ登録」、RFC 3839、2004年7月。
This section provides a coarse overview of the 3GP file structure, which follows the ISO Base Media file Format [2].
このセクションでは、3GPファイル構造の粗い概要を示します。これは、ISOベースメディアファイル形式[2]に従います。
Each 3GP file consists of "Boxes". In general, a 3GP file contains the File Type Box (ftyp), the Movie Box (moov), and the Media Data Box (mdat). The File Type Box identifies the type and properties of the 3GP file itself. The Movie Box and the Media Data Box, serving as containers, include their own boxes for each media. Boxes start with a header, which indicates both size and type (these fields are called, namely, "size" and "type"). Additionally, each box type may include a number of boxes.
各3GPファイルは「ボックス」で構成されています。一般に、3GPファイルには、ファイルタイプボックス（FTYP）、ムービーボックス（MOOV）、およびメディアデータボックス（MDAT）が含まれています。ファイルタイプボックスは、3GPファイル自体のタイプとプロパティを識別します。ムービーボックスとメディアデータボックスは、コンテナとして機能し、各メディアに独自のボックスが含まれています。ボックスは、サイズとタイプの両方を示すヘッダーから始まります（これらのフィールドは、「サイズ」と「タイプ」と呼ばれます）。さらに、各ボックスタイプには多数のボックスが含まれている場合があります。
In the following, only those boxes are mentioned that are useful for the purposes of this payload format.
以下では、このペイロード形式の目的に役立つボックスのみが言及されています。
The Movie Box (moov) contains one or more Track Boxes (trak), which include information about each track. A Track Box contains, among others, the Track Header Box (tkhd), the Media Header Box (mdhd), and the Media Information Box (minf).
ムービーボックス（MOOV）には、各トラックに関する情報が含まれる1つ以上のトラックボックス（TRAK）が含まれています。トラックボックスには、とりわけ、トラックヘッダーボックス（TKHD）、メディアヘッダーボックス（MDHD）、メディア情報ボックス（MINF）が含まれています。
The Track Header Box specifies the characteristics of a single track, where a track is, in this case, the streamed text during a session. Exactly one Track Header Box is present for a track. It contains information about the track, such as the spatial layout (width and height), the video transformation matrix, and the layer number. Since these pieces of information are essential and static (i.e., constant) for the duration of the session, they must be sent prior to the transmission of any text samples.
トラックヘッダーボックスは、セッション中にトラックがストリーミングされたテキストである単一のトラックの特性を指定します。トラック用に1つのトラックヘッダーボックスが存在します。空間レイアウト（幅と高さ）、ビデオ変換マトリックス、レイヤー番号など、トラックに関する情報が含まれています。これらの情報は、セッションの期間中は不可欠で静的（つまり、一定）であるため、テキストサンプルの送信前に送信する必要があります。
The Media Header Box contains the "timescale" or number of time units that pass in one second, i.e., cycles per second or Hertz. The Media Information Box includes the Sample Table Box (stbl), which contains all the time and data indexing of the media samples in a track. Using this box, it is possible to locate samples in time and to determine their type, size, container, and offset into that container. Inside the Sample Table Box, we can find the Sample Description Box (stsd, for finding sample descriptions), the Decoding Time to Sample Box (stts, for finding sample duration), the Sample Size Box (stsz), and the Sample to Chunk Box (stsc, for finding the sample description index).
メディアヘッダーボックスには、1秒で通過する「タイムスケール」または時間単位、つまり1秒あたりのサイクルまたはHERTZが含まれています。メディア情報ボックスには、サンプルテーブルボックス（STBL）が含まれています。これには、トラック内のメディアサンプルのすべての時間とデータインデックスが含まれています。このボックスを使用して、サンプルを時間内に見つけて、その種類、サイズ、コンテナ、およびその容器にオフセットすることができます。サンプルテーブルボックス内には、サンプル説明ボックス（STSD、サンプルの説明を見つけるためのSTSD）、サンプルボックスまでのデコード時間（STTS、サンプル期間を見つけるため）、サンプルサイズボックス（STSZ）、およびチャンクのサンプルを見つけることができます。Box（STSC、サンプル説明インデックスを見つけるため）。
Finally, the Media Data Box contains the media data itself. In timed text tracks, this box contains text samples. Its equivalent to audio and video is audio and video frames, respectively. The text sample consists of the text length, the text string, and one or several Modifier Boxes. The text length is the size of the text in bytes.
最後に、メディアデータボックスにはメディアデータ自体が含まれています。タイムされたテキストトラックでは、このボックスにはテキストサンプルが含まれています。オーディオとビデオに相当するのは、それぞれオーディオフレームとビデオフレームです。テキストサンプルは、テキストの長さ、テキスト文字列、および1つまたは複数のモディファイアボックスで構成されています。テキストの長さは、テキストのサイズのバイトです。
The text string is plain text to render. The Modifier Box is information to render in addition to the text, such as color, font, etc.
テキスト文字列は、レンダリングするプレーンテキストです。モディファイアボックスは、色、フォントなど、テキストに加えてレンダリングする情報です。
The authors would like to thank Dave Singer, Jan van der Meer, Magnus Westerlund, and Colin Perkins for their comments and suggestions about this document.
著者は、この文書についてのコメントと提案について、デイブ・ヴァン・デル・ミーア、マグナス・ウェスターランド、コリン・パーキンスに感謝します。
The authors would also like to thank Markus Gebhard for the free and publicly available JavE ASCII Editor (used for the ASCII drawings in this document) and Henrik Levkowetz for the Idnits web service.
著者はまた、無料で公開されたJave Asciiエディター（このドキュメントのASCII図面に使用）とIdnits WebサービスにはHenrik Levkowetzについて、Markus Gebhardに感謝したいと思います。
Authors' Addresses
著者のアドレス
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ホセ・レイ・パナソニックR＆DセンタードイツGMBHモンザスト。4C D-63225 Langen、ドイツ
EMail: jose.rey@eu.panasonic.com
Phone: +49-6103-766-134
Fax: +49-6103-766-166
Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006 Kadoma Kadoma-shi, Osaka, Japan
ヨシノリ松井松島電気産業株式会社1006 Kadoma Kadoma-Shi、大阪、日本
EMail: matsui.yoshinori@jp.panasonic.com
Phone: +81 6 6900 9689
Fax: +81 6 6900 9699
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。