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
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).
著作権（C）インターネット協会（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（3rd Generation Partnership Project）のテキストを時限の伝送のための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時限テキストは、「透明なエンド・ツー・エンドのパケットがストリーミングサービス（PSS）を切り替え、時間指定テキスト形式（リリース6）」3GPP技術仕様TS 26.245で指定した時間が並ぶ、装飾されたテキストのためのメディアフォーマットである[1]。プレーンテキストのほかに、3GPP時限テキスト形式は、ニュース番組のテキスト、またはハイパーリンクのテキストをスクロールし、そのようなカラオケアプリケーションのためのものとして飾られたテキストを作成することができます。これらの内容は、またはオーディオやビデオなどの他のメディアと同期してもしなくてもよいです。
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を使用して、3GPP時限テキストコンテンツをストリーミングするための手段を提供することである[3]。これは（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は、オファー/アンサーモデル[13]での使用を含む、ユニキャストとマルチキャストセッションのためのSDPを指定します。セクション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 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.
UTF-8 [18]またはUTF-16 [19]符号化のいずれかを使用してエンコードされた文字：実際のテキスト文字列O。
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]:
装飾○：一部の文字は異なるスタイル、遅延、点滅などを持っている場合は、これが示される必要があります。それが実際に必要になった場合の装飾は、テキストサンプルにのみ存在します。そうでない場合は、デフォルトの設定では、上記のように適用されます。必要に応じて、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.
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.また、このペイロードフォーマットを使用して、RTP受信可能であること、および3GPファイルフォーマットに従って受信されたテキストの内容を格納するRTPパケットから全ての必要な情報を得るために、3GPフォーマットで記憶することができるものとします。このファイルは、元のファイルと同じであってもなくてもよいです。
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.
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.
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.
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キロバイトだろうことを意味します。いいえ拡張メカニズムが提供されていません。
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ヘルツのタイムスタンプclockrateで最大持続時間をもたらします。それにも関わらず、拡張メカニズムは、セクション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。一つの完全なテキストサンプルが含まれているTYPE 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。完全な変性剤またはそれらの最初のフラグメントを含むTYPE 3部、
d. A TYPE 4 unit that contains one modifier fragment other than the first, and
D。最初以外の修飾フラグメントを含むTYPE 4ユニット、及び
e. A TYPE 5 unit that contains one sample description.
電子。一つのサンプル記述を含む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.
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.断片再組み立て：再アセンブルテキストサンプルするために、情報が必要とされるオフセット。代わりにオフセット文字やバイト、シングルバイト、TOTAL / THIS、の使用されています。これら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のように、この情報を提供する）、アクセスユニット（AUS）は、データの搬送に使用されるので、これは、RFC 3640との相互運用性を容易にし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.6と4.1.2にTYPEヘッダ）のヘッダ・フィールドは、32ビットマシン上で簡単に処理するために配置されています。この理由のため、フィールド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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
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.
この文書では、しかし、テキストサンプルは、ゼロ個以上の修飾子に続くテキスト文字列のみが含まれています。テキストサンプルのこの定義は、16ビットのテキスト文字列のバイト数と3GPファイルのテキストサンプル（4.3節および図9を参照）に存在する16ビットのバイトオーダーマーク（BOM）を除外します。セクション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.
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).
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.
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.
aggregation or aggregate packet
集約または集約パケット
The payload of an aggregate (RTP) packet consists of several
(transport) units.
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.
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.
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:
"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)".
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時限テキストトラックの場合は、タイムスタンプclockrateは、そのテキストトラックのメディアヘッダボックス内の「タイムスケール」パラメータの値です。メディアヘッダーボックスで指定された3GPファイル内のトラックは、それぞれ独自のclockrateを持っているかもしれません。同様に、ライブストリーミングアプリケーションは、適切なタイムスタンプclockrateを使用しなければなりません。 1000Hzでのデフォルト値が推奨されます。その他のタイムスタンプclockratesを使用することができます。この場合は、ここでの典型的な行動は、関連するオーディオまたはビデオストリームで使用されるものと3GPP時限テキストclockrateを一致させることです。
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.
凝集ペイロードに、ユニットは、ペイロード内の、すなわち、最も早い最初、プレイアウトのために配置されなければなりません。 TYPE 1ユニットが集約されている場合、後続のユニットのタイムスタンプはRTPのタイムスタンプ値に以前のサンプルの時限テキストサンプル持続時間を加算することによって得られなければなりません。 TYPE 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.
最後に、タイムスタンプclockratesは、アウトオブバンドによってシグナリングされなければならない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.
この文書で指定された（トランスポート）単位は、特定のヘッダフィールド（TYPES 1-5）とテキストサンプルの内容が続く、共通フィールド（U、R、TYPE、LEN）の集合から成ります。図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パケットが示されています。最初は2つの完全なテキストサンプルと凝集RTPペイロードを含み、第二は、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変換フラグ"：これは、RTP受信機に通知するために使用されているかどうかUTF-8（U = 0）またはUTF-16（U = 1）テキスト文字列をエンコードするために使用しました。 UTF-16このペイロード形式により搬送されたテキスト文字列はビッグエンディアン順序、別名、ネットワークバイト順で直列化されなければなりません。
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.
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値が定義されています。
- 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.
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ビット）「の長さフィールド」：テキスト文字列と修飾（もしあれば）：すなわち、このヘッダフィールドのサイズ（バイト単位）を示し、すべてのフィールドは、以下、LENフィールドは、ユニット・ペイロードが続きます。この定義は、共通ヘッダの最初のU / R / TYPEバイトを除外する。 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.
ライブストリーミングのために、現在の断片のためのサンプル長とLEN値の両方は、サンプリングプロセス中またはフラグメンテーション中に計算されなければなりません。
In general, LEN may take the following values:
一般的には、LENは以下の値をとることがあります。
- 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から4 = TYPE、レン> 6から5 = TYPE、レン> 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.
以下のサブセクションでTYPEの値に対して異なるペイロード・ヘッダが指定されています。
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. TYPE 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.
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).
彼らはサンプルの内容が含まれていないが、注意はまた、空のテキストサンプルは、全体のテキストサンプルと考えられています。空のテキストサンプルは、表示をクリアするか、例えば、未知の期間のサンプルに終止符を打つために使用することができます。サンプルコンテンツのないユニットは8（0x0008で）のLENフィールド値を持たなければなりません。
The fields above have the following meaning:
上記のフィールドの意味は以下のとおりです。
o U, R, and TYPE, as defined in Section 4.1.1.
U、R、およびTYPE O、セクション4.1.1で定義された通りです。
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 LENは、この場合には、（完全な）テキストサンプルを加えたヘッダの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値（閉）間隔[129254]に入らなければなりません。
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値は、明確にこのセッションでアクティブである期間中に1つの特定のサンプル記述に連結され、その期間中に変更されないもの。この期間は、セッション継続時間より小さいか同じであってもよいです。この期間は、事前に知られていません。 64の動的同時にアクティブSIDX値の最大値は、任意の瞬間に許容されます。ダイナミックなSIDX値は、閉区間[0127]内にする必要があります。これは、両方の記録されたコンテンツとライブストリーミングアプリケーションのために十分でなければなりません。それにもかかわらず、ラップアラウンド機構は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タイムスタンプユニットのサンプル期間を示します。このフィールドは、3バイトの長さが2バイトに好ましいです。 1000Hzでの典型的なclockrateため、16ビットがいくつかのストリームには短すぎるかもしれないわずか65秒の最大持続時間を可能にするであろうからです。 90キロヘルツのために、この値は約3分である一方、1000 Hzでの24ビットは、約4.6時間の最大期間を可能にします。これらの値は、ストリーミングアプリケーションのために十分でなければなりません。大きな期間が必要な場合は、セクション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（0×000000）は、未知の持続時間を知らせるために予約されています。そのタイムスタンプによって示されるように、未知の持続時間のテキストサンプルは、次のテキストサンプルがアクティブになるまで表示しなければならない：提示される未知の持続時間のサンプルが受信機に表示されるべき次のサンプルのタイムスタンプによって決定される時間の量。
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行のテキストが表示されます。いつものように、見出しは残りの部分よりも長い時間のために示されています。この時間は、原則的には、ライブストリーミングされたストリームサーバに不明です。次の見出しを受信したときに見出しを単に交換されます。
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値がゼロよりも常に大きくなければならないテキストサンプルの有効期間に変更されなければならない（ISOファイルフォーマットは、[2]明示的禁じ注意ゼロのサンプル時間）。有効期間は、（未知の持続時間）現在のサンプルと表示され、次のテキストサンプルとの間のタイムスタンプの差として計算しなければなりません。
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]にスクロールしてカラオケしています。これはまた、時間指定テキスト形式の将来の拡張のために適用されます。さらに、唯一のサンプル記述（TYPE 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は、それが演繹各断片のLEN値から計算することができるので、テキスト文字列断片（タイプ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のいずれかを使用してエンコードされた文字列からなります。何BOMなしバイトカウントがペイロードで運ばれた文字列に含まれていないことにも注意してください（3GPファイルに格納されたテキストサンプルとは対照的に、[1]）。
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. TYPE 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:
このヘッダタイプは、全体のテキスト文字列またはそのフラグメントのいずれかを輸送するために使用されます。 TYPE 2単位が修飾を含んではなりません。詳細に：
o U, R, and TYPE, as defined in Section 4.1.1.
U、R、およびTYPE O、セクション4.1.1で定義された通りです。
o SIDX and SDUR, as defined in Section 4.1.2.
O SIDXとSDUR、4.1.2項で定義されています。
Note that the U, SIDX, and SDUR fields are meaningful since
partial text strings can also be displayed.
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.
注また、そのTYPE 2単位が明示的にテキスト文字列の長さが含まれていない、TLEN（TYPE 1を参照）。 TYPE 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").
SLENフィールド（16ビット）Oこの断片が属する元の（全体の）テキストサンプルのサイズ（バイト単位）を示しています。この長さは、現在のテキスト文字列に加えて任意の修飾子ボックスを備え、（そして第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:
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
IP / UDP / RTP / TYPE1ヘッダー+（8秒のテキストサンプル）= 20 + 8 + 12 + 8 +（〜6つの文字/単語* 5ワード/秒×8つのS * 2つの文字/単語）= 528バイト<576バイト
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:
他のシナリオの場合は、損失の多いネットワークのように、サンプルごとに1つのパケットは、冗長性が低すぎることが起こり得ます。この場合、選択は、68バイトのエンコーダ「収集」テキスト毎秒、従って降伏テキストサンプル（TYPE 1単位）、タイプ1ヘッダが含まれるかもしれません。現在の最後の2つのテキストサンプル（下記参照）：我々は、例えば、1つのRTPペイロード内の3個の隣接するテキストサンプルを含むことができます。これは、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ファイルにSLEN値を見つける方法の詳細については、セクション4.3を参照してください。ライブコンテンツの場合は、SLENは、サンプリング処理中に取得する必要があります。
Finally, note that clients MAY use SLEN to buffer space for the remaining fragments of a text sample.
最後に、クライアントはテキストサンプルの残りのフラグメントのためのスペースをバッファリングするためにSLENを使用することがあります。
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.
フィールドTOTAL（4ビット）この（4ビット）フラグメントの総数を示すoを元のテキストサンプル（すなわち、テキスト文字列とその改質）が断片化されており、その順序は、その順序に現行断片を占めています、それぞれ。パケット（およびフラグメント）が繰り返し送信（セクション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.
a）は、それはもう一つのバイトを取ると、b）それは文字オフセット上の任意の情報を提供していません：いつもの「バイトオフセット」フィールドは、二つの理由のために、ここで使用されていません。 UTF-8 / UTF-16テキスト文字列は、一般的に、1〜6バイトの範囲の可変文字長を有しています。したがって、TOTAL /この溶液が好ましいです。また、LENとSLENフィールドは、この目的のために使用することが、彼らはテキストサンプルの完全性に関する情報を提供するだろうが、彼らは断片の順序を指定していないと主張することができます。
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）で、この値がTOTALより大きい又は合計がゼロ（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. TYPE 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、及びTYPEフィールドは、セクション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.
TOTAL O /このフィールドは、TYPE 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.
最後（末尾）修飾断片を含むTYPE 3単位のために、TOTALの値は、この（TOTAL = THIS）と等しくなければなりません。テキストサンプルの断片の総数は、論理的に常に1よりも大きくなっているのでまた、TOTAL = THISは、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.
合計TYPE 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は、断片は、常に自分のRTPパケットで輸送されているのでTYPE 1.同一の定義を有する、このフィールドは、このフラグメントが有効でどのくらい知っておく必要があります。これは、例えば、それは表示バッファに保持されなければならない時間の長さを決定するために使用されてもよいです。
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. TYPE 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、及びTYPEフィールドは、セクション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フィールドは、（0x0006）は、6より大きくなければなりません。そうしないと、ユニットは捨てなければなりません。
TOTAL/THIS is used as in TYPE 2.
TOTAL / THISは、TYPE 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. TYPE 5ヘッダー形式
This header type is used to transport (dynamic) sample descriptions. Every sample description MUST have its own TYPE 5 header.
このヘッダタイプは、（動的）サンプル記述を搬送するために使用されます。すべてのサンプル記述には、独自のTYPE 5ヘッダを持たなければなりません。
The U, R, and TYPE fields are used as per Section 4.1.1.
U、R、及びTYPEフィールドは、セクション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フィールドは、サンプル記述の長さを示し、加えて3つのユニットは、SIDXとLENフィールド自体を占めます。したがって、このフィールドは、三（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値は（閉鎖）間隔[0127]にあります。
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.
送信者は、TYPE 5単位を利用することができます。それが最低限の複雑さを追加し、ストリーミングセッションの堅牢性を高める可能性があるため、すべての受信機は、TYPE 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).
（1回以上使用されている場合）、動的SIDX値は、（一度だけ使用している場合）のいずれかのセッションの全期間の間、アクティブのままかの異なる間隔です。
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の最大ダイナミックSIDXsとして使用されることを可能にすることを選択する場合、新しいサンプル記述を有する任意の並べ替えられたパケットは、機構は失敗するであろう。例えば、受信された最後のパケットは、その後、SIDX = 6以外の全ての127個の値が「アクティブ」であろうSIDX = 5である場合。並べ替えパケットは新しい説明、SIDX = 9で到着した場合さて、それは誤ってSIDX = 9であるため、その瞬間に、廃棄された「アクティブ」とアクティブなサンプル記述が再書かれてはならないとしてマークされます。そのため、「ガードインターバル」を導入しました。このガードインターバルは、ほとんどの時間指定テキストのアプリケーションは、おそらく（合計で）セッション中に64未満のサンプルの説明が必要になりますが、64に任意の時点でアクティブなSIDXsの数を減らすことができ、より必要性を処理するために、ラップアラウンドメカニズムは、ここで記述されています。
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.
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がアクティブなサンプル記述の範囲を更新することを最後に受信したとします。最後に受信されたサンプル記述のSIDXことX.レットZから[0127]、および異なる：Yは、動的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.
まずは、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.間隔内の任意のSIDX [X + 1つのモジュロ（128）は、X + 64モジュロ（128）]を非アクティブとしてマークされ、そして任意の対応するサンプル記述を削除します。区間[X + 65モジュロ（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モジュロ（128）、X + 64モジュロ（128）]次に、X = Zを設定するサンプル記述を格納し、ステップ3に行きます。
b. Else, Z must be in the interval [X+65 modulo(128), X], thus:
B。さもなければ、Zは、したがって、[X + 65モジュロ（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 =区間[0127]に送信することが許可されています。 [64..127]は、現在のアクティブセットとSIDX = 0が送信される場合、例えば、新しいサンプル記述が定義されている（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値は、相補区間[69127]にあるプラス
[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.
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.
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").
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.
TYPE 5単位で搬送されるようれるstsdボックス内の「サイズ」フィールドの（符号なし）の32ビットは、サンプル記述の長さ（バイト単位）を表します。一方、TYPE 5単位のLENフィールドは16ビットに制限されています。したがって、[バイト]「サイズ」の値は、（^ 16-1-3 2）よりも大きい場合、サンプル記述は、このペイロード形式でストリーミングすることがないもの。サンプル記述の断片化が定義されていないので、この場合に定義された拡張機構（サンプル記述のサイズが約200のバイトまで、典型的に）、存在しません。注：3つの5ヘッダフィールドがLEN値に含まれるTYPEを占めます。
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.
ボックス（STTS）をサンプルにデコード時間からO SDUR。 「サンプルデルタ」フィールドの（符号なし）の32ビットはSDURを計算するために使用されます。 SDURフィールドのみが3バイト長であるので、期間を有するテキストサンプルは、[秒]（2 ^ 24-1）/（タイムスタンプclockrate）よりも大きい値を直接ストリーミングすることはできません。解決策は単純です：対応するテキストサンプルのコピーが送付されなければなりません。連続表示が保証されるように、ひとつのサンプルが送信されていたかのように、これにより、タイムスタンプ及び持続時間値を調整します。すなわち、タイムスタンプTSと持続時間SDUR有するサンプルは、TS1の=のTS、TS2 = TS1 + SDUR1、及びSDUR = SDUR1 + SDUR2ことは、タイムスタンプTS1とTS2と持続時間SDUR1とSDUR2を有する二つのサンプルとして送信することが可能です。
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.
サンプルサイズボックス（stsz）からOテキストサンプル長。 「サンプルサイズ」または（試料サイズは固定または可変であるかに応じてそれらのいずれかの）「エントリサイズ」の（符号なし）の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
KEY：TBC =テキスト文字列バイトカウントBOM =バイトオーダーマーク
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).
TYPE 1単位ヘッダ内のLENフィールドがあるので、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.
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).
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値は、使用順序で割り当てられなければならない、そしてそれは非アクティブに設定された後、任意のサンプル記述を使用しなければならない場合には、再送信され、新たな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.
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.
3GPファイルに格納されているように、1型ユニットの場合、TLENの値は、テキストサンプルのテキスト文字列の前に文字列のバイト数から抽出されます。 UTF-16エンコーディングを使用する場合は、2（2）より多くのバイトがBOMを排除するために、事前にこのバイト数から控除する必要があります。図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時間指定テキストアプリケーションは、低ビットレートで動作することが期待されています。この事実は、時限テキストサンプル（典型的には、1つのまたは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のテキスト文字列は文字境界で分割しなければなりません。 TYPE 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.
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は、パケット損失、すなわち、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をテキストサンプルを断片化の追加要件は、改質の開始（セクション4.1.4参照）TYPE 3単位を使用しなければならない、すなわち、その目的のために定義されたペイロード・ヘッダを使用して示さなければならないことです。これは、限り、二つ以上の連続したパケット損失がないよう修飾子の開始を検出するための受信機を可能にします。
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.
同じテキストサンプルに所属するユニットは同じタイムスタンプを持たなければなりません。彼らはいずれかの特定のテキストサンプルの一部ではないので、TYPE 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.検索、すなわち、その時点で利用可能になったものと同一のテキストサンプルまたはサンプル記述に属するユニット。同じサンプルのいくつかの単位が繰り返される場合は、そのうちの一つだけを使用しなければなりません。繰り返しの単位は、同じタイムスタンプおよびTOTAL / THISに対して同じ値を有するものです。
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.
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.チェックは、テキストサンプルからのユニットのいずれかが欠落しているかどうかを設定します。これは、TOTALこのフィールドを使用して行われます。 TOTALフィールドは、テキストサンプルから作成されたどのように多くの断片を示しており、このフィールドは、テキストサンプルでは、このフラグメントの位置を示しています。この操作の結果として、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.
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。一つ以上のフラグメントが不足している：このフラグメントは、テキスト文字列または修飾子に属しているかどうかを確認してください。 TYPE 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.
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。第三の可能性は、修飾またはテキスト文字列が完全に受信されたかどうかを識別することができないということです。サンプルに加え、次または前のパケットのTYPE 3ユニットが失われた場合、失われた一方または両方のパケットが修飾子に属している場合や、一部欠落しているテキスト文字列がある場合、RTP受信機が知る方法はありません。繰り返し、FEC、再送信、またはセクション4.6あたりなど、他の保護メカニズムは、このような状況を回避することをお勧めします。
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）は、ゼロ又はそれ以上の全体のテキストサンプル（TYPE 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.
ゼロまたは1つ修飾断片続い2.ゼロ以上のサンプル記述タイプ3又はタイプ4の少なくとも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.
0または1 TYPE 3単位続くゼロまたは1つのテキスト文字列フラグメント（タイプ2）、続いて3ゼロ以上のサンプル記述、。 TYPE 2ユニットとTYPE 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サンプル記述は、任意の非TYPE 5単位の発生前総計ペイロードに置かなければなりません。
o Correct reception of TYPE 5 units is important since their contents may be referenced by several other units in the stream.
その内容は、ストリーム内のいくつかの他のユニットによって参照することができるので、O TYPE 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.
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.
TYPE 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.
第1型部は、RTPタイムスタンプを受信した：第一の構成については、O。後続TYPE 1単位のタイムスタンプは、サンプル期間とタイムスタンプ、前TYPE 1単位の両方を添加することによって得られなければなりません。
o For the second and third configuration, all units, TYPE 2, 3, and 4, MUST receive the RTP timestamp.
O第二及び第三の構成、すべてのユニット、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つだけのテキストサンプルのいくつかのフラグメントを含むかもしれません。それがない場合には、正確に一つのTYPE 2ユニット3ユニットが同じペイロードで許可され、正確に一つのタイプが続きます。これは、明示的に同じRTPペイロード内の異なる試料の結合フラグメントを禁止RFC 3640 [12]、セクション2.4、に沿ったものです。この特殊なケースでは、何のタイムスタンプの計算を必要としない、ということに注意してください。つまり、両ユニットの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 + SDUR1 <TS3を保持している場合、タイムスタンプTS1とTS3および期間SDUR1とSDUR3を持つ2つのテキストサンプルは、連続していません。これに対する解決策は、TS2 + SDUR2 = TS1 + SDUR1 + SDUR2 = TS3ことは、それらの間の持続時間SDUR2と空TYPE 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
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に、4つのテキストサンプル（TS4を介してTS1は）は、3つのRTPパケットを使用して送信されます。これらの構成は、5 TYPEヘッダーが使用されているかを示すために選択されています。また、最後のテキストサンプルのための3つの異なる可能性は、TS4は、示されている：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
図10から11を選択したペイロードを図
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の通りPAYLOAD 3の場合を除く）は、ペイロード内のユニットの前の時間の合計。したがって、我々は持っています：
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タイムスタンプの両方を有することに留意されたいです。
ts(#5) = rtpts2
TS（＃5）= rtpts2
ts(#6) = ts(#7) = rtpsts2 = rtpts3
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つのTYPE 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において、二つのタイプ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
タイプ5およびタイプ1部を運ぶ図13.アン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に、サンプル記述とTYPE 1ユニットが集約されます。 TYPE 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において、テキストサンプルは、三個のRTPパケットに分割されます。図14では、テキスト文字列が大きく、全体のパケット長を取ります。図15において、同一のテキストサンプルの二つの断片を運ぶための唯一の可能性は、（4.6節で設定3を参照）が示されています。図16に示されている最後のパケットは、最後の修飾断片、TYPE 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
TYPE 2ユニットを搬送図15アンRTPパケットタイプ3部
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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エレメンタリストリームの種類の一つは、また、ISO / IEC 14496から17として知られているMPEG-4パート17 [26]、で指定されたMPEG-4時限テキストストリーム、です。 MPEG-4時限テキストストリームは、3GPP TS 26.245で指定されるように、3GPP時限テキストデータを運ぶことが可能である[1]。
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.
RFC 3640と、このペイロードフォーマットとの間の相互運用性を保証するために、MPEG-4時限テキストストリームは、意図的に構築されます。これは、時間指定テキストを運ぶ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
図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 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.
時間指定テキストストリームを輸送するためのRFC 3640には、「streamType」パラメータ値は0x0Dのに設定され、「設定」の「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
RFC 3640に図17の関係
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テキストはUTF-8余分なフレーミングとT.140 [24]で指定されるように符号化されます。 T.140で指定されT140blockは、一つ以上のT.140コード要素を含みます。コード要素は、このような「ニューライン」、「割り込み」、「文字列ターミネーター」、または「文字列のスタート」などの制御配列です。ほとんどのT.140コード要素は、単一のISO 10646 [25]の文字ですが、いくつかは、複数の文字列です。各文字はUTF-8でエンコードされた[18]一個の以上のオクテットにあります。
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.
完全なペイロードの場合のように、単一の繰り返し単位が正確に最初の送信で送信同じ単位に一致しなければなりません。即ち、フラグメント化が必要とされる場合は、それぞれのテキストサンプルに対して一度だけ実行されるものとします。唯一その後、受信機は、オリジナルのテキストサンプルを再構成するために既に受信及び繰り返し単位を使用することができます。 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.
With repetition, repeated units resolve to the same timestamp as their originals. Where redundant units are available, only one of them SHALL be used.
繰り返しでは、繰り返し単位は、そのオリジナルと同じタイムスタンプに解決します。冗長ユニットが利用可能な場合、それらの一方のみを使用しなければなりません。
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).
全体RTPペイロードが繰り返される場合、O、RTPヘッダ内のすべてのペイロード固有のフィールド（M、TSおよびPTフィールド）RTPに準拠するようにインクリメントされなければならないシーケンス番号（フィールドTOTAL以外は元の値を維持しなければなりません/これは）異なるシーケンス番号を持つ断片を再度組み立てることができます。
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.
表示領域にテキスト・トラックの位置とサイズを交渉するために使用されるパラメータは、これらは、テキストトラック、その変換値、「TX」と「TY」の「幅」および「高さ」である図18に示されているが、そしてその「層」や、ユーザーへの近接。
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
このレイアウト情報は、セッションアナウンスまたはオファーに/アンサー（O / A）交換中に、例えば、セッションの開始前に、信頼できる形で伝達されなければなりません。信頼性の高いトランスポートの例は、SDPのために使用される帯域外チャネルであってもよいです。セクション8と9提供
details on the mapping of these parameters to SDP descriptions and their usage in O/A.
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のテキストとビデオトラックの位置が決定されなければなりません。この目的のために、[9] SMILを使用することができます。
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は、それらのファイルのそれぞれに表示して領域を割り当て、それらの領域内のトラックを配置します。一般に、SMILに、一つのトラック（またはストリーム）の位置は、他のトラックに対して表されます。これは、左上隅には、すべての翻訳オフセットのためのリファレンスです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によって割り当てられた元のトラックヘッダ情報は、唯一、その領域内の各トラックのために使用されることにも留意されたいです。それらは、固有のメディアプロパティを表すしたがって、SMILのシーン記述を用いた場合でも、トラックヘッダ情報片が、いずれにせよ送信されるべきです。詳細については、[27]で3GPP SMIL言語プロファイルを参照してください。
In a 3GP file, within the Track Header Box (tkhd):
3GPファイルには、トラックヘッダボックス（tkhd）内：
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 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時間指定テキストコーデックのメディアサブタイプは規格木から割り当てられます。このペイロード形式が登録されているトップレベルのメディアタイプは「ビデオ」です。この登録は、RFC 3555 [28] [29]で定義されたテンプレートを使用して、以下に行われます。
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.
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）のサポート下位互換性のあるバージョンのリストが含まれています（そして送ることをいとわないのと同じであること）。最初の値は、受信（または送信することが好ましい）が好ましい値です。最初の値は、代替として使用すべきバージョンのカンマ区切りのリストが続いてもよいです。順序は、最初に最も好ましく、最も好ましいの最後であり、有意義です。各エントリは、フォーマット「紫」がリリースと「XI」と「YI」の数は、3GPP仕様のバージョン（即ち、vZi.xi.yi）から取られている紫（* 256 + YI XI）を有します。例えば、3GPP TS 26.245 5月v6.0.0、紫（XI * 256 +イル）= 6について（0）、バージョンの値が "60" です。 （「60」の値紫= 6、（XI * 256 +イル）= 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.
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.
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でエンコードされたエントリのカンマ区切りのリストが含まれています。このリストのエントリは、任意の特定の順序に従うことができ、リストは空であってはなりません。各エントリは、そのために、8ビットの符号なし整数として（静的）SIDX値とそのSIDXのための（静的）サンプル記述の連結上にbase64エンコーディングを実行した結果です。サンプル記述エントリのフォーマットは、3GPP TS 26.245リリース6およびそれ以降のリリースに見出すことができます。すべてのサーバーとクライアントは、このパラメータを理解する必要があり、その中に含まれるサンプル記述（複数可）を使用してことができなければなりません。 base64エンコードの詳細については、[6] RFC 3548を参照してください。
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ビット符号なし整数の10進表現です。このパラメータの説明のために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ビット符号なし整数の10進表現です。このパラメータの説明のために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ビット符号なし整数の10進表現です。
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ビット符号なし整数の10進表現です。
Encoding considerations:
エンコードの考慮事項：
This media type is framed (see Section 4.8 in [29]) and
partially contains binary data.
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.
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.
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]です。 RFC 3839 [31]により登録さ3GPファイルは、メディアタイプのビデオ/ 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.
Magic number(s): None.
マジックナンバー（S）：なし。
File extension(s): None.
ファイルの拡張子（秒）：なし。
Macintosh File Type Code(s): None.
Macintoshのファイルタイプコード（S）：なし。
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Jose Rey, jose.rey@eu.panasonic.com
Yoshinori Matsui, matsui.yoshinori@jp.panasonic.com
Audio/Video Transport Working Group.
Intended usage: COMMON
意図している用法：COMMON
Authors: Jose Rey Yoshinori Matsui
著者：ホセ・レイ義則松井
Change controller: IETF Audio/Video Transport Working Group delegated from the IESG.
変更コントローラ：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>
M =ビデオ<ポート番号> RTP / <RTPプロファイル> <ダイナミックペイロードタイプ>
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」）およびタイムスタンプclockrate「レート」（推奨1000ヘルツまたは他の値）がエンコーディング名および速度などのSDPの「a = rtpmap」ラインに移動し、それぞれ：
a=rtpmap:<payload type> 3gpp-tt/1000
= rtpmap：<ペイロードタイプ> 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」はセミコロンで区切られたパラメータ=値のペアとしてメディアタイプ文字列から直接コピーすることによって、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"、 "層"、 "tx3g"、 "幅"、 "高さ"、 "MAX-W" と "MAX-H" SDPに行く "=の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.
このセクションでは、オファー/アンサー内本書で定義されたSDPパラメータの意味は、[13]のコンテキストを説明します。
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.
また、パラメータの意味は、使用されている方向に応じて異なる場合があります。次のセクションでは、「<方向性>オファーが」ストリームセットに<方向性>が含まれているのオファーを意味します。 <方向性>の値がsendonlyで、がrecvonly、SENDRECVかかる場合があります。同様の考察が答えを適用されます。例えば、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.宣言パラメータ：申出人と回答は、それらが（sendonlyの）着信（SENDRECV / recvonlyで）または送信ストリームに使用する値を宣言する。オファー側とアンサーは異なる値を使用してもよいです。
a. "tx", "ty", and "layer": These are parameters describing
where the received text track is placed. Depending on the
directionality:
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.
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の申し出に表示され、sendonlyの答えに現れなければなりません。 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.
表示機能、「MAX-H」と「MAX-W」、着信ストリームのためのテキスト・トラック（テキスト表示領域）の最大サイズを示す「TX」と「TY」値を記述する2.パラメータ（図18を参照してください）。 「MAX-H」と「MAX-W」、「TY」はしたがって、（セクション9.3の例を参照）sendonlyのオファーと回答をどこにSHALLを除く、入力ストリームを指す「TX」およびすべてのオファーと回答に含まれなければなりません存在しません。
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.
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.対称パラメータ：「率」、タイムスタンプclockrateは、このクラスに属します。対称パラメータは答えに逐語的にこだましなければなりません。それ以外の場合は、ストリームが削除またはセッションを拒絶しなければなりません。
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.
KEY：M手段oが存在しなければなりません。 O M手段（例えば提案された値など）が存在してもよいです。該当する場合はO（M）または（m）は、MUSTまたはMAYを意味します。 Oハイフン（「 - 」）パラメータが存在してはならないことを意味します。
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-と」：ストリームを送信する答えは答えの「高さ」と「幅」の値は、公開買付者の者が能力を合図と互換性があることを保証しなければなりません。
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）ストリームについて、最初の値は、送信（および受信）のために好ましいものです。回答は一つの値を選択して解答でそれを返さなければなりません。回答を受信すると、提供者は、（sendonlyのとSENDRECV）を送信し、そのバージョンを使用して（がrecvonlyとの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（sendonlyのSENDRECV用と）「高さ」、「幅」、および「tx3g」のために、マルチキャスト申し出は、参加者が送信するために使用しなければならないこれらのパラメータのどの値を指定します。ストリームが受け入れられた場合このように、回答は、（もし存在するならば、また「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:
バージョン取り扱いについて○：
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」に記載されているバージョンのいずれかがサポートされているとして、マルチキャストの申し出を受け入れることができます。ストリームが受け入れられた場合、ユニキャストでは、オファー側は、この選択したバージョンに提供される流れを変えないものとは違って、新しい拡張をサポートしない他のセッションの参加者があるかもしれないので、したがって、回答は、その好ましいバージョンを選択する必要がありますが。したがって、異なるセッション参加者が異なる下位互換性メディアフォーマットのバージョンを使用して終了してもよいです。マルチキャストオファーはすべての参加者がセッションの同じビューを持つようにするために、バージョンの限られた数が含まれていることが推奨されます。これは、セッション作成者の責任です。提供されたバージョンのいずれもサポートされていない場合は、ストリームを撤去しなければならないか、セッションが拒否されました。代替の非互換性のあるバージョンが提供されている場合この場合も、これは、異なるペイロード・タイプを使用して実施されねばなりません。
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
- > 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
M =ビデオ<ポート> RTP / AVP 98 = rtpmap：98 3GPP-TT / 1000 A =のfmtp：98 TX = 100。 TY = 100;層= 0。高さ= 80。幅= 100。 MAX-H = 120。 MAX-W = 160。 sver = 6256,60; tx3g = 81 ... A = SENDRECV
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
M =ビデオ<ポート> RTP / AVP 98 .. A = rtpmap：98 3GPP-TT / 1000 A =のfmtp：98 TX = 100。 TY = 95;層= 0。高さ= 90。幅= 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を提供しています。この場合、回答の「MAX-H」と「MAX-W」に申出の「高さ」と「幅」と互換性があります。そうでなければ、回答はこのストリームを削除しなければならない、との申し出人のアカウントに回答者の能力を取って新しいプランを発行する必要があります。これは、「MAX-H」と「MAX-W」否定内で表されるようにそれらの少なくとも1つが、回答者の能力と一致するように、複数のペイロードタイプが最初のオファーに存在している場合にのみ可能です。最大値はプランに合図以内に回答のテキストボックスの寸法が収まることにも注意してください。最後に、回答時限テキスト形式のバージョン60を使用することを選択します。
For recvonly:
がrecvonlyの場合：
Offerer -> Answerer
申出人 - >回答
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
M =ビデオ<ポート> RTP / AVP 98 = rtpmap：98 3GPP-TT / 1000 A =のfmtp：98 TX = 100。 TY = 100;層= 0。 MAX-H = 120。 MAX-W = 160。 sver = 6256,60 = Aがrecvonly
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
M =ビデオ<ポート> RTP / AVP 98 .. A = rtpmap：98 3GPP-TT / 1000 A =のfmtp：98 TX = 100。 TY = 100;層= 0。高さ= 90。幅= 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」ストリームのプロパティが含まれていません。したがって、これらを認める回答コピー「TX」、「TY」、および「層」値。この特別な場合に「TX」と「TY」（及び「層」）、受信したストリームに、しかし、送信されたストリームには適用されないため、「MAX-H」と「MAX-W」は、答えには存在しません。オファー側とアンサーは非常に異なる表示サイズを持っていた場合にも、回答者の能力を表現することはできません。上記及び50×50ディスプレイと回答するための一例では、変換値が範囲外既にあります。
For sendonly:
sendonlyの場合：
O -> A
- > 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
M =ビデオ<ポート> RTP / AVP 98 = rtpmap：98 3GPP-TT / 1000 A =のfmtp：98 TX = 100。 TY = 100;層= 0。高さ= 80。幅= 100。 sver = 6256,60; tx3g = 81 ... A = sendonlyの
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
M =ビデオ<ポート> RTP / AVP 98 .. A = rtpmap：98 3GPP-TT / 1000 A =のfmtp：98 TX = 100。 TY = 100;層= 0。高さ= 80。幅= 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".
「MAX-H」と「MAX-wは」提供に存在しないことに注意してください。また、（したがって、「TX」、「TY」、「高さ」、「幅」、および「層」エコー）されたとして、この答えを、解答者は申し出を受け入れるだろうし、さらにその機能について、オファーを知らせる：「MAX- H」と "MAX-W"。
Another possible answer for this case would be:
このような場合のための別の可能な答えは次のようになります。
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
M =ビデオ<ポート> RTP / AVP 98 .. A = rtpmap：98 3GPP-TT / 1000 A =のfmtp：98 TX = 120。 TY = 105。層= 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.
このドキュメントのセクション8で指定されているIANAはメディアタイプのメディアサブタイプ名「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.
具体的には、攻撃者が古いサンプル記述、即ち、リプレイ攻撃にパケットを繰り返すことによって、クライアントにおけるアクティブサンプル記述の現在のセットを無効にすることができます。これは、まったく表示されている場合、テキストの表示は、破損してしまうことを意味します。攻撃の別の形態は、その境界異なる試料の長さ（SLEN）を搬送原稿（LENによって示されるように）、またはその断片の正確な境界と一致しない冗長フラグメントを、送信から構成されてもよいです。これは、デコーダがクラッシュする可能性があります。
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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[4]ハンドレー、M.および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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ローゼンバーグ、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]パーキンス、C.およびO.ホドソン、 "ストリーミングメディアの修理のためのオプション"、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.、マグリュー、D.、Naslund、M.、カララ、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]レイ、J.、レオン、D.、宮崎、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]ファンデミーア、J.、マッキー、D.、スワミナサン、V.、歌手、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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[14]ハンドレー、M.、パーキンス、C.、およびE.ウィーラン、 "セッション告知プロトコル"、RFC 2974、2000年10月。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[15] SchulzrinneとH.とラオと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）、V 6.1.0 TS 26.234、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]ホフマン、P.及び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]フリードマン、T.、カセレス、R.、およびA.クラーク、 "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.
"RTCPベースのフィードバック（RTP / AVPF）の拡張RTPプロファイル" [21]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ、進歩、2004年8月ワーク。
[22] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, May 2000.
[22]ヘルストローム、G.、 "テキストの会話のためのRTPペイロード"、RFC 2793、2000年5月。
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[23]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[24] ITU-T Recommendation T.140 (1998) - Text conversation protocol for multimedia application, with amendment 1, (2000).
改正1、（2000）にマルチメディアアプリケーションのためのテキスト会話プロトコル - [24] ITU-T勧告T.140（1998）。
[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言語プロファイル、（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]解放され、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.
、RFC 3839、2004年7月、 "第3世代パートナーシッププロジェクト（3GPP）のマルチメディアファイルのMIMEタイプの登録" [31]カスターニョ、R.とD.歌手、。
This section provides a coarse overview of the 3GP file structure, which follows the ISO Base Media file Format [2].
このセクションでは、ISOベースメディアファイルフォーマット[2]以下の3GPファイル構造の粗大な概要を提供します。
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.
トラックヘッダボックスは、トラックが、この場合には、セッション中にストリーミングされるテキストですシングルトラックの特性を指定します。正確に一つのトラックヘッダボックスは、トラックのために存在しています。このような空間的なレイアウト（幅と高さ）、ビデオ変換行列、および層番号として、トラックに関する情報が含まれています。これらの情報は、セッションの間に必須と静的（即ち、一定）であるので、それらは、従来の任意のテキストサンプルの送信に送信されなければなりません。
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秒間に通過する時間単位、即ち、毎秒サイクルまたはヘルツの数を含んでいます。メディア情報ボックスは、トラック内のメディアサンプルのすべての時間とデータのインデックスを含むサンプルテーブルボックス（STBL）を含みます。このボックスを使用して、時間にサンプルを配置すると、そのタイプ、サイズ、コンテナを決定することが可能であり、そのコンテナへのオフセット。サンプル表ボックス内に、我々はチャンクにボックス（サンプル時間を見つけるためのstts、）、サンプルサイズボックス（stsz）、およびサンプルをサンプリングするサンプル記述ボックス（サンプル記述を見つけるためのれるstsd）、デコード時間を見つけることができますボックス（サンプル記述インデックスを見つけるための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.
著者らはまた、Idnits、Webサービスのための無料で一般に公開（このドキュメントのASCIIの図面に使用）JavE ASCIIエディタとヘンリクLevkowetzためマルクスGebhardに感謝したいと思います。
Authors' Addresses
著者のアドレス
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ホセ・レイパナソニックR＆DセンタードイツGmbH社Monzastr。図4c D-63225ランゲン、ドイツ
EMail: jose.rey@eu.panasonic.com Phone: +49-6103-766-134 Fax: +49-6103-766-166
メールアドレス：jose.rey@eu.panasonic.com電話：+ 49-6103-766-134ファックス：+ 49-6103-766-166
Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006 Kadoma Kadoma-shi, Osaka, Japan
よしのり まつい まつした えぇｃｔりｃ いんづｓｔりあｌ こ。、 ＬＴＤ。 １００６ かどま かどまーし、 おさか、 じゃぱん
EMail: matsui.yoshinori@jp.panasonic.com Phone: +81 6 6900 9689 Fax: +81 6 6900 9699
メールアドレス：matsui.yoshinori@jp.panasonic.com電話：+81 6 6900 9689ファックス：+81 6 6900 9699
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。