HDDクラッシュ以前の従来環境では、MPEG2 8Mbpsで録画されたデータを、ffmpegによりXvid 2Mbps + mp3 に変換し、その後avidemuxでCMカットなどの編集を行い、DVDに焼く、という手順で動画作成をしていました。フォーマット変換してから編集、というのは一見二度手間ですが、この手順を考えた当時、MPEG2ファイルを直接編集できるいいフリーソフトがみつからなかったこと、ffmpegはコマンドラインから実行すれば自動的に実行されるのでそんなに手間ではないこと、などから、このような手順になりました。また視聴には、MPlayerとxineを用いていました。MPlayerの方がいろいろなファイルに対応している印象でしたが、画面拡大ができないなどデメリットもあり、xineと使い分けていました。
今回も、上記のような環境を再び構築したいと思います。
Debianは公式にはフリーなライセンスのものしか供給しないというポリシーで運営されており、mp3エンコーダすら収録していません。マルチメディア関係には他にもライセンス上Debianが収録できないものが多々あります。そこで非公式サイトの存在が重要となります。マルチメディア関係のパッケージを多く扱っているところとして、debian-multimedia.orgがありますので、ここを利用します。トップページにあるように、apt lineを追加してapt-get updateし、キーをインストールすると、ここから好きなパッケージをインストールできるようになります。私は以下のソフトをインストールしました：
lame （MP3エンコーダ）
w32codecs （ウィンドウズメディアやリアルメディアなどの動画を視聴可能にする）
libdvdcss2 （DVDを視聴可能にする）
xine-ui （メディアプレイヤー）
mplayer （メディアプレイヤー）
ffmpeg （動画変換）
avidemux （動画編集、変換）
ffmpegはDebian公式にもパッケージがありますが、そちらはmp3エンコーダなどが使用できない状態でコンパイルされたものですので、私の場合はdebian-multimedia.orgからインストールしました。現在はこちらの方がリビジョンNo.も上位なようなので、apt lineを追加した段階で自動的にこちらが選ばれインストールされます。
ここで各ソフトの動作を確認すると、ffmpegの実行が以前より遅いのに気づきました。HDDクラッシュ以前のDebian Etchの環境では、動画の実時間の半分強の時間で変換が終了していました。つまり50〜60フレーム/秒 ぐらいだったと考えられます。しかし今回は、40fpsぐらいしか出ていません。ハードウェアの違いはハードディスクのみです。前回と今回のHDDのスペックを比べてみると、前回は7200rpm、今回は5400rpmでしたが、転送レートは両者とも3Gbpsとなっていました。また、ffmpeg実行時のCPU使用率はtopコマンドによるとほぼ100％でした。したがって、ffmpeg実行速度の低下はHDD起因ではないと判断しました。
そこで、ffmpeg自体の高速化ができないか考えてみました。まず、ffmpegのオプションを眺めていると、--disable-mmx というのが目に付きました。mmxとはx86プロセッサにおいてマルチメディア系の計算が高速に実行できる命令群です。これを有効にすれば高速化できるのではないかと考えました。調べてみると、Debianパッケージでは、-fPICオプションをつけることが義務付けられていますが、ffmpegの場合、--disable-mmxなしだとPIC(PositionIndependentCode)の条件を満たさないらしくコンパイル不可となるため、--disable-mmxとしているということでした。そこで、ローカルパッケージとして、-fPICをはずして、--disable-mmxもはずしてmmx-enableとしてコンパイルしたffmpegを作ってインストールしてみました。しかし結果としては、ほとんど処理fpsに変化はありませんでした。
さらに調べていると、各プロセッサの最適化オプションがいろいろあることがわかりました。私の録画マシンのプロセッサはCore2Duoですが、Core2向けには -mtune=core2 -mfpmath=sse -msse というオプションがあるようです。そこでこのオプションで再びローカルパッケージを作って試してみましたが、結果はやはりほとんど変化なしでした。
また、ffmpegのオプションで、-threadsというのを見つけました。マルチスレッドで実行できるなら、デュアルコアマシンには有効そうです。そこでこのオプションを試しましたが、処理fpsに変化はなく、topコマンドで2つのCPUの使用率を見ても、片方のCPUしか使用していないようでした。
ここまでまったく改善が見られないので、ちょっと落ち着いて考えてみました。ffmpegをmmx対応させたりマルチスレッド実行させたりして高速化できるのはどの部分か。おそらくffmpeg内蔵エンコーダの実行時であろう。ffmpegはいくつかのエンコーダを内蔵しているが、私が使っているxvidやmp3limeは外部エンコーダである。ということは、これら外部エンコーダがプロセッサ最適化、マルチスレッド化されていることがポイントでは？ そう考え、xvidcoreとlimeについて調べてみました。limeについては、プロセッサ最適化、マルチスレッド化とも進んでいないようです。xvidcoreについては、プロセッサ最適化は、インラインアセンブラにより高速化が図られているようです。マルチスレッド化については、バージョン1.2から対応しており、最新バージョンは1.2.2です。一方、debian-multimedia.orgからインストールされたバージョンは1.1.3で、マルチスレッド化未対応のものでした。
そこで、xvidオフィシャルサイトからソースを入手し、見てみました。すると、Debianパッケージ作成用の環境が含まれています。さっそく、ローカルバイナリパッケージを作成してみることにしました。途中、debian/rulesに実行権がないこと、nasmが必要なこと、などのトラブルがありましたが、それらを解決してパッケージを作成しました。これをインストールして、オプション -threads 2 を指定してffmpegを実行してみました。すると、片方のCPUが90％前半に対し、もう一方のCPUが10〜15％程度稼動するようになりました。マルチスレッド実行はしているようです。が、両CPUの使用率の和は、110％を超えることはほとんどなく、結果としてほとんど処理fpsに変化はありませんでした。
ここまで、いろいろ勉強にはなりましたが、結果としてffmpegをHDDクラッシュ前のスピードに戻すことはできませんでした。その他にDebian lennyによりデグレードした点もいくつかあり、ivtvドライバのインストールの容易さ以外は、Debian lennyによるデメリットが目立つ結果となってしまいました。
 | FFmpegで作る動画共有サイト 関連商品 初めてのFlash Video ImageMagick逆引きコマンドリファレンス そこが知りたい最新技術 オーディオ・ビデオ圧縮入門 Linux高信頼サーバ構築ガイド シングルサーバ編 (Industrial Computing Series) HTML5&API入門 by G-Tools |
