前回までにノイズだらけのVHDカラオケをキャプチャするため、Windows環境でしか動かないUSBキャプチャボックスをLinux環境から遠隔操作する話をしてきました。
年経たVHDシステムは劣化も進んでいて再生不能なディスクがいくつもあったものの、USB経由にしたおかげでVHDプレイヤからのノイズがPCに影響することがなくなり、キャプチャ作業も安定に進むようになりました。
そうなると今度は、どんどん溜っていく動画ファイルをどう整理、活用したものかに頭を悩ますことになります。今回キャプチャしているのはビデオカラオケの動画なので、このデータを使って自前で通信カラオケのような仕組みが作れないかなぁ……、と考えてみることにしました。
楽曲ファイルの切り出し
今回のキャプチャではVHDの片面1時間を1つの動画ファイルにしているので、カラオケのように使うにはこの動画ファイルを曲単位に分割する必要があります。この手の動画編集ソフトはWindowsの方が揃っているだろうなぁ、と思いつつ、使いなれているLinux環境で処理した方が便利だろうと考えて、avidemuxというツールを使ってみました。
avidemuxはGPLで公開されているフリーソフトウェアで、Linuxだけでなく、たいていのUNIX系OSやWindowsでも動作する動画編集ソフトウェアです。ざっとイジってみたところ、それほど凝った編集機能は無いものの、読みこんだ動画ファイル内に任意の始点と終点を指定して、その間を別ファイルに切り出す、といった作業は十分こなせます。また、ファイルのCODECを変えない「コピーモード」で切り出せば、始点、終点のみを再エンコードするだけで、切り出し作業も軽快に進みます。
VHDカラオケをキャプチャした動画ファイルは、"8140-1.mpg"のように各ディスクのID番号に表裏を示す数字を付加したファイル名にしています。この動画ファイルから一曲目を切り出して、"8140-1-01_むらさき雨情.mpg"というファイルにしようとしたところ、ファイル名の文字コードはUTF-8になってしまいました。
あれれ、と思って、avidemuxの設定メニュー等を調べてみても、ファイル名の文字コードを指定するような機能は無さそうです。いざとなったらシェルスクリプトでファイル名の文字コードを変えるか…、と思いつつ、ざっとavidemuxのソースコードを眺めてみることにしました。
ソースコードをざっと調べたところ、avidemuxはLinuxやBSD UNIXさらにはWindowsでも動くように設計されているため、汎用的な処理をする部分とOS環境に依存するユーザインターフェイス部、さまざまな動画フォーマットに対応するためのCODEC処理部等が分離され、大規模なものの見通しのよい作りになっていました。
"filename"等をキーワードにソースコードをgrepしてみたところ、avidemux/common/gui_main.cppというファイルが動画ファイルの読み書き等の主要な処理を行っているようです。
このソースコードをより詳しく眺めたところ、どうやらファイル名の文字コードをlocaleの設定に合わせて変換するような機能は存在していません。
その手の機能は実際のGUI画面を作る方にまかせているのだろうか…、と、GUIを操作するQt用のコードも調べてみましたが、こちらにもUTF-8からQt用の内部コードであるQStringに変換する処理しか用意されていないようです。
確かにファイルシステムの文字コードをUTF-8に決め打ちすれば、ファイル名をやりとりする際にlocaleを考慮する手間はなくなります。しかし、Plamo Linuxでは過去のしがらみからファイルシステムの文字コードはEUC-JPのままなので、iconvを使ってファイル名の文字コードをEUC-JPに変換するようなパッチをでっちあげました。
例のごとくの「とりあえず」パッチなものの、切り出したファイル名が文字化けせずに扱えると効率もあがり、作業が順調に進むようになりました。
集めた楽曲ファイルをカラオケシステムとして利用するには、曲名や歌手名から目的の楽曲ファイルに到達する必要があります。そのため、動画ファイルの切り出しと平行して、各楽曲のタイトルや歌手名をリスト化する作業も始めました。
VHDカラオケでは、各楽曲の冒頭に曲名と作詞者、作曲者の名前が表示され、末尾に歌手名が表示されます。切り出し作業と平行してそれらのデータをテキストファイルに拾っていくことにしました。
各楽曲を切り出したファイルとそれらのデータを記録したファイルを、VHDカラオケ1枚ごとに用意したディレクトリに整理していきます。
方針が決まればあとはコツコツと作業を進めるだけです。再生状態の悪いディスクに悪態を吐きつつ、半年ほどで百数十枚のVHDディスクを整理することができました。
HTML5と<video>タグ
VHDカラオケのキャプチャは順調に進んできたものの、さてこれをどう使えばいいんだろう…、と考えたとき、ちょっと頭をかかえてしまいました。
お店のカラオケシステムを引きついだのは「セガカラ」というWindows上で動く通信カラオケです。「セガカラ」には3万曲以上の楽曲が登録されていて新曲も次々と登場するものの、VHDカラオケにあった曲が全て登録されているわけではないので、「セガカラ」にはない曲がリクエストされた際、キャプチャしたVHDカラオケの動画を流すようにできれば便利でしょう。
当初は、「セガカラ」専用のWindowsマシンには小さなHDDしか積んでいないけれど、samba経由でファイルサーバをネットワークドライブに見せてやれば容量面の問題はないだろう、動画の再生はWindowsのメディアプレイヤーでも使えばいいし…、と軽く考えていました。
しかしながら、キャプチャしたディスクが100枚を超え、切り出した楽曲も3000曲ぐらいになってくると、再生したい楽曲ファイルをメディアプレイヤーから探し回るのも大変です。前節で紹介した楽曲データを元に、タイトルや歌手名から楽曲ファイルを検索するようなアプリを作ることも考えたものの、Windows環境でその手のアプリを作るのに必要な知識はありませんし、わざわざWindows専用のアプリを作りたいとも思いません。
「GUIな部分はブラウザに任せてしまい、PHPで歌手名やタイトルからデータベースを検索して、適切なURLを返すぐらいなら簡単なんだけどなぁ……」と考えているうちに、HTMLの新しい規格であるHTML5には動画再生用の<video>タグが定義されていたことを思いだしました。
以前調べた際には、<video>タグはHTML5の規格には入るだろうものの、動画ファイルのCODECはGoogle(Chrome)やMozilla(Firefox)の推しているフリーなWebM/VP8と、Microsoft(IE)やApple(Safari)が推している商用のH.264が拮抗していて、ブラウザ間での互換性が不安な状況でした。
しかしながら、改めて最近の状況を調べてみると、H.264の各種特許を管理しているMPEG-LAが、「ネットの無料動画配信に関しては、H.264のライセンス料を将来に渡って無料にする」と発表して、動画配信事業者の支持を得る一方、2013年10月には、Cisco社がMPEG-LAに支払うライセンス料を自社で負担する形でOpenH264というH.264の実装を提供し、Firefoxもそのモジュールを使ってH.264に対応できることになりました。
だとすると、楽曲ファイルをH.264(=MP4)形式に変換しておき、HTML5/PHP経由で該当するファイルを<video>タグでブラウザに送るようなコードを書けば、HTML5に対応したブラウザさえ用意すれば、WindowsでもLinuxでも同じように使えるはずです。
「論より証拠」と思って、キャプチャしたMPEG-2形式の楽曲ファイルをMP4(MPEG-4 AVC/H.264)形式に変換して、HTML5で提供するようなコードを書いてみました。
まずはFFmpegを使ってMPEG-2形式の楽曲ファイルをMP4形式に変換します。
オプションに指定している -movflags faststart は、ファイル情報を記録したメタデータをファイルの先頭に移す指示です。メタデータは、通常、MP4ファイルの末尾に付加されるものの、このデータをあらかじめファイルの先頭部分に移しておけば、ファイル全体を読み込まなくても再生を開始できます。この機能は、今回のようなストリーミング再生的な使い方には必須です。-vcodec libx264 はVideoLANプロジェクトが開発しているx264ライブラリを利用して動画のCODECをH.264形式にする指示です。
MP4形式はMPEG-2形式に比べて圧縮率が高いと聞くので比べてみたところ、今回の例では222MBあった動画ファイルが46MBくらいまで小さくなったようです。これぐらい圧縮が効くと、ディスクやネットワークの容量的にも助かりそうです。
次にこのファイルをHTML5経由で提供するためのindex.htmlファイルを書きます。
index.htmlとtest1.mp4をhttpdで公開しているディレクトリにコピーして、LinuxではFirefox、Windows 7ではIEでそのページにアクセスしてみたところ、両者とも問題なく動画ファイルが再生できました。
楽曲ファイルをMP4形式に変換すれば動画再生はブラウザ任せにできそうなので、後は歌手名や曲名から楽曲ファイルを検索するような処理を用意すれば、簡単な「お家通信カラオケシステム」が構築できそうです。次回はそのために必要な、各種キーワードから楽曲ファイルを検索するあたりの処理を検討してみましょう。