| 昔々の話からします。
PCとモデムを接続する時、シリアル通信のプロトコルで、
無手順とか MNP5とかのクラスを知らずにはできなかったと思います。
複数bitを纏めて伝送するパラレル通信に対して、
タイミングを揃える必要のないシリアル通信は先頭bitの
検出とボーレートの取り決めさえ一致すれば、速度は
上げやすい特徴があります。
デジタル情報の 0/1は、電気レベルの Low/Highに変換されます。
000111の並びを[___---]で送った時に、01と誤認識されたら困るので、
送る間隔と受け取る間隔、ひっくるめてタイミングと言ってもいいんですが、
これは一致させる必要があります。
当然、100Mbpsの伝送と 1Gbpsの伝送では、0か 1かを判断するタイミングは
互いに一致させなければまともにデータが読めません。
古いシリアル通信では、同期bitとして決まったパターンを用意して、
それに続く 8bitを情報として採用したから、伝送レートは実際には
(2+8)/8が必要でした。 余分な 2bitは、スタートビットとストップビットです。
この方式でさえ、シリアル通信の処理が滞れば、スタートとストップの
同期を見ているから読み損ねはない理屈ですが、時間軸の遅れには繋がります。
デジタルだからと安心していいのは、データの劣化に対する補償がとりやすいことです。
で、話は大きくとんで受信した側の処理に入ると、
バッファがあればある程度の揺らぎは吸収できます。
時々おくれたり纏めて届いたりするデータから映像と音声を出力するには、
大きな前提があります。
送信側と受信側で、時間の流れが同じである、という前提です。
44.1kHzだったり 48kHzのサンプリングレートの音声を、
ネットワーク配信で受けて再生する場合、再生したい時間に
必要な情報が適切に（枯渇せず）届かねばなりません。
ただ、そのクロックは送り側と受け側で完全に一致してるでしょうか。
離れた地点同士で時間情報を一致させたい場合、以前は ISDNの信号を使いましたが、
今なら GPS信号を使います。
でも、映像音声の伝送でそこまではやりません。
つまりですね、IPも USBともに PCと周辺機器間の接続のため出来たものなので、
実時間情報という概念がなかったんです。
郵便で受け取った譜面情報を元に、楽団が切れ目ない楽曲再生をするとしたら、
手元にある譜面の数が足りなければテンポを落として調整しようとする、
そういう処理が、STB（ネットワークプレイヤー）の中では起きます。
バースト的に速度は出るけど、時間ごとにサンプリングすると
レートが変動する。 こういう伝送が、デジタルプレイヤーの処理には
とても影響を与えます。
視聴上の評価にこの理屈が関連するかは、おいときます（＾＾；）。
|
|