RFC4396 日本語訳
4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP)Timed Text. J. Rey, Y. Matsui. February 2006. (Format: TXT=155421 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rey
Request for Comments: 4396 Y. Matsui
Category: Standards Track Panasonic
February 2006
コメントを求めるワーキンググループJ.レイの要求をネットワークでつないでください: 4396年のY.松井カテゴリ: 標準化過程パナソニック2006年2月
RTP Payload Format
for 3rd Generation Partnership Project (3GPP) Timed Text
第3世代パートナーシッププロジェクト(3GPP)のためのRTP有効搭載量形式はテキストを調節しました。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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(第3Generation Partnership Project)の調節されたテキストの送信にRTPペイロード形式を指定します。 3GPPは調節しました。テキストは3GPファイルにおける定義されたストレージがある時間で裏打ちされて、飾り付けをされたテキストメディア形式です。 調節されたTextをオーディオ/ビデオコンテンツに連動して、キャプションや、背文字や、マルチメディアプレゼンテーションなどの応用で使用できます。 以下のセクションでは、調節されたテキストを流すという問題は扱われます、そして、ストリーミングの3GPPがRTPの上でテキストを調節したので、ペイロード形式は指定されます。
Rey & Matsui Standards Track [Page 1] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[1ページ]RFC4396有効搭載量形式
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
1. 序論…3 2. 動機、要件、およびデザイン原理…3 2.1. 動機…3 2.2. 3GPPの基本的な部品はテキストメディア形式を調節しました…4 2.3. 要件…5 2.4. 制限…6 2.5. 原理を設計してください…7 3. 用語…10 4. 3GPPのためのRTP有効搭載量形式はテキストを調節しました…12 4.1. 有効搭載量ヘッダー定義…13 4.1.1. 一般的な有効搭載量ヘッダーフィールド…15 4.1.2. 1個のヘッダーをタイプしてください…17 4.1.3. 2ヘッダーをタイプしてください…20 4.1.4. 3ヘッダーをタイプしてください…23 4.1.5. 4ヘッダーをタイプしてください…24 4.1.6. 5ヘッダーをタイプしてください…25 4.2. サンプル記述のバッファリング…25 4.2.1. ダイナミックなSIDX巻きつけて着るドレスメカニズム…26 4.3. 3GPで有効搭載量ヘッダー値を見つけるのはファイルされます…28 4.4. 調節されたテキストのサンプルの断片化…31 4.5. 受信機でテキストのサンプルを組み立て直します…33 4.6. 集合有効搭載量に関して…35 4.7. 有効搭載量の例…39 4.8. RFC3640との関係…43 4.9. RFC2793との関係…44 5. 立ち直りの早い輸送…45 6. 混雑コントロール…46 7. 場面記述…47 7.1. テキストレンダリング位置と構成…47 7.2. SMIL用法…48 7.3. 3GPの調査結果レイアウト値はファイルされます…48 8. 3GPPはテキストメディアタイプを調節しました…49 9. SDP用法…53 9.1. SDPに写像します。53 9.2. SDP申し出/答えモデルのパラメタ用法…53 9.2.1. ユニキャスト用法…54 9.2.2. マルチキャスト用法…57 9.3. 例に提供するか、または答えてください…58 9.4. Offer/答えにおける外のパラメタUsage…60 10. IANA問題…60 11. セキュリティ問題…60 12. 参照…61 12.1. 標準の参照…61 12.2. 有益な参照…61 13. 3GPの基礎は構造をファイルします…64 14. 承認…65
Rey & Matsui Standards Track [Page 2] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[2ページ]RFC4396有効搭載量形式
1. Introduction
1. 序論
3GPP timed text is a media format for time-lined, decorated text specified in the 3GPP Technical Specification TS 26.245, "Transparent end-to-end packet switched streaming service (PSS); Timed Text Format (Release 6)" [1]. Besides plain text, the 3GPP timed text format allows the creation of decorated text such as that for karaoke applications, scrolling text for newscasts, or hyperlinked text. These contents may or may not be synchronized with other media, such as audio or video.
3GPPは調節しました。テキストは3GPP仕様書TS26.245で指定された、時間で裏打ちされて、飾り付けをされたテキスト、「終わりから終わりに対するパケットわかりやすい切り換えられたストリーミングのサービス(PSS)」のためのメディア形式です。 「調節されたテキスト形式(リリース6)」[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.
このドキュメントの目的は3GPPを流す手段を提供するのがRTP[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はペイロードヘッダー、テキストのサンプルのための断片化と再アセンブリ規則、ペイロード集合のための規則、およびこのドキュメントの関係をRFC3640[12]とRFC2793[22]に指定します。 セクション5は、いくつかの簡単な体系を立ち直りの早い輸送に指定して、他の可能なメカニズムに指針を与えます。セクション6は、混雑がコントロールであると扱います。 セクション7は場面記述を指定します。 セクション8はメディアタイプを定義します。 セクション9はOffer/答えモデル[13]に用法を含むユニキャストとマルチキャストセッションとしてSDPを指定します。 セクション10と11は、IANAとセキュリティが問題であると扱います。 セクション12は参照をリストアップします。 3GP File Structureの基礎がセクション13にあります。
2. Motivation, Requirements, and Design Rationale
2. 動機、要件、およびデザイン原理
2.1. Motivation
2.1. 動機
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 Transparent Endから終わりへのPacketによって切り換えられたStreaming Services(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ペイロード形式の不足のために、3GPPを流すのがRTPの上でテキストコンテンツを調節したのは、可能ではありません。
This document specifies such a payload format.
このドキュメントはそのようなペイロード形式を指定します。
Rey & Matsui Standards Track [Page 3] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[3ページ]RFC4396有効搭載量形式
2.2. Basic Components of the 3GPP Timed Text Media Format
2.2. 3GPPの基本的な部品はテキストメディア形式を調節しました。
Before going into the details of the design, it is necessary to know how the media format is constructed. We can identify four differentiated functional components: layout information, default formatting, text strings, and decoration. In the following, we shortly explain these and match them to their designations in a 3GP file:
デザインの詳細を調べる前に、メディア形式がどのように構成されるかを知るのが必要です。 私たちは4個の差別化された機能部品を特定できます: レイアウト情報、デフォルト形式、テキスト文字列、およびデコレーション。 以下では、私たちは、3GPファイルにおける彼らの名称にまもなく、これらについて説明して、それらを合わせます:
o Initial spatial layout information related to the text
strings: These are the height and width of the text region
where text is displayed, the position of the text region in
the display, and the layer or proximity of the text to the
user. In 3GP files, this information is contained in the
Track Header Box (3GP file designations are capitalized for
clarity).
o 初期の空間的なレイアウト情報はテキスト文字列に関連しました: これらは、ユーザへのテキストのテキストが表示されるテキスト領域か、ディスプレイにおけるテキスト領域の位置と、層か近接の高さと幅です。 3GPファイルでは、この情報がTrack Header Boxに含まれています(3GPファイルの指定が明快ために大文字で書かれます)。
o Default settings for formatting and positioning of text: style
(font, size, color,...), background color, horizontal and
vertical justification, line width, scrolling, etc. For 3GP
files, this corresponds to the Sample Descriptions.
o テキストの形式と位置決めのための既定の設定: スタイル(フォント、サイズは着色する…)、背景色、水平で垂直な正当化、線幅、スクロールなど 3GPファイルに関しては、これはSample記述に対応しています。
o The actual text strings: encoded characters using either UTF-8
[18] or UTF-16 [19] encoding.
o 実際のテキスト文字列: UTF-8[18]かUTF-16[19]コード化のどちらかを使用することでキャラクタをコード化しました。
o The decoration: If some characters have different style,
delay, blink, etc., this needs to be indicated. The
decoration is only present in the text samples if it is
actually needed. Otherwise, the default settings as above
apply. In 3GP files, within each Text Sample, the decoration
(i.e., Modifier Boxes) is appended to the text strings, if
needed. At the time of writing this payload format, the
following modifiers are specified in the 3GPP timed text media
format specification [1]:
o デコレーション: 何人かのキャラクタに異なったスタイル、遅れ、明滅などがあるなら、これは、示される必要があります。 それが実際に必要であるなら、デコレーションは単にテキストのサンプルに存在しています。 さもなければ、上の既定の設定は適用されます。 3GPファイルでは、必要であるなら、各Text Sampleの中では、デコレーション(すなわち、Modifier Boxes)をテキスト文字列に追加します。 これを書いている時点でこのペイロード形式、以下の修飾語は指定されて、3GPPでは、テキストメディア書式仕様[1]に調節されていたということです:
- text highlight
- highlight color
- blinking text
- karaoke feature
- hyperlink
- text delay
- text style
- positioning of the text box
- text wrap indication
- テキストハイライト--テキスト--カラオケの特徴--ハイパーリンク--テキスト遅れ--テキストスタイル--テキストボックスの位置決め--テキスト包装指示を明滅させて、色を目立たせてください。
Rey & Matsui Standards Track [Page 4] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[4ページ]RFC4396有効搭載量形式
2.3. Requirements
2.3. 要件
Once the basic components are known, it is necessary to define which requirements the payload format shall fulfill:
基本的なコンポーネントがいったん知られていると、ペイロード形式がどの要件を実現させるだろうかを定義するのが必要です:
1. It shall enable both live streaming and streaming from a 3GP
file.
1. それはライブストリーミングと3GPファイルから流れる両方を可能にするものとします。
Informative note: For the purpose of this document, the
term "live streaming" refers to those scenarios where
the timed text stream is sent from a live encoder. Upon
reception, the content may or may not be stored in a 3GP
file. Typically, in live streaming applications, the
sender encapsulates the timed text content in RTP
packets following the guidelines given in this document.
At the receiving side, a buffer is used to cancel the
network delay and delay jitter. If receiver and sender
support packet loss resilience mechanisms (see Section
5), it may also be possible to recover from packet
losses. Note that how sender and receiver actually
manage and dimension the buffers is an implementation
design choice.
有益な注意: このドキュメントの目的について、「ライブストリーミング」という用語は調節されたテキスト小川が動いているエンコーダから送られるそれらのシナリオを参照します。 レセプションでは、内容は3GPファイルに保存されるかもしれません。 本書では与えられたガイドラインに従って、通常、送付者は、RTPパケットで動いているストリーミング・アプリケーションでは、調節されたテキストが内容であるとカプセル化します。 受信側では、バッファが、ネットワーク遅延と遅れジターを取り消すのに使用されます。 また、受信機と送付者が、パケット損失弾力がメカニズムであるとサポートするなら(セクション5を見てください)、パケット損失から回復するのも可能であるかもしれません。 送付者と受信機が実際に管理されて、寸法がバッファを管理するそれが実装デザイン選択であることに注意してください。
2. Furthermore, it shall be possible for an RTP receiver using this
payload format, and capable of storing in 3GP format, to obtain
all necessary information from the RTP packets for storing the
received text contents according to the 3GP file format. This
file may or may not be the same as the original file.
2. その上、それは、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.
有益な注意: 3GPファイル形式自体はISO基地のメディアFile Format推薦[2]に基づいています。 セクション13.1は3GPファイル構造に関する何らかの洞察を与えます。 さらに、セクション4.3と7.3は、ペイロードヘッダーに記入するのに必要である情報が3GPファイルでどこで見つけられるかを指定します。 ライブストリーミングの、そして、適切な値のために、[1]で説明される形式とユニットに応じるのは使用されるものとします。 必要であるところでは、本書では適切な値における明確化を与えます。
3. It shall enable efficient and resilient transport of timed text
contents over RTP. In particular:
3. それはRTPの上で調節されたテキストコンテンツの効率的で立ち直りの早い輸送を可能にするものとします。 特に:
a. Enable the transmission of the sample descriptions by both
out-of-band and in-band means. Sample descriptions are
important information, which potentially apply to several
text samples. These default formatting settings are
typically transmitted out-of-band (reliably) once at the
initialization phase. If additional sample descriptions
a。 バンドの外とバンドにおける手段によるサンプル記述の送信を可能にしてください。 サンプル記述は重要情報です(潜在的にいくつかのテキストのサンプルに適用されます)。 これらのデフォルト形式設定は初期設定段階でバンドの外(確かである)に一度通常伝えられます。 追加しているなら、記述を抽出してください。
Rey & Matsui Standards Track [Page 5] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[5ページ]RFC4396有効搭載量形式
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.
セッションの間に必要であることで、また、これらも、バンドの外に送られて、バンドであるかもしれません。 頼り無いのですが、例えば、SDPのために追加通信チャネルを確立することと対照的に頻繁にこれらを送るならサンプル記述を送るには、バンドにおけるトランスミッションは、より適切であるかもしれません。 また、それもバンドで出かけているチャンネルが入手できないかもしれないところとライブで流れるための場合で役に立ちます。そこでは、内容が先験的に知られていません。 したがって、ペイロード形式はバンドの外とバンドにおける、サンプル記述の送信を可能にするものとします。 セクション4.1 .6 バンドでサンプル記述を伝えるのにペイロードヘッダーを指定します。 セクション9はサンプル記述がどうSDPに写像されるかを指定します。
b. Enable the fragmentation of a text sample into several RTP
packets in order to cover a wide range of applications and
network environments. In general, fragmentation should be
a rare event, given the low bit rates and relatively small
text sample sizes. However, the 3GPP Timed Text media
format does allow for larger text samples. Therefore, the
payload format shall take this into account and provide a
means for coping with fragmentation and reassembly. Section
4.4 deals with fragmentation.
b。 さまざまなアプリケーションとネットワーク環境を含むためにテキストのサンプルの断片化をいくつかのRTPパケットに可能にしてください。 一般に、低ビット伝送速度と比較的小さいテキストサンプルサイズを考えて、断片化はめったにない事件であるべきです。 しかしながら、3GPP Timed Textメディア形式は、より大きいテキストのサンプルを考慮します。 したがって、ペイロード形式は、これを考慮に入れて、断片化に対処するための手段を提供して、再アセンブリされるものとします。 セクション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を見てください)。 より一般的な議論について、RFC2354[8]を参照してください。([8]はストリーム修理のために利用可能なメカニズムについて議論します)。
2.4. Limitations
2.4. 制限
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,
ペイロードヘッダーはRTPのためにサイズで最適化されました。 よく多くの未使用のビット運ぶ32ビットの(S)レンを使用する、SDUR、およびSIDXヘッダーフィールドの代わりに、それは、これらの分野のサイズを減少させるためにはデザイン選択です。 結果として、このペイロード形式は(テキスト)のサンプルとサンプル記述のサイズと持続時間に関して最大の値を減少させました。 これらの最大の値は3GPファイルに許容されたものと異なっています。そこでは、それらが、32ビット(未署名の)の整数を使用することで言い表されます。 いくつかの場合
Rey & Matsui Standards Track [Page 6] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[6ページ]RFC4396有効搭載量形式
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時間の1000Hzのタイムスタンプ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 encodingsに関係があります: ビッグエンディアンバイトオーダーに続くテキスト文字列の輸送だけがサポートされます。 詳細に関してセクション4.1.1を見てください。
2.5. Design Rationale
2.5. デザイン原理
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バイトの一般的なヘッダー(一般的な有効搭載量Header)はそれぞれのテキストサンプル(断片)タイプのための特定のヘッダーで続きました。 これらのヘッダーに続いて、テキストサンプル含有量は置かれます(セクション4.1.1と次の事柄)。 この構造は'ユニット'と呼ばれます。
The following units have been devised to comply with the
requirements mentioned in Section 2.3:
以下のユニットはセクション2.3で言及される要件に応じるために工夫されました:
a. A TYPE 1 unit that contains one complete text sample,
a。 1個の全文のサンプルを含むTYPE1ユニット
b. A TYPE 2 unit that contains a complete text string or a
fragment thereof,
b。 全文ストリングかそれの断片を含むTYPE2ユニット
Rey & Matsui Standards Track [Page 7] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[7ページ]RFC4396有効搭載量形式
c. A TYPE 3 unit that contains the complete modifiers or only
the first fragment thereof,
c。 完全な修飾語か1番目だけを含むTYPE3ユニットはそれについて断片化します。
d. A TYPE 4 unit that contains one modifier fragment other
than the first, and
d。 そして1番目を除いて、1つの修飾語を含むTYPE4ユニットが断片化する。
e. A TYPE 5 unit that contains one sample description.
e。 1つを含むTYPE5ユニットは記述を抽出します。
This 'unit' approach was motivated by the following reasons:
この'ユニット'アプローチは以下の理由によって動機づけられました:
1. Allows a simple classification of the text samples and
text sample fragments that can be conveyed by the
payload format.
1. ペイロード形式で伝えることができるテキストのサンプルとテキストサンプル断片の簡単な分類を許します。
2. Enables easy interoperability with RFC 3640 [12].
During the development of this payload format, interest
was shown from MPEG-4 standardization participants in
developing a common payload structure for the transport
of 3GPP Timed Text. While interoperability is not
strictly necessary for this payload format to work, it
has been pursued in this payload format. Section 4.8
explains how this is done.
2. RFC3640[12]で簡単な相互運用性を可能にします。 このペイロード形式の開発の間、関心は3GPP Timed Textの輸送のための一般的なペイロード構造を発生する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受信機が、テキストキャラクタのはっきりした数が損をしたのを見つけるのを可能にしません。 事実上、ペイロードヘッダーに含まれていた断片サイズは、[18][19]encodingsが使用したUTF-8/UTF-16が可変数の1キャラクタあたりのバイトもたらすので迷子になったキャラクタの数を見つけるのを手伝いません。
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"
「######現在のいくつかの######」
Rey & Matsui Standards Track [Page 8] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[8ページ]RFC4396有効搭載量形式
As opposed to:
以下と対照的に
"Some #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. 再アセンブリを断片化してください: テキストのサンプルを組み立て直すために、オフセット情報が必要です。 相殺されたキャラクタかバイトの代わりに、1バイト(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のように、通常低い層はこの情報を提供します)、それは相互運用性をRFC3640と共に緩和します。 これはRFC3640のデータのキャリッジに使用されるAccess Units(AUs)が長さの指示を含まなければならないからです。 詳細がセクション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. 簡単な処理のために32ビットのマシンの上に特定のペイロードヘッダー(TYPEヘッダーコネセクション4.1の.2〜4.1.6)のヘッダーフィールドを配置してあります。 この理由で、他のユニットと比べて、分野のSIDXとSDURはTYPEで1ユニット交換されます。
Rey & Matsui Standards Track [Page 9] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[9ページ]RFC4396有効搭載量形式
3. Terminology
3. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
Furthermore, the following terms are used and have specific meaning within the context of this document:
その上、次の用語は、使用されていて、このドキュメントの文脈の中に特定の意味を持っています:
text sample or whole text sample
テキストのサンプルか全文のサンプル
In the 3GPP Timed Text media format [1], these terms refer to a
unit of timed text data as contained in the source (3GP) file.
This includes the text string byte count, possibly a Byte Order
Mark, the text string and any modifiers that may follow. Its
equivalent in audio/video would be a frame.
3GPP Timed Textメディア形式[1]では、これらの用語はソース(3GP)ファイルに含まれていると調節されたテキストデータのユニットを呼びます。 これはテキスト文字列バイト・カウント、ことによるとByte Orderマーク、テキスト文字列、および従うどんな修飾語も含んでいます。 オーディオ/ビデオの同等物はフレームでしょう。
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ファイルテキストのサンプルに出席している16ビットのByte Orderマーク(BOM)を除きます(セクション4.3と図9を見てください)。 16ビットのBOMはセクション4.1.1で説明されるようにRTPで輸送されません。
text strings
テキスト文字列
The actual text characters encoded either as UTF-8 or UTF-16.
When using this payload format, the text string does not contain
any byte order mark (BOM). See Figure 9 for details.
実際のテキストキャラクタはUTF-8かUTF-16としてどちらかをコード化しました。 このペイロード形式を使用するとき、テキスト文字列は少しのバイト・オーダー・マーク(BOM)も含んでいません。 詳細に関して図9を見てください。
fragment or text sample fragment
断片かテキストサンプル断片
A fraction of a text sample. A fragment may contain either text
strings or modifier (decoration) contents, but not both at the
same time.
テキストのサンプルの部分。 断片は、同時に、テキスト文字列か修飾語(デコレーション)コンテンツのどちらかを含んでいますが、ともに含むかもしれないというわけではありません。
sample contents
サンプルコンテンツ
General term to identify timed text data transported when using
this payload format. Sample contents may be one or several text
samples, sample descriptions, and sample fragments (note that,
as per Section 4.6, there is only one case in which more than
one fragment may be included in a payload).
特定する一般項はこのペイロード形式を使用するとき輸送されたテキストデータを調節しました。 サンプルコンテンツは、1かいくつかのテキストのサンプルと、サンプル記述と、サンプル断片であるかもしれません(1個以上の断片がペイロードに含まれるかもしれないある場合しかセクション4.6に従ってないことに注意してください)。
Rey & Matsui Standards Track [Page 10] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[10ページ]RFC4396有効搭載量形式
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.
1個以上のテキストのサンプルによって潜在的に共有される情報。 3GPファイルでは、サンプル記述がそれを共有できる場所に保存されます。 それは方向、テキストボックス位置、遅れ値、デフォルトフォント、背景色などをスクロールすることなどのセットアップとデフォルト情報を含んでいます。
units or transport units
ユニットかトランスポート・ユニット
The payload headers specified in this document encapsulate text
samples, fragments thereof, and sample descriptions by placing a
common header and specific payload header (Sections 4.1.1 to
4.1.6) before them, thus building what is here called a
(transport) unit.
本書では指定されたペイロードヘッダーが一般的なヘッダーと特定のペイロードヘッダーを置くことによってテキストのサンプル、それの断片、およびサンプル記述をカプセルに入れる、(セクション4.1.1、4.1 それらの前の.6であって、)その結果、(輸送)ユニットと呼ばれるここにあるものを築き上げます。
aggregation or aggregate packet
集合か集合パケット
The payload of an aggregate (RTP) packet consists of several
(transport) units.
集合(RTP)パケットのペイロードは数個の(輸送)ユニットから成ります。
track or stream
道かストリーム
3GP files contain audio/video and text tracks. This document
enables streaming of text tracks using RTP. Therefore, these
terms are used interchangeably in this document in the context
of 3GP files.
3GPファイルはオーディオ/ビデオとテキスト探知を入れてあます。 このドキュメントは、RTPを使用することでテキスト探知のストリーミングを可能にします。 したがって、これらの用語は本書では3GPファイルの文脈で互換性を持って使用されます。
Media Header Box / Track Header Box / ...
メディアヘッダー箱/足跡ヘッダー箱/…
The 3GP file format makes use of these structures defined in the
ISO Base File Format [2]. When referring to these in this
document, initials are capitalized for clarity.
3GPファイル形式はISO基地のFile Format[2]で定義されたこれらの構造を利用します。 本書ではこれらについて言及すると、イニシャルは明快ために大文字で書かれます。
Rey & Matsui Standards Track [Page 11] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[11ページ]RFC4396有効搭載量形式
4. RTP Payload Format for 3GPP Timed Text
4. 3GPPのためのRTP有効搭載量形式はテキストを調節しました。
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 :
| | +-+-+-+-+-+-+-+-+
| | |
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |U| R| タイプ| レン| : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : U| : 可変..ヘッダーフィールド..よる
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): マーカーは1へのRTPパケットが1つを含んでいるか、そして、全体以上のテキストのサンプルか最終が断片化するセットがテキストのサンプルであったならSHALLに噛み付きました。 さもなければ、それが(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パケットに含まれる中で最も早い(単に)単位の標本抽出の瞬間を示さなければなりません。 初期値のSHOULDは手当たりしだいにそうです。指定されるとして、RTP[3]では、断固としています。
The timestamp value should provide enough timing resolution for
expressing the duration of text samples, for synchronizing text
with other media, and for performing RTP Control Protocol (RTCP)
measurements such as the interarrival delay jitter or the RTCP
Packet Receipt Times Report Block (Section 4.3 of RFC 3611
[20]). This is compliant to RTP, Section 5.1:
タイムスタンプ値はテキストのサンプルの持続時間を言い表して、他のメディアとテキストを同期させて、RTP Controlプロトコルを実行するための十分なタイミング解決(RTCP)にinterarrival遅れジターかRTCP Packet ReceiptタイムズReport Blockなどの測定値を提供するべきです。(RFC3611[20])のセクション4.3。 これはRTP、セクション5.1に言いなりになっています:
"The resolution of the clock MUST be sufficient for the
desired synchronization accuracy and for measuring packet
arrival jitter (one tick per video frame is typically not
sufficient)".
「時計の解決は必要な同期精度と測定パケット到着ジターに十分であるに違いありません(ビデオフレームあたり1回のカチカチする音は通常十分ではありません)。」
Rey & Matsui Standards Track [Page 12] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[12ページ]RFC4396有効搭載量形式
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はそのテキスト探知のためのメディアHeader Boxの「スケール」パラメタの値です。 3GPファイルの各道には、メディアHeader Boxの指定されるとしてのそれ自身のclockrateがあるかもしれません。 同様に、ライブストリーミング・アプリケーションSHALLは適切なタイムスタンプclockrateを使用します。 1000Hzのデフォルト値はRECOMMENDEDです。 他のタイムスタンプclockratesは使用されるかもしれません。 この場合、ここでの典型的な振舞いはそれへの調節されたテキストclockrateが関連オーディオかビデオストリームで使用した3GPPを合わせることです。
In an aggregate payload, units MUST be placed in play-out order,
i.e., earliest first in the payload. If TYPE 1 units are
aggregated, the timestamp of the subsequent units MUST be
obtained by adding the timed text sample duration of previous
samples to the RTP timestamp value. There are two exceptions to
this rule: TYPE 5 units and an aggregate payload containing two
fragments of the same text sample. The details of the timestamp
calculation are given in Section 4.6.
集合ペイロードでは、すなわち、最も早く最初に、ペイロードに外でプレーするオーダーにユニットを置かなければなりません。 TYPEであるなら、1個のユニットを集めて、前のサンプルの調節されたテキストサンプル持続時間をRTPタイムスタンプ価値に加えることによって、その後のユニットに関するタイムスタンプを得なければなりません。 この規則への2つの例外があります: 5ユニットに集合ペイロードに同じテキストのサンプルの2個の断片を含むTYPE。 タイムスタンプ計算の詳細はセクション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.
有効搭載量タイプ(太平洋標準時の): ペイロードタイプは、ダイナミックに設定して、バンドの外による手段を送ります。
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の規則と使用中のプロフィールに従います。
4.1. Payload Header Definitions
4.1. 有効搭載量ヘッダー定義
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.
本書では指定された(輸送)ユニットは特定のヘッダーフィールド(TYPES1-5)とテキストサンプルコンテンツがあとに続いた1セットの共同耕地(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、twoの例のRTPでは、パケットは表現されます。 1番目は2個の全文のサンプルがある集合RTPペイロードを含んでいます、そして、2番目は1個のテキストサンプル断片を含んでいます。 それぞれのユニットヘッダーが説明された後に、詳細なペイロードの例はセクション4.7で従います。
Rey & Matsui Standards Track [Page 13] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[13ページ]RFC4396有効搭載量形式
+----------------------+
| |
| RTP Header |
| |
---------+----------------------+
| | |
| |COMMON + TYPE 1 Header|
| ........................
UNIT 1 - | |
| | Text Sample |
| | |
|-------\........................
-------/| |
| |COMMON + TYPE 1 Header|
| ........................
UNIT 2 - | |
| | Text Sample |
| | |
| | |
---------+----------------------+
+----------------------+ | | | RTPヘッダー| | | ---------+----------------------+ | | | | |一般的な+タイプ1ヘッダー| | ........................ ユニット1、-| | | | テキストのサンプル| | | | |-------\........................ -------/| | | |一般的な+タイプ1ヘッダー| | ........................ ユニット2、-| | | | テキストのサンプル| | | | | | | ---------+----------------------+
+----------------------+
| |
| RTP Header |
| |
---------+----------------------+
| | COMMON + TYPE 2 |
| | (or 3 or 4) Hdr |
| ........................
UNIT 3 - | |
| | Text Sample Fragment |
| | |
| | |
---------+----------------------+
+----------------------+ | | | RTPヘッダー| | | ---------+----------------------+ | | 一般的な+タイプ2| | | (または、3か4) Hdr| | ........................ ユニット3、-| | | | テキストサンプル断片| | | | | | | ---------+----------------------+
Figure 2. Example RTP packets
図2。 例のRTPパケット
Rey & Matsui Standards Track [Page 14] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[14ページ]RFC4396有効搭載量形式
4.1.1. Common Payload Header Fields
4.1.1. 一般的な有効搭載量ヘッダーフィールド
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|タイプ| レン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Transformation旗」: これは、UTF-8(U=0)かUTF-16(U=1)がテキスト文字列をコード化するのに使用されたかどうかをRTP受信機に知らせるのに使用されます。 ビッグエンディアン注文、通称ネットワークバイトオーダーでこのペイロード形式によって輸送された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.
有益な注意: 3GPP Timed Text形式[1]に従う調節されたテキストクライアントはビッグエンディアン連載を理解するだけでよいです。 したがって、相互運用性を緩和するために、逆の連載(リトルエンディアン)はこのペイロード形式で後押しされていません。
For the payload formats defined in this document, the U bit is only
used in TYPE 1 and TYPE 2 headers. Senders MUST set the U bit to
zero in TYPE 3, TYPE 4, and TYPE 5 headers. Consequently,
receivers MUST ignore the U bit in TYPE 3, TYPE 4, and TYPE 5
headers.
本書では定義されたペイロード書式のために、UビットはTYPE1とTYPE2個のヘッダーで使用されるだけです。 SendersはTYPE3、TYPE4、およびTYPE5ヘッダーにUビットをゼロに設定しなければなりません。 その結果、受信機はTYPE3、TYPE4、およびTYPE5ヘッダーで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ビット)は「ビットを予約しました」: 今後の拡大のために。 この分野を(0×0)のゼロを合わせるように設定しなければならなくて、受信機で無視しなければなりません。
o TYPE (3 bits) "Type Field": This field specifies which specific
header fields follow. The following TYPE values are defined:
o TYPE(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
- 全文のサンプルのためのTYPE1。 - テキスト文字列断片のためのTYPE2(修飾語のない)。 - 全体の修飾語箱のためのTYPE3か修飾語箱の最初の断片。 - 最初にを除いた修飾語断片のためのTYPE4。 - サンプル記述のためのTYPE5。 ちょうどサンプル記述あたり1個のヘッダー。 - TYPE0、6、および7は今後の拡大のために予約されます。 今後の拡大が可能であることに注意してください、そして、例えば、明らかにキャラクタの数を示すユニットは中にaを提示します。
Rey & Matsui Standards Track [Page 15] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[15ページ]RFC4396有効搭載量形式
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.
断片化してください(セクション2.5を見てください)。 後方に互換性を保証してください、それ、SHALL、 より年取ったクライアントが彼らが理解していない(より新しい)のユニットを無視するのを可能であってください、タイムスタンプ計算メカニズムを無効にするか、またはそうでなければ、それらが他のユニットを解読するのを防がない。
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
- =1をタイプしてください、レン>=8--=2をタイプしてください、レン>9--=3をタイプしてください、レン>6--=4をタイプしてください、レン>6--=5をタイプしてください、レン>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の値のための異なったペイロードヘッダーは指定されます。
Rey & Matsui Standards Track [Page 16] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[16ページ]RFC4396有効搭載量形式
4.1.2. TYPE 1 Header
4.1.2. 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 >=8) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | TLEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|タイプ| LEN(いつも>=8)| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| TLEN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLEN| +-+-+-+-+-+-+-+-+
Figure 4. TYPE 1 Header Format
図4。 1つのヘッダー形式をタイプしてください。
This header type is used to transport whole text samples. This unit should be the most common case, i.e., the text sample should usually be small enough to be transported in one unit without having to separate text strings from modifiers. In an aggregate (RTP packet) payload containing several text samples, every sample is preceded by its own TYPE 1 header (see Figure 12).
このヘッダータイプは、全文のサンプルを輸送するのに使用されます。 このユニットは、1ユニットで修飾語からテキスト文字列を分離する必要はなくて輸送されるためには最も一般的なケース、通常、すなわち、テキストのサンプルが十分小さいはずであるということであるべきです。 いくつかのテキストのサンプルを含む集合(RTPパケット)のペイロードでは、あらゆるサンプルがそれ自身のTYPE1ヘッダーによって先行されています(図12を見てください)。
Informative note: As indicated in Section 3, "Terminology", a
text sample is composed of the text strings followed by the
modifiers (if any). This is also how text samples are stored in
3GP files. The separation of a text sample into text strings
and modifiers is only needed for large samples (or small
available IP MTU sizes; see Section 4.4), and it is accomplished
with TYPE 2 and TYPE 3 headers, as explained in the sections
below.
有益な注意: セクション3、「用語」にみられるように、テキストのサンプルは修飾語(もしあれば)があとに続いたテキスト文字列で構成されます。 また、これはテキストのサンプルが3GPファイルにどう保存されるかということです。 テキスト文字列と修飾語へのテキストのサンプルの分離が大標本に必要であるだけです、そして、(小さい有効なIP MTUサイズ; セクション4.4を見てください)それはTYPE2とTYPE3個のヘッダーと共に達成されます、下のセクションで説明されるように。
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).
また、サンプルコンテンツを含みませんが、空のテキストのサンプルが全文のサンプルであると考えられることに注意してください。 空のテキストのサンプルは、ディスプレイをクリアするか、または例えば、未知の持続時間のサンプルを終わらせるのに使用されるかもしれません。 サンプルコンテンツSHALLのないユニットには、8(0×0008)のLEN分野価値があります。
The fields above have the following meaning:
上の分野には、以下の意味があります:
o U, R, and TYPE, as defined in Section 4.1.1.
o セクション4.1.1における定義されるとしてのU、R、およびTYPE。
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(8)バイトを表します。 3GPファイルのSample Size Boxのテキストのサンプルの長さを見つけるには、セクション4.3を見てください。
o SIDX (8 bits) "Text Sample Entry Index": This is an index used to
identify the sample descriptions.
o SIDX(8ビット)「テキストサンプルエントリーインデックス」: これはサンプル記述を特定するのに使用されるインデックスです。
Rey & Matsui Standards Track [Page 17] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[17ページ]RFC4396有効搭載量形式
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分野は、サンプル記述がユニットのペイロードに対応しているのがわかるのに使用されます。 2つのタイプのSIDX値があります: 静的であって、ダイナミックです。
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つの特定のサンプル記述にリンクされます。 多くのサンプル記述のバンドで出ているSHOULDを運んで、避けられてください、これらが大きくなるかもしれなくて、結局輸送がバンドで出かけているチャンネルの目標でないので。 したがって、この特徴は、1セットの最小の省略時書式設定を提供するそれらのサンプル記述を輸送するためのRECOMMENDEDです。 静的なSIDX値が(閉じられる)の間隔[129,254]で下落しなければなりません。
Dynamic SIDX values are used for sample descriptions sent in-band.
Sample descriptions MAY be sent in-band for several reasons:
because they are generated in real time, for transport resiliency,
or both. A dynamic SIDX value is unequivocally linked to one
particular sample description during the period in which this is
active in the session, and it SHALL NOT be modified during that
period. This period MAY be smaller than or equal to the session
duration. This period is not known a priori. A maximum of 64
dynamic simultaneously active SIDX values is allowed at any moment.
Dynamic SIDX values MUST fall in the closed interval [0,127]. This
should be enough for both recorded content and live streaming
applications. Nevertheless, a wraparound mechanism is provided in
Section 4.2.1 to handle streaming sessions where more than 64 SIDX
values might be needed. Servers MAY make use of dynamic sample
descriptions. Clients MUST be able to receive and interpret
dynamic sample descriptions.
ダイナミックなSIDX値はバンドで送られたサンプル記述に使用されます。 数個のためのバンドの理由をサンプル記述に送るかもしれません: それらがリアルタイムで輸送の弾性、または両方のために生成されるので。 ダイナミックなSIDX値が明確にこれがセッション、およびそれでアクティブである期間、1つの特定のサンプル記述にリンクされる、SHALL NOT、その期間、変更されてください。 この期間はセッションより持続時間以下であるかもしれません。 この期間は先験的に知られていません。 最大64動力はいつ何時、同時に、許容されていますアクティブなSIDXが、評価する。 ダイナミックなSIDX値が閉じている間隔[0,127]で下落しなければなりません。 記録された内容と動いているストリーミング・アプリケーションの両方に、これは十分であるべきです。 それにもかかわらず、64以上のSIDX値が必要であるかもしれないストリーミングのセッションを扱うためにセクション4.2.1に巻きつけて着るドレスメカニズムを提供します。 サーバはダイナミックなサンプル記述を利用するかもしれません。 クライアントは、ダイナミックなサンプル記述を受けて、解釈できなければなりません。
Finally, SIDX values 128 and 255 are reserved for future use.
最終的に、SIDX値128と255は今後の使用のために予約されます。
o SDUR (24 bits) "Text Sample Duration": indicates the sample
duration in RTP timestamp units of the text sample. For this
field, a length of 3 bytes is preferred to 2 bytes. This is
because, for a typical clockrate of 1000 Hz, 16 bits would allow
for a maximum duration of just 65 seconds, which might be too short
for some streams. On the other hand, 24 bits at 1000 Hz allow for
a maximum duration of about 4.6 hours, while for 90 KHz, this value
is about 3 minutes. These values should be enough for streaming
applications. However, if a larger duration is needed, the
extension mechanism specified in Section 4.3 SHALL be used.
o SDUR(24ビット)「テキストサンプル持続時間」: テキストのサンプルのRTPタイムスタンプユニットのサンプル持続時間を示します。 この分野において、3バイトの長さは2バイトより好まれます。 16ビットは1000Hzの典型的なclockrateに関して最大いくつかのストリームには、短過ぎるかもしれないちょうど65秒の持続時間を考慮するでしょう、したがって、これがそうです。1000Hzで最大およそ4.6時間の持続時間を他方では、そして、24ビット考慮してください、この値は90KHzに関するおよそ3分ですが。 ストリーミング・アプリケーションに、これらの値は十分であるべきです。 拡張機能が、より大きい持続時間が必要であるならセクション4.3 SHALLでどのように指定したとしても、使用されてください。
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パケットペイロードの中にその後のユニットに関するタイムスタンプを見つけるのに使用されます(もしあれば)。
Rey & Matsui Standards Track [Page 18] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[18ページ]RFC4396有効搭載量形式
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)は、未知の持続時間に合図するために予約されます。 未知の持続時間のサンプルが提示される時間は受信機に表示されるものとする次のサンプルに関するタイムスタンプで決定します: テキストが抽出する、未知の持続時間SHALLでは、次のテキストのサンプルが能動態になるまで、タイムスタンプによって示されるように表示してください。
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.
しかしながら、SDUR=0と共に3GPファイルにテキストのサンプルを保存するとき、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.
未知の持続時間SHALL NOTのサンプルが特徴を使用することに注意してください。(特徴は前払いでサンプルの持続時間に関する知識を必要とします)。 そのような特徴は、[1]のスクロールとカラオケです。 また、これはTimed Text形式の今後の拡大に申し込みます。 その上、サンプル記述(TYPE5ユニット)だけが同じ集合ペイロードのユニットの未知の持続時間を次に続かせるかもしれません。 さもなければ、これらの他のユニットに関するタイムスタンプについて計算するのは可能でないでしょう。
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]と後のリリースによると、SHALLは適切な値とユニットを割り当てます。
Rey & Matsui Standards Track [Page 19] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[19ページ]RFC4396有効搭載量形式
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値からそれについて演えき的に計算できるので、テキスト文字列断片(TYPE2)に存在していません。
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.
3GPファイルの含まれるとしてのテキストのサンプルからTLEN値を得ます。 セクション4.3を参照してください。 内容、TLEN MUSTを住ませてください。サンプリング・プロセスの間、入手します。
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])に保存されたテキストのサンプルと対照的に。
4.1.3. TYPE 2 Header
4.1.3. 2ヘッダーをタイプしてください。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|タイプ| LEN(いつも>9)| 合計| これ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLEN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. TYPE 2 Header Format
図5。 2ヘッダー形式をタイプしてください。
This header type is used to transport either a whole text string or a fragment of it. TYPE 2 units SHALL NOT contain modifiers. In detail:
このヘッダータイプは、それの全文ストリングか断片のどちらかを輸送するのに使用されます。 TYPE2ユニットSHALL NOTは修飾語を含んでいます。 詳細に:
o U, R, and TYPE, as defined in Section 4.1.1.
o セクション4.1.1における定義されるとしてのU、R、およびTYPE。
o SIDX and SDUR, as defined in Section 4.1.2.
o 定義されたコネセクション4.1.2としてのSIDXとSDUR。
Note that the U, SIDX, and SDUR fields are meaningful since
partial text strings can also be displayed.
U、SIDX、およびSDUR分野がまた、部分的なテキスト文字列を表示できるので重要であることに注意してください。
o The LEN field (16 bits) indicates the length of the text string
fragment plus nine (9) bytes of headers. Its value is calculated
upon fragmentation. LEN MUST always be greater than nine (0x0009).
Otherwise, the unit MUST be discarded.
o LEN分野(16ビット)はテキスト文字列断片の長さとヘッダーの9(9)バイトを示します。 値は断片化のときに計算されます。 いつもレンは9歳以上であるに違いありません(0×0009)。 さもなければ、ユニットを捨てなければなりません。
Rey & Matsui Standards Track [Page 20] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[20ページ]RFC4396有効搭載量形式
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.
TLEN、また、2ユニットがするTYPEが明白なテキストストリング長を含まないことに注意してください(TYPE1を見てください)。 これはユニットがするTYPE2がテキスト文字列の後にどんな修飾語も含まないからです。 必要であるなら、TYPEのLEN値を2ユニット使用することで容認されたストリングの長さを得ることができます。
o The SLEN field (16 bits) indicates the size (in bytes) of the
original (whole) text sample to which this fragment belongs. This
length comprises the text string plus any modifier boxes present
(and includes neither the byte order mark nor the text string
length as mentioned in Section 3, "Terminology").
o SLEN分野(16ビット)はこの断片が属するオリジナル(全体の)のテキストのサンプルのサイズ(バイトによる)を示します。 この長さはテキスト文字列とどんな修飾語箱のプレゼント(そして、セクション3、「用語」で言及されるようにバイト・オーダー・マークもテキストストリング長も含んでいない)も包括します。
Regarding the text sample length: Timed text samples are not
generated at regular intervals, nor is there a default sample size.
If 3GP files are streamed, the length of the text samples is
calculated beforehand and included in the track itself, while for
live encoding it is the real time encoder that SHALL choose an
appropriate size for each text sample. In this case, the amount of
text 'captured' in a sample depends on the text source and the
particular application (see examples below). Samples may, e.g., be
tailored to match the packet MTU as closely as possible or to
provide a given redundancy for the available bit rate. The
encoding application MUST also take into account the delay
constraints of the real-time session and assess whether FEC,
retransmission, or other similar techniques are reasonable options
for stream repair.
テキストに関して、長さを抽出してください: 調節されたテキストのサンプルは一定の間隔を置いて発生しません、そして、デフォルトサンプルサイズがありません。 3GPファイルが流されるなら、テキストのサンプルの長さは、道自体にあらかじめ、計算されて、含まれています、それはライブコード化のためのSHALLがそれぞれのテキストのサンプルのための適切なサイズに選ぶリアルタイムのエンコーダですが。 この場合、サンプルで'捕らえられた'テキストの量はテキストソースと特定用途に頼ります(以下の例を見てください)。 サンプルは仕立てるかもしれません、例えば、仕立てられて、できるだけ密接にパケット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
例: ニュース放送シナリオを想像してください。そこでは、話されたニュースは、レポーターのイメージと声と転写されて、同期します。 私たちは、ニューススピーカーが5の平均した語長で1秒あたり5つの単語の平均速度に単語(すなわち、1秒あたり30のキャラクタ)あたりのスペースにキャラクタと1つに話し合うと思います。 私たちは、576バイトの利用可能なIP MTUと576*8つのbpsの利用可能なbitrateが4.6Kbpsと等しいと思います。 私たちは、UTF-16で2バイトを使用することで各キャラクタをコード化できると思います。 このシナリオでは、いくつかの規制が適用されるかもしれません。 例えば: 利用可能なIP MTU、利用可能な帯域幅、許容できる遅れ、および必要な冗長。 目標は最小にするつもりでした。
Rey & Matsui Standards Track [Page 21] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[21ページ]RFC4396有効搭載量形式
packet overhead, a text sample covering 8 seconds of text
would be closest to the IP MTU:
パケットオーバーヘッド、8秒のテキストのテキストサンプル覆いがIP MTUの最も近くにあるでしょう:
IP/UDP/RTP/TYPE1 Header + (8-second text sample)
= 20 + 8 + 12 + 8 + (~6 chars/word * 5 word/s * 8 s * 2 chars/word)
= 528 bytes < 576 bytes
528+ (~6雑用/単語*5単語/s*8秒間*2雑用/単語)=バイトのIP/UDP/RTP/TYPE1 Header+(8秒のテキストのサンプル)=20+8+12+8<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サンプルあたりちょうど1つのパケットが少な過ぎる冗長であることは起こるかもしれません。 この場合、選択はエンコーダが毎秒テキストを'集める'ということであるかもしれません、その結果、68バイトのテキストのサンプル(TYPE1ユニット)をもたらします、TYPE1ヘッダーを含んでいて。 私たちはそうすることができます、例えば、1個のRTPペイロードの3個の隣接のテキストのサンプルを含めてください: 現在で最後の2個のテキストのサンプル(以下を見ます)。 これは合計について244 20+8+12+3*(8+60)のIPパケットサイズ=バイト報告します。 現在、4.6Kbpsの同じ利用可能なbitrateで、1秒に2回冗長にこれらの244バイトのパケットを上げることができます:
RTP payload (1,2,3)(1,2,3) (2,3,4)(2,3,4) (3,4,5)(3,4,5) ...
Time: <----1s------> <----1s------> <-----1s-----> ...
RTPペイロード(1、2、3)(1、2、3)(2、3、4)(2、3、4)(3、4、5)(3、4、5)… 時間: <、-、-、--1------><。----1------><。-----1----->…
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ビーピーエス)packetizationとしても流れの冗長を増加させませんが。
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.
格納された内容に関しては、SLENが3GPファイルの値であることがどうわかるかに関する詳細に関してセクション4.3を見てください。 内容、SLEN MUSTを住ませてください。サンプリング・プロセスの間、入手します。
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
o すなわち分野のTOTAL(4ビット)とTHIS(4ビット)が中の原本が抽出する断片の総数を示す、(。
Rey & Matsui Standards Track [Page 22] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[22ページ]RFC4396有効搭載量形式
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.
テキスト文字列とその修飾語)、断片化された、そして、どのオーダーがその系列でそれぞれ現在の断片を占領しますか? 一連番号だけがTHIS分野の機能性を置き換えることができないことに注意してください、パケット(そして、断片)が繰り返されるかもしれないので、例えば、繰り返されたトランスミッションのように(セクション5を見てください)。 したがって、「断片は相殺した」指示が必要です。
The usual "byte offset" field is not used here for two reasons: a)
it would take one more byte and b) it does not provide any
information on the character offset. UTF-8/UTF-16 text strings
have, in general, a variable character length ranging from 1 to 6
bytes. Therefore, the TOTAL/THIS solution is preferred. It could
also be argued that the LEN and SLEN fields be used for this
purpose, but while they would provide information about the
completeness of the text sample, they do not specify the order of
the fragments.
普通の「バイトオフセット」分野は2つの理由にここで使用されません: a) それはもうひとつのバイトかかって、b) それはキャラクタオフセットの少しの情報も提供しません。 一般に、UTF-8/UTF-16テキスト文字列には、1〜6バイトに及ぶ可変キャラクタの長さがあります。 したがって、TOTAL/THIS解決策は好まれます。 また、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.
中に、すべてが(TYPEs2、3、および4)をケースに入れます、THISの値がTOTALより大きいか、またはTOTAL同輩ゼロ(0×0)、断片SHALLが捨てられるなら。
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文字列の断片から成ります。 修飾語は全く従いません。
4.1.4. TYPE 3 Header
4.1.4. 3ヘッダーをタイプしてください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN( always >6) |TOTAL | THIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|タイプ| LEN(いつも>6)|合計| これ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. TYPE 3 Header Format
図6。 3ヘッダー形式をタイプしてください。
This header type is used to transport either the entire modifier contents present in a text sample or just the first fragment of them. This depends on whether the modifier boxes fit in the current RTP payload.
このヘッダータイプは、テキストのサンプルの現在の全体の修飾語コンテンツかまさしくそれらの最初の断片のどちらかを輸送するのに使用されます。 これは修飾語箱が現在のRTPペイロードをうまくはめ込むかどうかによります。
If a text sample containing modifiers is fragmented, this header MUST be used to transport the first fragment or, if possible, the complete modifiers.
修飾語を含むテキストのサンプルが断片化されるなら、最初の断片かできれば完全な修飾語を輸送するのにこのヘッダーを使用しなければなりません。
In detail:
詳細に:
o The U, R, and TYPE fields are defined as in Section 4.1.1.
o 分野がセクション4.1.1で定義されるU、R、およびTYPE。
Rey & Matsui Standards Track [Page 23] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[23ページ]RFC4396有効搭載量形式
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以上であるに違いありません(0×0006)。 さもなければ、ユニットを捨てなければなりません。
o The TOTAL/THIS field has the same meaning as for TYPE 2.
o TOTAL/THIS分野には、同じ意味がTYPE2のようにあります。
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.
最後の(引きずること)の修飾語断片、TOTAL MUSTの値を含むTYPE3ユニットに関しては、THIS(TOTAL=THIS)のものと等しくいてください。 添加、TOTAL=THIS MUST、1以上になってください、テキストのサンプルの断片の総数が1より論理的にいつも大きいので。
Otherwise, if TOTAL is different from THIS in a TYPE 3 unit, this
means that the unit contains the first fragment of the modifiers.
さもなければ、TOTALがTYPE3ユニットのTHISと異なるなら、これは、ユニットが修飾語の最初の断片を含むことを意味します。
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には、TYPE1のための同じ定義があります。 断片が自己のRTPパケットでいつも輸送されるので、この分野がこの断片がどれくらい長い間有効であるかを知るのに必要であるだけです。 これは使用するかもしれません、例えば、使用されて、それが表示バッファにどれくらい長い状態で保たれるべきであるか決定してください。
Note that the SLEN and SIDX fields are not present in TYPE 3 unit headers. This is because a) these fragments do not contain text strings and b) these types of fragments are applied over text string fragments, which already contain this information.
SLENとSIDX分野がTYPE3ユニットヘッダーに存在していないことに注意してください。 これはa) これらの断片がテキスト文字列を含んでいないからですb) これらのタイプの断片はテキスト文字列断片の上に適用されます。既に、断片はこの情報を含みます。
4.1.5. TYPE 4 Header
4.1.5. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN( always >6) |TOTAL | THIS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|タイプ| LEN(いつも>6)|合計| これ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. TYPE 4 Header Format
図7。 4ヘッダー形式をタイプしてください。
This header type is placed before modifier fragments, other than the first one.
このヘッダータイプは最初のもの以外の修飾語断片の前に置かれます。
The U, R, and TYPE fields are used as per Section 4.1.1.
U、R、および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は、修飾語コンテンツの長さのTYPE3とSHALLのようにも断片化のときに得られるように示します。 LEN分野は6以上であるに違いありません(0×0006)。 さもなければ、ユニットを捨てなければなりません。
TOTAL/THIS is used as in TYPE 2.
TOTAL/THISはTYPE2のように使用されています。
Rey & Matsui Standards Track [Page 24] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[24ページ]RFC4396有効搭載量形式
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分野はTYPE1のように定義されます。 SLENとSIDXの不在の後ろの推理はTYPEと3ユニット同じです。
4.1.6. TYPE 5 Header
4.1.6. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN( always >3) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|タイプ| LEN(いつも>3)| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. TYPE 5 Header Format
エイト環。 5ヘッダー形式をタイプしてください。
This header type is used to transport (dynamic) sample descriptions. Every sample description MUST have its own TYPE 5 header.
このヘッダータイプは、(ダイナミック)のサンプル記述を輸送するのに使用されます。 あらゆるサンプル記述には、それ自身のTYPE5ヘッダーがなければなりません。
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分野はサンプル記述の長さ、およびSIDXとLEN分野自体のための3つの会計を示します。 したがって、この分野は3以上であるに違いありません(0×0003)。 さもなければ、ユニットを捨てなければなりません。
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値を含んでいます。 ダイナミックなサンプル記述だけがTYPE5を使用することで運ばれるとき、可能なSIDX値が(閉じられる)の間隔[0,127]にあります。
Senders MAY make use of TYPE 5 units. All receivers MUST implement support for TYPE 5 units, since it adds minimum complexity and may increase the robustness of the streaming session.
SendersはTYPE5の使用をユニットにするかもしれません。 すべての受信機がTYPEのサポートを5ユニット実行しなければなりません、最小の複雑さを加えて、ストリーミングのセッションの丈夫さを増加させるかもしれないので。
The next section specifies how SIDX values are calculated.
次のセクションはSIDX値がどう計算されるかを指定します。
4.2. Buffering of Sample Descriptions
4.2. サンプル記述のバッファリング
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 クライアントで静的なサンプル記述をバッファリングしなければならない、少なくとも、セッションの持続時間のために。
Rey & Matsui Standards Track [Page 25] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[25ページ]RFC4396有効搭載量形式
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値のバッファリングとアップデートは次のセクションで説明されたメカニズムに従わなければなりません。
4.2.1. Dynamic SIDX Wraparound Mechanism
4.2.1. ダイナミックな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.
送付者によるダイナミックなサンプル記述の使用はOPTIONALです。 しかしながら、それらが使用されているなら、送付者はこのメカニズムを実行しなければなりません。 受信機はいつもそれを実行しなければなりません。
Dynamic SIDX values remain active either during the entire duration of the session (if used just once) or in different intervals of it (if used once or more).
ダイナミックなSIDX値はセッション(一度だけ使用されるなら)の全体の持続時間かそれの異なった間隔でアクティブなままです(一度さらに使用されるなら)。
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=5であるなら、SIDX=6以外のすべての127の値が「アクティブでしょう」。 現在、再命令されたパケットが新しい記述、SIDX=9と共に到着すると、それは誤って捨てられるでしょう、SIDX=9がその瞬間に「アクティブである」としてマークされて、活発なサンプル記述を書き直さないものとするので。 したがって、「警備間隔」を導入します。 この警備間隔は時間内に、任意な点でアクティブなSIDXsの数を64まで減少させます。 ほとんどの調節されたテキストアプリケーションがたぶんセッション(合計で)の間64未満のサンプル記述を必要とするでしょうが、以上の必要性を扱う巻きつけて着るドレスメカニズムはここで説明されます。
Thereby, a sliding window of 64 active SIDX values is used. Values within the window are "active"; all others are marked "inactive". An SIDX value becomes active if at least one sample description identified by that SIDX has been received. Since sample descriptions MAY be sent redundantly, it is possible that a client receives a given SIDX several times. However, active sample descriptions SHALL NOT be overwritten: The receiver SHALL ignore redundant sample descriptions and it MUST use the already cached copy. The "guard interval" of (64) inactive values ensures that the correct association SIDX <-> sample description is always used.
その結果、64のアクティブなSIDX値の引窓は使用されています。 窓の中の値は「アクティブです」。 すべての他のものが「不活発である」とマークされます。 そのSIDXによって特定された少なくとも1つのサンプル記述を受けたなら、SIDX値はアクティブになります。 冗長にサンプル記述を送るかもしれないので、クライアントが何度か与えられたSIDXを受け取るのは、可能です。 しかしながら、能動態は記述SHALL NOTを抽出します。上書きされてください: 受信機SHALLは余分なサンプル記述を無視します、そして、それは既にキャッシュされたコピーを使用しなければなりません。 (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.
有益な注意: 「警備間隔」値自体に関して、128/2としての64はまだ予想された最大数のサンプル記述を満たしている間、十分簡単であると考えられました。 それ以外に、64か異価を選ぶことに関する他の動機は全くありません。
Rey & Matsui Standards Track [Page 26] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[26ページ]RFC4396有効搭載量形式
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のために許容範囲の中でYが値であることをさせてください: [0,127]、X.Let Zと異なるのは、最後の容認されたサンプル記述のSIDXです。 その時:
1. Initialize all dynamic SIDX values as inactive. For stored
contents, read the sample description index in the Sample to
Chunk box ("stsc") for that sample. For live streaming, the
first value MAY be zero or any other value in the interval
above. Go to step 2.
1. 不活発であるとしてすべてのダイナミックなSIDX値を初期化してください。 格納されたコンテンツには、そのサンプルのためのChunk箱("stsc")へのSampleのサンプル記述インデックスを読んでください。 ライブストリーミングのために、最初の値は、上の間隔のゼロかいかなる他の値であるかもしれません。 ステップ2に行ってください。
2. First, in-band sample description with SIDX=Z is received and
stored; set X=Z. Go to step 3.
2. まず最初に、SIDX=Zとのバンドにおけるサンプル記述は、受けられて、格納されます。 X=Zを設定してください。 ステップ3に行ってください。
3. Any SIDX within the interval [X+1 modulo(128), X+64 modulo(128)]
is marked as inactive, and any corresponding sample description
is deleted. Any SIDX within the interval [X+65 modulo(128), X]
is set active. Go to step 4 (wait state).
3. 間隔中にどんな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).
i。 SIDX=Zが格納されないなら、サンプル記述を格納してください。 ステップ4(待ち状態) iiの始まりまで行ってください。 ほかに、ステップ4(待ち状態)の始まりまで行ってください。
Informative note: It is allowed that any value of SIDX=X be sent
in the interval [0,127]. For example, if [64..127] is the
current active set and SIDX=0 is sent, a new sample description
is defined (0) and an old one deleted (64); thus [65..127] and
[0] are active. Similarly, one could now send SIDX=64, thus
inverting the active and inactive sets.
有益な注意: SIDX=Xのどんな値も間隔[0,127]で送られるのが許容されています。 例えば、[64 .127]がそうなら現在の活動的なセットとSIDX=0を送って、新規見本記述は定義されて、(0)と古いものが(64)を削除したということです。 その結果、[65 .127]と[0]はそうです。アクティブ。 同様に、1つは現在、SIDX=64を送って、その結果、アクティブで不活発なセットを逆にするかもしれません。
Example:
If X=4, any SIDX in the interval [5,68] is inactive. Active
SIDX values are in the complementary interval [69,127] plus
例: X=4であるなら、間隔[5、68]のどんなSIDXも不活発です。 アクティブなSIDX値が補足的な間隔に[69,127] そのうえ、あります。
Rey & Matsui Standards Track [Page 27] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[27ページ]RFC4396有効搭載量形式
[0,4]. For example, if the client receives a SIDX=6, then the
active interval is now different: [0,6] plus [71,127]. If the
received SIDX is in the current active interval, no change SHALL
be applied.
[0,4]. 例えば、クライアントがSIDX=6を受け取るなら、アクティブな間隔は現在、異なっています: [0、6]プラス[71,127]。 電流に容認されたSIDXがあるなら、適用されていて、いいえはアクティブな間隔、SHALLを変えます。
4.3. Finding Payload Header Values in 3GP Files
4.3. 3GPファイルの有効搭載量ヘッダー値を見つけます。
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はファイルして、↓これはガイドラインSHALLです。続かれています。
Note: All fields in the objects (boxes) of a 3GP file are found
in network byte order.
以下に注意してください。 3GPファイルの物(箱)のすべての分野がネットワークバイトオーダーで見つけられます。
Information obtained from the Sample Table Box (stbl):
情報はSample Table Boxから(stbl)を得ました:
o Sample Descriptions and Sample Description length: The Sample
Description box (stsd, inside the stbl) contains the sample
descriptions. For timed text media, each element of stsd is a
timed text sample entry (type "tx3g").
o 記述とSample記述の長さを抽出してください: Sample記述箱(stblの中のstsd)はサンプル記述を含んでいます。 調節されたテキストメディアにおいて、stsdの各要素は調節されたテキストサンプルエントリー("tx3g"をタイプする)です。
The (unsigned) 32 bits of the "size" field in the stsd box
represent the length (in bytes) of the sample description, as
carried in TYPE 5 units. On the other hand, the LEN field of
TYPE 5 units is restricted to 16 bits. Therefore, if the
value of "size" is greater than (2^16-1-3)[bytes], then the
sample description SHALL NOT be streamed with this payload
format. There is no extension mechanism defined in this case,
since fragmentation of sample descriptions is not defined
(sample descriptions are typically up to some 200 bytes in
size). Note: The three (3) accounts for the TYPE 5 header
fields included in the LEN value.
stsd箱の中の「サイズ」分野の(無記名)の32ビットはサンプル記述の長さ(バイトによる)を表します、TYPEで5ユニット運ばれるように。 他方では、TYPE5ユニットのLEN分野は16ビットに制限されます。 「サイズ」の値が(2^16-1-3)[バイト]、次に、サンプル記述SHALL NOTよりしたがって、このペイロード形式で流された状態で大きいなら。 この場合定義されている拡大メカニズムが全くありません、サンプル記述の断片化が定義されないので(サンプル記述は通常サイズにおけるおよそ200バイトまで達しています)。 以下に注意してください。 LEN値にTYPE5ヘッダーフィールドのための3(3)アカウントを含んでいます。
o SDUR from the Decoding Time to Sample Box (stts). The
(unsigned) 32 bits of the "sample delta" field are used for
calculating SDUR. However, since the SDUR field is only 3
bytes long, text samples with duration values larger than
(2^24-1)/(timestamp clockrate)[seconds] cannot be streamed
directly. The solution is simple: Copies of the corresponding
text sample SHALL be sent. Thereby, the timestamp and
duration values SHALL be adjusted so that a continuous display
o 箱(stts)を抽出する解読時間からのSDUR。 「サンプルデルタ」分野の(無記名)の32ビットは計算のSDURに使用されます。 しかしながら、SDUR分野が3バイト長にすぎないので、直接、持続時間値が(2^24-1)/(タイムスタンプclockrate)より大きいテキストのサンプル[秒]を流すことができません。 解決策は簡単です: コピーの対応するテキストはSHALLを抽出します。送ります。 その結果、タイムスタンプと持続時間は調整されたそうがそのa連続した表示であったならSHALLを評価します。
Rey & Matsui Standards Track [Page 28] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[28ページ]RFC4396有効搭載量形式
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.
まるでちょうど1個のサンプルを送るかのように、保証されます。 そのようなタイムスタンプの持続時間のTS1、TS2、SDUR1、およびSDUR2を持っている2個のサンプル、そのTS1=TS、TS2=TS1+SDUR1、およびSDUR=SDUR1+SDUR2としてすなわち、タイムスタンプTSと持続時間SDURがあるサンプルを送ることができます。
o Text sample length from the Sample Size Box (stsz). The
(unsigned) 32 bits of the "sample size" or "entry size" (one
of them, depending on whether the sample size is fixed or
variable) indicate the length (in bytes) of the 3GP text
sample. For obtaining the length of the (actual) streamed
text sample, the lengths of the text string byte count (2
bytes) and, in case of UTF-16 strings, the length the BOM
(also 2 bytes) SHALL be deducted. This is illustrated in
Figure 9.
o Sample Size Box(stsz)からのテキストサンプルの長さ。 「サンプルサイズ」か「エントリーサイズ」(それらの1つ、サンプルサイズが固定されているかどうかによるか、または変数)の(無記名)の32ビットは3GPテキストのサンプルの長さ(バイトによる)を示します。 (実際)の流されたテキストのサンプルの長さを得るために、テキスト文字列バイトの長さは(2バイト)を数えて、UTF-16ストリングの場合の長さはBOM(2バイトも)SHALLを数えます。差し引かれます。 これは図9で例証されます。
Text Sample according to 3GPP TS 26.245
3GPP t26.245に従ったテキストのサンプル
TEXT SAMPLE (length=stsz)
.--------------------------------------------------.
/ \
TEXT STRING (length=TBC)
.------------------------------------.
/ \
TBC BOM MODIFIERS
+---+---+----------------------------------+-----------+
||
|| TBC BOM -> TLEN field
|| +---+---+ U bit
||
\/
テキストのサンプル(長さはstszと等しいです)。--------------------------------------------------. /\テキスト文字列(長さ=TBC。)------------------------------------. /\TBC BOM修飾語+---+---+----------------------------------+-----------+ || || TBC BOM->TLEN分野|| +---+---+ Uビット|| \/
Text Sample according to this Payload Format
この有効搭載量Formatに従ったテキストSample
TEXT SAMPLE (length=SLEN w/o TBC,BOM)
.--------------------------------------------.
/ \
TEXT STRING (length=TLEN)
.--------------------------------.
/ \
TEXT STRING MODIFIERS
+----------------------------------+-----------+
テキストのサンプル(長さはTBC、BOMなしでSLENと等しいです)。--------------------------------------------. /\テキスト文字列(長さ=TLEN。)--------------------------------. /\テキスト文字列修飾語+----------------------------------+-----------+
KEY:
TBC = Text string Byte Count
BOM = Byte Order Mark
キー: テキスト文字列TBC=Byte Count BOMはバイトOrderマークと等しいです。
Figure 9. Text sample composition
図9。 テキストサンプル構成
Rey & Matsui Standards Track [Page 29] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[29ページ]RFC4396有効搭載量形式
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).
そのうえ、TYPE1個のヘッダーのLEN分野が(2^16-1-8)[バイト]SHALL NOTより16ビット長くて、大きいテキストサンプルサイズであるので、流されてください。 また、この場合、拡大メカニズムは全く定義されません。 これはこの最大が狙っているストリーミング・アプリケーションのために十分考えられるからです。 (注意: LEN値にTYPE1ヘッダーフィールドを含むための8(8)アカウント)。
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 Boxは、サンプルと彼らの対応するサンプル記述を見つけるのに使用されます。 これらは「サンプル記述インデックス」、32ビット(無記名の)の整数によって参照をつけられます。 できれば、これらのインデックスリストは直接SIDX分野に写像されるかもしれません。 しかしながら、数個のケースがこれが可能でないかもしれないところにあります:
a) The total number of indices used is greater than
the number of indices available, i.e., if the static
sample descriptions are more than 127 or the dynamic ones
are more than 64.
a) 使用されるインデックスリストの総数はインデックスリストの有効な数より大きいです、すなわち、静的なサンプル記述が127以上であるかダイナミックなものが64以上であるなら。
b) The original SIDX value ranges do not fit in the
allowed ranges for static (129-254) or dynamic (0-127)
values.
b) 元のSIDX値の範囲は静電気(129-254)かダイナミックな(0-127)値のための許容範囲をうまくはめ込みません。
Therefore, when assigning SIDX values to the sample
descriptions, the following guidelines are provided:
したがって、サンプル記述への値をSIDXに割り当てるとき、以下のガイドラインを提供します:
o Static sample descriptions can simply be assigned
consecutive values within the range 129-254 (closed
interval). This range should be well enough for static
sample descriptions.
o 範囲129-254(閉じている間隔)の中で単に静的なサンプル記述に連続した値を割り当てることができます。 静的なサンプル記述に、この範囲はよく十分であるべきです。
o As for dynamic sample descriptions:
o 動力に関して、記述を抽出してください:
a) Streams that use less than 64 dynamic sample
descriptions SHOULD use consecutive values for SIDX
anywhere in the range 0-127 (closed interval).
a) 64未満のダイナミックなサンプル記述SHOULDを使用する流れはSIDXに範囲0-127(閉じている間隔)でどこでも連続した値を使用します。
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におけるアルゴリズムによると)が再送されて、割り当てられる必要があるでしょう。
Rey & Matsui Standards Track [Page 30] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[30ページ]RFC4396有効搭載量形式
Information obtained from the Media Data Box:
情報はメディアからData Boxを入手しました:
o Text strings, TLEN, U bit, and modifiers from the Media Data
Box (mdat). Text strings, 16-bit text string byte count, Byte
Order Mark (BOM, indicating UTF encoding), and modifier boxes
can be found here.
o メディアData Box(mdat)からのテキスト文字列、TLEN、Uビット、および修飾語。 ここでテキスト文字列、16ビットのテキスト文字列バイト・カウント、Byte Orderマーク(UTFコード化を示すBOM)、および修飾語箱を見つけることができます。
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.
TYPE1ユニットに関しては、TLENの値はテキストのサンプルでテキスト文字列に先行するテキスト文字列バイト・カウントから抽出されます、3GPファイルに格納されるように。 UTF-16コード化が使用されているなら、より多くの(2)バイトが差し引かれるために持っている2はあらかじめこのバイトから重要です、BOMを除くために。 図9を参照してください。
4.4. Fragmentation of Timed Text Samples
4.4. 調節されたテキストのサンプルの断片化
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 Timed Textアプリケーションが低いbitratesで作動すると予想されます。 この事実、調節されたテキストのサンプルの小型に加えられて、(通常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.
それにもかかわらず、いくつかのテキスト文字列(例えば、映画の終わりのロール)といくつかの修飾語箱(すなわち、ハイパーリンク、カラオケ、またはスタイルのための)が大きくなるかもしれません。 また、これは将来の修飾語箱に申し込むかもしれません。 そのような場合、考える第1の選択は断片化が避けられるような方法で、コード化(例えば、サンプルのサイズ)を調整するのが可能であるかどうかということです。 それがそうなら、断片化とSHOULDよりこれを好みます。します。
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 テキストのサンプルが可能で、すなわち、最も可能でない数の断片がテキストのサンプルから作成されるのと同じくらいめったに断片化されないのは、RECOMMENDEDです。
o If there is some bitrate and free space in the payload available,
sample descriptions (if at hand) SHOULD be aggregated.
o いくらかのbitrateと空きスペースがあれば、ペイロード利用可能なサンプル記述(近いなら)SHOULDで集められてください。
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
o テキスト文字列は文字境界で分かれなければなりません。 TYPE2ヘッダーを見てください。 さもなければ、前の断片がなくされたなら、断片のテキストコンテンツを表示するのは可能ではありません。 結果、テキストとして
Rey & Matsui Standards Track [Page 31] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[31ページ]RFC4396有効搭載量形式
string fragmentation requires knowledge of the UTF-8/UTF-16
encoding formats to determine character boundaries.
ストリング断片化は、文字境界を決定するために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 テキスト文字列と異なって、修飾語箱は重要な境界で分けられるべきNOT REQUIREDです。 しかしながら、可能であるときはいつも、これをするのは、RECOMMENDEDです。 これはパケット損失の影響を静まらせます。 このペイロード形式は、部分的に、容認された修飾語がテキスト文字列に適用されるのを確実にしません。 修飾語の部分だけが受け取られているなら、すなわち、どのようにこれらに対処するかが、アプリケーション問題である、それらを使用であるかどうか
Informative note: Ensuring that partially received modifiers can
be applied to text strings in all cases (for all modifier types
and for all fragment loss constellations) would place additional
requirements on the payload format. In particular, this would
require that: a) senders understand the semantics of the
modifier boxes and b) specific fragment headers for each of the
modifier boxes are defined, in addition to the payload formats
defined below. Understanding the modifiers semantics means
knowing, e.g., where each modifier starts and ends, which text
fragments are affected, which modifiers may or may not be split,
or what the fields indicate. This is necessary to be able to
split the modifiers in such a way that each fragment can be
applied independently of previous packet losses. This would
require a more intelligent fragmentation entity and more complex
headers. Given the low probability of fragmentation and the
desire to keep the requirements low, it does not seem reasonable
to specify such modifier box specific headers.
有益な注意: 部分的に、すべての場合(すべての修飾語タイプとすべての断片損失星座のための)で容認された修飾語をテキスト文字列に適用できるのを確実にするのがペイロード形式に追加要件を置くでしょう。 これが、以下のことが特に、必要でしょう。 a) 送付者は修飾語箱の意味論を理解しています、そして、それぞれの修飾語箱のためのb)特定の断片ヘッダーは定義されます、以下で定義されたペイロード書式に加えて。 修飾語意味論が、例えば、各修飾語が始まって、終わるところのどのテキスト断片が影響を受けるか、そして、どの修飾語が分けられるかもしれないか、そして、または分野が何を示すかを知っていることを意味するのを理解しています。 これが、前のパケット損失の如何にかかわらず各断片を適用できるような方法で修飾語を分けることができるように必要です。 これは、より知的な断片化実体と、より複雑なヘッダーを必要とするでしょう。 断片化の低い確率と要件を低く保つ願望を考えて、そのような修飾語の箱の特定のヘッダーを指定するのは妥当に思えません。
o Modifier and text string fragments SHOULD be protected against
packet losses, i.e., using FEC [7], retransmission [11], repetition
(Section 5), or an equivalent technique. This minimizes the
effects of packet loss.
o 修飾語とテキスト文字列はパケット損失に対して保護されて、すなわち、使用しているFECが[7]、「再-トランスミッション」[11]、反復(セクション5)、または同等なテクニックであったならSHOULDを断片化します。 これはパケット損失の影響を最小にします。
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 テキストのサンプルを断片化するとき、追加要件はそのために定義されたペイロードヘッダーを使用して、修飾語の始まりを示さなければならなくて、すなわち、TYPE3ユニットを使用しなければならないという(セクション4.1.4を見てください)ことです。 これは2がない限り、修飾語の始まりを検出する受信機か、より連続したパケット損失を可能にします。
o Finally, sample descriptions SHALL NOT be fragmented because they
contain important information that may affect several text samples.
o 最終的に、記述SHALL NOTを抽出してください。いくつかのテキストのサンプルに影響するかもしれない重要情報を含むので、断片化されてください。
Rey & Matsui Standards Track [Page 32] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[32ページ]RFC4396有効搭載量形式
4.5. Reassembling Text Samples at the Receiver
4.5. 受信機でテキストのサンプルを組み立て直します。
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)、およびペイロードヘッダーの分野TOTAL/THISは使用されています。
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.
同じテキストのサンプルに属すユニットは同じタイムスタンプを持たなければなりません。 ユニットがするTYPE5は、それらがどんな特定のテキストのサンプルの一部でないのでも、この規則に従いません。
The process for collecting the different fragments (units) of a text sample is as follows:
テキストのサンプルの異なった断片(ユニット)を集めるための過程は以下の通りです:
1. Search for units having the same timestamp value, i.e., units
that belong to the same text sample or sample descriptions that
shall become available at that time instant. If several units
of the same sample are repeated, only one of them SHALL be used.
Repeated units are those that have the same timestamp and the
same values for TOTAL/THIS.
1. 同じタイムスタンプ値(すなわち、その時利用可能になる同じテキストのサンプルかサンプル記述に即時で属すユニット)を持っているユニットを捜し求めてください。 数個なら、同じユニットのサンプルは繰り返されて、唯一の1つはそれらのSHALLです。使用されます。 繰り返されたユニットは同じタイムスタンプと同じ値が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.
受信機SHALLがセクション4.1.1で言及されるように認識されていないTYPE値があるユニットを無視することに注意してください。 しかしながら、RTPヘッダーフィールドとペイロードにおける、ユニット(もしあれば)の残りはまだ役に立っています。
2. Check within this set whether any of the units from the text
sample is missing. This is done using the TOTAL and THIS
fields; the TOTAL field indicates how many fragments were
created out of the text sample, and the THIS field indicates the
position of this fragment in the text sample. As result of this
operation, two outcomes are possible:
2. このセットの中でテキストのサンプルからのユニットのどれかがなくなるかどうかチェックしてください。 これはTOTALとTHIS分野を使用し終わっています。 TOTAL分野は、いくつの断片がテキストのサンプルから作成されたかを示します、そして、THIS分野はテキストのサンプルでこの断片の位置を示します。 この操作の結果として、2つの結果が可能です:
a. No fragment is missing. Then, the THIS field SHALL be used
to order the fragments and reassemble the text sample
before forwarding it to the decoding application. Special
care SHALL be taken when reassembling the text string as
indicated in bullet 4 below.
a。 どんな断片もなくなっていません。 その時(SHALLが解読アプリケーションにそれを送りながら断片を注文するのに使用されて、テキストのサンプルを組み立て直すTHIS分野)。 特別番組はSHALLについて気にかけます。以下の弾丸4にみられるようにテキスト文字列を組み立て直すときには、取ってください。
b. One or more fragments are missing: Check whether this
fragment belongs to the text string or to the modifiers.
TYPE 2 units identify text string fragments, and TYPE 3 and
4 identify modifier fragments:
b。 ある断片がなくなっています: この断片がテキスト文字列、または、修飾語に属するかどうかチェックしてください。 TYPE2ユニットはテキスト文字列断片を特定します、そして、TYPE3と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
i。 消えて、断片か断片であるならテキスト文字列に属して、完全な状態で修飾語を受け取りました、そして、次に、プレーンテキストとして容認されたテキストキャラクタを少なくとも見せてもよいです。 いくつかの修飾語があるだけであるかもしれません。
Rey & Matsui Standards Track [Page 33] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[33ページ]RFC4396有効搭載量形式
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.
キャラクタ番号を特定するのが可能である限り、適用されて、例えば、最後のテキスト文字列断片が無くなりさえする場合、よかったでしょう。 これは、特定のフォント・スタイルを定義する修飾語のためのそう('styl')で、強調されたキャラクタ('hlit')と、カラオケの特徴('krok')と、キャラクタ('blnk')を明滅することにさせます。 キャラクタ番号に関する知識なしで'dlay'か'tbox'などの他の修飾語を適用できます。 それは修飾語を適用するかどうか決めるアプリケーション問題です。
ii. If the fragment missing belongs to the modifiers and
the text strings were received complete, then the
incomplete modifiers may be used. The text string
SHOULD at least be displayed as plain text. As
mentioned in Section 4.4, modifiers may split without
observing meaningful boundaries. Hence, it may not
always be possible to make use of partially received
modifiers. However, to avoid this, it is RECOMMENDED
that the modifiers do split at meaningful boundaries.
ii。 完全な状態で断片の取り逃がすのが修飾語に属すか、そして、テキスト文字列を受け取って、次に、不完全な修飾語を使用するかもしれません。 テキストはSHOULDを結びます。プレーンテキストとして少なくとも表示します。 セクション4.4で言及されるように、重要な境界を観測しないで、修飾語は分かれるかもしれません。 したがって、容認された修飾語を部分的に利用するのはいつも可能であるかもしれないというわけではありません。 しかしながら、これを避けるために、修飾語が重要な境界で分かれるのは、RECOMMENDEDです。
iii. A third possibility is that it is not possible to
discern whether modifiers or text strings were received
complete. For example, if the TYPE 3 unit of a sample
plus the following or preceding packet is lost, there
is no way for the RTP receiver to know if one or both
packets lost belong to the modifiers or if there are
also some missing text strings. Repetition, FEC,
retransmission, or other protection mechanisms as per
section 4.6 are RECOMMENDED to avoid this situation.
iii。 3番目の可能性は修飾語かテキスト文字列が完全な状態で受け取られたかどうか明察するのが可能でないということです。 例えば、サンプルと以下か前の3つのパケットがTYPEであるなら無くなる、失われたものかパケットの両方が修飾語に属すかどうか、またはまた、いくつかのなくなったテキスト文字列があるかどうかを知るために、RTP受信機のための方法は全くありません。 反復、FEC、「再-トランスミッション」、またはセクション4.6に従って他の保護メカニズムがこの状況を避けるRECOMMENDEDです。
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ストリングにそれをprependしなければなりません(図9を見てください)。 UTF-16ストリングのビッグエンディアン連載だけがこのペイロード形式で後押しされているので、BOMの値は0xFEFFです。
Rey & Matsui Standards Track [Page 34] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[34ページ]RFC4396有効搭載量形式
4.6. On Aggregate Payloads
4.6. 集合有効搭載量に関して
Units SHOULD be aggregated to avoid overhead, whenever possible. The aggregate payloads MUST comply with one of the following ordered configurations:
ユニットSHOULD、可能であるときはいつも、集められて、オーバーヘッドを避けてください。 集合ペイロードは構成が注文された以下の1つに従わなければなりません:
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. ゼロか以上がゼロがあとに続いた記述(TYPE5)か全体以上のテキストのサンプル(TYPE1ユニット)を抽出します。 少なくとも1つのタイプが出席しているに違いありません。
2. Zero or more sample descriptions followed by zero or one modifier
fragment, either TYPE 3 or TYPE 4. At least one unit MUST be
present.
2. ゼロか以上がゼロがあとに続いた記述か1個の修飾語断片(TYPE3かTYPE4のどちらか)を抽出します。 少なくとも1個のユニットは存在していなければなりません。
3. Zero or more sample descriptions, followed by zero or one text
string fragment (TYPE 2), followed by zero or one TYPE 3 unit. If
a TYPE 2 unit and a TYPE 3 unit are present, then they MUST belong
to the same text sample. At least one unit MUST be present.
3. ゼロか以上がゼロがあとに続いた記述か1個のテキスト文字列断片(TYPE2)を抽出します、続いて、ゼロか1TYPEの3ユニットを抽出します。 3個のユニットがTYPE2ユニットとTYPEであるなら存在している、そして、彼らは同じテキストのサンプルに属さなければなりません。 少なくとも1個のユニットは存在していなければなりません。
Some observations:
いくつかの観測:
o Different aggregates than the ones listed above SHALL NOT be used.
o ものはSHALL NOTの上に記載しました。異なった集合、使用されます。
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 それらのコンテンツが他の数ユニットで流れで参照をつけられるかもしれないので、TYPE5ユニットの正しいレセプションは重要です。
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.
彼らの対応するサンプル記述が受け取られているまで、受信機はテキストのサンプルを使用できません。 それに従って、送付者SHOULDは、信頼性を確実にするためにサンプル記述の複本を送ります(セクション5を見てください)。 受信機は特定のサンプル記述を受けたと送付者に言うペイロード特有のフィードバックメッセージ[21]を使用するかもしれません。
o Regarding timestamp calculation: In general, the rules for
calculating the timestamp of units in an aggregate payload depend
on the type of unit. Based on the possible constellations for
aggregate payloads, as above, we have:
o タイムスタンプ計算に関して: 一般に、集合ペイロードでユニットに関するタイムスタンプについて計算するための規則はユニットのタイプに頼っています。 集合ペイロードのための可能な星座に基づいて、同じくらい上では、私たちが以下を持っています。
o Sample descriptions MUST receive the RTP timestamp of the
packet in which they are included.
o サンプル記述はそれらが含まれているパケットに関するRTPタイムスタンプを受け取らなければなりません。
Note that for TYPE 5 units, the timestamp actually does not
represent the instant when they are played out, but instead
the instant at which they become available for use.
TYPE5ユニットに関して、タイムスタンプが実際に、それらが使い果たされる瞬間、しかし、代わりにそれらが使用に利用可能になる瞬間を表さないことに注意してください。
Rey & Matsui Standards Track [Page 35] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[35ページ]RFC4396有効搭載量形式
o For the first configuration: The first TYPE 1 unit receives
the RTP timestamp. The timestamp of any subsequent TYPE 1
unit MUST be obtained by adding sample duration and
timestamp, both of the preceding TYPE 1 unit.
o 最初の構成のために: まず最初に、TYPE1ユニットはRTPタイムスタンプを受け取ります。 サンプル持続時間とタイムスタンプ、前のTYPEの両方を1ユニット加えることによって、どんなその後のTYPE1ユニットに関するタイムスタンプも得なければなりません。
o For the second and third configuration, all units, TYPE 2,
3, and 4, MUST receive the RTP timestamp.
o 2番目と3番目の構成のために、すべてのユニット(TYPE2、3、および4)がRTPタイムスタンプを受け取らなければなりません。
Refer to detailed examples on the timestamp calculation
below.
以下でのタイムスタンプ計算に関する詳細な例を参照してください。
o As per configuration 3 above, a payload MAY contain several
fragments of one (and only one) text sample. If it does, then
exactly one TYPE 2 unit followed by exactly one TYPE 3 unit is
allowed in the same payload. This is in line with RFC 3640 [12],
Section 2.4, which explicitly disallows combining fragments of
different samples in the same RTP payload. Note that, in this
special case, no timestamp calculation is needed. That is, the RTP
timestamp of both units is equal to the timestamp in the packet's
RTP header.
o 上の3、ペイロードがそうする構成に従って、1個(そして、1だけ)のテキストのサンプルの数個の断片を含んでください。 そうするなら、次に、ちょうど1TYPE2のユニットは同じペイロードに許容されています、続いて、ちょうど1TYPEの3個のユニットを許容します。 これはRFC3640[12]、同じRTPペイロードで異なったサンプルの断片を結合するのを明らかに禁じるセクション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 最終的に、空のテキストのサンプルの使用が、同じペイロードで非連続したTYPEに1ユニット集めると考慮することに注意してください。 TS1+SDUR1<TS3を持っているなら、2個のテキストのサンプルはタイムスタンプの持続時間のTS1、TS3、SDUR1、およびSDUR3について連続していません。 この解決策はそれらの間の持続時間SDUR2と共に空のTYPEを1ユニット含むことです、TS2+SDUR2がTS1+SDUR1+SDUR2=TS3と等しいように。
Some examples of aggregate payloads are illustrated in Figure 10. (Note: The figure is not scaled.)
集合ペイロードに関するいくつかの例が図10で例証されます。 (注意: 図はスケーリングされていません。)
Rey & Matsui Standards Track [Page 36] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[36ページ]RFC4396有効搭載量形式
N/A TS1 TS2 TS3
+------+-----+------+-----+
|TYPE5 |TYPE1|TYPE1 |TYPE1|
+------+-----+------+-----+
N/A sdur1 sdur2 sdur3
なし、TS1 TS2 TS3+------+-----+------+-----+ |TYPE5|TYPE1|TYPE1|TYPE1| +------+-----+------+-----+ N/はsdur1 sdur2 sdur3です。
N/A TS4
+-----+-------+
|TYPE5| TYPE 1| a)
+-----+-------+
N/A sdur4
なし、TS4+-----+-------+ |TYPE5| 1をタイプしてください。| a) +-----+-------+ N/はsdur4です。
TS4 TS4 TS4
+--------------+ +--------------+
| TYPE2 | |TYPE2 |TYPE 3 | b)
+--------------+ +--------------+
sdur4 sdur4 sdur4
TS4 TS4 TS4+--------------+ +--------------+ | TYPE2| |TYPE2|3をタイプしてください。| b) +--------------+ +--------------+ sdur4 sdur4 sdur4
TS4 TS4
+--------------+ +--------------+
| TYPE2| TYPE 3| | TYPE4 | c)
+--------------+ +--------------+
sdur4 sdur4 sdur4
TS4 TS4+--------------+ +--------------+ | TYPE2| 3をタイプしてください。| | TYPE4| c) +--------------+ +--------------+ sdur4 sdur4 sdur4
|----------PAYLOAD 1------| |--PAYLOAD 2---| |--PAYLOAD 3---|
rtpts1 rtpts2 rtpts3
|----------ペイロード1------| |--ペイロード2---| |--ペイロード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
キー: Text Sample x N/の有効搭載量y sdurx=持続時間のための標準のRTP TSx=テキストSample x rtptsy=タイムスタンプは適切でない=です。
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、fourテキストでは、サンプル(TS1からTS4)に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)は、各ユニットタイムスタンプがどのように見つけられるかを例証するために選ばれています。
Rey & Matsui Standards Track [Page 37] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[37ページ]RFC4396有効搭載量形式
N/A TS1 TS2 TS3 TS4 TS4 TS4
+------+-----+------+-----+ +--------------+ +--------------+
|TYPE5 |TYPE1|TYPE1 |TYPE1| | TYPE2 | |TYPE2 |TYPE 3 |
+------+-----+------+-----+ +--------------+ +--------------+
N/A sdur1 sdur2 sdur3 sdur4 sdur4 sdur4
なし、TS1 TS2 TS3 TS4 TS4 TS4+------+-----+------+-----+ +--------------+ +--------------+ |TYPE5|TYPE1|TYPE1|TYPE1| | TYPE2| |TYPE2|3をタイプしてください。| +------+-----+------+-----+ +--------------+ +--------------+ N/はsdur1 sdur2 sdur3 sdur4 sdur4 sdur4です。
(#1) (#2) (#3) (#4) (#5) (#6) (#7)
(#1) (#2) (#3) (#4) (#5) (#6) (#7)
|----------PAYLOAD 1------| |--PAYLOAD 2---| |--PAYLOAD 3---|
rtpts1 rtpts2 rtpts3
|----------ペイロード1------| |--ペイロード2---| |--ペイロード3---| rtpts1 rtpts2 rtpts3
Figure 11. Selected payloads from Figure 10
図11。 図10からの選択されたペイロード
Assuming TSx means Text Sample x, rtptsy represents the standard RTP timestamp for PAYLOAD y and sdurx, the duration of Text Sample x, the timestamp for unit #z, ts(#z), can be found as the sum of rtptsy and the cumulative sum of the durations of preceding units in that payload (except in the case of PAYLOAD 3 as per rule 3 above). Thus, we have:
TSxがText Sample xを意味すると仮定して、rtptsyは有効搭載量yとsdurxのための標準のRTPタイムスタンプを表します、Text Sample xの持続時間、rtptsyの合計とそのペイロード(規則3上に従って有効搭載量3に関するケースを除いた)の前の単位の持続時間の累積合計としてz(t(#z))を見つけることができるユニット#タイムスタンプ。 したがって、私たちには、以下があります。
1. for the units in the first aggregate payload, PAYLOAD 1:
1. 1番目の何ユニットも、ペイロード、有効搭載量1に集めてください:
ts(#1) = rtpts1
ts(#2) = rtpts1
ts(#3) = rtpts1 + sdur1
ts(#4) = rtpts1 + sdur1 + sdur2
rtpts1+sdur1rtpts1rtpts1t(#1)=t(#2)=t(#3)=t(#4)はrtpts1+sdur1+sdur2と等しいです。
Note that the TYPE 5 and the first TYPE 1 unit have both the
RTP timestamp.
TYPE5と最初のTYPEが1ユニットそうすることに注意してください。両方のRTPタイムスタンプ。
2. for PAYLOAD 2:
2.、ペイロード2のために:
ts(#5) = rtpts2
t(#5)はrtpts2と等しいです。
3. for PAYLOAD 3:
3.、ペイロード3のために:
ts(#6) = ts(#7) = rtpsts2 = rtpts3
t(#6)=t(#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.
構成によると、ユニットがTYPEであるものとする3上のTYPE、TYPE2、およびTYPE3は同じサンプルに属します。 したがって、rtpts3はrtpts2と等しいに違いありません。 同じ理由からSDURの値はそうではありません。次のユニットに関するタイムスタンプについて計算するために、使用されます。
Rey & Matsui Standards Track [Page 38] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[38ページ]RFC4396有効搭載量形式
4.7. Payload Examples
4.7. 有効搭載量の例
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) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE1| LEN(いつも>=8)| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| TLEN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLEN| | +---------------+ | | テキスト文字列(No.バイトはTLENと等しいです)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 修飾語(No.バイトはレン--8--TLENと等しいです)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE1| LEN(いつも>=8)| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| TLEN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLEN| | +---------------+ | | テキスト文字列(No.バイトはTLENと等しいです)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 修飾語(No.バイトはレン--8--TLENと等しいです)| | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12. A payload carrying two TYPE 1 units
図12。 2TYPEを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、2TYPE1を運ぶRTPパケットでは、ユニットは表現されます。 次のユニットの始まり(LEN)、修飾語の始まり(TLEN)、および修飾語の長さ(レン-TLEN)を見つけるのにどのように長さの分野のLENとTLENを使用できるか見ることができます。
Rey & Matsui Standards Track [Page 39] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[39ページ]RFC4396有効搭載量形式
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) |
| |
| |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE5| LEN(いつも>3)| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | サンプル記述(No.バイト=LEN--3)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE1| LEN(いつも>=8)| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| TLEN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLEN| | +-+-+-+-+-+-+-+-+ | | テキスト文字列断片(No.バイトはTLENと等しいです)| | | | | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13. An RTP packet carrying a TYPE 5 and a TYPE 1 unit
図13。 TYPE5とTYPEを1ユニット運ぶRTPパケット
In Figure 13, a sample description and a TYPE 1 unit are aggregated. The TYPE 1 unit happens to contain only text strings and is small, so an additional TYPE 5 unit is included to take advantage of the available bits in the packet.
図13、サンプル記述、およびTYPE1では、ユニットは集められます。 TYPE1ユニットがテキスト文字列だけがたまたま含んで、小さいので、追加TYPE5ユニットは、パケットで有効なビットを利用するために含まれています。
Rey & Matsui Standards Track [Page 40] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[40ページ]RFC4396有効搭載量形式
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) |
| |
: :
: :
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE2| LEN(いつも>9)|=4を合計してください。|この=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLEN| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | テキスト文字列断片(No.バイト=LEN--9)| | | : : : : | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14. Payload with first text string fragment of a sample
図14。 サンプルの最初のテキスト文字列断片がある有効搭載量
In Figures 14, 15, and 16, a text sample is split into three RTP packets. In Figure 14, the text string is big and takes the whole packet length. In Figure 15, the only possibility for carrying two fragments of the same text sample is represented (see configuration 3 in Section 4.6). The last packet, shown in Figure 16, carries the last modifier fragment, a TYPE 4.
図14、15、および16では、テキストのサンプルは3つのRTPパケットに分けられます。 図14では、テキスト文字列は、大きく、全体のパケット長を取ります。 図15では、同じテキストのサンプルの2個の断片を運ぶための唯一の可能性が表されます(セクション4.6で構成3を見てください)。 図16で見せられた最後のパケットは最後の修飾語断片、TYPE4を運びます。
Rey & Matsui Standards Track [Page 41] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[41ページ]RFC4396有効搭載量形式
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) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE2| LEN(いつも>9)|=4を合計してください。|この=2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| SIDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLEN| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | テキスト文字列断片(No.バイト=LEN--9)| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE3| LEN(いつも>6)|=4を合計してください。|この=3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 修飾語(No.バイト=LEN--6)| | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15. An RTP packet carrying a TYPE 2 unit and a TYPE 3 unit
図15。 TYPE2ユニットとTYPE3ユニットを運ぶRTPパケット
Rey & Matsui Standards Track [Page 42] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[42ページ]RFC4396有効搭載量形式
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) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| R|TYPE4| LEN(いつも>6)|=4を合計してください。|この=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDUR| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | 修飾語(No.バイト=LEN--6)| | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16. An RTP packet carrying last modifiers fragment (TYPE 4)
図16。 最後の修飾語断片を運ぶRTPパケット(タイプ4)
4.8. Relation to RFC 3640
4.8. RFC3640との関係
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].
RFC3640[12]はどんな非多重送信されたMPEG-4基本のストリームの輸送のためにもペイロード書式を定義します。 MPEG-4人の様々な基本のストリーム型のひとりはまた、ISO/IEC14496-17として知られているMPEG-4部分17[26]で指定されたMPEG-4つの調節されたテキストストリームです。 調節されたテキストストリームが運ぶことができるMPEG-4 3GPPは3GPP TS26.245[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.
MPEG-4つの調節されたテキストストリームが、RFC3640とこのペイロード形式の間の相互運用性を保証するために故意に構成されます。 これは、調節されたテキストを運ぶRTPパケットの工事が同じであることを意味します。 すなわち、ISO/IEC14496-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/IEC14496-17で定義されたTimed Text Units(TTUs)と同じです。 同様に、セクション4.6に従ってペイロード集合のための規則は、ISO/IEC14496-17で定義されたものと同じであり、RFC3640と共に対応します。 その結果、このペイロード形式を使用するRTPパケットはISO/IEC14496-17によると、TTUsを運びながらRFC3640を使用するのがRTPパケットと同じです。 使用するとき、特に、MPEG-4Part17はそれを指定します。
Rey & Matsui Standards Track [Page 43] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[43ページ]RFC4396有効搭載量形式
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.
調節されたテキストストリームを輸送するためのRFC3640、"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 |
+-------------------------------------------------------------------+
+--------------------------------------+ テキストのサンプル| +--------------+ +--------------+ | 3GPPに従って| |テキストのサンプル1| |テキストのサンプルN| | t26245| +--------------+ +--------------+ | +--------------------------------------+ \/ +-------------------------------------------------------------------+ | Text Samplesをユニットに仕切ってください。 TTU[i]= TYPE iユニット。 | | | |[U Rタイプレン]、[総である、これ、SIDX SDUR、TLEN、SLEN] [SampleContents]| |現在ですが、適切であることを意味する、[]、手段はいつも提示します。| +-------------------------------------------------------------------+ \/ \/ +-------------------------------------------------------------------+ | 集合(できれば)| +-------------------------------------------------------------------+ \/ \/ +-------------------------------------------------------------------+ | RTP EntityはRTPヘッダーとSends RTPパケット、どこを加えて、いっぱいにしているか。| | この有効搭載量Format=に従ったRTPパケット| | MPEG-4Timed Text ESをRFC3640の上まで運ぶRTPパケット| +-------------------------------------------------------------------+
Figure 17. Relation to RFC 3640
図17。 RFC3640との関係
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.
以下に注意してください。 RFC3640のISO/IEC14496-17データの輸送の使用はどんな新しいSDPパラメタか少しの新型定義も必要としません。
4.9. Relation to RFC 2793
4.9. RFC2793との関係
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.
RFC2793[22]とその改正(RFC4103[23])はテキストの会話を可能にするのにプロトコルを指定します。 このペイロード形式の主用途は、テキストコミュニケーション端末とテキスト会議ツールです。 テキストセッション内容はITU-T Recommendation T.140[24]で指定されます。 T.140テキストはT.140[24]で付加的な縁どりなしで指定されるようにコード化されたUTF-8です。 T140blockはT.140の指定されるとしての1個以上のT.140コード要素を含んでいます。 コード要素は、「復帰改行」などの制御配列である、「ストリングターミネーター」と「中断する」か、または「ストリングを始動します」。 ほとんどのT.140コード要素が独身のISO10646[25]キャラクタですが、何かが複数のキャラクタシーケンスです。 各キャラクタはUTF-8が1つ以上の八重奏に[18]をコード化したということです。
Rey & Matsui Standards Track [Page 44] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[44ページ]RFC4396有効搭載量形式
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 Timed Textメディア形式の差別化の特徴はテキストデコレーションを許容するということです。 これはマルチメディアプレゼンテーション、カラオケ、商業バナー、ニュースティッカー、クリック可能なテキスト文字列、および見出しで特に役に立ちます。 RFC2793で使用される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、パケット冗長SHOULDで使用されるように説明するので。 セクション4.6の集合ガイドラインは余分なペイロードを許容します。
5. Resilient Transport
5. 立ち直りの早い輸送
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.
完全なペイロードのケースに関して、単一の繰り返された単位はまさに最初のトランスミッションで送られた同じユニットに合わなければなりません。 断片化が必要であり、それはSHALLです。すなわち、それぞれのテキストのサンプルのためにかつてだけ実行されてください。 そしてだけ、受信機は、原本のサンプルを再建するのに既に受け取られているのと繰り返されたユニットを使用できます。 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.
例えば、また、元々ただ一つの非断片化しているテキストのサンプル(1TYPEの1ユニット)としてテキストのサンプルを送ったなら、ただ一つの非断片化しているテキストのサンプルとして1ユニットでそのサンプルの反復を送らなければなりません。 同様に、原本のサンプルがいくつかのRTPパケットの上で断片化されて、広まったなら(たとえば、合計3ユニット)、繰り返された断片はSHALLがまた、同じバイト境界を持って、同じユニットヘッダーとバイトを使用する単位断片化します。
Rey & Matsui Standards Track [Page 45] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[45ページ]RFC4396有効搭載量形式
With repetition, repeated units resolve to the same timestamp as their originals. Where redundant units are available, only one of them SHALL be used.
反復、それらのオリジナルと同じタイムスタンプへの繰り返されたユニット決心で。 余分であるところでは、ユニットが利用可能であり、唯一の1つはそれらのSHALLです。使用されます。
Regarding the RTP header fields:
RTPヘッダーを見なすと、以下はさばかれます。
o If the whole RTP payload is repeated, all payload-specific fields
in the RTP header (the M, TS and PT fields) MUST keep their
original values except the sequence number, which MUST be
incremented to comply with RTP (the fields TOTAL/THIS enable to
re-assemble fragments with different sequence numbers).
o 全体のRTPペイロードが繰り返されるなら、一連番号を除いて、RTPヘッダー(M、TS、およびPT分野)のすべてのペイロード特有の分野がそれらの元の値を保たなければなりません。(RTP(TOTAL/THISが異なった一連番号で断片を組み立て直すのを可能にする分野)に従うためにそれを増加しなければなりません)。
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]、または同様のテクニックなどの他のメカニズムを使用できました。
6. Congestion Control
6. 輻輳制御
Congestion control for RTP SHALL be implemented in accordance with RTP [3] and the applicable RTP profile, e.g., RTP/AVP [17].
RTP SHALLのために混雑を制御します。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 (ユニット)集合の使用で、ペイロードはヘッダーオーバーヘッドを避けて、その結果、中古のbitrateを減少させることによって効率的なより多くの帯域幅をフォーマットするかもしれません。
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 弾力がある移送機構の使用: 調節されたテキストアプリケーションは低いbitratesで通常作動しますが、立ち直りの早い輸送による増加は、メカニズムこれがすべてのメカニズムに適用する輻輳制御のために考えられますが、特にそれほど効率的でないものに反復が好きであるものとします。
Rey & Matsui Standards Track [Page 46] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[46ページ]RFC4396有効搭載量形式
7. Scene Description
7. 場面記述
7.1. Text Rendering Position and Composition
7.1. テキストレンダリング位置と構成
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
+-------------------------------------------+ | <。>tx| +-------------+ | +-------------------------------+ | <、-、--、|ディスプレイ領域| | ^ | | | +-------------+ | : | | | | :ty| | | +-------------+ | : | | <、-、-、-、-、-、-、-、--、|ビデオ道| | : | | | +-------------+ | : | | | | : | | | | : | | | | v| | | | - | x-------------------------+ | | +-------------+ |h^| | | <、-、-、-、-、-、-、-、-、-、--、|テキスト探知| |e: +---|-------------------------|-+ | +-------------+ |i: | +---------------------+ | | |g: | | | | | +-------------+ |h: | | | <、-、-、-、-、-、-、-、-、-、-、-- |テキストボックス| |t v| +---------------------+ | | +-------------+ | - +-------------------------+ | +-------------------------------------------+<… >w i d t h
Figure 18. Illustration of text rendering position and composition
図18。 テキストレンダリング位置と構成のイラスト
The parameters used for negotiating the position and size of the text track in the display area are shown in Figure 18. These are the "width" and "height" of the text track, its translation values, "tx" and "ty", and its "layer" or proximity to the user.
ディスプレイ領域のテキスト探知の位置とサイズを交渉するのに使用されるパラメタは図18に示されます。 これらは、そのユーザのテキスト探知の「幅」と「高さ」か翻訳値か"tx"と"ty"と、「層」か近接です。
At the same time, the sender of the stream needs to know the receiver's capabilities. In this case, the maximum allowable values for the text track height and width: "max-h" and "max-w", for the stream the receiver shall display.
同時に、ストリームの送付者は、受信機の能力を知る必要があります。 この場合、テキストのための最大の許容量は高さと幅を追跡します: 「最大h」と「最大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
例えば、セッションの始まりの前の信頼できるフォーム、セッション発表またはOffer/答えでこのレイアウト情報を伝えなければなりません。(O/a)交換。 信頼できる輸送に関する例はSDPに使用されるバンドで出かけているチャンネルであるかもしれません。 セクション8と9 提供してください。
Rey & Matsui Standards Track [Page 47] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[47ページ]RFC4396有効搭載量形式
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.
保存された内容において、Track Header Boxからストリームの特性を示すレイアウト値を得なければなりません。 セクション7.3を見てください。
For live streaming, appropriate values as negotiated during session setup shall be used.
ライブストリーミングのために、セッションセットアップの間に交渉される適切な値は使用されるものとします。
7.2. SMIL Usage
7.2. SMIL用法
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ファイルのTrack Header Boxesに含まれた属性は与えられた3GPファイルの中で道の空間的な関係を指定するだけです。
If multiple 3GP files are sent, they require spatial synchronization. For example, for a text and video stream, the positions of the text and video tracks in Figure 18 shall be determined. For this purpose, SMIL [9] MAY be used.
複数の3GPファイルを送るなら、彼らは空間的同期を必要とします。 例えば、図18のテキストとビデオ道の立場はテキストとビデオストリームにおいて、決定するようになるでしょう。 このために、SMIL[9]は使用されるかもしれません。
SMIL assigns regions in the display to each of those files and places the tracks within those regions. Generally, in SMIL, the position of one track (or stream) is expressed relative to another track. This is different from the 3GP file, where the upper left corner is the reference for all translation offsets. Hence, only if the position in SMIL is relative to the video track origin, then this translation offset has the same value as (tx, ty) in the 3GP file.
SMILはそれらの領域の中でそれぞれのそれらのファイルと場所へのディスプレイにおける領域に道を割り当てます。 一般に、SMILでは、1つの道(流れる)の位置は別の道に比例して言い表されます。 これは3GPファイルと異なっています。そこでは、左上隅はすべての翻訳オフセットの参照です。 したがって、SMILの位置がビデオ道の発生源に比例している場合にだけ、この翻訳オフセットは3GPファイルに(tx、ty)と同じ値を持っています。
Note also that the original track header information is used for each track only within its region, as assigned by SMIL. Therefore, even if SMIL scene description is used, the track header information pieces SHOULD be sent anyway, as they represent the intrinsic media properties. See 3GPP SMIL Language Profile in [27] for details.
また、オリジナルトラックヘッダー情報が領域だけの中の各道に使用されることに注意してください、SMILによって割り当てられるように。 したがって、SMIL場面記述が使用されていても、とにかく道のヘッダー情報断片SHOULDを送って、それらのように本質的なメディア所有地を表してください。 詳細のための[27]で3GPP SMIL Language Profileを見てください。
7.3. Finding Layout Values in a 3GP File
7.3. 3GPファイルのレイアウト値を見つけます。
In a 3GP file, within the Track Header Box (tkhd):
3GPでは、Track Header Box(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 tx、ty: これらの値はビデオ道の左上隅に比例して(テキスト)道の翻訳オフセットを指定します、存在しているなら。 統一マトリクスで、それらは、2番目にもかかわらず、最終と3番目にもかかわらず、最終値です。 値は定点の16.16の値の、そして、制限された(署名される)整数(すなわち、それぞれの価値の低級16ビットはゼロにすべてなる)です。 最初の16ビットだけが、メディア型引数の値を得るのに使用されます。
Rey & Matsui Standards Track [Page 48] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[48ページ]RFC4396有効搭載量形式
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ビットは使用されています。
8. 3GPP Timed Text Media Type
8. 3GPPはテキストメディアタイプを調節しました。
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 Timed Textコーデックのためのメディア「副-タイプ」を割り当てます。 このペイロード形式が登録されているトップレベルメディアタイプは'ビデオ'です。 この登録は[29]で定義されて、RFC3555[28]に続いて、テンプレートを使用し終わっています。
The receiver MUST ignore any unrecognized parameter.
受信機はどんな認識されていないパラメタも無視しなければなりません。
Media type: video
メディアは以下をタイプします。 ビデオ
Media subtype: 3gpp-tt
メディア「副-タイプ」: 3gpp-tt
Required parameters
必要なパラメタ
rate:
Refer to Section 3 in RFC 4396.
以下を評価してください。 RFC4396のセクション3を参照してください。
sver:
The parameter "sver" contains a list of supported
backwards-compatible versions of the timed text format
specification (3GPP TS 26.245) that the sender accepts
to receive (and that are the same that it would be
willing to send). The first value is the value
preferred to receive (or preferred to send). The first
value MAY be followed by a comma-separated list of
versions that SHOULD be used as alternatives. The order
is meaningful, being first the most preferred and last
the least preferred. Each entry has the format
Zi(xi*256+yi), where "Zi" is the number of the Release
and "xi" and "yi" are taken from the 3GPP specification
version (i.e., vZi.xi.yi). For example, for 3GPP TS
26.245 v6.0.0, Zi(xi*256+yi)=6(0), the version value is
"60". (Note that "60" is the concatenation of the
values Zi=6 and (xi*256+yi)=0 and not their product.)
sver: パラメタ"sver"は送付者が受信するために受け入れる調節されたテキスト書式仕様(3GPP TS26.245)のサポートしている後方にコンパチブルバージョンのリストを含んでいます(それはそれが送っても構わないと思っている同じくらいです)。 最初の値は受信するのが(または、発信するのを好みます)好ましい値です。 最初の値は続かれて、aが代替手段として使用されていた状態でSHOULDがあるバージョンのリストをコンマで切り離したということであるかもしれません。 最少が好んだ最初に、最も都合のよいのと最後でありオーダーは重要です。 各エントリーには形式Zi(ξ*256+yi)があります。そこでは、"Zi"がReleaseの数であり、「ξ」と"yi"は3GPP仕様バージョン(すなわち、vZi.xi.yi)から取られます。 例えば、3GPP TS26.245v6.0.0、Zi(ξ*256+yi)=6(0)に関して、バージョン値は「60インチ」です。 (「60インチは値Zi=6、および(ξ*256+yi) =0とそれらの製品でない)の連結です。」と述べてください。
If no "sver" value is available, for example, when
streaming out of a 3GP file, the default value "60",
corresponding to the 3GPP Release 6 version of 3GPP TS
26.245, SHALL be used.
3GPファイルから流れるとき、例えば、どんな"sver"値も利用可能でないなら、デフォルト値「3GPP t26.245の3GPPリリース6バージョンに対応する60インチは使用されるものとします」。
Rey & Matsui Standards Track [Page 49] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[49ページ]RFC4396有効搭載量形式
Optional parameters:
任意のパラメタ:
tx:
This parameter indicates the horizontal translation
offset in pixels of the text track with respect to the
origin of the video track. This value is the decimal
representation of a 16-bit signed integer. Refer to TS
3GPP 26.245 for an illustration of this parameter.
tx: このパラメタは、水平な翻訳がビデオ道の発生源に関するテキスト探知の画素で相殺されたのを示します。 この値は16ビットの署名している整数の10進表現です。 このパラメタのイラストについてTS 3GPP26.245を参照してください。
ty:
This parameter indicates the vertical translation offset
in pixels of the text track with respect to the origin
of the video track. This value is the decimal
representation of a 16-bit signed integer. Refer to TS
3GPP 26.245 for an illustration of this parameter.
ty: このパラメタは、垂直な翻訳がビデオ道の発生源に関するテキスト探知の画素で相殺されたのを示します。 この値は16ビットの署名している整数の10進表現です。 このパラメタのイラストについてTS 3GPP26.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によってコード化されたエントリーのコンマで切り離されたリストを含んでいます。 このリストのエントリーはどんな特定の注文とリストSHALL NOTにも従うかもしれません。空であってください。 各エントリーは8ビットの符号のない整数と(静電気)がそのSIDXのために記述を抽出しながら実行しているbase64が(静電気)の連結の上でSIDX値をコード化するという結果です、そのオーダーで。 3GPP TS26.245Release6以降リリースでサンプル記述エントリーの形式を見つけることができます。 すべてのサーバとクライアントは、このパラメタを理解しなければならなくて、それに含まれたサンプル記述を使用できなければなりません。 base64コード化に関する詳細のためのRFC3548[6]を参照してください。
width:
This parameter indicates the width in pixels of the text
track or area of the text being sent. This value is the
decimal representation of a 32-bit unsigned integer.
Refer to TS 3GPP 26.245 for an illustration of this
parameter.
幅: このパラメタはテキスト探知の画素か送られるテキストの領域で幅を示します。 この値は32ビットの符号のない整数の10進表現です。 このパラメタのイラストについてTS 3GPP26.245を参照してください。
Rey & Matsui Standards Track [Page 50] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[50ページ]RFC4396有効搭載量形式
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 3GPP26.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.
最大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.
最大h: このパラメタは表示能力を示します。 これはこのパラメタの送付者が支持する最大の「高さ」値です。 この値は32ビットの符号のない整数の10進表現です。
Encoding considerations:
問題をコード化します:
This media type is framed (see Section 4.8 in [29]) and
partially contains binary data.
このメディアタイプは罪に陥れられます。(セクション4.8がバイナリーデータを[29])と部分的に含むのを確実にしてください。
Restrictions on usage:
用法における制限:
This media type depends on RTP framing, and hence is only
defined for transfer via RTP [3]. Transport within other
framing protocols is not defined at this time.
このメディアタイプは、RTP縁どりによって、したがって、転送のためにRTP[3]を通して定義されるだけです。 他の縁どりプロトコルの中の輸送はこのとき、定義されません。
Security considerations:
セキュリティ問題:
Please refer to Section 11 of RFC 4396.
RFC4396のセクション11を参照してください。
Interoperability considerations:
相互運用性問題:
The 3GPP Timed Text media format and its file storage is
specified in Release 6 of 3GPP TS 26.245, "Transparent end-to-
end packet switched streaming service (PSS); Timed Text Format
(Release 6)". Note also that 3GPP may in future releases
specify extensions or updates to the timed text media format in
a backwards-compatible way, e.g., new modifier boxes or
extensions to the sample descriptions. The payload format
defined in RFC 4396 allows for such extensions. For future 3GPP
Releases of the Timed Text Format, the parameter "sver" is used
to identify the exact specification used.
3GPP TS26.245のRelease6、「透明な終わりから終わりに対するパケット切り換えられたストリーミングのサービス(PSS)」で3GPP Timed Textメディア形式とそのファイル記憶装置は指定されます。 「テキスト形式(リリース6)を調節します。」だった また、3GPPが今後のリリースで例えば、サンプル記述への後方にコンパチブル道、新しい修飾語箱または拡大で調節されたテキストメディア形式に拡大かアップデートを指定するかもしれないことに注意してください。 RFC4396で定義されたペイロード書式はそのような拡大を考慮します。 Timed Text Formatの将来の3GPP Releasesに関しては、パラメタ"sver"は、使用される正確な仕様を特定するのに使用されます。
Rey & Matsui Standards Track [Page 51] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[51ページ]RFC4396有効搭載量形式
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 Timed Text形式のための定義された格納形式は3GPP File Format(3GP)[30]です。 登録されるとしてのRFC3839[31]によるメディアタイプビデオ/3gppを使用することで3GPファイルを移すかもしれません。 3GPP File Formatは3GPP Timed Textと同期するかもしれないそれが含むかもしれない容器ファイルと、例えば、オーディオとビデオです。
Published specification: RFC 4396
広められた仕様: RFC4396
Applications which use this media type:
このメディアタイプを使用するアプリケーション:
Multimedia streaming applications.
マルチメディアストリーミング・アプリケーション。
Additional information:
追加情報:
The 3GPP Timed Text media format is specified in 3GPP TS 26.245,
"Transparent end-to-end packet switched streaming service (PSS);
Timed Text Format (Release 6)". This document and future
extensions to the 3GPP Timed Text format are publicly available
at http://www.3gpp.org.
3GPP TS26.245、「終わりから終わりに対するパケットわかりやすい切り換えられたストリーミングのサービス(PSS)」で3GPP Timed Textメディア形式は指定されます。 「テキスト形式(リリース6)を調節します。」だった 3GPP Timed Text形式へのこのドキュメントと今後の拡大は http://www.3gpp.org で公的に利用可能です。
Magic number(s): None.
マジックナンバー(s): なし。
File extension(s): None.
ファイル拡張子(s): なし。
Macintosh File Type Code(s): None.
マッキントッシュファイルタイプは(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.
ホセ・レイ、 jose.rey@eu.panasonic.com 松井義紀、 matsui.yoshinori@jp.panasonic.com オーディオ/ビデオ輸送作業部会。
Intended usage: COMMON
意図している用法: 一般的
Authors:
Jose Rey
Yoshinori Matsui
作者: ホセ・レイ松井義紀
Change controller: IETF Audio/Video Transport Working Group delegated
from the IESG.
コントローラを変えてください: IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
Rey & Matsui Standards Track [Page 52] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[52ページ]RFC4396有効搭載量形式
9. SDP Usage
9. SDP用法
9.1. Mapping to SDP
9.1. SDPへのマッピング
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が「評定する」メディア(RECOMMENDED1000のHzか他の値)は、コード化名としてSDP"a=rtpmap"線を調べて、それぞれ評価します:
a=rtpmap:<payload type> 3gpp-tt/1000
a=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 直接タイプがセミコロン切り離されたパラメタ=値組として結ぶメディアからそれをコピーすることによって、REQUIREDパラメタ"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 パラメタ=価値のセミコロンの切り離されたリストが対にされるので直接タイプが結ぶメディアからそれらをコピーすることによって、OPTIONALパラメタ"tx"、"ty"、「層」、"tx3g"、「幅」、「高さ」、「最大w」、および「最大h」はSDP"a=fmtp"属性に入ります:
a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>]
a=fmtp: ダイナミックな<の><パラメタ名前>ペイロードタイプ=<値>[<値の>][; <パラメタ名前>=<値>]
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 SHALLを使用する装置に、無視されてください。 例えば、パラメタは、SDPとSHALLがそれらを理解していない受信機によって無視されると後の仕様による形式がコピーされるかもしれないメディアに追加しました。
9.2. Parameter Usage in the SDP Offer/Answer Model
9.2. SDP申し出/答えモデルのパラメタ用法
In this section, the meaning of the SDP parameters defined in this document within the Offer/Answer [13] context is explained.
このセクションで、本書ではOffer/答え[13]文脈の中で定義されたSDPパラメタの意味は説明されます。
In unicast, sender and receiver typically negotiate the streams, i.e., which codecs and parameter values are used in the session. This is also possible in multicast to a lesser extent.
ユニキャスト、送付者、および受信機では、流れを通常交渉してください。すなわち、コーデックとそのパラメタ値はセッションのときに使用されます。 また、これもマルチキャストである程度可能です。
Additionally, the meaning of the parameters MAY vary depending on which direction is used. In the following sections, a "<directionality> offer" means an offer that contains a stream set to <directionality>. <directionality> may take the values sendrecv,
さらに、どの指示が使用されているかによって、パラメタの意味は異なるかもしれません。 以下のセクションでは、「<方向性>申し出」は、流れを含む申し出が<の方向性>にセットしたことを意味します。 <の方向性>は値のsendrecvを取るかもしれません。
Rey & Matsui Standards Track [Page 53] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[53ページ]RFC4396有効搭載量形式
sendonly, and recvonly. Similar considerations apply for answers. For example, an answer to a sendonly offer is a recvonly answer.
sendonlyと、recvonly。 同様の問題は答えに申し込みます。 例えば、sendonly申し出の答えはrecvonly答えです。
9.2.1. Unicast Usage
9.2.1. ユニキャスト用法
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. 叙述的なパラメタ: 申出人とanswererはそれらが入って来るのである(sendrecv/recvonly)か出発している(sendonly)流れに使用する値を宣言します。 申出人とanswererは異価を使用するかもしれません。
a. "tx", "ty", and "layer": These are parameters describing
where the received text track is placed. Depending on the
directionality:
a。 "tx"、"ty"、および「層」: これらは容認されたテキスト探知がどこに置かれるかを説明するパラメタです。 方向性によります:
i. They MUST appear in all sendrecv offers and answers and
in all recvonly offers and answers (thus applying to
the incoming stream). In the case of sendrecv offers
and answers and in recvonly offers, these values SHOULD
be used by the sender of the stream unless it has a
particular preference, in which case, it MUST make sure
that these different values do not corrupt the
presentation. For recvonly answers, the answerer MAY
accept the proposed values for the incoming stream (in
a sendonly offer; see ii. below) or respond with
different ones. The offerer MUST use the returned
values.
i。 彼らはすべてのsendrecv申し出と答えとすべてのrecvonly申し出と答えに現れなければなりません(その結果、入って来る流れに適用します)。 sendrecv申し出と答えの場合とrecvonly申し出では、それに特定の優先がない場合これらの値のSHOULDが流れの送付者によって使用されて、その場合、それは、これらの異価がプレゼンテーションを崩壊させないのを確実にしなければなりません。 recvonly答えのために、answererは入って来る流れ(sendonly申し出で; ii下を見る)のために提案された値を受け入れるか、または異なったもので応じるかもしれません。 申出人は戻り値を使用しなければなりません。
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答えでは、これらの値のSHOULDが流れの受信機による特定の優先が存在していない場合流れを受け入れるときの対応するrecvonly申し出からコピーされて、前で説明されるように指してください。
2. Parameters describing the display capabilities, "max-h" and
"max-w", which indicate the maximum dimensions of the text track
(text display area) for the incoming stream "tx" and "ty" values
(see Figure 18). "max-h" and "max-w" MUST be included in all
offers and answers where "tx" and "ty" refer to the incoming
stream, thus excluding sendonly offers and answers (see example
in Section 9.3), where they SHALL NOT be present.
2. 表示能力について説明するパラメタ、「最大h」、および「最大w」(テキストの最大の次元を示す)は入って来る流れの"tx"と"ty"値のために(テキスト表示領域)を追跡します(図18を見てください)。 「最大h」と「最大w」がすべてが提供する含まれているコネでなければならなく、"tx"と"ty"が入って来る流れを示す、その結果、sendonly申し出と答えを除く答え(セクション9.3で例を見る)、どこがそれらであるか、SHALL NOT、存在してください。
Rey & Matsui Standards Track [Page 54] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[54ページ]RFC4396有効搭載量形式
3. Parameters describing the sent stream properties, i.e., the
sender of the stream decides upon the values of these:
3. パラメタが送られた流れの特性について説明して、すなわち、流れの送付者はこれらの値について決めます:
a. "width" and "height" specify the text track dimensions.
They SHALL ALWAYS be present in sendrecv and sendonly
offers and answers. For recvonly answers, the answerer
MUST include the offered parameter values (if any) verbatim
in the answer upon accepting the stream.
a。 「幅」と「高さ」はテキスト探知寸法を指定します。 それら、SHALL ALWAYSはsendrecvに存在していて、申し出と答えをsendonlyします。 recvonly答えのために、answererは流れを受け入れるときの答えに提供されたパラメタ値(もしあれば)を逐語的に含まなければなりません。
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するかもしれません。 このパラメタは申出人かanswerersが送る流れに適用されます。
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"のそうです。 このパラメタはあらゆる申し出と答えで存在していなければなりません。 answerer SHALLが申出人のリストから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:
以下のテーブルはすべてのオプションをまとめます:
Rey & Matsui Standards Track [Page 55] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[55ページ]RFC4396有効搭載量形式
+..---------------------------+----------+----------+----------+
| ``--..__ 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 |
+--------------+--------------+----------+----------+----------+
+..---------------------------+----------+----------+----------+ | ``--..__ 方向性/| sendrecv| recvonly| sendonly| + 「--」のタイプ。__ ○か+----------+----------+----------+ | 「--」というパラメタ。__ | O/A| O/A| O/A| +--------------+------------``+----------+----------+----------+ | 叙述的|tx、tyは層にされます。| M/M| M/M| m/M| | | | | | | +--------------+--------------+----------+----------+----------+ | 表示|最大h、最大w| M/M| M/M| -/- | | 能力| | | | | +--------------+--------------+----------+----------+----------+ | 流れ|高さ、幅| M/M| -/(M)| M/M| | 特性|tx3g| m/m| -/- | m/m| | | | | | | +--------------+--------------+----------+----------+----------+ | 交渉可能|sver| M/M| M/M| M/M| | | | | | | +--------------+--------------+----------+----------+----------+ | 左右対称|レート| M/M| M/M| M/M| +--------------+--------------+----------+----------+----------+
Table 1. Parameter usage in Unicast Offer / Answer.
1を見送ってください。 Unicast Offer/答えにおけるパラメタ用法。
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.
キー: o Mは、手段がプレゼントoがmでなければならなかったならプレゼント(提案された値などの)o(M)、手段がそうしなければならない(m)または5月であるかもしれないことを意味します、適切であるなら。○ ハイフン(「-」)は、パラメタが存在しているはずがないことを意味します。
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申し出の場合では、これらの値を使用することで流れをレンダリングするように申し出を受け入れるanswererを準備しなければなりません。 これらの状態のいずれも満たされないなら、流れは、取り除いて拒絶されたセッションであるに違いありません。
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 能力、「最大h」、および「最大w」を表示してください: 流れのSHALLを送るanswererは、答えにおける「高さ」と「幅」値は申出人の合図された能力と互換性があるのを確実にします。
Rey & Matsui Standards Track [Page 56] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[56ページ]RFC4396有効搭載量形式
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"を通したバージョン取り扱い: 考えは申出人とanswererが同じバージョンを使用することで交信するということです。 answererに支持されたバージョンのリストから"sver"と選ばせることによって、これは達成されます。 recvonlyの流れのために、リストにおける最初の値は受ける都合のよいバージョンです。 その結果、最初の値はsendonly(そして、sendrecv)の流れのための、送付(そして、受信)のために好まれたものです。 answererは1つの値を選んで、答えでそれを返さなければなりません。 答えを受けると、申出人SHALLは、発信するように準備されて(sendonlyとsendrecv)、そのバージョンを使用することで流れを受けます(recvonlyとsendrecv)。 リストのバージョンのいずれも支持されないなら、流れは、取り除いて拒絶されたセッションであるに違いありません。 次にこのSHALLが代替の非コンパチブルバージョンを提供するなら異なったペイロードタイプを使用し終わっていることに注意してください。
9.2.2. Multicast Usage
9.2.2. マルチキャスト用法
In multicast, the parameter usage is similar to the unicast case, except as follows:
マルチキャストでは、以下の通りを除いて、パラメタ用法はユニキャストケースと同様です:
o the parameters "tx", "ty", and "layer" in multicast offers only
have meaning for sendrecv and recvonly streams. In order for all
clients to have the same vision of the session, they MUST be used
symmetrically.
o マルチキャスト申し出におけるパラメタ"tx"、"ty"、および「層」は、sendrecvのための意味を持つだけであり、流れをrecvonlyします。すべてのクライアントにはセッションの同じビジョンがあるように、対称的に彼らを使用しなければなりません。
o for "height", "width", and "tx3g" (for sendrecv and sendonly),
multicast offers specify which values of these parameters the
participants MUST use for sending. Thus, if the stream is
accepted, the answerer MUST also include them verbatim in the
answer (also "tx3g", if present).
o 「高さ」、「幅」、および"tx3g"(sendrecvとsendonlyのための)として、マルチキャスト申し出は、関係者が送付にこれらのパラメタのどの値を使用しなければならないかを指定します。 その結果、また、小川を受け入れるなら、answererが答えにそれらを逐語的に含まなければならない、(存在しているなら"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 能力パラメタと「最大h」と「最大w」、SHALL NOT、マルチキャストでは、使用されてください。 提供されたテキスト探知であるなら、大きさの変化、新しい申し出SHALLは代わりに使用されるべきですか?
o Regarding version handling:
o バージョン取り扱いに関して:
In the case of multicast offers, an answerer MAY accept a multicast
offer as long as one of the versions listed in the "sver" is
supported. Therefore, if the stream is accepted, the answerer MUST
choose its preferred version, but, unlike in unicast, the offerer
SHALL NOT change the offered stream to this chosen version because
there may be other session participants that do support the newer
extensions. Consequently, different session participants may end
up using different backwards-compatible media format versions. It
is RECOMMENDED that the multicast offer contains a limited number
of versions, in order for all participants to have the same view of
the session. This is a responsibility of the session creator. If
マルチキャスト申し出の場合では、"sver"に記載されたバージョンの1つが支持される限り、answererはマルチキャスト申し出を受け入れるかもしれません。 したがって、小川を受け入れるなら、他のセッションのときに、より新しい拡大を支持する関係者がいるかもしれないので、answererはしかし、この選ばれたバージョンへのユニキャスト、申出人SHALL NOT変化における提供された流れと異なって都合のよいバージョンを選ばなければなりません。 その結果、異なったセッション関係者は結局、異なった後方にコンパチブルメディア形式バージョンを使用するかもしれません。 マルチキャスト申し出が限られた数のバージョンを含んでいるのは、RECOMMENDEDです、すべての関係者にはセッションの同じ視点があるように。 これはセッション創造者の責任です。 if
Rey & Matsui Standards Track [Page 57] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[57ページ]RFC4396有効搭載量形式
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.
提供されたバージョンのいずれも支持されないで、流れはSHALLです。取り除いてセッションになってください拒絶されて。 この場合も、異なったペイロードは次に、非コンパチブルバージョンが提供される代替手段、このSHALLがされた使用であるならタイプされます。
9.3. Offer/Answer Examples
9.3. 申し出/答えの例
In these unicast O/A examples, the long lines are wrapped around. Static sample descriptions are shortened for clarity.
これらのユニキャストO/の例、線が巻きつけられる長さ。 静的なサンプル記述は明快ために短くされます。
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
ビデオ<ポート>RTP/AVP98m=a=rtpmap: 98 3gpp-tt/1000a=fmtp: 98tx=100。 ty=100。 =0を層にしてください。 高さ=80。 幅=100。 最大-h=120。 最大-w=160。 sver=6256、60。 tx3gは81…a=sendrecvと等しいです。
A -> O
->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/AVP98a=rtpmap: 98 3gpp-tt/1000a=fmtp: 98tx=100。 ty=95。 =0を層にしてください。 高さ=90。 幅=100。 最大-h=100。 最大-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.
この例では、申出人は、それが受信されるとそれが容認された流れを置くanswererと流れにおいて、許容できる最大の高さと幅であることに言っています。 また、それはそれが使用するものとする記述を抽出する送られた流れのためのテキスト探知の次元のanswererに言います。 それは2つのバージョン、6256、および60を提供します。 answererはそれが受ける流れのための同等なセットのパラメタで応じます。 この場合、answererの「最大h」と「最大w」は申出人の「高さ」と「幅」と互換性があります。 さもなければ、answererはこの流れを取り除かなければならないでしょう、そして、申出人がanswererの能力を考慮に入れる新しい申し出を発行しなければならないでしょう。 複数のペイロードタイプが初期の申し出で出席している場合にだけこれが可能であるので、少なくとも彼らのひとりは否定的な返答における「最大h」と「最大w」によって言い表されるようにanswererの能力に合っています。 また、answererのテキストボックス寸法が申し出で示唆された最大の値の中で合うことに注意してください。 最終的に、answererは、調節されたテキスト形式のバージョン60を使用するのを選びます。
Rey & Matsui Standards Track [Page 58] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[58ページ]RFC4396有効搭載量形式
For recvonly:
recvonlyのために:
Offerer -> Answerer
申出人->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
ビデオ<ポート>RTP/AVP98m=a=rtpmap: 98 3gpp-tt/1000a=fmtp: 98tx=100。 ty=100。 =0を層にしてください。 最大-h=120。 最大-w=160。 sver=6256、60a=recvonly
A -> O
->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/AVP98a=rtpmap: 98 3gpp-tt/1000a=fmtp: 98tx=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"を含んでいません。 answererは"tx"、"ty"、および「層」値をコピーして、その結果、これらを承認します。 この特別な場合における"tx"と"ty"(「層にする」)が容認された流れに適用するのではなく、送られた流れに適用されるので、「最大h」と「最大w」は答えで存在していません。 また、申出人とanswererに非常に異なった表示サイズがあるなら、answererの能力を言い表すのも可能でないでしょうに。 answererと50×50表示があるanswererのための例では、翻訳値は範囲から既に脱しています。
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
ビデオ<ポート>RTP/AVP98m=a=rtpmap: 98 3gpp-tt/1000a=fmtp: 98tx=100。 ty=100。 =0を層にしてください。 高さ=80。 幅=100。 sver=6256、60。 tx3gは81…a=sendonlyと等しいです。
A -> O
->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/AVP98a=rtpmap: 98 3gpp-tt/1000a=fmtp: 98tx=100。 ty=100。 =0を層にしてください。 高さ=80。 幅=100。 最大-h=100。 最大-w=160。 sver=60 a=recvonly
Rey & Matsui Standards Track [Page 59] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[59ページ]RFC4396有効搭載量形式
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".
「最大h」と「最大w」が申し出で存在していないことに注意してください。 また、この答えで、answererは申し出がそのままであると(その結果、"tx"、"ty"、「高さ」、「幅」、および「層」を反響します)受け入れて、能力に関してさらに、申出人に知らせるでしょう: 「最大h」と「最大w。」
Another possible answer for this case would be:
別の可能な答えはこのような場合以下の通りでしょう。
A -> O
->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/AVP98a=rtpmap: 98 3gpp-tt/1000a=fmtp: 98tx=120。 ty=105。 =0を層にしてください。 最大-h=95。 最大-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.
この場合、answererは、値が提供されていると受け入れません。 申出人は、これらの値を使用しなければならないか、または流れを取り除かなければなりません。
9.4. Parameter Usage outside of Offer/Answer
9.4. Offer/答えにおける外のパラメタUsage
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はレアルTime Streamingプロトコル(RTSP)[15]を通してSession Announcementプロトコル(SAP)[14]を通して発表されるか、または流されるマルチメディアセッションにOffer/答え文脈の外で使われるかもしれません。
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.
この場合、セッション記述の受信機が、パラメタを支持するのが必要であり、流れのために値を与えなければなりませんか、またはそれはセッションを拒絶しなければなりません。 セッションパラメタを定義するのが、セッション記述の送付者(または、創造者)の責任であるので、失敗のセッションセットアップの確率は最小にされます。 このドキュメントの範囲の外にこれはあります。
10. IANA Considerations
10. IANA問題
IANA has registered the media subtype name "3gpp-tt" for the media type "video" as specified in Section 8 of this document.
IANAはこのドキュメントのセクション8における指定されるとしてのメディアタイプのためのメディア「副-タイプ」名前"3gpp-tt"「ビデオ」を登録しました。
11. Security Considerations
11. セキュリティ問題
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
古いサンプル記述(すなわち、反射攻撃)でパケットを繰り返すことによって特に、攻撃者はクライアントで活発な現在のサンプル記述を無効にするかもしれません。 少しでも表示するなら、これは、テキストの表示が崩壊することを意味するでしょう。 別の形式の攻撃は境界がオリジナルの正確な限界に合っていない送付の余分な断片から成るかもしれません。
Rey & Matsui Standards Track [Page 60] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[60ページ]RFC4396有効搭載量形式
(as indicated by LEN) or fragments that carry different sample lengths (SLEN). This may cause a decoder to crash.
(LENによって示されるように) または、異なったサンプルの長さ(SLEN)を運ぶ断片。 これで、デコーダはクラッシュするかもしれません。
These types of attack may easily be avoided by using source authentication and integrity protection.
これらのタイプの攻撃は、ソース認証と保全保護を使用することによって、容易に避けられるかもしれません。
Additionally, peers in a timed text session may desire to retain privacy in their communication, i.e., confidentiality.
さらに、調節されたテキストセッションにおける同輩は、すなわち、彼らのコミュニケーション、秘密性でプライバシーを保有することを望むかもしれません。
This payload format does not provide any mechanisms for achieving these. Confidentiality, integrity protection, and authentication have to be solved by a mechanism external to this payload format, e.g., SRTP [10].
このペイロード形式はどんなメカニズムもこれらを達成するのに提供しません。 秘密性、保全保護、および認証はこのペイロード形式、例えば、SRTP[10]への外部のメカニズムによって解決されなければなりません。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[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)を切り換えました。 2004年6月にText Format(リリース6)、TS26.245v6.0.0を調節しました。
[2] ISO/IEC 14496-12:2004 Information technology - Coding of audio-
visual objects - Part 12: ISO base media file format.
[2]ISO/IEC14496-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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[4] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[6]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
12.2. Informative References
12.2. 有益な参照
[7] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999.
[7] ローゼンバーグとJ.とH.Schulzrinne、「一般的な前進型誤信号訂正のためのRTP有効搭載量形式」、RFC2733、1999年12月。
[8] Perkins, C. and O. Hodson, "Options for Repair of Streaming
Media", RFC 2354, June 1998.
[8] パーキンスとC.とO.ホドソン、「ストリーミング・メディアの修理のためのオプション」、RFC2354、1998年6月。
[9] W3C, "Synchronised Multimedia Integration Language (SMIL 2.0)",
August, 2001.
[9]W3C、「連動したマルチメディア統合言語(SMIL2.0)」、2001年8月。
Rey & Matsui Standards Track [Page 61] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[61ページ]RFC4396有効搭載量形式
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[10]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[11] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg,
"RTP Retransmission Payload Format", Work in Progress, September
2005.
2005年9月のレイとJ.とレオンとD.と宮崎とA.とVarsa、V.とR.Hakenberg、「RTP Retransmission有効搭載量形式」が進行中で扱う[11]。
[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] derミーア、J.、Mackie、D.、Swaminathan、V.、Singer、D.、およびP.Gentric、「MPEG-4つの基本の流れの輸送のためのRTP有効搭載量形式」をバンに積んでください、RFC3640、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[14] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[15]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[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)、TS26.234v6.1.0、2004年9月。
[17] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[17] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[18] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[18]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
[19] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[19] ホフマン、P.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781、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)」、RFC3611 2003年11月。
[21] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", Work
in Progress, August 2004.
[21] オット、J.、ウェンガー、S.、佐藤、N.、バーマイスター、C.、およびJ.レイは「RTCPベースのフィードバック(RTP/AVPF)のためにRTPプロフィールを広げました」、処理中の作業、2004年8月。
[22] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793,
May 2000.
[22] ヘルストリョーム(G.、「テキストの会話のためのRTP有効搭載量」、RFC2793)は2000がそうするかもしれません。
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[23] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、2005年6月。
Rey & Matsui Standards Track [Page 62] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[62ページ]RFC4396有効搭載量形式
[24] ITU-T Recommendation T.140 (1998) - Text conversation protocol
for multimedia application, with amendment 1, (2000).
[24]ITU-T Recommendation T.140(1998)--修正1、(2000)によるマルチメディア応用のためのテキスト会話プロトコル。
[25] ISO/IEC 10646-1: (1993), Universal Multiple Octet Coded
Character Set.
[25] ISO/IEC10646-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 FCD14496-17情報技術--オーディオの視覚物のコード化--パート17: 2004年6月にテキスト形式、進行中のWorkを流します。
[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] 終わりから終わりへの透明なPacketによって切り換えられたStreaming Service(PSS)。 3GPP SMIL言語プロファイル、(リリース6)、TS26.246v6.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の種類登録」、RFC3555、2003年7月。
[29] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[29]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、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)を切り換えました。 TS26.244V6.3、3GPPは形式(3GP)(リリース6)をファイルします。 2005年3月。
[31] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd
Generation Partnership Project (3GPP) Multimedia files", RFC
3839, July 2004.
[31] カスターニョ、研究開発Singer、「第3Generation Partnership Project(3GPP)マルチメディアのためのMIMEの種類Registrationsはファイルします」、RFC3839、2004年7月。
Rey & Matsui Standards Track [Page 63] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[63ページ]RFC4396有効搭載量形式
13. Basics of the 3GP File Structure
13. 3GPファイル構造の基礎
This section provides a coarse overview of the 3GP file structure, which follows the ISO Base Media file Format [2].
このセクションは3GPファイル構造の粗い概観を提供します。(ファイル構造はISO基地のメディアファイルFormat[2]に続きます)。
Each 3GP file consists of "Boxes". In general, a 3GP file contains the File Type Box (ftyp), the Movie Box (moov), and the Media Data Box (mdat). The File Type Box identifies the type and properties of the 3GP file itself. The Movie Box and the Media Data Box, serving as containers, include their own boxes for each media. Boxes start with a header, which indicates both size and type (these fields are called, namely, "size" and "type"). Additionally, each box type may include a number of boxes.
それぞれの3GPファイルは「箱」から成ります。 一般に、3GPファイルはFile Type Box(ftyp)、Movie Box(moov)、およびメディアData Box(mdat)を入れてあます。 File Type Boxは3GPファイル自体のタイプと特性を特定します。 容器として機能して、Movie BoxとメディアData Boxはそれぞれのためのそれら自身の箱を含んでいます。メディア。 箱はヘッダーから始めて、どれがサイズとタイプの両方を示すか。(これらの分野が呼ばれる、すなわち、「サイズ」と「タイプ」、) さらに、それぞれの箱のタイプは多くの箱を入れるかもしれません。
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).
Movie Box(moov)は1Track Boxes(trak)を含んでいます。(Track Boxesは各道の情報を含んでいます)。 Track Boxは特にTrack Header Box(tkhd)、メディアHeader Box(mdhd)、およびメディア情報Box(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.
Track Header Boxは単線の特性を指定します。(そこでは、この場合セッションの間、道が流されたテキストです)。 ちょうど1Track Header Boxが道に存在しています。 それは道の情報を含んでいます、空間的なレイアウト(幅と高さ)や、ビデオ変換行列や、層の番号などのように。 セッションの持続時間に、情報のこれらの断片が不可欠であって、静的であるので(すなわち、一定の)、どんなテキストのサンプルの伝達の前にもそれらを送らなければなりません。
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).
Header Boxがすなわち、1秒後に通るタイム・ユニット、サイクルの1秒あたりの「スケール」か数に含むメディアかHertz。 メディア情報BoxはSample Table Box(stbl)を含んでいます。(Sample Table Boxは道でメディアのサンプルに索引をつけるすべての時間とデータを含みます)。 この箱を使用して、時間内に、サンプルの場所を見つけて、彼らのタイプ、サイズ、容器、およびオフセットをその容器の中に決定するのは可能です。 Sample Table Boxの中では、私たちはChunk Box(サンプル記述インデックスを見つけるためのstsc)においてSample記述Box(サンプル記述を見つけるためのstsd)、Sample BoxへのDecoding Time(サンプル持続時間を見つけるためのstts)、Sample Size Box(stsz)、およびSampleを見つけることができます。
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.
最終的に、メディアData Boxはメディアデータ自体を含んでいます。 調節されたテキスト探知では、この箱はテキストのサンプルを入れてあます。 オーディオとビデオと同等物は、それぞれオーディオとビデオフレームです。 テキストのサンプルはテキストの長さか、テキスト文字列と、1か数個のModifier Boxesから成ります。 テキストの長さはバイトで表現されるテキストのサイズです。
Rey & Matsui Standards Track [Page 64] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[64ページ]RFC4396有効搭載量形式
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.
テキスト文字列は表すプレーンテキストです。 Modifier Boxはテキストに加えて表す色、字体などの情報です。
14. Acknowledgements
14. 承認
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.
作者はこのドキュメントに関する彼らのコメントと提案についてデーヴSinger、ジャン・バンderミーア、マグヌスWesterlund、およびコリン・パーキンスに感謝したがっています。
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ウェブサービスのために自由で公的に利用可能なJavE ASCII Editor(ASCII図面のために、本書では使用される)とHenrik Levkowetzについてマーカス・ゲープハートに感謝したがっています。
Authors' Addresses
作者のアドレス
Jose Rey Panasonic R&D Center Germany GmbH Monzastr. 4c D-63225 Langen, Germany
ホセレイパナソニック研究開発センタードイツ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 Fax: +49-6103-766-166
Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006 Kadoma Kadoma-shi, Osaka, Japan
義紀松井松下電器産業社のLtd.1006門真門真市、大阪(日本)
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、Fax: +81 6 6900 9699
Rey & Matsui Standards Track [Page 65] RFC 4396 Payload Format for 3GPP Timed Text February 2006
テキスト2006年2月に調節された3GPPのためのレイと松井標準化過程[65ページ]RFC4396有効搭載量形式
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。 IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rey & Matsui Standards Track [Page 66]
レイと松井標準化過程[66ページ]
一覧
スポンサーリンク
