動画編集アプリケーションのavidemux の並列化によるMPEG

2002 年度卒業論文
動画編集アプリケーションの avidemux
の並列化による MPEG-4 動画エンコー
ドの高速化
提出日 : 2003 年 2 月 5 日
指導
: 上田和紀教授
早稲田大学理工学部情報学科
学籍番号 : G99P045-1
北井翼
概要
本研究は MPEG-4 動画エンコードの高速化を目的としている。
現在、MPEG-4 動画のエンコードは一般ユーザが PC で行う処理の中で特に重
い処理の一つである。動画のエンコードといった類の処理にはハードウェアエン
コーダを使うのが効率的であるが、現状、民生用の MPEG-4 ハードウェアエン
コーダは存在しない。そこで、その処理を MPI による並列化で高速化出来ないか
と考え、それを研究テーマとした。当初は XviD というオープンソースの MPEG-4
のエンコードライブラリを改造することにより高速化を試みようと考えたが、調
査を進めるうちに、MPEG 動画の構造から、データ並列的に問題なく処理出来る
ことに気付き、逐次の動画編集アプリケーションである avidemux を MPI を用い
て並列化改造することにより MPEG-4 動画のエンコードの高速化を試みた。具
体的には、エンコードライブラリ自体は逐次のものをそのまま使い、それを呼び
出し、使う側である動画編集アプリケーションが並列に複数立ち上がりエンコー
ド区間を PE 毎に分割し、エンコード後それらを結合するというものである。そ
の結果、この方式で台数に応じた速度向上が得られた。
目次
第 1 章はじめに
1.1 研究の目的と背景 . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 論文構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
第2章
2.1
2.2
2.3
2.4
.
.
.
.
2
2
4
4
5
.
.
.
.
.
.
6
6
6
6
9
9
9
.
.
.
.
.
.
.
.
.
.
12
12
12
14
14
14
17
18
21
22
24
並列化案について
MPEG-4 の概要 . . . . . . . . . . . . . . . . .
MPEG-4 動画エンコード全体の流れについて .
エンコードライブラリの改造による方法 . . .
動画編集アプリケーションの改造による方法 .
第 3 章実行環境
3.1 ハードウェア構成
3.1.1 PE 構成 .
3.1.2 Myrinet .
3.2 ソフトウェア構成
3.2.1 OS . . . .
3.2.2 SCore 5.2
第4章
4.1
4.2
4.3
4.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
並列版 avidemux の実装
並列版の設計方針 . . . . . . . . . . . . . . . . . . . . . . . .
コンパイル . . . . . . . . . . . . . . . . . . . . . . . . . . .
実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
コードの追加・修正 . . . . . . . . . . . . . . . . . . . . . .
4.4.1 下準備 . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 起動・初期化 . . . . . . . . . . . . . . . . . . . . . .
4.4.3 親ノードと子ノードの処理の分岐、及びイベント伝達
4.4.4 終了処理 . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.5 ファイルのオープン . . . . . . . . . . . . . . . . . .
4.4.6 エンコード開始から終了まで . . . . . . . . . . . . .
第 5 章並列版 avidemux の性能評価
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
i
第 6 章まとめと今後の課題
6.1 並列効果の考察 . . . . . . . . . . . . . . . . . . . .
6.2 今後の課題 . . . . . . . . . . . . . . . . . . . . . .
6.2.1 並列効果の低下を招く処理のチューンナップ
6.2.2 2-Pass エンコードの品質 . . . . . . . . . . .
6.2.3 エンコード設定同一化法の問題 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
33
34
34
36
参考文献
ii
図目次
2.1
2.2
動き補償予測のイメージ図 . . . . . . . . . . . . . . . . . . . . . .
MPEG-4 の VOP 符号化器の構成 . . . . . . . . . . . . . . . . . .
3
5
3.1 Folon-III/Folon-IV ネットワーク構成図 . . . . . . . . . . . . . . .
3.2 SCore ソフトウェアアーキテクチャ . . . . . . . . . . . . . . . . .
8
10
4.1
4.2
ディスプレイオープン失敗の様子 . . . . . . . . . . . . . . . . . .
ディスプレイオープン成功の様子 . . . . . . . . . . . . . . . . . .
15
16
5.1
並列 avidemux の性能評価 . . . . . . . . . . . . . . . . . . . . . .
32
iii
表目次
2.1
MPEG フェイズ概要 . . . . . . . . . . . . . . . . . . . . . . . . .
2
3.1 FOLON-III ハードウェア構成 . . . . . . . . . . . . . . . . . . . .
3.2 FOLON-IV ハードウェア構成 . . . . . . . . . . . . . . . . . . . .
7
7
4.1
MPI のためのコンパイラドライバ . . . . . . . . . . . . . . . . . .
13
5.1
5.2
DivX 640x360 35899frames to DivX CQ4 . . . . . . . . . . . . . .
Avi 320x240 900frames to DivX CQ4 . . . . . . . . . . . . . . . .
30
31
iv
第 1 章はじめに
1.1
研究の目的と背景
本研究は MPEG-4 動画エンコードの高速化を目的としている。
現在 MPEG-4 動画エンコードは一般ユーザが PC で行う処理の中で特に重い
処理の一つである。動画エンコードといった類の処理はハードウェアエンコーダ
を用いるのが最も効率的であるが、現時点では民生用のハードウェア MPEG-4
エンコーダは存在しない。そこで、本研究では PC Cluster システム Folon3 及び
Folon4 環境下で MPEG-4 動画エンコードの並列処理による高速化を試みる。具
体的には既存の逐次型動画処理アプリケーション avidemux を並列化改造するこ
とによって動画エンコード全体の高速化を図る。並列化に際して使うライブラリ
としては MPI(Message Passing Interface) を、開発環境としては RWCP(:技術研
究組合新情報処理開発機構、英語名 Real World Computing Partnership) が開発・
提供している SCore を用いることにする。
1.2
論文構成
第 2 章において、MPEG-4 の概要と、動画エンコードの高速化に際して考え
た案、結果として改造対象に avidemux を選んだ理由を説明する。第 3 章におい
て、実行環境である PC Cluster システム folon3 及び folon4 を紹介する。第 4 章
において、並列版 avidemux の実装について説明する。第 5 章において、並列版
avidemux の性能評価を行う。第 6 章で今後の展望と課題について述べる。
1
第 2 章並列化案について
並列化の大まかな方法について当初は avidemux のような動画編集アプリケーショ
ンを改造するのではない方法も考えていた。そこで、この章ではまず MPEG-4 動
画、MPE-4 動画のエンコードの流れについて解説したのち、考えた二つの並列
化案を挙げ、何故結果として動画編集アプリケーションの改造をすることとした
のかについて述べる。
2.1
MPEG-4 の概要
MPEG とは Moving Picture Expert Group という ISO(国際標準化機構) の中の
マルチメディア符号化規格作成組織の略称であるが、近年ではこの組織が作成し
た標準規格の呼び名として一般的となっている。MPEG 規格は、メディアの記
録、放送、通信などのためのマルチメディア符号化の規格であり、主に動画の符
号化方法に関する規定、音声の符号化方法に関する規定、及び両者の統合方法な
どに関する規定、の３つから成りたつものである。MPEG には現在 4 つのフェイ
ズがあり概要は表 2.1 のようなものである。
本研究で扱うのは MPEG-4 ビデオである。MPEG-4 ビデオの主な応用領域は
以下の二つである。
• 移動体通信
• インターネット/イントラネット
このために MPEG-4 ビデオ符号化では、MPEG-1/2 と比べ、これらの応用に適
した改善がなされている。以下に MPEG-4 ビデオ符号化の特徴をあげる。
フェイズ
MPEG-1
MPEG-2
MPEG-4
MPEG-7
表 2.1: MPEG フェイズ概要
符号化ビットレートの目安主な用途
384kbps∼4Mbps
VideoCD
1Mbps∼100Mbps
DVD、デジタル放送
∼10Mbps
移動体通信、インターネット
EPG、ホームサーバー
2
I
B
:
B
P
I
I
P
図 2.1: 動き補償予測のイメージ図
• 符号化効率改善のためのツール
(AC/DC 予測、8x8 ブロック動き予測、直接予測、スプライトなど)
• 任意形状画像への応用
(二値形状符号化、多値形状符号化、各種パディング手法、ポリゴンマッチ
ングなど)
• エラー耐性ツール
(生成ビット長さを基準としたパケット分割、データパーティショニング、ス
タッフィンングバイトの改善など)
MPEG-4 ビデオ符号化においては、ビデオ・オブジェクトの時系列を VO(Video
Object) と呼んでいる。さらに VO を構成する各画面を VOP(Video Object Plane)
と呼ぶ。これがビデオ符号化の基本となる。VOP には予測符号化の違いにより、
次の 4 種類が存在する。
• I-VOP(フレーム内符号化 VOP)
• P-VOP(フレーム間順方向予測符号化 VOP)
• B-VOP(フレーム間双方向予測符号化 VOP)
• S-VOP(スプライト VOP)
それぞれの VOP について簡単に解説する。I-VOP はそれ単体でフレームを生成
できる VOP、P-VOP は前の I または P-VOP と自身によりフレームを生成でき
る VOP、B-BOP は前の I、または P-VOP と次の I、または P-VOP と自身によ
りフレームを生成できる VOP である。S-VOP は上記三つとは少し違い、背景な
どの合成に使われる VOP である。
3
2.2
MPEG-4 動画エンコード全体の流れについて
一般に、動画エンコーダはダイナミックリンクライブラリとして各種アプリケー
ションに読み込まれ、API を通してその機能を提供する。しかし、それ単体で動画
のエンコードが出来るわけではなく、エンコード全体の作業は、ソースを (デコー
ドして素の状態にした上で) 渡す側があって始めて可能となる。本論文ではソー
スを渡す側を動画編集アプリケーション、実際に各種演算を行い圧縮しその結果
を返すものをエンコードライブラリと呼ぶことにする。今回調査した MPEG-4
コーデック、XviD のエンコードライブラリを例に挙げるとその API はおおまか
には、1. エンコードしたいフレームを置いた場所を指定してその API 関数を呼び
出す。2. エンコードライブラリはそのフレームをエンコードして、エンコード結
果を返す。と言ったものであった。実際のエンコードはこの作業のループによっ
て行われることとなる。ここで、並列化による高速化を考えるにあたって、二つ
の改造箇所候補が考えられた。
2.3
エンコードライブラリの改造による方法
一つ目はエンコードライブラリの並列化である。エンコードライブラリの並列
化と言ってもやり方は幾つもあるが、方法の一つとして、図 2.3 のような流れで
行われる、形状符号化、動き補償、動き予測、テクスチャ符号化等の処理を各 PE
に割り振ってその中を順にデータを流していくようなものが考えられた。しかし
単純にそうするだけでは実行 PE 数が厳しく制限されてしまい、容易に台数を減
らしたり増やしたりすることが出来ない。また、単純に 1 工程 1PE と割り振って
しまったのでは、それぞれの処理の重さも当然違ってくるので、重い処理を担当
した部分が全体のボトルネックとなってしまうだろう。それを解決するには重い
処理の部分はそれ自体を並列化しないとならない。もちろん、全ての処理を細か
く並列化するような方法をとってもいい。この方式の利点は
• そのエンコードライブラリを使用しているソフトウェアでそのまま利用で
きる
• 同じ設定で同じ動画をエンコードすれば (多少の浮動小数点演算の誤差範囲
の違いはあるものの) 逐次版と同等のものが出来る
などがあげられる。しかし、次に挙げる方法と比べると著しく実装難易度が高く、
そのわりに速度向上は少なくなるとは確実だと思われる。
4
図 2.2: MPEG-4 の VOP 符号化器の構成
2.4
動画編集アプリケーションの改造による方法
二つ目は、データ分割による並列化、動画編集アプリケーションの側の並列化
である。やり方は至って単純で、各ノードで同じソースファイルを同じ設定で、
エンコードするフレーム区間のみをずらしてエンコードして、出来上がったもの
を連結するだけである。MPEG-4 動画は時系列圧縮がかかっているため、再計算
なしで分割・結合が出来るのは GOV(Group Of Video Object Plane) と呼ばれる
I,B,P,S-VOP の一纏まり単位でのみだが、一つの MPEG-4 動画ファイルとして
完結しているものであれば当然 GOV も完結している。この方式は実行速度の点
では確実にエンコーダコアを並列化する方式よりも優れていると考えられる。ま
た、エンコード負荷の分散だけでなく、デコードや、リサイズ、クロップ、ノイ
ズ除去などといった各種フィルタ処理の負荷も分散されることとなる。欠点もな
いわけではない。例えば、2-Pass エンコード (生成ファイルのサイズを指定して、
1-Pass 目でビットレート割り振りを決め、2-Pass 目で実際にエンコードをするエ
ンコード方式) の際、単純に各フレーム区間に指定ファイルサイズを台数で割っ
たものを指定してそれを行ったのでは、全体として最適なビットレート割り振り
が出来ない。その他にも、分割数に対して極端にフレーム数の少ないファイルを
エンコードするとなると、適当な場所で動画を分割し、結合するということは、
本来ならばまだ I-VOP を入れずに済んでいたところに I-VOP を挿入することと
同義であるので、圧縮率が大幅に落ち込むことも予想される。
予測される速度の差と圧縮率の差、実装の難易度等を考えた結果、この研究で
は動画編集アプリケーション側の並列化、データ分割により MPEG-4 動画圧縮
にかかる時間を短縮することとした。
5
第 3 章実行環境
この章では、本研究に用いた実行環境、PC クラスタシステム FOLON-III 及び
FOLON-IV のシステム構成について述べる。
3.1
ハードウェア構成
3.1.1
PE 構成
FOLON-III は 9 台のシングル CPU PC によるノードで構成されている。各ノー
ドは Myrinet2000 及び 100BASE-TX Ethernet で接続されている。各ノードのハー
ドウェア構成は Pentium-III 1GHz、メインメモリ 1152MB で統一され、管理ノー
ドは計算ノードを兼ねる。
FOLON-IV は 17 台のデュアル CPU PC によるノードで構成されている。各
ノードを接続するネットワークは FOLON-III 同様 Myrinet2000 及び 100BASETX Ethernet である。ただし Myrinet2000 のケーブルは FOLON-III では serial、
FOLON-IV では fiber となっている。各ノードのハードウェア構成としては、CPU
は Pentium-III-S 1.26GHz のデュアル、メインメモリは管理ノードが 4096MB、残
り 16 台の計算ノードが 2048MB となっている。FOLON-III とは異なり管理ノー
ドと計算ノードが分けられているため普段の管理ノード上での作業が並列プログ
ラムの計算速度に影響を与えない。
3.1.2
Myrinet
Myrinet とは米 Myricom 社が開発・販売している Gigabit LAN である。Ethernet
と比較して Myrinet には次のような特徴がある。
1. 低レイテンシ
Ethernet スイッチでは、パケットをスイッチ内部で蓄積した後、他のポー
トに送出する、いわゆる、ストア・アンド・フォワード型のルーティング
が主流である。このために、スイッチを経由するごとに大きな通信遅延が
生じる。
6
表 3.1: FOLON-III ハードウェア構成
ホスト名
CPU
L2 chache main memory
PE0
PE1
PE2
PE3
PE4
PE5
PE6
PE7
PE8
roquefort
roquefort01
roquefort02
roquefort03
roquefort04
roquefort05
roquefort06
roquefort07
roquefort08
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
1GHz
1GHz
1GHz
1GHz
1GHz
1GHz
1GHz
1GHz
1GHz
256kB
256kB
256kB
256kB
256kB
256kB
256kB
256kB
512kB
表 3.2: FOLON-IV ハードウェア構成
ホスト名
CPU
L2 chache
管理ノード
PE0, PE1
PE2, PE3
PE4, PE5
PE6, PE7
PE8, PE9
PE10, PE11
PE12, PE13
PE14, PE15
PE16, PE17
PE18, PE19
PE20, PE21
PE22, PE23
PE24, PE25
PE26, PE27
PE28, PE29
PE30, PE31
comte
comte00
comte01
comte02
comte03
comte04
comte05
comte06
comte07
comte08
comte09
comte10
comte11
comte12
comte13
comte14
comte15
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
Pentium-III
7
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
1.26GHz
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
512kB
1152MB
1152MB
1152MB
1152MB
1152MB
1152MB
1152MB
1152MB
1152MB
main memory
4096MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
2048MB
backborn network
NIS Server, NFS Server, Router
comte15
Ethernet Hub
Myrinet Switch
comte00
comte
folon-IV
roquefort07
Ethernet Hub
roquefort
folon-III
図 3.1: Folon-III/Folon-IV ネットワーク構成図
8
Myrinet Switch
Myrinet のスイッチは 16 ポートを持つクロスバスイッチ構造になっている。
クロスバスイッチはパケットをスイッチ内部で蓄積することなく他のポー
トに直接送出する。Myrinet のスイッチではクロスバスイッチにワームホー
ルルーティングと呼ばれる方式を採用することによりスイッチ処理を高速
化している。このように Myrinet のスイッチではストア・アンドフォワー
ド型ルーティング方式と違って、低遅延通信を実現している。
2. NIC 上でのプロトコル処理
Myrinet では NIC に LANai と呼ばれるプロセッサが搭載している。LANai
プロセッサでは、
• ホストメモリから NIC メモリ
• NIC メモリからホストメモリ
• NIC から他の NIC
• 他の NIC から NIC
の 4 方向のデータ転送を同時に発行することが可能である。本ハードウェ
ア機能を用いることにより低遅延、高バンド幅が実現可能となる。
3. 高バンド幅
Gigabit Ethernet が 1Gbps なのに対し、Myrinet-2000 では片方向 2Gbps、
小方向 4Gbps のバンド幅を持つ。
3.2
3.2.1
ソフトウェア構成
OS
FOLON の各マシンには Redhat Linux7.3 がインストールされている。これは
次節で紹介する SCore5.2 がサポートしている為である。カーネルは SCore のた
めにパッチを当てたものがインストールされている。
3.2.2
SCore 5.2
Score は技術組合新情報処理開発機構 (RCWP) が開発し、現在 PC クラスタコ
ンソーシアムで開発・配布されている PC クラスタシステムソフトウェアである。
図 3.2.2 に SCore のソフトウェアアーキテクチャを示す。この図が示すように、
SCore クラスタシステムソフトウェアは次のコンポーネントから構成される。
9
図 3.2: SCore ソフトウェアアーキテクチャ
• PMv2 通信ライブラリ
PMv2 通信ライブラリは、多くの種類のネットワークで使用可能なクラス
タコンピューティング専用の通信ライブラリである。PMv2 は、Myrinet、
Ethernet、UDP、Shmem 共有メモリインターフェース等、異なった種類の
ネットワーク上でプログラムが同一の方法で通信することを可能とする。
• SCore-D
SCore-D は、プロセッサやネットワークのような、クラスタのリソースを
管理するグローバルオペレーティングシステムである。Linux カーネルを
修正することなく、デーモンプロセスによって実現されている。種々の PM
ネットワークデバイスは SCore-D によって管理、利用される。
SCore-D のジョブスケジューリング機能により、複数のユーザプロセスが
同時に実行可能となっている。また、実時間ロードモニタやデッドロック
検出、プロセス状態チェックポイント・リスタート機能も SCore-D によって
提供される。
• MPICH-SCore
MPICH-SCore は米国アルゴンヌ国立研究所によって開発された MPI 通信
ライブラリの実装、MPICH をもとに、メッセージ通信に PMv2 通信ライブ
ラリを用いるようにした MPI 通信ライブラリである。
MPICH-SCore には Version 1.0 と Version 2.0 の二つがあり、それぞれ MPICH1.2.0 と MPICH-1.2.1 をもとにしている。MPICH-SCore Version 2.0 の性能
10
は MPICH-SCore Version 1.0 よりも高いが、安定性に関する実績が少ない
ため、初期設定時はデフォルトでは Version 1.0 が有効となる。
• PVM-SCore
米国テネシー大学、オークリッジ国立研究所、エモリー大学が開発した PVM
を SCore 用に移植したものであり、PVM3.4 をもとにしている。
PVM は異機種環境で並列環境を提供し、計算ノードの動的な追加が可能で
ある。しかし、PVM-SCore では、SCore 環境したの計算ノード上でしか実
行できなく、また、計算ノードの最大数は PVM 実行に必要なデ−モンプロ
セス起動時に決定される。
• SCACH
SCACH は PMv2 を用い、ユーザレベルで実現したソフトウェア分散共有
メモリシステムである。ソフトウェア分散共有メモリシステムとは、共有
メモリ型並列コンピュータのように、各プロセッサからアクセスできる共
有メモリ領域をソフトウェアで実現したシステムのことである。
• PBS
MRJ テクノロジソリューション社 (現:ベリディアン社) が NASA のために
開発した、バッチシステム環境 PBS(Protable Batch System) が SCore 環境
に移植されている。
• MPC++
C++のテンプレート機能を用いた、C++のマルチスレッド拡張である。同
期/非同期リモート関数呼び出し機構、同期構造体、グローバルポインタや、
ほかにもさまざまな機能を提供する。
• Omni OpenMP コンパイラ
OpenMP は、共有メモリシステム上でのマルチスレッドプログラミングを
支援する API である。マルチスレッド制御を指示文の形でコンパイラに与
えることでコンパイラがマルチスレッドライブラリをリンクする。
RWCP が開発した Omni OpenMP では、SCASH ソフトウェア分散共有メ
モリシステムを使い、OpenMP のプログラムをクラスタ上で実行するため
の言語処理系である。
• TACO
トポロジと通信を抽象化した C++テンプレート機能として TACO が存在
する。
11
第 4 章並列版 avidemux の実装
4.1
並列版の設計方針
分割してエンコードを開始する前に、ユーザがアプリケーションを起動し、エ
ンコード開始までの間に行った操作による、エンコードにかかわりうる全ての変
数設定、初期化処理等が全 PE でなされていなければならない。処理によっては
実行の順番も結果に影響してくるかもしれない。この改造対象であるソフトウェ
アの構造に熟知していれば、そういったことは全てエンコード開始時に全 PE に
通知すれば済むことなのだが、今回は時間が足りず、このソフトウェアの全てを
把握するには至らなかった。そこで、今回はユーザの GUI 操作により発生するイ
ベントを全 PE に通知し、そのイベントでなされた変数設定数や初期化処理を逐
一全 PE で行うこととした。なお、今回改造の対象としたのは avidemux のバー
ジョン pre30 版である。
4.2
コンパイル
MPI による並列化改造を始める前に、まずは最低限の MPI のコードを入れて
コンパイルが出来るかどうかの確認を行った。MPI を使用した C++のプログラ
ムをコンパイルするには mpic++を用いる。
¶
³
mpic++ [ options ] filename ...
µ
´
mpic++はコンパイラドライバであり、自動的に MPICH-SCore で用いる MPI 通
信ライブラリ及びインクルードファイルライブラリの PATH を設定し、コンパイ
ルオプションと共にコンパイラ、リンカに渡す働きをしている。言語とコンパイ
ラドライバの対応については表 4.2 に示す。以下のようにコンパイラを指定して
configure し、make を行ってみた。
¶
³
./configure CC=mpicc CXX=mpic++
µ
´
しかし
12
mpicc
mpic++
mpif77
mpif90
C 言語用 MPI 通信ライブラリのためのドライバ
C++言語用 MPI 通信ライブラリのためのドライバ
Fortran77 言語用 MPI 通信ライブラリのためのドライバ
Fortran90 言語用
表 4.1: MPI のためのコンパイラドライバ
¶
³
/usr/bin/ld: BFD 2.11.93.0.2 20020207 assertion fail elf-strtab.c:262
µ
´
というエラーが出てしまい make は通らなかった。
調べてみたところ、これは SCore の checkpointing 機能が原因であるようだっ
た。SCore は checkpointing 機能のために、デフォルトでライブラリを static にリ
ンクする。しかし avidemux は共有ライブラリを用いてバイナリを作成しようと
するためこのエラーが発生するようである。そこで、以下のように static にリン
クしないように指定するオプションを付けて configure した。
¶
³
./configure CC="mpicc -nostatic" CXX="mpic++ -nostatic"
µ
´
これで先ほどのエラーメッセージは出なくなったが、今度は
¶
³
source=’oss_out.cpp’ object=’oss_out.o’ libtool=no \
depfile=’.deps/oss_out.Po’ tmpdepfile=’.deps/oss_out.TPo’ \
depmode=gcc3 /bin/sh ../../admin/depcomp \
mpic++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/kde/ar
(中略)
-fno-check-new
-c -o oss_out.o ‘test -f oss_out.cpp || echo
’./’‘oss_out.cpp
mv: cannot stat ‘.deps/oss_out.TPo’: そのようなファイルやディレク
トリはありません
ar cru libADM_audiodevice.a ADM_deviceArts.o ADM_audiodevice.o
ADM_deviceoss.o oss_out.o
ar: oss_out.o: そのようなファイルやディレクトリはありません
µ
´
といったところで止まってしまった。実際の gcc のバージョンは 2.96 であるのに dependency style が gcc3 と configure スクリプトに判定されてしまっているのが原因
かと思い Makefile を修正してみたりしたしたがそういうことでもないようだった。
このエラーの原因は結局分からなかったものの、avidemux/ADM audiodevice/内
のコードを一通り見てみたところ、今回の並列化に際して MPI のコードを追加する
必要がある部分ではなさそうだったので、configure 後に avidemux/ADM audiodevice/Makefile
13
を
¶
³
CC = gcc
CPP = gcc -E
CXX = g++
CXXXPP = g++ -E
µ
´
といった具合に書き換えることで、とりあえずはこの問題を回避することに成功
した。
4.3
実行
avidemux は GTK+アプリケーションであるため、仮にウィンドウを表示しな
いようにプログラムを書き換えたとしても、ディスプレイが開けないと
¶
³
Gtk-WARNING **: cannot open display: localhost:10.0
µ
´
とエラーを表示し起動後そのまま終了してしまう。ssh の X Forwarding では、ssh
で直接繋いでいるノードしかディスプレイをオープンすることが出来ない。(図:4.3)
そのため、DISPLAY 環境変数を scout 前に設定しておく必要がある。scout は実
行時に環境変数を各ノードにコピーするので、こうすれば全ノードが問題なくディ
スプレイを開けるようになる (図:4.3)。
4.4
4.4.1
コードの追加・修正
下準備
まずは、MPI の命令が使えるように、C++のソースには
¶
³
#include <mpi++.h>
µ
´
C のソースには
¶
³
#include <mpi.h>
µ
´
と書き足して、ライブラリを include する。
MPI のプログラムでは、全 PE で同じバイナリが動く。各 PE の動作はランク
という値を使い実行時に選択される。よって main.cpp 中で myid(自分のランクを
格納),nprocs(実行 PE 数を格納) はプログラム中どこからでも参照が可能なよう、
グローバル変数として宣言しておく。
14
ssh login
user’s console
cluster host
DISPLAY=localhost:10.0
cluster host
DISPLAY=localhost:10.0
cluster host
DISPLAY=localhost:10.0
cluster host
"scrun avidemux"
X Forwarding
user’s console
DISPLAY=localhost:10.0
cluster host
avidemux
DISPLAY=localhost:10.0
cluster host
avidemux
DISPLAY=localhost:10.0
図 4.1: ディスプレイオープン失敗の様子
15
"scout -g pcc"
environment variables copied
ssh login
user’s console
cluster host
DISPLAY=user’s console:10.0
cluster host
DISPLAY=user’s console:10.0
cluster host
DISPLAY=user’s console:10.0
cluster host
"scrun avidemux"
"scout -g pcc"
environment variables cop
user’s console
DISPLAY=user’s console:10.0
cluster host
avidemux
DISPLAY=user’s console:10.0
cluster host
avidemux
DISPLAY=use’s console:10.0
図 4.2: ディスプレイオープン成功の様子
16
¶
³
int myid,nprocs;
int main(int argc, char *argv[])
{
µ
´
また、これらの変数はプログラム中随所で使うことになるので各ソースファイル
において
¶
³
extern int myid;
// 自分のランク
extern int nprocs; // 実行 PE 数
µ
´
といった具合に外部で宣言されていることを明記しておく。
4.4.2
起動・初期化
MPI の初期化作業である MPI Init を行わなくては MPI の機能は使えない。ま
た、前節でも説明したように自身のランク、実行 PE 数はは早い時点で取得してお
くにこしたことはないものであるため、main 開始直後に以下のように MPI Init、
MPI Comm rank、MPI Comm size を実行する。
¶
³
int main(int argc, char *argv[])
{
pthread_t tid;
FCT_VOID *thread;
MPI_Init(&argc,&argv);
MPI_Comm_rank(MPI_COMM_WORLD,&myid);
MPI_Comm_size(MPI_COMM_WORLD,&nprocs);
µ
´
続いてフィルタの初期化、エンコーダの dll 読み込み等々各種初期化が行われる。
その中に GTK+の初期化処理である gtk init もあるのだが、メインウィンドウを
表示しない PE だからと言ってそこを飛ばしてはいけない。avidemux は GTK+
を利用しているアプリケーションであるのでそれを飛ばしてしまうとどこで問題
が起きるかわからない。なお、この初期化作業中にある atexit という関数はプロ
グラム終了時に呼び出される関数を登録するものであり、このことについては後
に解説する。
17
¶
³
atexit(onexit);
gtk_set_locale();
gtk_init(&argc, &argv);
gdk_rgb_init();
µ
4.4.3
´
親ノードと子ノードの処理の分岐、及びイベント伝達
親 PE は初期化処理終了後 gtk main というイベントの待ち受けを行うメイン
ルーチンに入る。それに対し、子 PE は親 PE 発生したイベントを受信し各種処
理に移す為のメインルーチンを作る必要がある。ここではそれを children main
という名前で作った。なお、親 PE 以外でのウィンドウ表示を抑制するために、
ウィンドウ表示の関数である gtk widget show が PE0 でしか実行されないように
してある。しかしこれはメインウィンドウである window1 の表示を抑制しただけ
であって、後に作られ、表示されるウィンドウまでもをここで表示させないよう
に出来たわけではない。そういった修正は実行してみて問題が出た時点で逐一や
ることとした。
¶
³
if(myid==0) {
gtk_widget_show(window1);
gtk_main();
} else {
children_main();
}
return 0;
}
µ
´
親 PE では、メインウィンドウでの GUI イベントが発生すると avidemux/gtk gui.cpp
内の void HandleAction(Action action) という関数に処理が移る。この関数で行
われる処理は、受け取ったイベントの値 (avidemux/gui action.hxx 内で enum に
より列挙されている) により switch し、各イベント毎の処理に移るといったもの
である。そこで、この関数の開始直後に各 PE へのイベント通知の処理を書き足
す。イベントの内容を示す action の値は整数値であるので、これをタグに入れて
MPI Isend を使った自作のブロードキャスト関数により各 PE へ送る。
なお、ここでで記述されているものはメインウィンドウ下での GUI イベントの
処理についてのみである。ここから新たにダイアログボックスなどのウィンドウ
が開いてユーザからの入力を受け付けるような個所もあり、それらについては別
途処理する必要がある。
18
¶
³
void HandleAction(Action action)
{
uint32_t nf=0;
mybcast_pe0(NULL, 0, MPI_CHAR, (int)action, MPI_COMM_WORLD);
switch(action) {
case ACT_LoadWork:
GUI_FileSelRead("Select workbench to load ", A_loadWorkbench);
updateLoaded();
return;
break;
case ACT_VideoConfigure:
printf("\n **\n");
videoCodecConfigure();
return;
break;
µ
´
親 PE でのイベント送信部と対になるものとして、子 PE でのイベント受信、及
び各種処理への switch 部を作らなければばならない。それは gtk main の代替とし
て用意した children main と HandleAction の代替として用意した event switcher
の役割となる。実際のコードは以下のようなものである。
¶
³
void children_main(void)
{
int eventtag;
printf("node %d stand by ok.\n",myid);
while(1){
eventtag = MPI_ANY_TAG;
mybcast_children(NULL, 0, MPI_CHAR, &eventtag, MPI_COMM_WORLD);
event_switcher(eventtag);
}
}
µ
´
19
¶
³
void event_switcher(int eventtag) {
uint32_t nf=0;
switch(eventtag) {
case 444444:
exit(0);
case ACT_LoadWork:
recvfile(eventtag);
updateLoaded();
return;
case ACT_VideoConfigure:
videoCodecConfigure();
return;
µ
´
event switcher の HandleAction との相違点、case 444444 の存在や GUI FileSelRead
の代わりに入っている recvfile といった関数については後述する。
なお、これらのイベント伝達に使っている mybcast pe0 及び mybcast children
は MPI の非ブロッキング通信命令 MPI Isend, MPI Irecv を用いて作ったブロー
ドキャスト関数である。このプログラム中では PE0 からのブロードキャストしか
発生しないため、それに特化して作ってある。
¶
³
void mybcast_pe0(void *buff, int count, MPI_Datatype datatype, int tag, MPI_Comm
MPI_Request mpirequest;
MPI_Status mpistatus;
int dest = 1;
while(1) {
if(dest > nprocs -1) break;
MPI_Isend(buff, count, datatype, dest, tag, comm, &mpirequest);
MPI_Wait(&mpirequest, &mpistatus);
dest = dest * 2;
}
}
µ
´
20
¶
³
void mybcast_children(void *buff, int buffsize, MPI_Datatype datatype, int *retu
MPI_Request mpirequest;
MPI_Status mpistatus;
int tag, count, distance, dest;
tag = *returntag;
MPI_Irecv(buff, buffsize, datatype, MPI_ANY_SOURCE, tag, comm, &mpirequest);
MPI_Wait(&mpirequest, &mpistatus);
if(tag== MPI_ANY_TAG) {
*returntag=mpistatus.MPI_TAG;
}
distance = myid-mpistatus.MPI_SOURCE;
MPI_Get_count(&mpistatus, datatype, &count);
while(1) {
distance = distance * 2;
dest = myid + distance;
if(dest > nprocs -1) break;
MPI_Isend(buff, count, datatype, dest, *returntag, comm, &mpirequest);
MPI_Wait(&mpirequest, &mpistatus);
}
}
µ
4.4.4
´
終了処理
一連の初期化処理の中にあった atexit という関数は、プログラム全体の終了時
に呼び出される関数を設定するものである。よって、この atexit で設定された関
数、onexit に改造を施して親 PE が終了する際には子 PE に終了メッセージとし
て、イベント 444444 を送信するよう書き足した。
21
¶
³
void onexit( void )
{
MPI_Request mpirequest;
MPI_Status mpistatus;
if(myid==0) mybcast_pe0(NULL,0,MPI_CHAR,444444,MPI_COMM_WORLD);
filterCleanUp();
printf("node %d exiting...\n",myid);
MPI_Finalize();
}
µ
´
444444 というイベントを受け取った子 PE は exit(0) を行いプログラム全体の終
了処理に入り、その際最後に onexit 関数を呼び出すこととなる。
4.4.5
ファイルのオープン
親 PE で起きた全てのイベントを子 PE に伝達すれば親 PE と子 PE を同じ状
態におけるかというとそうではなく、親 PE にあって子 PE にないものとしては、
オープンすべきファイルがある。そこで、ファイルをオープンするイベントに差
し掛かった際には親 PE は自分がオープンしたファイルを子 PE に送信し、子 PE
はそれを受信する必要がある。avidemux において、ファイルオープン関連のイ
ベントの処理は以下のようなものとなっていた
¶
³
case ACT_LoadWork:
GUI_FileSelRead("Select workbench to load ", A_loadWorkbench);
µ
´
ここで使われている GUI FileSelRead という関数の大まかな動作の説明をす
る。この関数はファイルセレクタダイアログボックスを表示し、ユーザにより入
力されたファイルのパスを引数として GUI FileSelRead の第二引数で示される関
数を、この例でいえば A loadWorkbench を、実行するというものである。そこで、
GUI FileSelRead から処理が移っていった先、ファイルが選択され、それがオー
プン可能と判定される個所、avidemux/ADM tookkit/filesel.cpp 内の start thread
に各 PE へのファイルの送信のコードを追加することとした。
22
¶
³
void start_thread(void *ptr)
{
(中略)
fd=fopen(selected_file,"rb");
if(!fd) {
GUI_Alert("Cannot open this file !");
/*ファイルサイズが負の値と通知することで
子 PE に待ち受けを解除させる
*/
filesize = -1;
mybcast_pe0(&filesize, 1, MPI_INT, 0, MPI_COMM_WORLD);
return;
} else {
fseek(fd, 0, SEEK_END);
filesize = ftell(fd);
fseek(fd, 0, SEEK_SET);
buff = (char *)malloc(filesize);
fread(buff, filesize, 1, fd);
//ファイルサイズを通知
mybcast_pe0(&filesize, 1, MPI_INT, 0, MPI_COMM_WORLD);
//ファイルを送信
mybcast_pe0(buff, filesize, MPI_CHAR, 1, MPI_COMM_WORLD);
free(buff);
}
fclose(fd);
_callback(selected_file);
µ
´
子 PE はファイルオープンのイベントを受信した際、GUI FileSelRead を呼び
出す代わりにファイル受信の為の待ち受け関数 recvfile を呼び出すようにした。
recvfile は親 PE で発生したイベントの番号を引数に取り、ファイル受信後それを
もとに switch することで、GUI FileSelRead が第二引数で示された関数に選択さ
れたファイルのパスを引き渡すのと同様の動作が出来るようにしている。
23
¶
³
void recvfile(int action) {
(中略)
mpitag = 0;
//ファイルサイズ受信
mybcast_children(&buffsize,1,MPI_INT,&mpitag,MPI_COMM_WORLD);
//ファイルサイズが負の場合は待ち受け解除
if(buffsize < 0) return;
buff = (char *)malloc(buffsize);
mpitag = 1;
//ファイル受信
mybcast_children(buff,buffsize,MPI_CHAR,&mpitag,MPI_COMM_WORLD);
(中略)
fd = fopen(tmpfilename, "wb");
if(!fd) {
printf("node: %d can’t make the tmpfile\n", myid);
return;
}
if(!(fwrite(buff, buffsize, 1, fd))) {
return;
}
free(buff);
fclose(fd);
switch(action) {
case ACT_LoadWork:
A_loadWorkbench(tmpfilename);
break;
(中略)
}
return;
}
µ
4.4.6
´
エンコード開始から終了まで
メニューから「Save AVI」を選択し、保存ファイル名を決定するとエンコード
が開始され、決定された保存ファイル名でエンコード結果のファイルが保存され
る。そこで、各 PE で分割してエンコードを行い、各 PE でのエンコード結果を
24
ファイルを収集、結合し、結合結果のファイルをユーザが決定した保存ファイル
名で保存するまでの処理について説明する。
フレーム区間の割り振り
保存ファイル名が決定された後呼び出される関数は avidemux/gui savenew.cpp
内の A SaveAudioNVideo である。この関数が呼び出された時点で各 PE は自分
の受け持ちとなるフレーム区間を算出する。受け持ちフレーム区間の算出には以
下のような計算を行っている。
• 1PE が受け持つフレーム数 = (終了フレーム - 開始フレーム) / PE 数
• ある PE での開始フレーム = 開始フレーム + (1PE が受け持つフレーム数
x 自身のランク)
• ある PE での終了フレーム = ある PE での開始フレーム + 1PE が受け持つ
フレーム数 - 1
フレーム数は整数値であるので、PE 数で割る際余りが出てしまう。それについ
て現時点の実装では、余りの分を全て最終 PE に全て押し付けるかたちとなって
いる。
この後、ユーザにより決定された保存ファイル名一時的に退避させ、各 PE 毎
の決め打ちのテンポラリファイル名に置き換え、各 PE 毎に実際のエンコード工
程に移る。
ファイルの収集
エンコードが完了した時点で、親 PE は子 PE からのファイル受信、子 PE は
親 PE へのファイル送信の処理に移る。
¶
³
if(myid==0)filegather_recvfiles();
else filegather_sendfile();
µ
´
送信、受信にはブロッキング通信を用いた。動作の流れとしては、
• 子 PE
filegather sendfile
1. 親 PE へファイルサイズ通知 (ブロッキング通信のため親 PE がこれを
受信するまで停止)
2. 親 PE へファイルを送信
25
¶
³
void filegather_recvfiles(void)
{
(中略)
for(i = 1; i<nprocs; i++) {
// ファイルサイズ通知、兼、ファイル送信準備完了通知受信
MPI_Recv(&buffsize,1,MPI_INT,MPI_ANY_SOURCE,0,MPI_COMM_WORLD,&mpistatus);
source = mpistatus.MPI_SOURCE;
(中略)
buff = (char *)malloc(buffsize);
// ファイル受信
MPI_Recv(buff,buffsize,MPI_CHAR,source,1,MPI_COMM_WORLD,&mpistatus);
ofstream out(tmpsaveavifilename, ios::out |ios::binary);
out.write(buff,buffsize);
out.close();
free(buff);
}
}
µ
´
• 親 PE
filegather recvfiles
1. 子 PE からファイルサイズ通知を受信 (ブロッキング通信のためいずれ
かの子 PE から送信があるまで停止)
2. ファイルサイズ通知をしてきた子 PE からファイルを受信
3. 子 PE 全てからのファイル受信を完了したら終了、そうでなければ 1
へ戻る
26
¶
³
void filegather_sendfile(void)
{
(中略)
ifstream in(tmpsaveavifilename, ios::in | ios::binary);
in.seekg(0,ios::end);
filesize = in.tellg();
in.seekg(0,ios::beg);
buff = (char *)malloc(filesize);
in.read(buff,filesize);
MPI_Send(&filesize,1,MPI_INT,0,0,MPI_COMM_WORLD); // ファイル
サイズ送信
MPI_Send(buff,filesize,MPI_CHAR,0,1,MPI_COMM_WORLD); // ファイ
ル送信
free(buff);
in.close();
}
µ
´
といったものになっている。MPI Gather に似た動作となっているが、受信結果
をファイルに格納をしている点がことなる。
ファイルの結合、保存
全 PE でのエンコード結果のファイルが親 PE に集まったら、ファイルの結合
に入る。結合には元から avidemux に存在した関数、A openAvi(AVI ファイルの
オープン)、A appendAvi(オープンしているファイル末尾に別の AVI ファイルを
結合)、A SaveAudioNVideo(変数 audioProcessMode、videoProcessMode を共に
0 とすることでオープンしてある AVI ファイルをエンコード工程なしで保存) に
僅かに手を加えたものを使用した。
27
¶
³
A_openAvi_pe0(tmpsaveavifilename00);
for(i=1;i<nprocs;i++) {
tmpsaveavifilename[filename_length] = ’0’ + (int)(i / 10);
tmpsaveavifilename[filename_length+1] = ’0’ +(i % 10);
tmpsaveavifilename[filename_length+2] = ’\0’;
A_appendAvi_pe0(tmpsaveavifilename);
}
tmpsaveavifilename[filename_length] = ’\0’;
frameStart = tmpframeStart;
frameEnd = tmpframeEnd;
A_SaveAudioNVideo_pe0(realname);
µ
´
28
第 5 章並列版 avidemux の性能評価
実装した並列版 avidemux の性能評価を行った。映像ソースとしては解像度 640x360,
フレーム数 35899 の DivX 動画、解像度 320x240, フレーム数 900 の無圧縮 AVI の
二種類を用い、それらを DivX の CQ(固定品質)、パラメータ 4 でエンコードし
た。実行環境は第 3 章で説明した folon4 である。なお、今回は SMP マシン用実
装が間に合わなかったため、1 ノード辺り 1PE の設定で使用している。
図 5.1 は並列効果を示したグラフである。横軸は PE 数であり、逐次版を PE 数
1 として扱っている。縦軸は「逐次版での所要時間/各 PE 数での所要時間」によ
り算出した並列効果である。細かい測定値については表 5.1 に示す。値の単位はは
sec である。それぞれの値について説明すると、total がエンコード開始からファイ
ル結合終了までの時間、bcasting がファイルオープン時のブロードキャストにか
かった時間、merging がファイル結合にかかった時間、gathering が PE0 がファイル
受信待ち受け状態になった時点からファイル回収完了の時点までの時間、enctime
max がもっともエンコードに時間がかかった PE のエンコード時間、enctime min
がもっともはやくエンコードが完了した PE のエンコード時間、enctime pe0 が
PE0 でのエンコード時間、enctime avg が全 PE でのエンコード時間の平均をとっ
たもの、waittime max が子 PE がエンコード完了した後、PE0 へのファイル転送
を行える状態になるまでにかかった時間の中で最も大きいものである。
両者とも概ね並列効果のみられる結果となった。PE 数が大きくなったところ
で性能が落ちている個所があるが、まず、DivX 動画をソースとしたものについて
は、この性能低下の原因として、ファイル結合にかかる時間のばらつきがあげら
れる。ばらつきの範囲の絶対値については PE 数が小さいときと PE 数が大きい
ときとで大差ないのだが、エンコードにかかる時間が小さくなるにつれ全体の時
間に占めるファイル結合にかかる時間の割合が増え、結果として性能に響いてき
てしまっている。ばらつきの出る原因自体についてはこの個所は元々avidemux に
あったコードをブラックボックス的に流用しているだけなので分からない。次に、
Avi 動画をソースとしたものについては、性能低下の原因として、まずフレーム
区間が細かく分割されることにより、各担当区間毎でエンコードにかかる時間に
ばらつきが出やすくなり、子 PE の待ち時間も含めたファイル回収にかかる時間
が増えたことがあげられる。また、フレーム数が少なくエンコード自体にかかる
時間も少なかったことからエンコード工程自体の並列効果の低下も起こっている。
29
PE 数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
PE 数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
total
1500
766
529
404
336
280
242
219
195
172
161
150
148
136
126
122
enctime pe0
1500
708
471
358
287
240
207
187
171
159
148
134
127
116
108
101
bcasting
0
1.13
2.22
2.22
3.33
3.33
3.33
3.33
4.65
4.44
4.66
4.44
4.44
4.44
4.66
4.44
enctime avg
1500
732
487
368
293
243
210
183
164
148
134
123
113
106
98.0
92.0
merging
0
3.46
7.46
3.51
7.51
3.39
3.47
6.09
9.93
3.61
8.87
3.53
8.65
3.54
3.43
8.45
waittime max
0
1.27
1.87
10.4
16.8
15.8
15.2
24.3
27.2
25.9
27.7
25.4
27.2
22.3
19.7
20.9
gathering
0
54.4
50.4
43.0
41.3
36.9
31.5
25.5
13.1
9.96
3.95
12.0
13.0
16.0
14.8
11.8
表 5.1: DivX 640x360 35899frames to DivX CQ4
30
enctime max
1500
757
520
400
327
276
238
212
184
168
151
146
139
132
122
113
enctime min
1500
708
470
348
271
224
192
163
145
133
120
109
99.5
94.1
88.3
80.6
PE 数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
PE 数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
total
18
9.11
6.48
4.90
3.97
3.52
3.17
2.53
2.36
2.12
2.64
2.22
1.82
1.72
2.06
2.62
enctime pe0
18
8.81
5.81
4.54
3.55
2.95
2.58
2.23
1.99
1.81
1.68
1.51
1.43
1.29
1.28
1.16
bcasting
0
1.20
2.40
2.61
3.60
3.81
3.81
3.60
5.00
4.79
4.82
5.01
4.79
4.79
4.79
4.79
enctime avg
18
8.82
5.87
4.57
3.64
3.10
2.65
2.20
1.98
1.75
1.74
1.69
1.35
1.29
1.45
1.53
merging
0
0.234
0.514
0.252
0.205
0.301
0.224
0.249
0.215
0.257
0.226
0.224
0.338
0.280
0.310
0.276
waittime max
0
0.0292
0.0203
0.0225
0.0125
0.0105
0.0862
0.100
0.113
0.118
0.0966
0.0518
0.121
0.0791
0.0676
0.133
gathering
0
0.0716
0.158
0.103
0.211
0.269
0.374
0.0534
0.151
0.0558
0.728
0.480
0.0582
0.146
0.472
1.19
表 5.2: Avi 320x240 900frames to DivX CQ4
31
enctime max
18
8.83
5.94
4.62
3.75
3.20
2.94
2.26
2.13
1.81
2.40
1.98
1.43
1.43
1.75
2.29
enctime min
18
8.81
5.81
4.53
3.55
2.95
2.49
2.13
1.88
1.70
1.58
1.46
1.31
1.21
1.22
1.05
図 5.1: 並列 avidemux の性能評価
32
第 6 章まとめと今後の課題
6.1
並列効果の考察
今回取った方式、エンコードフレーム区間を分割してのエンコードという方式
は、エンコード工程自体には一切 PE 間の依存関係はない。そのためこの工程に
おいては、完全に並列効果が出る。並列効果の低下を招く要素は、エンコード対
象ファイルの各 PE への送信、エンコード終了後のファイル回収とファイルの結
合のみである。MPEG-4 エンコードの計算量と比較して、これらの処理の計算量
と通信量は十分に少ないため、十分な並列効果が出た。
6.2
6.2.1
今後の課題
並列効果の低下を招く処理のチューンナップ
エンコード対象ファイルの各 PE への送信
今回の実装では、エンコード対象となるファイルはそのまま各 PE へ送信して
いる。対象の動画が MPEG-1/2/4 であっても GOP(GOV) 単位での分割により、
本来必要な部分のみを送信すれば、この作業における通信量はおおよそ 1/子 PE
数となる。
ファイル I/O
今回の実装では、改造個所を少なくするために、無駄なファイル I/O を各所で
発生させてしまっている。これは、このソフトや MPEG、AVI ファイルの構造な
どを熟知することにより減らしていけるものである。ファイル I/O を行うにして
も、mmap を用いることにより、HDD ではなくメモリ上にファイルを置くとい
う方法もある。
33
6.2.2
2-Pass エンコードの品質
実行速度の問題ではなく生成ファイルの品質についてであるが、2-Pass エン
コードの際には単純にフレーム区間と指定容量を PE 数で割るという、今回とっ
た方式では、最適なビットレート割り振りが出来ず、結果、同設定の逐次版で生
成したものと比べて画質が落ちてしまうという問題がある。そこで、1-Pass 目は
逐次、またはエンコードライブラリ側での並列処理で行い、1-Pass 目のログを元
に各 PE の担当フレーム区間を決め、1-Pass 目のログによるビットレート割り振
りに従ってエンコードするような方法をとれば品質を落とさず並列化による高速
化が出来るのではないかと考える。
6.2.3
エンコード設定同一化法の問題
エンコード速度とは関係ない部分であるが、今回の実装は、全 PE でのエンコー
ド設定を同一にするために、GUI イベント毎に通信を発生させるという非常に非
効率的な方法をとってしまった。しかも、GUI イベントを各 PE に通知すると言っ
てもそれはあくまでメインウィンドウのものだけであって、各種ダイアログボッ
クスなどには並列化未実装の部分の部分も出てしまった。今後、このソフトウェ
アの全体構造を把握した後に、通信を発生させるのはエンコード開始時のみで済
むような実装を試みたい。
34
謝辞
本研究を進めるにあたり、ご指導を賜った上田和紀教授に感謝致します。
数々の助言をくださった Folon 班の増田大樹氏、柿崎庸泰氏、関輝夫氏、稲垣
良一氏に感謝致します。特に増田氏からは多大な助言や叱咤激励を頂きました。
それなくしてはこの卒論を書き上げることは出来なかったでしょう。深く感謝致
します。
今回改造の対象とした avidemux という素晴らしいソフトを開発・公開して下
さっている mean 氏に感謝致します。
35
参考文献
[1] P. パチェコ著, 秋葉博訳 :MPI 並列プログラミング, 培風館,2001.
[2] 石川裕, 佐藤三久, 堀敦史, 住元真司, 原田浩, 高橋俊行 : Linux で並列処理を
しよう, 共立出版株式会社, 2002.
[3] PC Cluster Consortium, 2001, http://www.pccluster.org/
[4] 増田大樹: 分散共有画像管理に基づく GIMP 並列化, 早稲田大学理工学部情
報学科卒業論文, 1999.
[5] 増田大樹: MPI による GIMP core 分散並列実行, 早稲田大学理工学部情報学
科修士論文, 2002.
[6] avidemux, 2002, http://fixounet.free.fr/avidemux/
[7] MPEG Home Page, 2003, http://mpeg.telecomitalialab.com/
[8] ISO/IEC JTC1/SC29/WG11 N2564 Overview of the MPEG-4 Standard,
1998.
[9] PIONEER R&D 技術解説, 2002, http://www.pioneer.co.jp/crdl/tech/index.html
36

Download Report