ローカルエリアテレビ会議ネットワークの構築

1．は じ め に 近年の高速なネットワークの普及により，大容量の動 画像コンテンツの配信が可能となっている1)–4) ．またそれ にあわせて，情報通信を巡る環境が多様化しており，コ ンテンツ送受信のための端末として，デスクトップ PC， ノート PC などさまざまなものが存在している． そのような環境において，映像や音声などのマルチメ ディア情報を配信する際，通信経路や符号化に用いる端 末等の性能や状態に合わせてリソースの性能を引き出し た最適な符号化・配信等の処理を行うことにより，快適 な通信環境の実現が可能となる．そこで，我々は環境に 適応するマルチメディア情報通信システムの開発を進め ており5)–8) ，あわせて，いくつかの環境適応技術の技術の 研究を行ってきた9),7),10)_． 現在，このようなシステムの具体的な運用例として， 研究室複数個所を結ぶ「ローカルエリアテレビ会議ネッ トワーク」の構築を進めている．本システムは，専用の ハードウェアを用いず，既存のネットワーク回線や PC 等の安価なハードウェアを用いることで，低コストなテ レビ会議システムを構築することを目的としたもので， 学内で実際に運用することにより，システムにおいて改 善すべき問題点を明らかにすることを狙いとしている． 本計画は，本年度から開始されたものであり，計画の 第一段階として，本年度末までに多対多の映像・音声通 信を可能とする「基本システム」を実現するために必要 な作業を進めている．次年度以降，システムの充実のた めに必要な要素技術の開発を行う予定である． 本稿は，現在構築中であるローカルエリアテレビ会議 ネットワークの基本システムの構成，および基本システ ムに搭載する二つの要素技術の概略について述べる．2 章において，関連研究を紹介し，本研究との違いを明確 にする．3 章において，システムに求められる条件，お よびシステム構成の概略を述べる．4 章では，システム 構築の詳細を，映像インターフェイス，音声インター フェイス，エンコーダを含む配信モジュール，デコーダ を含む受信モジュール，および通信ネットワークの 5 つ の部分に分けて説明する．5 章で，システムに搭載する 二つの要素技術，および今後の研究課題となる二つの要 素技術概略について述べる． 2．既存の映像通信システム 動画や音声を配信するためのソフトウェアは数多く存 在する1)–4)_．DVTS2)_{は，家庭用デジタルビデオカメラか}

ローカルエリアテレビ会議ネットワークの構築

三 浦 康 之 * ・日 下 真 士 * ・佐々木健太郎 * ・佐 藤 慶 一 *

武 田 裕 司 * ・西 潟 拓 朗 *

A Development of Local Area Tele-Conference Network

Yasuyuki MIURA*, Masashi KUSAKA*, Kentaro SASAKI*, Keiichi SATO*,

Yuji TAKEDA* and Takuro NISHIKATA*

In recent days, the environment of communication is diverse. Terminals for transmitting/receiving are also diverse such as desktop PC, mobile PC, and cell-phone and so on. In such environment, when multimedia contents such as video and audio data are transmitted, it seemed to be able to realize pleasant environment of communications to encode or transmit adaptively to resources such as terminal or network. In response to this situation, we previously developed a software-based real-time MPEG (Moving Picture Experts Group) system for streaming live video. We are now imple-menting this system in our laboratory for use as a tele-conference system. In this year, we are developing some basic technologies of the system.

Vol. 42, No. 1, 2008

*情報工学科 講師

ら IEEE1394 ケーブルを通して PC に取り込んだ DV (Digi-tal Video) 規格の圧縮データを UDP/IP 経由で伝送するシ ステムである．カメラ内で符号化された信号をそのまま 配信するため，PC 内の処理は，DV データのパケット化 のみで，VGA (720
480) ピクセルの信号を毎秒 30 フレー ムの速度で配信できる．DV データは，比較的高画質な 映像を提供できるという特長を有しているものの，圧縮 データのビットレートが 20 Mbps と大きいため，配信に 際してネットワークへの負担が大きなものになるため， LAN上での運用には問題がある． Ekiga3) は，オープンソースの GNOME 向けのビデオ会 議アプリケーションソフトである．ソフトウェアベース による多くのビデオ・オーディオコーデックをサポート し，離れた 2 地点を結ぶテレビ通話を PC 上で実行する ことが可能である．Ekiga は，現在 Linux 対応の動画配 信ソフトとして最も幅広く用いられているソフトの一つ である．ffmpeg4) は，動画と音声の各種ファイルフォー マットへの変換ソフトである．多彩な符号化形式に対応 しているため，幅広く利用されている他，内部に配信 サーバが含まれており，http プルトコルによるビデオの ストリーミング配信が可能である． これらのソフトウェアは高フレームレートで自然な動 画を提供できるが，ソフトウェアベースの符号化を行っ ているため，圧縮処理の能力に限界がある．そのため， 解像度が低く，低画質なものとなる．本システムは，手 書きの文字やディスプレイの画面などの情報を映像を通 して受け取りつつ研究指導を行う運用を考えており，高 画質であることが求められるため，低解像度の画像では 本システムの運用目的を満足することができない． また，上記のシステムはすべて単一ストリームを前提 としたシステムであり，多地点での運用に適さず，特に 多地点を前提とした通信環境に適応した技術があるわけ ではないので，リソースの性能が制限された環境内で， その性能を引き出して運用せざるを得ない状況には適さ ない． 専用のキャプチャボードを用いるか，または専用のテ レビ電話機器を用いれば高画質で低遅延な通信が可能に なるが，高価な専用機器を購入する必要がある．これら の機器を多地点におけるテレビ会議システムとして運用 するためには莫大なコストがかかるため，本計画での使 用には適さない． 3．システム概略 3.1 要求条件 本システムは，大学の研究室において実際にテレビ会 議システムとして運用しつつ，運用上の問題点を検証し， 解決することを目指すものである．従って，下記のよう な機能が求められる． • 低コスト化 • 改変の容易化 • 多地点間通信 特に 3 番目の項目に関しては，少なくとも 3 地点で 20 箇所規模の通信を扱う必要がある．そこで，本システム は下記の要件を満たすものとする． • 低コスト化のため，市販の PC を使用してソフトウェ アで符号化・復号を行う． • 必要なソフトウェアを自作する． • 多地点間の通信に対応するため，動的なシステムへ の参加・脱退を可能なものにする． 3.2 システム構成 図 1 に，本システムの構成を示す．本システムは， Lab. 1–Lab. 3の 3 ヶ所を結ぶ多地点テレビ会議システム である．各地点に 1 台の PC を配置し，各 PC で配信モ ジュールと受信モジュールを一つずつ動作させる． 本システムは，制御，配信，受信の 3 種類のモジュー ルを持つ．これらは，それぞれ以下の機能を有する． 制御モジュール 配信モジュール・受信モジュールのシ ステムへの加入や脱退，ストリームデータ量の制御や 図 1 システム構成

シーンの構築等，システム全体の管理に関わる処理を 行う． 配信モジュール ビデオカメラから映像を取り込み， MPEG-414)_{形式に符号化してパケット化し，受信モ} ジュールに向けて配信する． 受信モジュール 配信モジュールから受け取った MPEG-4ストリームデータを復号し，ディスプレイに表示す る． 上記のうち，配信そのものに関する処理は基本的には 配信モジュール・受信モジュール間でのみ行われる．制 御モジュールはシステム管理に関する最小限度の処理の みを担わせる設計にすることにより，システムに参加す る配信・受信モジュールの増加に伴う制御モジュールの 負担を最小限に抑え，システム規模の拡大に耐えられる 構造とする． PCにおいて最も頻繁に用いられている OS は Windows であるが，Windows では時間計測の精度が ms 単位と荒 い点，Linux はオープンソースのソフトウェアが多く，自 作によるシステム構築の都合が良いことから，本研究で は，OS として Windows を用いず，Linux ディスリビュー ションの一つである Ubuntu を用いている． 4．システム詳細 4.1 制御モジュール 現在，制御モジュールの詳細に関しては検討中である が，おおよそ下記の機能を持たせることを想定している． 現在の予定では，下記の機能の多くを配信モジュールま たは受信モジュールに持たせる方針で検討を進めており， システム全体の管理に関わるため，配信・受信モジュー ルに担当させるのが適切でないものについて制御モ ジュールに担当させる予定としている． 制御モジュールは， 各端末における配信・受信モ ジュールの加入・脱退状況を管理する部分となる．制御 モジュールには， システムに参加中の配信・受信モ ジュールに関する情報を記述したテーブルを用意して， 加入・脱退を管理する．

制御モジュールではまた，SNMP (Simple Network Man-agement Protocol) に基づき，各端末やネットワークの MIB (Management Information Base) から各種情報を収集して， 収集した情報に基づいてシステム全体の管理を行う予定 である．これまでのところ，Linux 上で SNMP エージェ ントを起動させ，MIB ツリーに基づいてメモリや CPU， プロセスの各種情報を取得することが可能になっている． 4.2 配信モジュール 配信モジュールの MPEG ソースコードは，MoMuSys (Mobile Multimedia Systems) の MPEG-4 参照ソフトウェ

ア12)_{を利用する．MoMuSys 参照ソフトウェアは，著作} 権表示を行うという条件において改変・再配布が認めら れている． ただしこれらのソフトウェアは，多機能であることと 正確に動作することに主眼が置かれ，さほど速度が考慮 されていないため，高速化のためのいくつかの改善が必 要となる．具体的には，DCT 変換やメモリ領域の確保， 符号化に関する種々の情報の収集や表示に関して余分な 処理を行っているため，これらの処理の見直すため下記 の作業を予定している． • MoMuSys参照ソフトウェアでは，テレビ会議システ ムでは使用されない「形状情報符号化」や「空間ス ケーラビリティ」に要する処理が多数含まれている ことが，処理時間増加の大きな要因になっている． これらを削減することで，符号化処理の高速化が可 能となるので，該当部分の見直しを行う． •参照ソフトウェアでは，符号化に必要なメモリ領域 に対して動的に確保・解放を行っている．また，符 号化の途中経過を出力するルーチンが存在する．こ れらの処理に要する時間を削減するため，動的に割 り当てられていたメモリ領域を静的に割り当てる， 不要な結果出力を削減するなどの見直しを行う． • DCT変換の高速化のためには Pentium プロセッサ独 自の命令セットである MMX や SSE が有効なので， 実装に向けた作業を進める． 4.3 受信モジュール 受信モジュールは，ユーザーインターフェイスを扱う 部分である．受信モジュールでは，配信モジュールから の複数の要求を受け付けることができる構造にする．そ の際に，管理モジュールと連携して，加入・脱退などの 要求処理を行う必要がある．また，複数の映像の符号化 を効率よく実行するため，タスクスケジューリングの枠 組みが必要になる． 本年度は，2 箇所からの映像を一度に取り込み，同時 に復号できる構造のものを構築している．次年度以降， 3地点間の通信を可能とすることを目指し，開発を進め る．ユーザーインターフェイスの構築，配信モジュール の加入・脱退管理は後日の課題とする． 4.4 映像インターフェイス 現在のシステムでは，IEEE1394 インターフェイスを用

いて，デジタルビデオカメラからの映像を取り込んでい る．本システムの要求条件の一つに，低コスト化が挙げ られるため，安価な USB カメラからの映像の取り込みを 可能にするための取り組みを進めている．Linux では， U S B カ メ ラ か ら の 映 像 の 取 り 込 み の た め に ， Video4Linux13)_{や Linux UVC (USB Video Class)}14)_のデバイ スドライバが用いられている．うち，LINUX-UVC は，現 バージョンの Ubuntu では正しく動作していないため， Video4Linux対応のソフトウェアをもとに映像インター フェイスの開発を行っている． 4.5 音声インターフェイス 本システムでは，多地点間で会話を行うことが前提と なるため，マイク入力を可能にするための，音声イン ターフェイスを構築する必要がある．そこで，Linux カー ネル 2.6 以降に標準的に実装されている ALSA (Advanced Linux Sound Architecture) の枠組みに基づいて音声イン ターフェイスを開発する．ALSA は，カーネル 2.4 以前 に標準で組み込まれていた OSS/Free (Open Sound Sys-tem/Free) と 互 換 性 を 保 つ よ う に 開 発 さ れ て お り ， OSS/Freeに比べて多くのサウンドカードに対応している． 本システムは，同一の部屋の中で複数の受信モジュー ルが稼動するケースが考えられるため，同一の部屋内の 受信モジュール間で映像・音声ストリームの再生時刻に 差が生じると，音声が聞き取りにくくなることが考えら れる．そこで，システムの運用にあたっては，映像と音 声の同期や，音声同士の同期が必要となる．特に，上記 の理由により音声同士の同期は重要な課題となることが 予想される．そこで開発の際には，他のストリームとの 同期が容易に取れるよう，音声データに同期データを ヘッダとして付加できる構造にする． 音声は映像データに比べて情報量が少ないので，初期 仕様では圧縮は行わないものとしている．ただしその場 合，CD 品質の音声データの伝送に約 1.5 Mbps 前後の容 量を必要とするため，音声の伝送に十分な帯域のみに制 限することで情報量を削減している．具体的には，音声 の帯域を，人間の声の範囲である約 3.4 kHz までとする ことで，データ量を 1/8 に削減している． 現在開発中のソフトウェアでは，音声の処理による端 末への負担を避けるために，特に符号化を行わず，単純 にサンプリング周波数を削減しているだけであるが，人 間の声の範囲の周波数の音声ならば，特に不自然な感覚 を与えることなく再生が可能となっている． なお，現在の設計では PC のマイク端子からの音声入 力に限られているが，将来的には USB カメラ付属のマイ クからの音声の取り込みも可能にする予定である． 4.6 通信ネットワーク 配信モジュールと受信モジュールの間では，符号化 データと制御情報の二種類のデータがやり取りされる． 前者はさらに，映像と音声の二種類のデータに分けられ る．従って，配信モジュールと受信モジュールの間は合 計 3 つのストリームが流れることになる． これらのうち，符号化データのためのストリームでは， 映像・音声データが配信され，制御情報のためのスト リームには，各 VOP の符号化時間や，各モジュールの 時刻情報，配信される VOP の種別等がやり取りされる． 後者は，確実な情報伝達を保障するため TCP を用いる． 前者は，通常は UDP が用いられるが，本システムでは 実装の都合上，映像情報の伝送には TCP を用いた．実 際，LAN 上での運用では通信遅延が比較的小さく，かつ 途中経路でのデータ損失が発生しにくいため，大量の データを少しずつ小出しにして転送する場合，TCP の方 が効率的な場合がある． 本システムでは，各モジュールがネットワークと端末 の情報を収集できるものにするため，各モジュールに SNMPエージェントを配置し，ネットワークスイッチや PCの MIB を参照できる構造にする予定で作業を進めて いる．Linux では多くのディストリビューションで SNMP を標準搭載している． Windows でも， 簡単な設定で SNMPを動作させることができるので，Windows へ移植 する際にも SNMP は問題なく使用することができる．将 来的には，SNMP や既存の様々なレートコントロール技 術15)–18) を組み合わせた運用を想定している． 本システムは，ルータを挟んで異なるサブネットワー ク間で運用することを想定しているため，サブネット ワークを跨いだ通信を可能とする枠組みの構築が必要に なる．特に本システムでは，ルータを挟んだローカル ネットワークにおいて多数の USB カメラを接続する可能 性があるため，通常用いられるような，ルータにおける ポートのマッピングによらない方法が求められる．この 問題について，多くのネットワークルータに搭載されて いる DMZ (DeMilitarized Zone) 機能を活用する方法を現在 検討中である． 5．要 素 技 術 本稿では，システムに搭載する要素技術として，過去 に開発済みの「VOP 選択アルゴリズム」，現在開発中の

「遅延設定モデル」，および今後検討する予定の「受信モ ジュールにおけるタスクスケジューリング」「リソース 管理アルゴリズム」の 4 点を取り上げる． 5.1 VOP 選択アルゴリズム 5.1.1 アルゴリズム 2.1のモデルにおいて実時間配信を行うため，配信側 PCの MPEG エンコーダにおいてサーバマシンや家庭用 PCなど使用するハードウェアの性能に対応した柔軟な符 号化を行うための VOP 選択アルゴリズム7) 提案した． VOP選択アルゴリズムとは，各 VOP の符号化時間計測 の結果を用いて後続の VOP の符号化時間を予測して，構 成の異なる 3 種類の VOP ブロックから最適な種類と長さ のものを選択するものである．ここで，VOP ブロックと は複数個の VOP の並びと定義される． アルゴリズム中で，I-VOP と P-VOP それぞれにつき， 後続の VOP によって参照されないため符号化処理の一 部を簡略化できる簡略化 VOP と簡略化の不可能な非簡 略化 VOP に分け，下記の 3 種類の VOP ブロックから適 切なものを選択する．なお，下記の（ ）内の i, I, p, P は それぞれ，簡略化 I-VOP，非簡略化 I-VOP，簡略化 P-VOP，非簡略化 P-VOP を示している． IPブロック 一個の非簡略化 I-VOP の後に複数の非簡略

化 P-VOP が続き，簡略化 P-VOP を配置した VOP ブ ロック (IPPP...Pp)

PIブロック 一個の非簡略化 I-VOP の後に一個の簡略化

P-VOPを配置し，続いて複数の簡略化 I-VOP が続く

VOPブロック (Ipiii...)

Iブロック 一個の簡略化 I-VOP のみの VOP ブロック (i) その際，これらの VOP ブロック長，すなわち VOP ブロッ クに含まれる VOP の数は， 1. IPブロックの場合は VOP ブロックの合計符号化時 間が目標符号化時間以下になる最長の長さ 2. PIブロックの場合は VOP ブロックの合計符号化時 間が目標符号化時間以下になる最短の長さ 3. Iブロックなら 1 と決定する． VOP選択アルゴリズムを図 2 に示す．VOP 選択アルゴ リズムの使用により，本システムは符号化に用いるハー ドウェアの性能にしたがって適切な量の符号量を削減す ることが可能となる．さらに，MPEG のレートコント ロール機能を組み合わせることにより，一定の符号量の 中でハードウェアの性能にしたがって品質の異なる動画 像を提供することができる． 5.1.2 実験結果 上記のアルゴリズムを検証するため，MPEG-4 参照ソ フトウェアを用いて実験映像の変換実験を行った．その 際，目標平均符号化時間を 100 ms
350 ms の可変値とし ている．実験映像を図 3 に示す．実験映像は，カメラを 固定して右側の列車が画面後方に進行する様子を撮影し た映像である． 実験映像において 4 種類の VOP が使用された割合を 図 4 に示す．図中，横軸が目標平均符号化時間，縦軸が 各 VOP の割合である．図 4 に示されるように，目標符 号化時間が長くなるに従って符号化に多くの時間を要す る P-VOP の数が増えてゆく．このように，提案手法では 使用する VOP の数を調節している． P-VOPが増加することによる効果を確認するため， MPEG-4参照ソフトウェアのレートコントロール機能を 用いて比較を行った．参照ソフトウェアのレートコント 図 2 VOP選択アルゴリズム 図 3 実験映像

ロール機能は，量子化スケールを変更して目標平均符号 量 を 達 成 す る た め の 機 能 で あ る ． 本 実 験 で は ， 30000 bits/frameを目標フレームレートとした実験を行っ た．目標平均符号化時間を 350 ms とし，I-VOP のみで符 号化を行った場合と提案手法を用いて P-VOP を併用した 場合の比較を行った．符号化後の画像を一部拡大したも のを図 5 に示す．図 5a) は I-VOP のみで符号化を行った 場合，図 5b) は提案手法を用いた場合である．前者に比 べて後者はブロックノイズが軽減され，画質が良いもの になっていることがわかる．P-VOP を併用してフレーム 間圧縮を行うことにより，個々の VOP に対する量子化 スケールによって削減するビット数を抑えることができ るため，提案手法では同程度の符号量に対する画質が向 上する． 5.2 遅延設定モデル 5.2.1 概要 配信・受信モジュール間には符号化・通信・復号に伴 う遅延が発生する．特に本システムでは，ソフトウェア で符号化・復号を行っている性質上，符号化・復号に 伴って一定でない値の遅延が発生する．遅延設定モデル は，これらの遅延を予め予測して，予測される最大の値 をシステムの遅延時間として設定することで自然な動画 像の再生を可能にするものである9),10)_{．以下に，遅延の} 設定法について述べる． 5.2.2 パラメータの定義 図 6 に，本システムにおける動画像情報の流れ図を示 す．図 6(a)，および図 6(b) が，それぞれ配信モジュール および受信モジュールにおける流れ図である．本章で述 べるモデルにおける各時刻を示すパラメータを以下のよ うに定義する．なお，VOP の通し番号として i (i0) を使 用する．また，各パラメータのタイミングを図 6 の下の 直線に示す．

CAP(i) i番目の VOP である VOPiをビデオカメラから取得

した時刻

Es(i) VOPiの符号化を開始する時刻 Ef(i) VOPiの符号化を終える時刻

Dp(i) i番目の AU が配信モジュールを出発する時刻（E f (i)

と同一とする） Ar(i) i番目の AU が受信モジュールに到着する時刻 図 4 符号化後の VOP の割合 図 5 符号化後の映像 図 6 配信・受信モジュールにおける動画像情報の 流れ

Ds(i) VOPiの復号を開始する時刻 Df(i) VOPiの復号を終える時刻 CTS(i) i番目の CU に設定された CTS TrI, TI, TrP, TPそれぞれ簡略化 I-VOP，非簡略化 I-VOP， 簡略化 P-VOP，非簡略化 P-VOP における平均符号化時 間 Fフレームレート 5.2.3 配信モジュールのモデル VOP表示間隔が一定でなければ，見る側に不自然な動 きを感じさせる動画になる．そこで，本システムのオブ ジェクト間のタイミング処理には，各 VOP の CTS の同 期インターバルを一定間隔とするという条件を以下のよ うに与える． CAP(i)CAP(0)i ·1/F (1) VOPiの，配信モジュールにおける遅延 Ls(i) は Ls(i)Ef(i)CAP(i) (2)

となる． エンコーダの「フレーム取得待ち」による処理待ち時 間の発生を防ぐため，図 7 のように予め VOP0の符号化 の前に空隙を挿入する．この遅延 TAを，「時間補正」と 呼び，下記のように定義する． TAEs(0)CAP(0) (3) ここで簡単化のため，配信モジュールの遅延を「時間補 正による遅延」LA(TA)と「その他の遅延」Liに分けて 考える．「その他の遅延」は VOP ブロック内で発生する ため，以後「ブロック内遅延」と呼ぶ．以降，おのおの について考える． 時間補正による遅延 ここでは TAの値を求める．k (k0) 番目の VOP ブロッ

クの先頭の VOP を VOPn(k)とし，k 番目の VOP の「時間

補正による遅延」TA(k) とすると TA(k)Es(n(k))CAP(n(k)) (4) となる． ここから，TAの値は，下記の手順で求められる． 1. 初期設定として，TA0 とする． 2. 4に基づき，各 VOP ブロックの先頭 VOPn(k)に符号 化処理が到達した時に，実際の時間遅れ TA(k) を 計測する． 3. TATA(k)tu (5) または TATA(k)tl (6) のように，予め定められた TAと今回計測した TA(k) に一 定以上の差があるとき，新たに TATA(k) (7) と設定し直す． ここで，tu, tlを，TA再設定の上方閾値，または下方 閾値と呼ぶ．これらの値が小さいほど，TAの再設定が 発生しやすくなる． ブロック内遅延 (1) およびブロック内遅延の定義より，VOPjのブロッ ク内遅延は下記のようになる． Li( j)Ls( j)TAEf( j)CAP( j)TA (8) From (3) 上式は，下記のようになる． (9) ここから (10) となる． N個の VOP を含む IP ブロックの n 番目の VOP におい て，(10) は nN で最大値となるので， L ji Enc i j n k F i n k j ( ) ( ) { ( )}/ ( )    

∑

∑

∑

N/F(N1)/F1/F (11) となる． 同様に PI ブロックにおいて，(10) は下記のようになる． (12) (11) および (12) より，Liは Limax{Li( j)}max{TITrP1/F, 1/F} (13) となる． 5.2.4 受信モジュールのモデル 復号に要する時間は符号化に要する時間に比べて小さ いので，復号時間の予測は比較的容易である． 復号時間 Tdecは，下記のように求められる． 復号時間は I-VOP と P-VOP で異なるので，それぞれ別個 に過去一定数フレームの平均値を求め，それぞれ TdecI, TdecPとする．

Tdecmax{TdecI, TdecP} とする．

通信時間の評価はより複雑である．ビットレートが少 ない場合，通信時間は少ないものに留まるが，ビット レートが増えるに従って通信時間は無視できなくなる． そこで，下記の方法により将来の通信時間を予測する． 1. 各 VOP の符号化バイト数，符号化情報全体の通信 遅延を測定する． 2. 符号化バイト数を x 軸，通信時間を y 軸とした回帰 直線を最小二乗法により求め，符号化バイト数 b に 対応する通信時間予測直線 T˜(b) とする． 3. 各 VOP について下式の値を求め，値の大きいもの 上位 P% の VOP を選び，その時の符号化バイト数 を bP%，通信遅延を TP%とする． En(TnT˜(bn))/T˜(bn) (14) ここで， T：各 VOP の通信遅延の実測値 T˜：回帰直線に基づく，符号化バイト数 bnにおけ る通信遅延の予測値 である． 4. 下式の曲線 TTr(b) を，通信遅延の最終的な予測値と する． (15) (15) に基づいて通信時間の予測値を求めることにより， 過去の通信時間の P% 以外を予測値以内に含むことがで きる． 上記より，システム全体の遅延 L は，下記のようにな る．

LLs(i)TTr(b(i))Dec(i) (16)

ここで，b(i) は VOPiの符号化ビット数である． 5.2.5 タイムスタンプの設定 (7), (13) および (16) より，全体の最大遅延時間 Lmax は，下記のようになる． LmaxTAmin{2/FTrITI, TPTI} max{TITrP1/F, 1/F}

maxi{TTr(b(i))Dec(i)} (17)

5.2.6 実験結果 提案手法の有効性を確認するため，MPEG-4 参照ソフ トウェア12) を用いて簡単な配信・受信システムを構築 し，ライブ映像の符号化・伝送・表示を行った．サンプ ル画像を図 8 に示す．Movie 1 は建物の外側を写した映 像で，ほとんど画面に変化は現れない．Movie 2 は樹木 が激しく風に揺れている映像で，画面の変化が大きく， 符号化時間の分散が Movie 1 より大きい． 今回は二種類の実験を行った．第一の実験として，配 信モジュールにおける符号化修了時刻 Ef(i) を計測し，測 定した時刻 Ef(i) と予測値を比較した．実測値が予測値 よりわずかに遅れた場合，フレーム遅れが発生するため， 動画像の動きがやや不自然なものになる．実測値が予測 値より 1/F 以上遅れた場合，そのフレームは破棄され， フレームロスとなる．第一の実験では，tu0, tl1/2F と している．第二の実験として，各 VOP の通信時間を計 TTr( )b (1 EP% b b/ P%) ˜( )T b L ji Enc i F TI TrP F i n k n k ( ) ( ) / / ( ) ( )        1 1 1

∑

∑

測し，(15) に基づき予測通信時間を求めた． 第一の実験によって計測されたフレーム遅れの数を図 9に示す．図 9 に示すように，フレーム遅れの数は数十 フレームに一回に留まっている．実験中，フレームロス は一度も発生していない．従って，予測値に加えて 1/F 未満の一定の遅延を与えることで，フレーム遅れを防ぐ ことが可能と考えられる． Movie 1における通信時間の計測値，回帰直線，およ び P10%, 5%, 2% における予測通信時間を図 10 および 11に示す． それぞれ図 10 が 90 kbits/frame， 図 11 が 270 kbits/frameにおける値である．これらの図から，予 測値は回帰直線とさほど大きな開きがないことが分かる． 両者の違いは図 10 においておよそ 8.5%–13.9%，11 にお いておよそ 4.2%–14.1% に留まっている．これらの結果 を利用することにより，特に遅延の大きい 10%, 5%, 2% を除くすべての VOP を予測遅延時間以内に収めること ができる． 6．ま と め 本稿では，現在構築中であるローカルエリアテレビ会 議ネットワークの基本システムの構成，および基本シス テムに搭載する二つの要素技術の概略について述べた． 本システムは，環境に適応するマルチメディア情報通信 システムの具体的な運用例として，研究室複数個所を結 ぶネットワークとして構築を進めているもので，専用の ハードウェアを用いず，既存のネットワーク回線や PC 等の安価なハードウェアを用いることで，低コストなテ レビ会議システムを構築することを目指している． 本計画によりこれまでに，音声の伝送方式，および SNMPによる端末情報の取得法についての技術を確立し たので，以降はこれらの技術の実装，および USB カメラ の取り付け法，多対多通信への対応等の技術開発を進め る．また，次年度以降，システムの充実のために必要な 要素技術の開発を行う予定である． 謝  辞 本研究の一部は，文部科学省科学研究補助金（若手 (B)）によって行われいる．関係各位に感謝する． 参 考 文 献 1) 勝本道哲，原田雅博，中川晋一，D1 over IP による 高品位動画像転送・蓄積システムの設計，情報処理 学会・マルチメディア通信と分散処理研究会報告論 文集，No. 95, pp. 85–90, 1999. 2) 杉浦一徳，小川晃通，中村 修，村井 純，民生 用 DV を用いたインターネットビデオ会議システム， 情報処理学会誌，Vol. 40, No. 7, 1999.

3) Ekiga, http://ekiga.org/ (URL)

4) FFmpeg, http://ffmpeg.sourceforge.net/ (URL)

5) 三浦康之，勝本道哲，実時間環境におけるビジュア

ル符号化のための実証実験，情報処理学会研究報 告，2002-DPS-100, pp. 25–30, 2002.

6) Yasuyuki Miura, Michiaki Katsumoto, An Overview of a Real-time Contents Edition System for MPEG-4, Proc. of 2003 IEEE Pacific Rim Conference on Communications Computers and Signal Processing (PACRIM 2003), pp. 図 10 予測通信時間 (90 kbits/frame)

図 11 予測通信時間 (270 kbits/frame)

81–85, 2003.

7) 三浦康之，勝本道哲，実時間コンテンツ編集システ

ムの動画像符号化における VOP 選択アルゴリズム の提案，情報処理学会論文誌，Vol. 45, No. 2, pp. 498–508, 2004.

8) Yasuyuki Miura, Michiaki Katsumoto, A Proposal of “Intelligent” Multimedia Communication System Using MPEG-4, The 1st Workshop on Tools and Applications for Mobile Contents.

9) 三浦康之，実時間 MPEG 動画伝送における通信時

間解析，電子情報通信学会 2007 年総合大会，D-11-12, 2007. 3.

10) Yasuyuki Miura, Michiaki Katsumoto, A Latency-Esti-mation Method for Software-Based MPEG-4 Video Streaming Systems using Gigabit Ethernet, Proc. of the 2007 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing.

11) ISO/IEC 14496, Final Draft International Standard MPEG-4, 1998.

12) ISO/IEC 14496-5, Final Draft International Standard

MPEG-4: Reference Software, 1998. 13) Video4Linux, http://www.video4linux.net/ 14) Linux UVC, \\http://linux-uvc.berlios.de/

15) Vetro, A., Sun, H. and Wang, Y., “Object-Based Transcoding for Adaptable Video Content Delivery”, IEEE Trans. on Circuits and Systems for Video Technol-ogy, Vol. 11, No. 3, pp. 387–401, 2001.

16) Cavallaro, A., Steiger, O. and Ebrahimi, T., “Semantic Segmentation and Description for Video Transcoding”, Proc. International Conference on Multimedia and Expo (ICME), Vol. 3, pp. 597–600, 2003.

17) Takeshi Takahashi, Tsuyoshi Hanamura, Hiroyuki Kasai, Isao Nagayoshi, Hideyoshi Tominaga, “Remulti-mexing Scheme for MPEG-2 Multiprogram Transport Stream Transcoder”, Electronics and Communications in Japan, Part 1, Vol. 86, No. 2, 2003.

18) M. Wakui，I. Nagayoshi，T. Hanamura，H. Tominaga, “A Bandwidth Adaptive Rate Control Scheme of MPEG Transcoder for Video Streaming over Non QOS-guaran-teed Network”, SCI 2003, Vol. III, pp. 24–29, 2003.