第 10 部
マルチメディア (マルチメディアメッセー
ジ交換)

315

第 1章序論

1.1 はじめに近年のワークステーションやパーソナルコンピュータは、データ処理能力の向上と周辺デバイスの発達によって、様々な形態をとるようになってきた。たとえば 、高解像度のビットマップデ ィスプレ イやマウスは、現在のワークステーションには標準装備として接続され、音声入出力デバイスやビデオ画像入力デバイスなども接続可能になってきている。また、タッチスクリーンやデータグローブのような新種のポインティングデバイ
スも接続可能である。このような入出力装置の多様化に伴って、コンピュータが取扱う情報はテキストだけでなく音声や画像など 多岐に渡ってきている。また、これらのデー
タが、時間と密接な関係を保ちながら、表現されるようになってきた。
また、ネットワーク環境が整備されてきたことによって、電子メール、電子掲示板などがユーザ間でのコミュニケーションの手段として利用できるようになってきた。電子
メールは、現在の手紙というメディアがネットワーク環境に置き換えられたものであり、電子掲示板は掲示板というメディアが置き換えられたもである。このことは、既存のメディアがネットワーク環境に置き変わっていく兆候としてとらえることができる。
最近では、CD-ROM や光磁気ディスクといった大容量の記憶装置を比較的安価で利用できるようになったため、音声や画像といった大きな記憶領域を必要とするデータも取扱えるようになってきた。
また、近い将来には、大容量で高速なネットワークによって、テレビ放送で流される
情報もネットワーク環境によって得ることができるようになると考えられる。このように、ネットワーク環境はすべてのメディアを包括するものへと変化していくと考えられる。したがって、社会的な動向として、今後、情報がどのような形態によって取扱われていくかを考える必要がある。
一般に、様々なデバイスが接続され、様々な形態の情報を取扱うメディアをマルチメディ
アと呼ぶ。本論文では、マルチメディア化によって現われてくる問題点を提示し 、メッ
セージ交換システムにおけるマルチメディアデータの取扱いについて述べる。

317

第 2章
背景
メッセージ交換システムにおけるマルチメディアデータの取扱いを論ずる前に、マルチメディアデータがどのように生成されるか、その背景を述べておかなければならない。
そのために、近年のワークステーションやパーソナルコンピュータに接続されているデバイスと、今後接続されるであろうデバイスについて述べ、それらからどのような特徴を持ったデータが生成されるかを述べる。
また、メッセージ交換システムの現状として MHS(Message Handling System) を概観する。次に、近年マルチメディアデータのフォーマットとして提案されている ODA(OceDocument Architecture) について述べ、最後に、本論文でのマルチメディアの解釈について述べる。

2.1 周辺機器
コンピュータに接続されるデバイスには、文字を取扱うもの、画像を取扱うもの、音声を取扱うもの、それらから生成されるデータを格納するための記憶装置がある。本節では、これらの各種デバイスとそれらより生成されるデータの性質について述べる。さらに、最近接続されるようになった、新しい記憶装置について述べる。

2.1.1

画像を取扱うデバイス

静止画像を取扱うデバイス
静止画像を取り込むデバイスとしてイメージスキャナ、フィルムスキャナ、ビデオデジ
タイザ (ビデオキャプチャ、ビデオオーバレイボードとも呼ばれる) があげられる。スキャ
ナは、印刷物などの紙媒体の図や写真を入力するデバイスである。ビデオデジタイザは、
ビデオカメラや VTR などからのフレームごとの映像をコンピュータに入力するデバイスである。共にアナログ情報をディジタル化し 、コンピュータで利用できるようにする。
これらの画像入力デバイスには、カラーを取扱えるものとモノクロのものとがある。モ
ノクロのものには、二値表現しかできないものと階調表現が可能なものとに分けられる。
さらに、階調表現には 16 階調や 256 階調などがある。カラーで入力できるものもあり、

318

第 10 部

マルチメディア (マルチメディアメッセージ交換)319

その表現可能な色の数には 256 色、4096 色、1670 万色など多くの種類が存在する。また
解像度や入力画像の大きさも複数存在する。
動画像を取り扱うデバイス
多くのワークステーションには、走査線数が千本以上のディスプレ イが接続されているが、動画像を扱うデバイスはあまり一般的ではない。しかし 、次世代のワークステー
ションやパーソナルコンピュータは、ビデオ対応のものとなり、ビデオ情報の入力、表示、編集、出力が自在にできる可能性が高いと考えられる。現在実用化されているテレ
ビ放送の方式は複数存在する。日本およびアメリカでは、NTSC と呼ばれる方式を採用している。しかし 、ヨーロッパでは PAL と呼ばれる方式を採用しており、走査線の数は前者が 525 本、後者が 625 本と異なる。また、最近では次世代の映像方式として HDTVが開発されている。これにも現在のテレビと同様に複数の方式が存在する。アメリカのテレビ局の ABC と NBC が採用する方式は Sarno と呼ばれ 、NHK と SMPTE(Society
Of Motion Picture And Television) の採用する方式は 240M 、また、ヨーロッパで採用されている方式は Eureka と呼ばれる。それぞれの方式により走査線の数、1 秒間に描画されるフレーム数などが異なる。以下に現在のテレビと HDTV の標準を示す。

 現在のテレビ画像
方式
走査線数 (本)フィールド 周波数 (Hz)走査方式 ( インターレース)
有効走査線数 (本)アスペクト比 (横:縦)転送レート (Mbit/s) 提案されている HDTV 画像方式
走査線数 (本)フィールド 周波数 (Hz)走査方式 ( インターレース)
有効走査線数 (本)アスペクト比 (横:縦)転送レート (Mbit/s)

米国, 日本

NTSC
525
59.94
2:1
483
4:3
114

欧州, アジア

PAL
625
50.00
2:1
575
4:3
142

ABC, NBC NHK, SMPTE 欧州
Sarno
240M
Eureka
1050
1125
1250
50.94
60.00
50.00
2:1
2:1
2:1
1035
1035
1152
16:9
16:9
16:9
1152
1188
1152

上述の方式は、走査線の数が画面の大きさによらず一定のアナログ方式であるが 、解像度は画面の大きさによって変えるほうが合理的であり、将来的にはこれらのアナログ

1990 年度 WIDE 報告書

320

方式では不十分であると考えられている。そのために、現在、完全なディジタル方式が検討されている。今後のテレビ画像では、走査線数は可変となる可能性がある。
コンピュータで動画像を取扱う上での問題点は、各フレームごとのカラーの画像が、特に解像度が高い場合に膨大な記憶領域を必要とすることである。これは、ディスクスペー
スを消費するだけでなく、コンピュータのメモリと I/O のバンド 幅も大量に必要とする。
これを解決するために画像の圧縮技術が開発され、近年では CD-ROM などに動画像を記録する際に使われている。代表的なものとして、インテル社が開発した DVI(Didital
Video Interactive) 方式があげられる。DVI 方式では、圧縮された動画像はパーソナルコ
ンピュータによって実時間で再生可能であるが、約 120 分の 1 への画像圧縮には、専用の並列コンピュータ (トランスピュータ) が必要であり、非対称方式と呼ばれる。また、
パーソナルコンピュータで再生と圧縮記録の両方ができる対称方式の開発も行なわれている。将来的には、複数のデータ圧縮方式が使われるようになると考えられる。

2.1.2

音声

音声入出力デバイスは、マイクロホンなどのオーディオ機器から音声を入力し 、A/D
変換によりアナログ情報をディジタル化して、コンピュータで利用できるものにする。また、ディジタル情報をアナログ化して、スピーカなどのオーディオ機器から出力する。入出力のサンプリング周波数には、8kHz 、22kHz 、44.1kHz 、48kHz など複数存在し 、量子化数にも、4 ビット、8 ビット、16 ビットなど複数存在する。また、ステレオとモノラルの違いもある。A/D 変換の方法には、PCM 、DPCM 、ADPCM などがある。

2.1.3

記憶装置

マルチメディアデータは動画像も扱うので、膨大な二次記憶装置を必要とする。現在、価格と性能の両面で比較的に適しているものが光ディスクである。540MB のデータを記録できる CD-ROM や、600〜800MB のデータを記録できる追記型光ディスクが一般的である。また、消去可能な光ディスクの販売も開始され、100MB 単位でのリムーバブル
な二次記憶装置として使うことができるようになった。CD-ROM は ISO(International
Organization for Standardization) によって規格が標準化されており、DVI 方式の画像圧
縮により 72 分の動画像 (256 240 ピクセル) が記録できる。

2

2.2 MHS(Message Handling System)
CCITT は X.400 シリーズ勧告をメッセージ通信に関する標準として規定している。MHS
はメッセージをヘッダとボディで構成されたものとしている。ヘッダには、発信時刻、配
信時刻、符号化情報タイプ、などの転送と変換に関する情報が記述される。ボディにはユーザの送りたい情報が入り、配送される過程で表現形式の変換が行われる。配送の方法はメッセージの内容に依存しない。

第 10 部

マルチメディア (マルチメディアメッセージ交換)

321

X.400 シリーズでは、MHS がテレックス、テキスト、テレテックス、G3 ファクシミリ、G4 ファクシミリ、ビデオテックス、音声、ミクストモード の 8 種類を扱うことを想定しており、X.408 で MHS のメディア変換を実現する際に必要な変換アルゴリズムを規定している。

2.3 ODA(Oce Document Architecture)
ODA は、異なるシステム間での文書の交換を可能にするために標準化されている。文
書には文字だけでなく、図形や表を含むことを考慮している。また、文書の交換に関して、発信者の意図どおりに表示することと、編集や再フォーマットなどの処理を可能とすることが考慮されている。
ODA では、文書の内容を意味によってわけた論理的側面と、表示上の位置など表示媒体に関する物理的な要素でわけたレイアウト的側面によってとらえている。また、文書を階層的な木構造で表わし 、論理的側面とレ イアウト的側面から、それぞれ論理構造とレ イアウト構造という 2 つの構造によって文書を表現する。この構造でノードにあたる部分をオブジェクトといい、葉のオブジェクトを基本オブジェクトという。基本オブジェ
クトには、文字の回転、文字の進行方向、行の進行方向といったテキストに関する情報、
ラスタグラフィックスの内部構造に関する情報、CGM 1によるジオメトリックグラフィッ
クスに関する情報が含まれる。また、文書を処理するアプリケーションの基礎機能として基本標準 (Base Standard) を規定している。それぞれのアプリケーションごとに、基本標準のサブセットである DAP(Documet Application Pro le) によって、システムに応じた ODA 環境を構築する。これによって、たとえばマルチカラム機能や縦書き機能などを実現することができる。これまでに、いくつかの機能標準が開発されている。たとえば 、NIST の DAP によって、マルチメディアに対応する機能を実現できる [95]。

2.4 マルチメディア
従来から、コンピュータは単に計算をする道具としてではなく、ワードプロセッサや描画ツールとして利用され 、我々の生活にたいへん役立ってきた。近年では、デスクトッ
プパブリッシングは 、我々の身の回りの様々な出版物の新しい作成手段として、非常に重要なものとなってきている。また、これまでに述べたように、近年のワークステーショ
ンやパーソナルコンピュータは、コンピュータ技術そのものと周辺デバイスの発達によって、様々な形態をとるようになってきた。これらは一般にマルチメディアと呼ばれている。しかし 、メディアは情報を表現、伝達、蓄積、理解するための媒体であり、文字や言葉といったものから、出版、放送といったものまで、非常に多岐に渡った意味を持つので、単にメディアを結合したものをマルチメディアといったのでは、その意味するところは明確ではない。ここでは、本論文におけるマルチメディアの解釈のしかたを述べる。
1

CGM は ISO8632 で定義された線、弧、多角形などの要素で表現される 2 次元画像情報である。

1990 年度 WIDE 報告書

322
マルチメディアの解釈接続されるデバイスなどの技術的な点からいえば 、近い将来のワークステーションは100MB のオーダで メモリが搭載され 、標準としてビデオ対応になり、ビデオ情報の入力、編集、蓄積、出力をおこなう能力を持つようになると考えられる。また、多くのコンピュータがネットワークに接続され 、ユーザ間のコミュニケーションの手段として広く普及するだろう。既存の電話やファックスは、複数のコンピュータを接続するネットワー
ク環境と、コンピュータに接続される様々なデバイスに置き換えられていくと考えられる。これによって、音声、映像、テキストなどの統合化されたデータがネットワークを介して転送されるようになり、必要なときに必要な情報を得ることが可能となると考えられる。
また、このように変化したコンピュータとネットワーク環境は、情報の統合によって、コミュニケーションや学習などの面で有力な手段をユーザに提供する。マルチメディア
はこの統合の核心となるものである。すなわち、マルチメディアとは文字や図形によって表現される知識としての情報および音声や映像などの人間の五感に関係する様々なイ
メージを入力、蓄積、出力するデバイスと、データを自在に編集・加工をするアプリケー
ション、さらに、それを移動させるネットワーク環境全体を指すものである。
マルチメディアの提供するものは、電子メール、ボイスメール、画像の配送、グラフィッ
クスの配送、ファックス配送、ビデオ会議、ビデオ編集、データベースへのアクセスなどの統合化されたサービスである。また、マルチメディアは様々なメディアを相互に結合することを可能にし 、マルチメディアそのものと、それによって生成されるデータの内部構造を意識することなく、統合化された情報を極めて自然に取扱うことができる環境
をユーザに提供する。
そのためには、マルチメディアはユーザに対して対話的な動作をし 、ユーザと親密な関係を保ちながら、音声や映像などの統合化された情報を表現できるものでなければならない。

2.5 ネットワーク環境
現在の電子メールや電子掲示板など の メッセージ交換では 、SMTP(Simple Message
Transfer Protocol) 、RFC822 、MHS など のプロトコルが使われている。ここでは 、これらのプロトコルが使っている現在のネットワーク環境について概観し 、そこでの問題点を提示する。さらに、今後のネットワーク環境がどのようになるかについて述べる。

2.5.1

ローカルエリアネット ワーク

ワークステーションの性能は近年飛躍的に向上している。1991 年には平均 10〜20Mipsに到達すると言われており、これは数年後には 40〜50Mips になるであろう。現在、我々が使用しているローカルなネットワークの媒体としては Ethernet(10Mbps) が一般的であ第 10 部

マルチメディア (マルチメディアメッセージ交換)

323

るが、これは、ワークステーションの性能の向上にともない、FDDI(100Mbps) などのさらに高速なネットワークに置き換えられていくことが予想される。

2.5.2

広域ネット ワーク

WIDE プロジェクトで実験されているような、高速な専用回線を用いた広域ネットワー
クや、ISDN による広域ネットワークが構築できるようになってきた。ネットワークの広域化は計算機環境を拡大し 、遠隔地にある計算機資源を共有したり、遠隔地にいるユー
ザとのコミュニケーションを可能とする。
現在、広域ネットワークを構築する手段として、公衆電話回線、アナログ専用回線、ディジタル専用回線、公衆パケット交換網、プライベートパケット交換網、ISDN 、通信衛星
経由や海底ケーブル経由の国際回線などを利用することができる。
例えば 、米国の NSFnet では、米国内に 7ヶ所あるスーパーコンピュータセンタを T1
回線 (1.544Mbps) で接続している。これをバックボーンとして、専用回線または公衆パケット交換網によって地域ごとのネットワークが接続されている。このように、米国全土のネットワークを接続し インターネットが作られている。日本国内でも、米国のインターネットのような広域ネットワークの構築が必要となってきている。
信頼性と経済性の点から、広域ネットワークの構築にパケット交換網を取り込んでいくことは、重要になってきている。ディジタル専用回線や ISDN などの異種通信技術を並列に利用することは信頼性を向上させ、経済的にも性能的にも有利である場合もあり、広域分散環境を構築するにあたって重要な技術となる。たとえば 、ディジタル専用回線のバックアップとして ISDN による間欠リンクを実現することによって、信頼性を向上させることができる。

2.5.3 現在の広域ネット ワークにおける課題と問題点
 現在利用可能な ISDN やディジタル専用回線などのデータリンクを有効に活用することは重要な課題である。

 一般に広域ネットワークでは、バンド 幅当たりの回線コストが大きいので、ローカ
ルエリアネットワークと比較してバンド 幅の狭いリンクが使われることが多い。そのために、転送するデータ量が増えると通信にかかる時間が非常に大きくなる。

 通信を行う場合には、データ量とは関係なく遅延のために、一定の時間が必要である。これは、特に通信衛星経由での通信の場合などではかなり大きくなる。

 広域ネットワークでは、通信を行なうホスト間に多数の中継点が存在する。それぞれの中継点での中継によるオーバヘッド のために、データ量が少なくても遅延が生じる。送られるデータの量が多い場合には輻輳によって遅延が著しく増大することがある。

1990 年度 WIDE 報告書

324

2.5.4

ネット ワーク環境の今後

今後、ローカルエリアネットワークでは、Ethernet から FDDI や、さら高速な媒体に置き換えられていくだろう。これにともなって、動画像や音声といった大量のデータをネットワークを介して比較的容易に転送することが可能になり、ローカルエリアネット
ワークの内部ではユーザ間のコミュニケーションにボイスメールやビデオメールなどが利用できるようになると考えられる。
また、光ディスクなどの大容量の記憶装置に蓄積された動画像や音声などの情報が、ネッ
トワークを介して転送できるようになると考えられる。
広域ネットワークは、専用回線や間欠リンクなどの複数のネットワーク技術によって構築されるようになっていき、それらの効率のよい運用が可能となるであろう。

2.6 まとめ 音声入力デバイスや画像入力デバイスが生成するデータには複数の符号化方式があり、互いに異なる方式を採用するシステムでデータをやりとりするためには、データの変換を必要とする。

 音声や画像のデータは、いままでのハードディスクなどの記憶装置だけでなく、光ディスクなどの新しい記憶装置に格納されるようになってきた。また、データを記録する際の圧縮方式は複数存在する。

 広域ネットワークは、大量のデータを転送できるようになっていくと考えられる。しかし 、動画像のように広いバンド 幅を必要とするデータの転送には、ネットワークの専有や輻輳が問題となる。

 MHS では変換に関しての規定に動画像の取扱いが含まれていない。また MHS では、ユーザのメッセージはその大きさや種類に依らず一度に転送される。マルチメディ
アデータは、動画像のような非常に大きなデータを含むので、これをネットワーク
を介して転送する場合には、ネットワークへの負荷をなるべく増加させない方法が必要である。

 ODA では、文書の構造などのフォーマットと出力などの再生時に要求される機能のみを表現する。

第 3章
マルチメディアデータの考察
ネットワーク環境は、電子メールやファイル転送などのサービスによってユーザ間のコ
ミュニケーションを可能にしている。近年のワークステーションやパーソナルコンピュー
タはマルチメディア化されてきており、動画像や音声などの膨大なデータを同時に取扱うようになってきた。これに伴って、ネットワークにおいても、さらに大きなデータを頻繁に取扱う必要性がでてきた。現在のネットワーク環境では、大きなデータを転送する際には、ネットワークの輻輳が問題となる。現在のようなデータの配送方法では、マルチメディア化によって、この問題は深刻なものなっていくと考えられる。ネットワーク
環境を快適に利用していくためには、マルチメディアデータを効率よく取扱うメッセー
ジ交換システムが必要である。このメッセージ交換システムでマルチメディアデータを効率よく取扱うためには、マルチメディアデータにその取扱いのための情報を持たせなければならないと考えられる。

3.1 メッセージ交換システム
マルチメディアデータによるユーザ間のコミュニケーションは、メッセージ交換システ
ムによって実現される。メッセージ交換システムとは、ユーザの指示した受信者にメッセージを配送する配送系と、受取り側で、それの取扱いに関して困らないような形式に変換する再生系である。マルチメディアデータは、動画像や音声などの複数のデータの統合化されたものであり、そのデータは一般に膨大な量となる。したがって、メッセー
ジ交換システムは、ネットワークの輻輳を極力回避するために、マルチディアデータの種類や大きさなどの情報によって、効率のよく配送を行なう機能を持つものである必要がある。

3.2 問題点と解決方法
ここでは、マルチメディアデータをメッセージ交換システムによって配送する場合の問
題点とその解決方法を述べる。

325

1990 年度 WIDE 報告書

326

3.2.1

ト ラヒックの増大の回避

動画像や音声のデータを含む膨大な量のマルチメディアデータを転送する際でも、ネッ
トワークの各部が十分なバンド 幅を持てば 、ネットワークの輻輳といった問題は発生しない。しかし 、インターネットのように複数のローカルエリアネットワークを接続した
場合、ネットワーク全体には、様々なバンド 幅を持つネットワークが含まれる。
たとえば 、次に示すようなネットワークの場合を考える (図 3.1) 。
HOST A

HOST CHOST B

Data

Data

図 3.1: 複数のバンド 幅のあるネットワーク
現在行われている電子メールの配送では、ホスト A からホスト B に対しデータを転送する場合、データの大きさや種類に関係なくホスト A ホスト C ホスト B の順番で転送されていく。このとき、ホスト A からホスト C への転送は十分なバンド 幅を持つネットワークを利用するので何ら問題はない。しかし 、ホスト C からホスト B への転送については、ネットワークの容量に対して負荷が非常に大きい。
これの解決方法として、次のようなものが考えられる。

!

!

経路の制御による解決方法
ホスト C とホスト B の間に、バンド 幅の広い他のネットワークがある場合や、間欠リ
ンクによってバンド 幅の広い回線を利用できるならば、それを利用して配送を行なう (図3.2)。
転送速度の低下による解決方法
ホスト C からホスト B へのデータの転送速度を通常より落して配送する。

3.2.2

記憶装置の問題

マルチメディアデータは動画像などの巨大なデータを含むので、これを取扱うには膨大な記憶領域を必要とする。しかし 、ネットワーク上のすべてのホストが 、十分な容量の記憶装置を持っているとは限らない。ネットワークに接続されている計算機の記憶装置の容量は、経済的な理由や管理上の問題から様々であるのが現状である。
例えば 、次に示すようなネットワークの場合を考える (図 3.3) 。
現在の電子メールなどのメッセージ交換では、ホスト A からホスト B にデータを転送する場合、データの大きさに関係なく、ホスト A ホスト C ホスト B の順番でデータ!

!

第 10 部

マルチメディア (マルチメディアメッセージ交換)

HOST D

HOST A

HOST CHOST BData

図 3.2: 経路の制御による解決方法

HOST A

HOST CHOST B

Huge Data

Small Storage

図 3.3: 記憶装置が十分でない場合

327

1990 年度 WIDE 報告書

328を転送しようと試みる。このとき、各ホストが十分な容量の記憶装置を持てば何ら問題はない。しかし 、受取り側に十分な記憶装置がない場合には、送られたデータを受取れないことがある。現在でも電子メールやニュースサービスでしばしば問題となっている。
この場合には、次のような解決方法が考えられる。
データの分割による解決方法
ホスト C の記憶装置の容量が十分にあるならば 、ホスト C にデータの大部分を保存させておき、保存されたデータに関する情報のみをホスト B に配送する。ホスト C に保存したデータが必要になったとき、先に B に転送されている情報にしたがって、ホスト C
からホスト B へ残りのデータを配送する (図 3.4)。
HOST A

HOST CHOST B

Data

Info.
Data

図 3.4: データの分割による解決方法

データの管理の委託による解決方法
ホスト C の記憶装置にそれほど余裕がない場合には、データをホスト C に預けておくことはできない。しかし 、ホスト D が十分な容量の記憶装置を持つならば 、データの保存をホスト D が代行することによって解決できる。(図 3.5)

3.2.3

処理の分散への対応

経済的な理由や技術的な問題から、すべての計算機に音声入出力デバイスや動画像処理デバイスが接続されているとは限らない。したがって、マルチメディアデータの再生には、ネットワークを活用することが考えられる。
現在の電子メールのデータ配送では、データの種類やデータの処理方法を一切考慮しないデータ転送をおこなっている。ホスト A からホスト B を宛先としてデータを送る場
合、データの再生をホスト D に代行してもらうのであっても、データは必ず一度ホスト
B に配送される (図 3.6)。

第 10 部

マルチメディア (マルチメディアメッセージ交換)

HOST D

Data

HOST A

HOST CHOST BInfo.

Data

図 3.5: データの管理の委託による解決方法

HOST D

HOST A

HOST CHOST B
Data

Data

Data

図 3.6: 現在のデータの配送され方

329

1990 年度 WIDE 報告書

330

しかし 、ホスト D が処理するデータはホスト C に一時的に保存し 、ホスト B にとって必要な情報のみをホスト B に送り、その後、必要となったらホスト C からホスト D へ
データを転送し 、処理を代行させるほうがデータの転送量は少なく合理的である (図 3.7) 。
HOST D

HOST A

HOST CHOST B
Data

Data

Info.

図 3.7: 分散処理への対応

3.3 マルチメディアデータに必要な情報
これまでに述べたように、マルチメディアデータをネットワーク上で効率よく快適に取り扱うためには、マルチメディアデータ自身に取扱いのための情報を付加しなくてなら
ない。

3.3.1

再生に関する情報

マルチメディアデータは、音声や画像などの複数種のデータを含んでいる。これらのデータは、異なったマルチメディアシステムにおいても取扱えることが要求される。メッ
セージ交換システムがメディア変換を行えるように、マルチメディアデータは、自分自身を説明する情報を含む必要がある。また、たとえば 、音声と動画像を同期して出力する
ようなこともあるので、各データの同期をとるための時間情報も含んでいる必要がある。

3.3.2

位置に関する情報

これまでに述べてきたように、マルチメディアデータをメッセージ交換システムで取扱うためには、受取り側に十分な容量の記憶装置があるか、また、ネットワークに対する負荷はどれくらいであるかを考慮する必要がある。メッセージ交換システムが、データの分散管理を行えるようにするために、データを位置に関する情報 (ポインタ) で表現できる必要がある。これには、ハードディスクや光ディスクといった計算機の二次記憶装置として開発されたものばかりでなく、今後、マルチメディア化によって接続される可第 10 部

マルチメディア (マルチメディアメッセージ交換)

331

能性のある VTR やディジタルオーディオ機器などの、すべてのデバイスを表現できる必要がある。また、そのデバイス上のどこにあるかを表現できなくてはならない。たとえば 、VTR の場合ならば、何フレーム目から何フレーム目までというように表現できる必
要がある。

3.3.3

転送の優先度

転送の優先度を設けて、ユーザがこれを指定できる必要がある。たとえば 、バンド 幅の狭い回線を利用してデータを転送する場合には、非常に長い時間が必要である。このとき、転送するデータが重要でない場合には、ユーザは転送を行わないかしれない。また、重要なデータの場合には、どんなに長い時間を要するとしても、必ず転送を行なうと考えられる。

3.3.4

返送の要求

受取り側が十分な記憶装置を持たない場合や、回線のバンド 幅が狭い場合などには 、
データの配送ができないことがある。このとき、送信者に必ず返送を行なうようになっていると、ネットワークへの負荷を増大させる。これは 、マルチメディアデータに限ったことではないが 、データの量が膨大になる可能性の高いマルチメディアデータの場合には、特に重要である。したがって、もしも配送ができなかった場合に、返送をするかしないかを指定できる必要がある。

3.3.5

情報の種類

メッセージ交換システムは先に述べたように、データの配送系であると同時にデータの再生系である。実際には、配送されたデータを変換するのはマルチメディア環境として提供されるサービスである。しかし 、サービスには音声変換サービスや画像変換サー
ビスなど複数あるので、どのサービスを利用するかを決定するためにデータの種類が必要である。
また、配送されるデータは、その種類によって配送経路を決定することが考えられる。
たとえば 、動画像の場合にはバンド 幅の広い経路を選択したり、間欠リンクを使用した
りすることが考えられる。
また、データの種類によって、転送のプロトコルを変える場合も考えられる。たとえば 、音声や動画像のような連続的に出力されるデータの場合には、転送経路上の計算機の性能やロードによって転送量が変動してはならず、ある一定量以上の転送能力を必要とする場合がある。このような場合には、メッセージ交換システムは転送プロトコルとして、SRP[96] などを選択する。
現在考えられるデータの種類は以下のとおりである。

 テキスト1990 年度 WIDE 報告書

332

 音声
 静止画像
 動画像

3.3.6

データの表現形式

様々なデバイスから入力されたデータは、固有のデータ構造やフォーマットをもつので、一般的にその互換性は低い。たとえば 、音声データの場合にはサンプリング周波数や量子化数が異なり、これをサポートするデバイスでないと再生することはできない。したがって、異なったマルチメディア間でデータを交換する際にはデータの変換が必要となる。
たとえば 、音声と動画像の場合には次のようなものが必要である。
音声

 サンプリングレート
 サンプリング量子化数
 符号化方法 (ADPCM、DPCM、PCM など )
 符号化後の量子化数
動画像 映像方式 (NTSC、PAL など )
 走査線数 垂直同期

3.3.7

時間情報

マルチメディアには、『動画像と音声を同期させながらテキストを表示する』といったことが要求される (図 3.8)。この場合、動画像とテキストがいつ表示され、音声がいつ出力されるかを明確に記述できる必要がある。

第 10 部

マルチメディア (マルチメディアメッセージ交換)

TEXT

Time

TEXT

Video
Sound
Text

図 3.8: 時間情報

333

第 4章
メッセージ制御言語の設計
現在のコンピュータには、様々なデバイスが接続されるようになってきた。これらのデバイスから生成されるデータは、デバイスごとにフォーマットが定義されている。また、
これらのデータをネットワークを介して転送するためのプロトコルが個別に定義されている。今までのデータの取扱い方では、マルチメディアとして様々なデバイスが接続されるようになると、定義していかなければならないフォーマットやプロトコルは益々増えていくと考えられる。このように、すべてのデータやデバイスに対して個別にフォー
マットやプロトコルを定義することは大変である。これを解決するためには、データとその処理方法を記述でき、さらにフォーマットやプロトコルの定義をも記述できる言語が必要である。また、データを出力する際に、複数のデータを同期する必要もあり、時間に関する記述もできる必要がある。

4.1 メッセージ制御言語の条件
メッセージ制御言語は次の条件を満たしている必要がある。

 データのもつ情報を表現できなければならない。
 データのフォーマットを表現できなければならない。
 データの処理方法 (配送・管理・変換方法) を記述できなければならない。

4.2 仮想計算機の言語によるフォーマット 変換
データ間の関係は、仮想計算機での言語によって表現することができる。例として、データの変換について述べる。
あるアプリケーションによって生成されたデータは、そのアプリケーションの採用するフォーマットによってのみ意味を持つ。したがって、個々のデータは、そのフォーマットと密接な関係にあるといえる。また、特定のデバイスから生成されるデータは、アプ
リケーションの場合と同様に、デバイスの採用するフォーマットと密接な関係にあるといえる。デバイスに入力されるデータも同様である。

334

第 10 部

マルチメディア (マルチメディアメッセージ交換)

335

これらのデータを相互に交換する際には、一端共通のフォーマットに変換されて、それをさらに変換することで実現されると考えてよい (図 4.1)。

Common Format

Program
DataFormat

DataFormat

Data

Application

Data

Application

図 4.1: 仮想計算機の言語によるフォーマット変換
この言語によって記述される各データを、共通のフォーマットに変換するためのプログ
ラムが必要となる。このプログラムはデータのフォーマットに関する抽象化された情報を解釈し 、この情報にしたがってフォーマットを変換するものである。このとき、デー
タとフォーマットに関する情報を一緒にしておき、変換プログラムがメッセージ交換シ
ステムから供給されればデータの変換は可能である。
一般に、データとデバイスとアプリケーションとの関係は、ある言語によって、表現できる。これは、多くのアプリケーションプログラムをアセンブラや C 言語で記述できることからも類推できる。

4.2.1

メッセージ制御言語

ここでは、メッセージ制御言語の記述例を示し 、それぞれの場合について、その概略を説明する。
例 1: 音声を出力する場合
サンプリングされた音声には属性として、サンプリング周波数、量子化数、符号化方法、符号化後の量子化数を含み、データのフォーマットの記述と音声を出力するするためのプログラムを含むものとする。また、音声を出力するデバイスは、仮想的な計算機の生成したデータを出力するド ライバを含むものとする。
このとき、音声は次のように出力される。

1990 年度 WIDE 報告書

336
処理の流れ

1. 音声データはユーザからの指示 \PLAY" を受取る。このとき、音声データ内のプログラムが実行される。

2. encode() によって、音声データが共通フォーマットに変換される。
3. play() によって、変換されたデータが仮想計算機に渡される。
4. 仮想計算機はメッセージ \PLAY" をデバイスに渡す。
5. デバイスは、メッセージ \PLAY" を受取ると decode() でデバイスが理解できるフォー
マットに変換する。

6. dev play() によって実際に音声を出力する。
ここで、play() 、encode() 、decode() は仮想計算機によって提供されるものとする。また、format 、dev format はフォーマットの抽象化された表記法である。
プログラム
音声データ側on PLAY soundplay(decode(sound, format))end PLAY
デバイス側

on PLAY dev_sounddev_play(encode(dev_sound, dev_format))end PLAY
例 2: ネットワークを介して他の計算機に音声を出力する場合
前の例とほぼ同様であるが、play() の代わりに send() を用いる。
ここで、send() は仮想計算機が提供するもので、目的のホストにメッセージとパラメータを送るものとする。
プログラム
音声データ側on SEND host_name PLAY soundsend(host_name, PLAY, encode(sound, format))end SEND

第 10 部

マルチメディア (マルチメディアメッセージ交換)337

例 3: 音声と動画像を同期して出力する場合

syncronize() によって、時間情報に従った実行が行われる。時間情報は基本時間単位とオフセットによって同期する動作を記述する。
時間情報

define TIME_TABEL basic_time_unit [
offset [play(decode(sound, sound_format))display(decode(movie, movie_format))]]on USE_TIME_TABLE
syncronize(TIME_TABLE)
end USE_TIME_TABLE
basic_time_unit: 基本時間単位
offset: 開始時刻からのオフセット

第 5章
今後の課題
複数のメッセージ交換システムが協調して動作するためのメッセージ制御言語の厳密な定義を完成させなくてはならない。メッセージ制御言語には、メッセージの動作を記述する機能と、メッセージのフォーマットの定義を記述できる必要がある。メッセージの動作を記述するにあたっては、同期に関する情報の表現方法を具体化することが重要である。また、どのような動作が必要かを今後の計算機環境の変化を予想しつつ決定していく必要がある。また、マルチメディアデータを効率よく取扱うためには、データを分散して管理するための機構が必要である。たとえば 、データは、データの実体とデー
タに関する情報に分割される。したがって、データに関する情報のみが削除され、データの実体のみが残ってしまった場合の処理方法といったように、個々の場合について検証していく必要がある。この管理機構は機種に依存せず、構造が簡単で、強力な機能を持つものが望ましい。これをメッセージ制御言語で記述するためには、NeFS[97] のような言語がよいと考えられる。

338

第 6章
結論
現在のネットワーク環境は高速な専用回線をすべてのネットワーク間接続に使用することは経済的に実現不可能であったり、すべてのネットワーク間通信で必要であるとは限らず、複数の種類の異なった回線によって接続されている。マルチメディアデータは膨大なデータとなるので、メッセージ交換システムで取扱うためには、ネットワークの混
雑と、記憶領域を十分考慮した、効率のよい運用が重要である。様々なネットワークに対して柔軟な対応を行うためには、メッセージに自分自身の動作を記述する必要がある。
マルチメディアは、画像、音声などを取扱うサービスを統合するが 、これらのサービスの完全な統合には、現在まだ検討を要する。特にマルチメディアデータの転送のためのプロトコルは他種のホストおよびマイクロコンピュータで利用可能で、さらに各種のインタフェースおよび通信技術に対応できるものでなければならない。また、マルチメ
ディアデータの表現形式は将来にわたって拡張できるものである必要がある。

339

340

1990 年度 WIDE 報告書