RFC7310日本語訳 (2)
4. Payload Format Capabilities（ペイロードフォーマットの機能）
This RTP payload format carries an integer number of Standard apt-X or Enhanced apt-X coded audio samples. When multiple related audio channels are being conveyed within the payload, each channel contributes the same integer number of apt-X coded audio samples to the total carried by the payload.
このRTPペイロードフォーマットは、Standard apt-X または Enhanced apt-Xで符号化された、整数個のオーディオサンプルを搬送する。関連する複数のオーディオチャンネルがペイロードで運ばれるとき、ペイロードによって運ばれる全体に対して、各チャンネルは同一整数個のapt-X符号化オーディオサンプルを与える。
訳注："contributes"がうまく訳せませんでした。要は、チャンネル毎の符号語数はペイロード内で同一である、ということだと思います。
4.1. Use of Forward Error Correction（前方誤り訂正の使用）
Standard apt-X and Enhanced apt-X do not inherently provide any mechanism for adding redundancy or error-control coding into the coded audio stream. Generic schemes for RTP, such as forward error correction as described in RFC 5109 [RFC5109] and RFC 2733 [RFC2733], can be used to add redundant information to Standard apt-X and Enhanced apt-X RTP packet streams, making them more resilient to packet losses at the expense of a higher bit rate.
Standard apt-X または Enhanced apt-Xは、その符号化オーディオストリームにおいて、冗長性や誤り制御符号を追加するための固有のメカニズムを一切提供しない。 Standard apt-X または Enhanced apt-X RTPパケットストリームへ冗長情報を追加するために、RFC5109やRFC2733に記載されているような前方誤り訂正など、RTPのための一般的なスキームが使用でき、ビットレートの増加と引き替えにパケットロスへの回復力を得る。
5. Payload Format（ペイロードフォーマット）
The Standard apt-X and Enhanced apt-X algorithms encode four successive PCM samples from each audio channel and produce a single compressed sample for each audio channel. The encoder MUST be presented with an integer number S of input audio samples, where S is an arbitrary multiple of 4. The encoder will produce exactly S/4 coded audio samples. Since each coded audio sample is either 16 or 24 bits, the amount of coded audio data produced upon each invocation of the encoding process will be an integer number of bytes. RTP packetization of the encoded data SHALL be on a byte-by-byte basis.
Standard apt-X または Enhanced apt-Xアルゴリズムは、各オーディオチャンネルから4つの連続したPCMサンプルをエンコードし、各オーディオチャンネル毎の単一の圧縮サンプルを生成する。エンコーダには、任意の4の倍数である、整数S個の入力オーディオサンプルを与えなければならない。エンコーダは、S/4個ぴったりの符号化されたオーディオサンプルを生成する。各符号化オーディオサンプルは16bitか24bitのいずれかとなるため、符号化プロセスの呼び出しにより生成された符号化オーディオデータ量は、byteの整数倍となる。符号化データのRTPパケット化は、バイト単位で行うものとする。
5.1. RTP Header Usage（RTPヘッダの使用法）
Utilization of the Standard apt-X and Enhanced apt-X coding algorithms does not create any special requirements with respect to the contents of the RTP packet header. Other RTP packet header fields are defined as follows.
Standard apt-X または Enhanced apt-X符号化アルゴリズムの利用にあたっては、RTPパケットヘッダの内容に対して特別な要件を新設しない。他のRTPパケットヘッダーフィールドを以下のよう定義する。
o V - As per [RFC3550]
o P - As per [RFC3550]
o X - As per [RFC3550]
o CC - As per [RFC3550]
o M - As per [RFC3550] and [RFC3551] Section 4.1
o PT - A dynamic payload type; MUST be used [RFC3551]
o SN (sequence number) - As per [RFC3550]
o Timestamp - As per [RFC3550]. The RTP timestamp reflects the instant at which the first audio sample in the packet was sampled, that is, the oldest information in the packet.
RTPタイムスタンプは、パケット内の最初のオーディオサンプルが取得された瞬間を反映している。つまり、パケット内の最も古い情報となる。
Header field abbreviations are defined as follows.
以下に、ヘッダフィールドの略記を定義する。
o V - Version Number
o P - Padding
o X - Extensions
o CC - Count of contributing sources
o M - Marker
o PT - Payload Type
o PS - Payload Structure
5.2. Payload Structure（ペイロード構造）
The RTP payload data for Standard apt-X and Enhanced apt-X MUST be structured as follows.
Standard apt-X または Enhanced apt-XのためのRTPペイロードデータは、次のように構造化されなければならない。
Standard apt-X and Enhanced apt-X coded samples are packed contiguously into payload octets in "network byte order", also known as big-endian order, and starting with the most significant bit. Coded samples are packed into the packet in time sequence, beginning with the oldest coded sample. An integer number of coded samples MUST be within the same packet.
Standard apt-X または Enhanced apt-Xの符号化サンプルは、ネットワークバイトオーダー（ビッグエンディアンオーダーとしても知られている）でペイロードオクテットに連続してパックされていて、最上位ビットから開始される。符号化サンプルは、最も古い符号化サンプルから始まるような時系列で、パケットにパックされる。整数個の符号化サンプルは、同じパケット内に含まれていなければならない。
訳注：符号語はパケットにまたがってはいけない、ということだと思います。
When multiple channels of Standard apt-X and Enhanced apt-X coded audio, such as in a stereo program, are multiplexed into a single RTP stream, the coded samples from each channel, at a single sampling instant, are interleaved into a coded sample block according to the following standard audio channel ordering [RFC3551]. Coded sample blocks are then packed into the packet in time sequence beginning with the oldest coded sample block.
ステレオプログラムのように、Standard apt-X または Enhanced apt-X符号化オーディオの複数のチャンネルが単一のRTPストリームに多重化される場合、RFC3551で標準化されているオーディオチャンネル順序に従って、符号化サンプルブロックにインターリーブされる。符号化サンプルブロックは、最も古い符号化サンプルブロックから始まるような時系列で、パケットにパックされる。
l left
r right
c center
S surround
F front
R rear
channels description channel
1 2 3 4 5 6
___________________________________________________
2 stereo l r
3 l r c
4 l c r S
5 Fl Fr Fc Sl Sr
6 l lc c r rc S
For the two-channel encoding example, the sample sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample). Coded samples for all channels, belonging to a single coded sampling instant, MUST be contained in the same packet. All channels in the same RTP stream MUST be sampled at the same frequency.
2チャンネルの符号化を例に取ると、サンプルシーケンスは（第1サンプルの左チャンネル）、（第1サンプルの右チャンネル）、（第2サンプルの左チャンネル）、（第2サンプルの右チャンネル）というようになる。同一のサンプリング時刻に属するすべてのチャンネルの符号化サンプルは、同じパケットに含まれなければならない。同一RTPストリーム内のすべてのチャンネルは、同じ周波数でサンプリングされなければならない。
5.3. Default Packetization Interval（デフォルトパケット化間隔）
The default packetization interval MUST have a duration of 4 milliseconds. When an integer number of coded samples per channel cannot be contained within this 4-millisecond interval, the default packet interval MUST be rounded down to the nearest packet interval that can contain a complete integer set of coded samples. For example, when encoding audio with either Standard apt-X or Enhanced apt-X, sampled at 11025 Hz, 22050 Hz, or 44100 Hz, the packetization interval MUST be rounded down to 3.99 milliseconds.
デフォルトのパケット化間隔は、4ミリ秒の持続時間を持たなければならない。チャンネル毎の整数個の符号化サンプルが、この4ミリ秒の間隔内に含めることができない場合には、デフォルトのパケット間隔を、符号化サンプルの完全な整数個の集合を含むことができるような、直近のパケット間隔に切り下げなければならない。例えば、11025Hz、22050Hzまたは44100HzでサンプリングされたStandard apt-X または Enhanced apt-Xオーディオをエンコードする場合は、パケット化間隔は3.99ミリ秒に切り捨てなければならない。
訳注：48kHzの場合、1,000[ms] / 48,000[Hz] * 4[sample] * 48[block] = 4msとなり、48符号化サンプルがきっちり収まります。一方44.1kHzの場合、1,000[ms] / 44,100[Hz] * 4[sample] * 44[block] = 3.9909297msとなり、1パケットは44符号化サンプルということになります。
The packetization interval sets limits on the end-to-end delay; shorter packets minimize the audio delay through a system at the expense of increased bandwidth, while longer packets introduce less header overhead but increase delay and make packet loss more noticeable. A default packet interval of 4 milliseconds maintains an acceptable ratio of payload to header bytes and minimizes the end-to-end delay to allow viable interactive applications based on apt-X. All implementations MUST support this default packetization interval.
パケット化インターバルは、エンドツーエンド遅延の限界を規定する。短いパケットは、帯域幅の増加を犠牲にしてシステム間の音声遅延を最小限に抑えることができる。一方、長いパケットは少ないヘッダオーバヘッドをもたらすが、遅延を増加させ、パケット損失がより顕著になる。4ミリ秒のデフォルトのパケット間隔は、ペイロードとヘッダ長との許容可能な比率を維持し、apt-Xによる実行可能なインタラクティブアプリケーションを可能にするためのエンドツーエンド遅延を最小限に抑えることができる。すべての実装は、このデフォルトのパケット化間隔をサポートしなければならない。
5.4. Implementation Considerations（実装に関する考慮）
An application implementing this payload format MUST understand all the payload parameters that are defined in this specification. Any mapping of these parameters to a signaling protocol MUST support all parameters. Implementations can always decide whether they are capable of communicating based on the entities defined in this specification.
このペイロード形式を実装するアプリケーションは、この仕様で定義されているすべてのペイロードパラメータを解釈できなければならない。シグナリング・プロトコルへのパラメータのどんなマッピングでも、全パラメータがサポートされていなければなりません。実装は常に、この仕様で定義されたエンティティに基づいて、互いに通信可能かどうかを決めることができる。
訳注：このパラグラフは意味が取りにくかったです。第2センテンスはRFCお決まりの言い回しのようですが。
5.5. Payload Example（ペイロード例）
As an example payload format, consider the transmission of an arbitrary 5.1 audio signal consisting of six channels of 24-bit PCM data, sampled at a rate of 48 kHz and packetized on an RTP packet interval of 4 milliseconds. The total bit rate before audio coding is 6 * 24 * 48000 = 6.912 Mbit/s. Applying Enhanced apt-X coding with a coded sample size of 24 bits results in a transmitted coded bit rate of 1/4 of the uncoded bit rate, i.e., 1.728 Mbit/s. On packet intervals of 4 milliseconds, packets contain 864 bytes of encoded data that contain 48 Enhanced apt-X coded samples per channel.
ペイロード形式の一例として、4ミリ秒のRTPパケット間隔における、48kHzのサンプリングレート、24bit PCMデータ 6チャンネルからなる5.1オーディオの情報伝送を考える。オーディオ符号化前の総ビットレートは6*24*48000=6.912Mbit/sである。非符号化ビットレートの1/4、すなわち1.728Mbit/sの符号化ビットレートになるような、24ビットの符号化サンプルサイズを持つEnhanced apt-Xを使用する。4ミリ秒のパケット間隔であるから、パケットには、チャンネルあたり48個のEnhanced apt-X符号化サンプルとなるような、864バイトの符号化データを含む。
訳注：5.3の訳注に書いたとおり、48kHzの場合は48符号化サンプルとなります。Enhanced apt-Xは1符号化サンプルあたり24bit=3byteですから、3*48*6[channel]=864[byte]となります。なお当然ながら、このビットレートはA2DPで転送できません。
For the example format, the diagram below shows how coded samples from each channel are packed into a sample block and how sample blocks 1, 2, and 48 are subsequently packed into the RTP packet.
各チャンネルからの符号化サンプルがサンプルブロックへどのようにパックされるか、また、サンプルブロックの1から48までがRTPパケットへどのようにパックされるかを、下図のフォーマット例に示す。
C:
Channel index: Left (l) = 1, left center (lc) = 2,
center (c) = 3, right (r) = 4, right center (rc) = 5,
and surround (S) = 6.
T:
Sample Block time index: The first sample block is 1; the final sample is 48.
S(C)(T):
The Tth sample from channel C.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(1)(1) | S(2)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(2)(1) | S(3)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(3)(1) | S(4)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(5)(1) | S(6)(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(6)(1) | S(1)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(2)(2) | S(3)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(4)(2) | S(5)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(5)(2) | S(6)(2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(6)(2) | S(1)(3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(6)(47) | S(1)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(1)(48) | S(2)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(3)(48) | S(4)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(4)(48) | S(5)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S(5)(48) | S(6)(48) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
訳注：5.2の最後のパラグラフで言及されていたとおり、（第1サンプルのチャンネル1）、（第1サンプルのチャンネル2）という順序になります。
For the example format, the diagram below indicates the order that coded bytes are packed into the packet payload in terms of sample byte significance. The following abbreviations are used.
サンプルバイト順序の観点から、パケットペイロードへの符号化バイトパック順序を、下図のフォーマット例に示す。 以下の略語を使用する。
MSB:
Most Significant Byte of a 24-bit coded sample
MB:
Middle Byte of a 24-bit coded sample
LSB:
Least Significant Byte of a 24-bit coded sample
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSB | MB | LSB | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
訳注：ビッグエンディアンということですね。"significance"は「順序」と意訳しました。
いくつかの知見がありました。
- apt-Xコーデックそのものには、エラー訂正機構が無い
- 符号化は4PCMサンプル単位
- 1パケット4ms、PCMサンプル数で言えば192点@48kHz、176点@44.1kHz
- 1パケットには44～48符号語が含まれる
符号語間に相関はあるのでしょうか。たった4サンプルだけでは1/4に圧縮するのは難しいように思います。しかしパケットロスを考えると、相関があるのは都合が悪いし・・・
apt-Xアルゴリズムの詳細が知りたいですね。
latests
tags
archive
author
