メモ： VLC Media Player とは何か
■ VLC Media Player とは何か
"VLC Media Player"（http://www.videolan.org/vlc/）は Linux における高品位の MPEG4 プレイヤーです。
このツールは MPEG4 だけでなく複数のフォーマットの動画ファイルを再生でき、windows の .wmv 形式などもカバーしているため、実用性はきわめて高くなっています。
機能の詳細は以下の URL を参照のこと。
http://www.videolan.org/vlc/features.html
本稿に取り上げる VLC は CentOS では正式パッケージとして採用されていません。従来 CentOS では windows や MacOS に比べてマルチメディア機能が弱く、
パッケージもそれほど豊富に用意されてこなかった経緯があります。これは CentOS の罪ではなく、CentOS5 のベースとなる RHEL5 がエンタープライズ向けサーバ用途に
構成されているためと考えられます。もう少し噛み砕いて言うと、サーバ上で X アプリケーションのようなリソース喰いを稼働させるのは有利ではなく、
ましてや VLC のような個人ユーザ向けのメディアプレイヤーを、サーバプラットフォームの標準パッケージとして採用する理由がなかったのだと思われます。
■ VLC Media Player のインストール
本章では CentOS5 環境における VLC Media Player の yum による導入手順を簡単に述べてみます。 なお、HW 構成はプラットフォームとして VMware Workstation5.5 を用い、CPU は Pentium(R) Dual-Core E5200 2.50GHz に 1GB のメモリを配分してあります。 筆者の環境ではこれで特に問題なく動作していますが、可能なかぎり CPU コア数およびメモリは大い方がよいと思っています。 一般論ですが、マルチメディアアプリケーションは CPU およびメモリリソースを消費する傾向にありますので。
1. リポジトリの登録
※ 上記の場所に接続できないような場合には dag リポジトリを使って rpm パッケージをダウンローすることが可能です。
2. パッケージのインストール
このため、次の手順として yum によるパッケージ本体のインストールが必要です。インストールするには以下のコマンドを実行します。
（なお、環境ごとにパッケージ構成によって導入パッケージ数は変化しますので、以下をインストールしたら終わりというわけではないことにご注意ください。）
vlc-0.9.9a-5.el5.rf
lirc-0.6.6-4.el5.rf
SDL_image-1.2.5-1.el5.rf
twolame-0.3.12-1.el5.rf
libsndfile-1.0.17-1.el5.rf
opencv-1.0.0-1.el5.rf
libupnp-1.6.6-1.el5.rf
svgalib-1.9.25-1.el5.rf
xosd-2.2.14-1.el5.rf
libcddb-1.3.1-1.el5.rf
libdca-0.0.5-1.el5.rf
portaudio-19-1.20071207.el5.rf
libdvdnav-0.1.10-3.el5.rf
libshout-2.2.2-2.el5.rf
qt4-4.2.1-1
mpeg2dec-0.4.1-2.el5.rf
libmpcdec-1.2.6-1.el5.rf
libdvdread-0.9.7-1.el5.rf
libdvbpsi-0.1.7-1.el5.rf
zvbi-0.2.33-1.el5.rf
libmatroska-0.8.1-1.el5.rf
libebml-0.7.8-1.el5.rf
-----
以上でインストールは完了です。参考までに申し上げておけば、インストールの完了と同時にデフォルトのアイコンが「アプリケーション」→「サウンドとビデオ」→「VLC Media Player」として登録されていました。このため、同アイコンをクリックすればただちにプレーヤーが起動してきます。
3. テスト
なお、動作テストは一般ユーザで行います。root ユーザではセキュリティ上の理由で起動できないようになっているので、注意が必要です。
■ 補追 リポジトリについて
yum や subversion などのバージョン管理システムを使っているとしばしば repository という単語に出会うことがあります。
これは辞書を引いて出てくるとおり、容器、貯蔵庫、倉庫、集積所などの意味を持っており、何らかのデータや情報、プログラムなどを体系立てて保管するための場所を指しています。
具体的には、バージョン管理されているパッケージやソフトウェアの保管庫（一種のファイルサーバ）であると考えるとわかりやすいかもしれません。
実運用でのリポジトリは http によるアクセスを許すサーバ上に公開することが多いため、一般的に URL でその所在が示されます。
ところで、リポジトリによるパッケージ管理では「体系立てて保管されている」という一節が重要なポイントで、ただごちゃごちゃにパッケージやデータが置いてあっても、
ユーザにとっての利便性は上がりません。少なくとも、パッケージの置いてあるディレクトリ構造が論理的な体系を持って設計されており、一定のルールでバージョンが管理されている
必要があるのです。数千に上るファイルのバージョンをユーザ自身が把握していなければならないとすれば気の遠くなるような話ですが、これをユーザに代わって行うのが yum や
subversion システムです。
yum リポジトリサーバでは xml にパッケージの更新を記述します。
このファイルは単なるファイルリストですが、クライアントは記述されたリポジトリ上の最新ファイルリストを取り込み、
直近に更新されたファイルとの差分をアップデートしていきます。そのときサーバからダウンロードした新しい xml にだけ存在するファイルがあればインストールするわけですが、
いずれの場合も rpm コマンドおよび rpm データベースで管理を行います。つまり、yum はローカルに存在する rpm データベースを利用したリモートファイル管理システムなのです。
一方、subversion ではデータベースはサーバ側にあり、クライアントは作業コピーをサーバからダウンロード（チェックアウト）して作業を開始します。
クライアントは更新した作業コピー（の差分）をサーバに転送し、サーバ側のデータベースを更新（コミット）することによってリポジトリを更新していきます。
つまり、subversion はリモートに存在する subversion データベースを利用したリモートファイル管理システムであり、構造的に yum と逆の構成になっていることがわかることと思います。
以上、駆け足でリポジトリについて説明しましたが、バージョン管理の重要性はもっと認識されてよいのではないでしょうか。
過去、パッケージ管理では apt, up2date, ports, yum, zabom などが使われてきましたが、セキュリティや利便性の面からさらに使い易いツールへの改良が期待されます。
また、バージョン管理ツールも CVS に始まって subversion, git などよりよい操作性と信頼性を目指して開発が進められています。
どのツールにも一長一短があるため、使い勝手と目的に合わせてユーザー自ら各ツールをお試しいただきたいと思います。