Video.jsの簡単なつかいかた

授業でビデオを観る課題などをよく出すのだけれど、Flashには死んでほしいので、授業のMoodleではmplayerモジュールは緊急避難的に使って、普通のHTMLリソースのなかにvideo要素を手で書いて対応していました。

ところがなんだか、いったんMoodle 2.2+にして大はまりしたあげく1.9に戻ってきたら、なぜだかいままでのビデオが全く表示されなくなり、一念発起してVideo.jsを使えるように無理やりlib/weblib.phpを書き換えたりなどしました。ほんとはちゃんとモジュール開発すべきなんですが、時間がなかったもので。

というわけで、Video.jsです。

なかみはとても単純で、CSSとJavaScriptで書かれたHTML5ビデオプレーヤーに、念のためFlashにfallbackするためのswfがついているという構成。設定は、CSSをheader要素間にlink要素で入れて、あとbodyにscript要素としてJavaScript本体を読むように書くだけ。

と、これだけならオリジナルサイトに書いてあるだけのことなんだけれど、ちと大きくはまったのが字幕なので、そのことについてだけ記すことにします。

まず、字幕（ここではsubtitlesということにします）は、WebVTTを使います。まぁ、一応W3C的には標準。だけど、従来の字幕とはやや趣が違うフォーマットなので、直接これを編集できるアプリケーションは、なんかMSが出しているとかいう話ぐらいしか見当たりませんでした。

でもまぁ、なんとかなるという話を以下に。

まず、ここはやはりオープンソースなAegiSubを使うことにします。これの素晴らしいところは、音声波形ビューアで、適当に音声の切れ目らしいところを単位にして、自動的に次の字幕項目を入れられること。必ずしもきれいにいくわけではないので、多少マウス操作で調整したりはしますが、時間の数値をいじることを全くしないで字幕トラックを作れるというのがたいへんありがたいと思いました。出力形式は、SRTにしときます。なぜかというと、WebVTTとかなり近いから。

とはいえ、WebVTTのほうが表現力は高く、縦書きの字幕を表示できたり（bidiも考慮されてる）、表示位置の指定ができたりといったようなことはあります。そのへんはASSから変換できたりするといいのかもしれないのですが、まぁそれはそれ。

SRTからWebVTTを作る手順は以下のとおり。

1. SRTに入っている通し番号を削除する
2. 1行目に先頭から「WEBVTT」と書き、2行目を空白行にする
3. 表示タイムスタンプの時間表記を、ミリ秒の前の「,」を「.」に置き換える

仕様書に従えば、たったこれだけのことでOKということになります。vi使ってれば一瞬ですね。

%s/^[0-9][0-9]*$//
%s/,/./g

ところがよくわからんのですが、いまのVideo.jsは、仕様書ではオプションとして定義されているタイムスタンプの「hour」の項目があるとダメっぽいのです。hourなしでどうやって59分以上の長さの字幕を作るんだというと、60以上の数字にするんだとか。桁数については「59を超えたら60の剰余とし、商を上の位に上げる」的なことしか書いてないので99分超えても大丈夫なのかもしれないけどやってないので不明。

というわけで、残念ながらタイムスタンプから時間を消す編集が必要。こんな感じでしょうか。

%s/^00://
%s/> 00:/> /

で、まぁ、1時間以後は毎分ごとに60を足してやるみたいな感じでしょうか。もうこうなってくると、スクリプト書きたくなる感じですが、とりあえずこんなところで。

あと、オリジナル設定だと字幕は10ptベースの1.4emなので、日本語の表示にはちょっと小さすぎる感じです。2emにしたらいい感じになりました。あと、text-shadowとかお好みでタイプフェースをいじる等はやってくださいという感じです。font-familyもarial, sans-serifぐらいしか書いてないので、僕は日本語フォントを追加しておきました。ヒラギノとか。

回路シミュレータQUCS

電子回路の設計や学習に、PC上で回路の実験や測定ができる回路シミュレータは便利だ。それこそ、単純なオームの法則でもさくっと回路図を描いて抵抗値や電圧・電流などを測定できるので、年齢を問わず教材として使えるものだと思う。

業界標準ではSPICEということになっていて、一般的にはリニアテクノロジー社のLTSpiceをダウンロードして使うことになっている。LTSpiceは同社のアナログICなどのデバイスを買ってもらうために無償で配布している（専門家はもっと高級なものを購入するのだろう）。

問題は、Windows専用ということだろう。

そこで、他のOSを使う人で、GUIがほしいよという人はQUCSを使うらしい。Qt3ベースで、GUIのマルチプラットフォーム化を実現している。また、各国語の翻訳データも入っているので、日本語メニューに設定変更できるのも授業で使うにはありがたい。

念のため、2011年秋頃最終更新の0.0.16をダウンロードして入れてみた。Windows用バイナリは同じSourceForgeの別リンク先からとってくる。Macの場合は、MacPortsに入っているので、適当にパッチを流用するなどすれば手動でも入れられるだろう。それより、Qt3が巨大なフレームワークなので、MacPortsではQt3のコンパイルで一仕事になるように思う。

問題は、日本語メニューの表示だ。Windows 7の場合どうなるか、という記述はあまり検索上位に上がってこないようだ。なので、一応書いておくと、

1. Languageを「Japanese (jp)」にする
2. その2段上にある「Font (set after reload)」を「Meiryo UI」にする
3. ScriptをUnicodeにする（と、いいのではないかと思う）

という手順になる。最も注意すべきは、「2.」だ。必ず日本語の「UI」書体を選ばなければならない。間違えて「MS ゴシック」などにすると、グリフのバウンディングボックスが負の値になるのかわからないが、一文字の大きさが巨大な横長になってしまい、もとに戻すのも一苦労だ。運がよければ、言語を「English (en)」にした時点でだいぶましになるが、そのあとで「Default Value」のボタンをクリックして、「Apply」または「OK」をクリックしなければもとに戻せない。レジストリをいじって解決することもできるかもしれないが、探した範囲では設定は見つからなかった。かといって設定ファイルも見当たらなかったし、再インストールしても以前の設定が残るので手が出ない。

なお、QUCSの開発は止まっているというような記述も一部にある。後継プロジェクトはQucsStudioらしい。QUCSにもASCOという最適化ツールやOctave（MatLabのGNU版）スクリプトを用いたシミュレーション結果の視覚化などが同梱されているが、QucsStudioはさらに多数のデバイスやシミュレーション手法、プリント基板設計やガーバーデータ出力などまで含むようで、なんだかたいへんなことになっている。Qt4ベースにも書き換えられている。しかし、GPLのQUCSをベースとしながらソースコードが公開されていないしWindows専用ということで、いまひとつ食指が動かない（起動はしてみたが）。いまのところ言語ファイルも英語とドイツ語のみ（ドイツ語のqmファイルから日本語に翻訳すればいいのかもしれないが）。

それから、コマンドラインでよければ、NGSPICEというプロジェクトもある。各種OSで動く（ただしXが必要なので、WindowsではCygwin環境ということになる）。SPICE3に準拠しているので、本格的にエンジニアリング目的で使うなら、こちらのほうがいいのかもしれない。

ついでに、QUCSはgplEDAというGPLに基づく電子回路設計ツールスイートプロジェクトの一部ということになっていて、プリント基板設計ツールや、Arduino本でおなじみの、ブレッドボード配線図などが描けるFrizingなどがファミリーとなっている。gEDAだけでも、シミュレーション以外の、回路図を描いたりプリント基板設計したり、ガーバーデータ出力したりすることはでき、WindowsでもMacでも動くので、一見の価値はあるかもしれない。

IPv6は普及しない

主に技術者や研究者、それから組織のネットワーク管理者や一部の経営者に誤った考えが広まっているので、念のために確認しておく。

あきみち氏のブログや記事で繰り返されていることでもあるのだけれど（例えばこれ）、IPv4とIPv6は全く違う設計のネットワーク。同じなのはパケット通信であることと階層的なデザインになっていることぐらいで、それならIPを使わない他のパケット通信方式も同じことになる。

よく「IPv6への移行」とかいわれるのだけれど、そうするとなんだかお引越しのようなニュアンスがあって、かなりの嘘が入ってると考えられる。なにかこう、IPv4ネットワークを使いながら、IPv6の通信が使えて、知らない間にIPv6になっているようなイメージ作りの意図を感じる。まるで新製品への買い替えを促しているようで、そうなると技術用語ではなくビジネス用語なのではないか。

IPv4は、「いまあるネットワーク」。一方、IPv6は、「動いているが限られた人が使っているネットワーク」。そして、いまどきの「インターネット」という商品を買っている人にとって、IPv6は全くメリットがないことを強調しておきたい。例えば、GoogleはIPv6ネットワークにも存在しているけれど、GoogleのサーバにないもののほとんどはIPv4ネットワークに存在している。したがって、IPv4ネットワークにしかないリソースへのアクセスは、IPv6ネットワークではできない。多くの人がAmazonとかiTunesとかFacebookとかに接続するだけなら、それらがIPv6ネットワークにサービス提供すればそれでいいのだけれども、それだけのことだ。しかし、IPv6でなければならない理由にはならない。実際、自宅や職場や無線通信でネットを利用している人は、「そこに到達すればよい」のであって、どんな通信手段を使っているかには注意を払っていないはずだからだ。

IPv4のアドレス枯渇がIPv6の設計動機であったことは歴史的に間違いない。だけれども、その時代の「インターネット」といまのネットは世界が全く違う。当時はこれほど、ネットに接続する人々が、プラットフォーム提供者のビジネスを、接続する人々が（広告など間接的にであれ）「購入する」という分断された関係ではなかった。

スティーブン・レヴィの著書「ハッカーズ」（工学社から翻訳が出ている）は、PCやネット黎明期の息吹を現在に伝える貴重な資料だが、PCもインターネットも、もともとアナーキーな若者たちによって理想と考えられ、取り組まれてきた結果普及してきたものだ。そのひとりで、誰もが知っている人物がスティーブ・ジョブズ。彼も60年代のカウンターカルチャーにどっぷりと浸かった時代の若者だった。ドラッグ使用の過去があるのは当然だ。インターネットは、60年代頃に、マサチューセッツ工科大学（MIT）の「テック鉄道模型クラブ」の連中が、巨大な鉄道模型システムを制御するために使っていた電話会社の中古のリレーの組み合わせに頭をひねっているときに、当時アメリカ唯一の電話会社AT&Tの技術者に食い込んで、電話システムのしくみに興味をもち、巨大システムの硬直性と脆弱性に気づき、無料で世界のどこにでも（海外の政府機関でさえも）キャンパス内の公衆電話から通話できる、その手口を明らかにすることに熱中したことと、他の一部のメンバーがMITの計算機センターに常駐するIBMの管理者に自由な利用を制限されることに嫌気をさして、AIラボに納品された、当時としてはとても小さな（といっても広い実験室でなければ設置できない）コンピュータの利用許可を、「夜中に利用者がいない時間に限る」という限定付きで得て、誰もいないことをいいことにハードウェアをいじりまわして機能（演算命令）を追加したり、ついに電話回線につないでしまったことからはじまっている。その時点で、「自分がやりたいことを実現するための、自分のためのコンピュータ」「作成したソフトウェアの共有と改良」「コンピュータを電話回線を通して通信する」という考え方が生まれたとされている。それに、西海岸で起こった、マイクロプロセッサの発明が加わって、PCの実現、フリーソフトゥエア、コンピュータネットワークが「草の根の運動」として発展していくことになる。ここでは、PCやネットワークの利用者は、皆が平等で、また限られた資源を共有することの暗黙のルールがあった。いまの、サービス提供者と利用者が分断された状況とは全く違う。

長くなってきたので、残りははしょる。

IPv4ネットワークは、もはやビジネスや政治の道具だ。中東の独裁政権打倒運動も、バラク・オバマ大統領誕生も、国際テロ組織による秘密のネットワークも、どれもIPv4ネットワークの上にある。

一方で、IPv6ネットワークは、かつての「ハッカーたち」の理念を引き継いだ、「相手の顔が互いに見える」ネットワークの理想を胚胎したまま、実験的に構築されているネットワークだ。もし、IPv6ネットワークをいまのまま発展させるならば、ビジネスや政治とは無関係な、草の根の人々の道具として維持していかなければならないことになる。ここでは、IPv6ネットワーク利用者は、サービスを金で買ってあとはしらんとか、自分の満足のため他の利用者の利害に影響を与えてもかまわない振る舞いをするといったことはできない。

いま、IPv4ネットワークの上での活動に自分が満足しているならば、IPv6を使う必要はないし、IPv4ネットワークの実情がIPv6ネットワークにそのまま持ち込まれることは、いまIPv6ネットワークにいる人々は望まないだろう。

IPv6ネットワークが一般化しないと主張する最大の理由は、「IPv4アドレス枯渇問題は、未だアドホックな対応で対処可能」という理由による。具体的には、Large Scale NATの導入で、いままで大量のグローバルIPアドレスを必要としていた通信事業者が、顧客の増大に対してIPアドレスを確保する必要がなくなる、ということに尽きる。そもそも家庭へのネット接続にはprivate IPアドレスしか原則として与えられないし、それをさらに家庭用IPルータで別のprivate IPアドレスに変換して使っているのが実情だ。企業においても、クラウド利用によって、外向きのIPアドレスはそんなにたくさん持たなくても十分な計算資源を持つことができるようになっている。多重NATの問題などは、ほとんどの利用者は気にしていないだろうから、本当にISPや国レベルでのprivate IPアドレスの利用がなされたとしても、大きな混乱はないだろうと考えられる。個別の問題に対しては、随時アドホックな対応で解決が図られていくだろう。

だから、（実はこれがいちばん言いたいことなのだが）「IPv4とIPv6のデュアルスタックでのシステム構築」とか「IPv4とIPv6のゲートウェイについての配慮」とか、いろんな案件が業者や知ったかぶりの利用者から寄せられると思うけれども、そんなのは金と労力のムダなので相手にしてはいけない。

IPv6ネットワークは、可能であれば予備の回線で独立に、そうでなければIPv6パススルーするスイッチやルータの設置にとどめ、あくまで別のネットワークとして構築するとともに、ネットワーク設置する立場にある人は、「IPv6をみんなに使わせなければ」などといった使命感は持たないことだ。導入する以上、コスト負担の問題が発生するから平等に行き渡らせることで受益者コスト負担を避けようというのは健全な思考だろうけれども、労多くして功少なしの結果が強く予想されるので、「やりたい人にやらせる」「コストは受益者負担で」というのが現実的ではないか。

いずれにせよ、「いまのIPv4ネットワークは延命される」という予想と「IPv6は別物」という事実によって、IPv6は絶対に普及しない、というのが僕の主張。

Kinectを500円で買った

名古屋大須のジャンク屋をみていて、Kinectが500円で置かれているのに心ときめき、即座に購入した。

O'reillyの「Making Things See」をななめ読みして興味を持っていたのでこれはありがたいと、早速ソフトウェアを準備。

Macの場合、OpenKinectことlibfreenectを入れることになるようだ。そして、libusbにパッチを当てたものが必要とのこと。

しかし、Xcode 4.3を入れてしまったため、MacPortsが使えなくなっている（upgradeが通るものがないわけではないが、まっさらからでは何もできない）ため別の手段をとったのだが、いろいろと問題含みだった。なお、MacPortsでサーバにしているMac miniはXcode 4.2.1をDeveloperサイトから落として、バージョンを下げておいた（ただ、command line toolsが4.3なのでコンパイル時に怪しげな警告が出たりする）。

以下経過。

まず、開発マシンは/opt/local以下をすべて消してMacPortsを一掃し、Xcode 4.3でもよいというHomebrewに移行することにした。brewコマンドのだいたいの使い方を覚えて、wgetとかlvとかが手軽に入ることがわかったのだが、libfreenect/platform/osx/homebrew以下のformulaは依存関係が不足していてだめ。また、ゆうべあたりにautoconf, automake, libtoolがいっせいにバージョンアップしたせいか、これらを先に入れてもautogen.shのなかで落ちてしまう。ちなみにautogenが入らない件、tracはclosedになっているが全く解決していない。--use-llvmを追加してもだめ。

で、しかたがないのでReadme.asciidocにしたがって、手で該当バージョンのlibusbを落としてパッチを当てるのだが、やはりautoconf.shが通らない。いちかばちか、www.libusb.orgから最新の1.0.8のtarballをもってきて、パッチがrejectした部分を自己判断でなんとかした上で、configure; make installした。動くかどうかはつないでみないとわからない。

brewにおけるformulaの扱いがまだいまひとつわかっていないので、次はやむをえずlibfreenect全体をgit cloneして、cmakeをbrew installしたのち、cmake .; make installしておいた。

さて、あとはKinectをMacにつなぐだけだ... と思ったら、コネクタの形状が違う。USBなら4本のはずが、オスメス違うし、よく見ると9端子だ。で、ざっと検索したところ、Kinectは外部電源が必要で、ACアダプタとUSBに分岐するケーブルが別にあるということだった。普通に買えばセットになっているらしいが、古いXBox 360持ちで何らかの事情がある人はマイクロソフトから4000円弱払って買うらしい（本体のシリアル番号を言わないと売ってくれないらしい）。でもたぶん中古があるはずだと検索してみたところ、アマゾンと楽天で1980円プラス送料（480円）で新品を扱っているところが出てきた。ヤフオクも同じ値段。ではさっそくそのへんで...と思ったが、こういうときはeBayを見るのが鉄則である。すると、簡単に日本向けshipping $0.99で本体$7.99というのが出てきた。USからであることと、送料が安い（国際宅配便なら$40はかかる）ことを考えると、船便で1ヶ月弱の納期を考える必要があるが、急がないならかなりお得といえる。

だが、こんなものにお金を払う連中ばかりではないはず。たいていのゲーム周辺機器は事細かに解析されているものだ。というわけで、「Kinect USB adapter DIY」で検索すると、ちゃんと自作記事が出てきた。ありがたや。元記事はこちら。9pinのうち、5本を下にして、USBに対応する（配列は違う）のは下の右4本、左は上下が+12V（1A以上必要らしいので分配しているのだろう）、上の真ん中2本がGND、右上は未使用ということのようだ。あとは作るだけ。よかった。

なお、外部電源の件だが、Kinectは台座にモーターが入っていて回転する。また、カメラが可視光と赤外光の2つが入っているし、赤外光ライトもあるので、USBの5V最大500mAでは心もとないに違いない。モーターといえば、PlayStation 2のDual Shock 2も振動モーター回転のためには7〜9Vの別電源が必要だ。

MozcもGoogle Updateの対象になる

Googleが様々な手段でユーザのコンピュータ（及びスマホなど）の利用状況をデータとして収集していることが懸念されているわけですが、Webブラウザに関しては、Webkitエンジンの代表格であるGoogle Chromeを外して考えるわけにはいかなかったところを、ChromeのソースがChromiumという形でオープンソースになっていることから、懸念される情報収集及びその送信部分を取り除き、正しく動作するよう大量のコードを加えた「SRWare Iron」を使うことで、心配から逃れるすべがありました。

他によく使われているのはGoogle Earth、そして日本人は「Google日本語入力」を使っている人がたくさんいるのではないかと思います（僕もそのひとり）。

Google日本語入力は辞書の優秀さとサジェッション（候補表示）の巧みさから、商用のIMEを購入して、OSバンドルのIME（WindowsならMS IME、Macならことえり）の阿呆さ加減を克服するのをためらわせるほどの魅力があります。

ただ、もしGoogle日本語入力が入力内容をGoogleに送信していたら、と考えると、これは究極のキーロガー（キーボード入力を記録して第三者に送信するプログラム）ともいえることになってしまいます。

そこで、Google日本語入力のオープンソース版であるmozcはどうなのか、ということになるのですが、mozcはGoogle日本語入力で使われる辞書は使うことができないようになっており、かわりにIPA（情報処理推進機構）が作成し、公開している辞書を使うようになっています。ソースがすべて公開されていることから、キーロガー的ななにかや、使用状況をGoogleに送信していないかどうかなどを確かめることができます。

そこで、mozcのソースを、ごく簡単に、ざっくり見てみました。

すると、「omaha」という語を含むキーを作成したり登録したりする処理が最初に目につきました。これは、Windows用の部分では、レジストリをアクセスして、内容を確認したり登録したりします。そして、そのレジストリキーの名前が「Google\Update」なのです。

Google Updateといえば、Googleのソフトウェアを入れると必ず入るプログラムで、MacでもKeystoneという形でマシン起動時にデーモンとして起動しますし、Windowsでプロセスマネージャーを見ると、GoogleUpdate.exeというプロセスとして確認することができます。

ChromeやGoogle日本語入力は、特にアップデート作業をしなくても、「いつのまにか」最新版に更新されています。いままでこの理由を説明するサイトは見当たらなかったのですが、要するにつねにGoogleと通信して最新版かどうかを確認し、そうでなければダウンロードして勝手に最新版に置き換える挙動をGoogle Updateが実行しているのです。

問題は、このとき、コンピュータなりスマホなりに固有のIDを作成してGoogleに登録しておくという動作が含まれていることです。これによって、Google側ではソフトウェアの更新状況や利用状況を把握できるというわけです。それだけなら会社で共同で使っている人は気にしないかもしれませんが、Googleアカウントとひもづけられると、誰がどのソフトウェアをどのぐらい使っているかということが、個人の他の属性（氏名、居住地、その他GoogleアカウントやGoogle+などのプロフィールに登録した内容）と関連付けられてしまうということになります。ある意味、Googleへの忠誠度がはかられているといえるかもしれません。

そして、「omaha」ですが、これはGoogle Updateのオープンソース版だそうです。

Omaha - Project page

Googleによれば、Google Updateが不審なプログラムと捉えられることは望まないので、どのような挙動をし、どのような通信が行われているかを、その仕様と実際のプログラムを文書とソースコードとして公表した、ということなのだそうです。

結論からいうと、mozcにはOmahaが入っています。したがって、mozcをインストールしたことはGoogleが把握していますし、どのバージョンが使われているかをGoogleは知っています。どのマシンで使わているかもGoogleは知っています。もしかしたら、勝手に最新版に置き換えられているかもしれません。

Ironはドイツで作られ、メニュー等の表示の翻訳をどなたかが提供される形で日本語対応がなされていますが、mozcに関しては日本人自身があらゆる作業に取り組まなくてはいけません。Ironは単にコードを削っただけではなく、相当量のコードの追加が必要だったとフォーラムで開発者が明かしています。mozcはChromiumと比べれば非常に小さなコード量ですが、Chromium由来のソースがたくさん含まれています。オープンソースですから、派生プログラムを作成して公表することに法的な問題は全くありません。ソースコードには、Googleからの派生物であることを明示し、Googleがつけたクレジットさえ書き換えなければよいと書かれています。ライセンスはBSDですから、要するにas-isです。どなたか腕に覚えのある方、mozcをクリーンにするプロジェクトに取り組んでみませんか。

ffmpegとmplayerは自分でコンパイルしよう

MacPortsからffmpeg-develとmplayer-develを入れていても、なかなか更新はかからないのだけれど、実際には、少なくともffmpegは毎日膨大な変更が入っています。それも、とても基本的なところでの修正が多いのです。

だから、ffmpeg-user MLで「〜ができないんですが」的な質問をすると必ず「古すぎる。Git headを使え」という答えがつくことになっているのが実態。

というわけで、みなさんももしffmpegお使いなら、MacPortsはあてにせず、自分でgit headを入れるようにしましょう。

ライブラリまで自分で管理するのは面倒なので、いったんport install ffmpeg-develして、依存関係にあるライブラリはすべて自動で入れてしまいます。そのあと、port uninstall ffmpeg-develしてしまいます。あと、x264もMacPortsで入るバージョンは古い(最新が12に対して10)ので、こちらは上書きインストールすることにします（他で依存関係があって、uninstallするとせっかく入れたものが古いものに上書きされてしまうから）。

まず、x264の最新版を上書きインストールしましょう。ソースはgitで入手します（port install gitしておいてくださいね）。適当なディレクトリを作って（僕は/var/srcというのを作りました）、その下にいろいろ置くことにします。

# git clone git://git.videolan.org/x264.git
# cd x264
# ./configure --prefix=/opt/local --enable-shared
# make install distclean

これで入ります。最新版にするには、

# cd /var/src/x264
# git pull

でできます。そしたら、またconfigure以後の作業をして置き換えます。更新頻度は毎日ではありませんが、最低でも月に2度ぐらいはあるような感じがします。

ffmpegは、なんか開発グループが分裂して、一方はlibavを名乗るようになってしまいました。ffmpeg.orgにどちらのリポジトリも掲載されているので、好きな方を使ってください。僕は本家を入れています。

# cd /var/src
# git clone git://source.ffmpeg.org/ffmpeg.git

これでソースが手に入りました。次にconfigureするわけですが、オプションの指定が必要です。最低でもどれだけ必要かは、

/opt/local/var/macports/sources/rsync.macports.org/release/ports/multimedia/ffmpeg-devel/Portfile

に書いてあります。

まぁ、

configure.args \
        --enable-gpl \
        --enable-postproc \
        --enable-swscale --enable-avfilter \
        --enable-libmp3lame \
        --enable-libvorbis \
        --enable-libtheora \
        --enable-libdirac --enable-libschroedinger \
        --enable-libopenjpeg \
        --enable-libmodplug \
        --enable-libxvid \
        --enable-libx264 \
        --enable-libvpx \
        --enable-libspeex \
        --mandir=${prefix}/share/man \
        --enable-shared --enable-pthreads \
        --cc=${configure.cc}

こんなことが書いてあるので、そのままパクることにします。で、最後のccですが、Xcode 3.6の人は無視、Xcode 4以上の人はclangを指定します。

毎回手で入れるのは面倒なので、shell scriptにしておくといいでしょう。

#!/bin/sh
./configure --prefix=/opt/local --enable-gpl --enable-postproc --enable-swscale \
                      --enable-avfilter --enable-libmp3lame --enable-libvorbis \
                      --enable-libtheora --enable-libdirac --enable-libschroedinger \
                      --enable-libopenjpeg --enable-libmodplug --enable-libxvid \
                      --enable-libx264 --enable-libvpx --enable-libspeex \
                      --mandir=/opt/local/share/man --enable-shared --enable-pthreads \
                      --extra-ldflags="-L/opt/local/lib" --extra-cflags="-I/opt/local/include" \
                      --enable-version3 --arch=x86_64 --cpu=x86_64 --cc=clang

こんな感じでしょうかねぇ。

もし、MP4ファイルを作る人で、音声のAACをffmpeg内蔵の実験コードではなく、実績のあるlibfaacを使いたい人は、

# port install faac

しておき、configureのオプションに--enable-libfaacを入れてください。AAC HEをやりたい物好きな人は、最近ffmpegにも実験コードが入りましたが、以下

http://tipok.org.ua/ru/node/17

に、libaacplusのソースが置かれているので、適当にダウンロードして/opt/local以下にインストールし、configureのオプションに--enable-libaacplusつければ入ります。

ただ、優先順位としては、高い順に

1. libaacplus
2. ffmpeg実験コード
3. libaac

になっているので、libaacを使いたい方、libaacplus入れたけど普通のAACを作りたい方は、ffmpegのオプションでaudio codecの設定が必要になります。libaacなら、-c:a libaac、libaacplusを入れてしまって内蔵の実験コードを選択したい方は、-strict experimental -c:a aacと指定することになります。

ffmpegのビルドとインストールも簡単で、configureのshell scriptを実行したあと、

# make install distclean

これだけです。

さて、次はmplayerなんですが、mplayer単体で動画を見る人もいるかもしれませんが、それならffplay使う手もあるし、どちらかというと、mencoderを使うために入れるのが普通だと思います。で、MacPortsのmplayer-develは現在、mplayerのsvnリポジトリとffmpegのgitリポジトリから最新版をもってくるようになっています。なので、port selfupdateしたあとport list outdatedしてmplayer-develの最新版が表示されないとしても、使うたびに再インストールする価値はあります。というわけで、

# port -f uninstall mplayer-devel
# port -f install mplayer-devel

するだけで、いつでも最新版に置き換えることができるわけです。画質は明らかに向上しますし、多くの場合処理速度も単調増加するので、最新版を維持する価値はあります。

ffmpegにせよmencoderにせよ、地デジ程度の解像度、特にアニメなんかの場合は20fps超えることもざらにあります。瞬間最高速度では60fps程度になることもしばしばです。

動画や音声のトランスコードをする人にffmpegは必須だと思いますし、何らかの形で生TSファイルを扱う人で、画と音がずれない方法を探している人には、いったんmencoderでAVI（なかみはMPEG4 simple profile）に変換することをおすすめします。このあたりはまた後日、機会があったら書いてみたいと思います。

Engadget Japaneseについてひとこと言っておこうか

Engadget Japaneseといえば有名なブログ形式のデジタルガジェット方面ニュースサイトだけれども、どっかの「ぎがじん」とか「ぎずもーど」とか「てっくくらんち」などと違って、単なるネタ提供とか噂爆発などとは一線を画したサイトだと思っている。

特に、じんわりと心の芯まで染みてから吹き出す絶妙な爆笑芸に長けた文章がなんともいえない。このあたりは、日本版立ち上げのIttousai先生（なぜか先生と呼ばれているようだ）のキャラクタの立ち具合から成立しているものと思われる。

Ittousai先生とはどんな人か、正体は知らないが、小寺氏のIT Mediaでの記事（2006年と、かなり古いが）から、ライフスタイルそのものからしてたいへん立派な方だと想像できる（芸達者な文章家として）。

現在のEngadget Japaneseは複数のライター体制のようだが、ダントツの記事数かつ速報に強いIttousai先生に対して、日中の記事数では負けないHaruka Ueda氏にも一目置いている。ネットでの評価はさんざんな彼女（と思われる）だが、Ittousai先生の芸を受け継ぎ、なおかつより女性的な冷徹なツッコミ、しれっと暴言言い放ちなどの女の怖さを増幅させた体の文体で、実に味わい深い。

女性（と勝手に決めているが、真相は闇）ライターとしては、ネットでは元IT戦士yukatanなどが有名だが、ネタ記事は面白かったものの、気がついたら露出が増えてしまい、ついったーなども始めてしまって、普通の人ということが判明してしまった。つまらん。

Haruka Ueda氏がどんな人物かには興味はないが、Ittousai先生とともに本家のややGeek臭さに蓋をしつつ元ネタを生かしかつ味わいを加えた文章に作り変える芸道にさらに磨きをかけていただきたいと思う。

最後にひとつ、最近の記事では出色と感じた記事にリンクしておく。