動画の世界で何かと話題のWebM(libvpx)ですが、どうなんでしょうか。H.264より性能は少し落ちるという話ですが、特許の問題がないのであれば、少しくらい落ちてもいいかなとは思ってます。Theoraも期待してたんですがそれほど来なかったですね。diracとかschoedingerなんてのもありましたが、やはり来なかったです。WebMはどうなのか？

プレイヤーではvlc(1.1.0)がすでに対応してますし、ffdshowもそのうち対応すると思います。エンコーダはffmpegが対応済みであると。実際にlibvpxとffmpegを使ってみました。Fedora 13のlibvpx/libvpx-develは古いようなので、gitで最新の状態を取ってくる。

• git clone git://review.webmproject.org/libvpx.git
• git clone git://git.ffmpeg.org/ffmpeg/
• cd ffmpeg
• git clone git://git.ffmpeg.org/libswscale/
• cd ../libvpx
• ./configure
• make
• sudo make install
• cd ../ffmpeg
• ./configure –enable-lib{vpx,vorbis,dirac,gsm,mp3lame,openjpeg,schoedinger,theora,x264,xvid} –enable-gpl –extra-ldflags=-L/usr/local/lib
• make
• ./ffmpeg -i /path/to/file.avi out.webm

エラー。

  Duration: 00:02:06.99, start: 0.000000, bitrate: 8842 kb/s
    Stream #0.0: Video: mjpeg, yuvj422p, 640x480, 30 tbr, 30 tbn, 30 tbc
    Stream #0.1: Audio: pcm_mulaw, 8000 Hz, 1 channels, s16, 64 kb/s
[ffmpeg_output @ 0x144b4a0] auto-inserting filter ‘auto-inserted scaler 0’ between the filter ‘src’ and the filter ‘out’
[scale @ 0x1481fd0] w:640 h:480 fmt:yuvj422p -> w:640 h:480 fmt:yuv420p flags:0xa0000004
[libvpx @ 0x1447030] v0.9.1-18-gf1a3b1e
[libvorbis @ 0x14476a0] oggvorbis_encode_init: init_encoder failedOutput #0, webm, to ‘/tmp/out.webm’:
    Stream #0.0: Video: libvpx, yuv420p, 640x480, q=2-31, 200 kb/s, 90k tbn, 30 tbc
    Stream #0.1: Audio: libvorbis, 8000 Hz, 1 channels, s16, 64 kb/s

今さらですがドイツvs.オーストラリアでワールドカップが開幕しました。退場があったとは言え、何もできずに4-0とはね。日本のスタジアムにはブブゼラを持ち込めるんでしょうか？

先日、写真の管理ソフトをLinux上のdigikam(KDEのソフト)からWindows上のPicasaに変更しました。

発端はVMware Serverが使いづらくなってきたのでVMware Playerに乗り換えようと決心したところあたりかな。ホストはノートPCのWindows Vistaです。

それまでhomedirというvmdkファイルを持ち回りながらVMware ServerにFedoraの新しめなものを入れて、新しいFedoraが出る度(半年ごと)に乗り換えて、VNC経由でデスクトップを使っていた。写真もこのhomedirに入れていたのだけど、これがなかなか厄介で、Windowsからローカルにある写真を見る場合もそこそこあるのだけど、このときSamba/Linux経由では効率が良くない。しかもたまに見ようとするとスワップされているのかどうか分からないけど、異常な遅さになることも。

しばらく前からこのサーバのHDDが壊れがちでSMARTがブータれていました。容量の少なさもあり、昔のデータを消しながらの運用だったこともあり、交換しました。

このサーバは2002年に買ったThinkPadで、かなり古い。本当はfit-PCみたいな小型の省電力マシンを買って、ついでにSATAにして1～2TBくらいの容量にしたいところでしたが、予算の関係でPATAの320GBのHDD(Western Digital)を買って交換しただけ。2.5インチのPATAだとこれが一番容量が大きいようです。値段は1万円もしませんでした。

新しいマシン用の予算とCentOS6を待ちたいという気持ちは大きかったけど、一気にクラッシュする恐怖感には勝てなかったんです。

トラブルはいろいろありました。主な原因は(いつものことですが)手順を考える前に実行してしまったことと、子供の相手があるのでまとまって作業できなかったため、相当横着してしまい、けっこうダウンタイムが発生しました。

私のネット上の活動はこのブログとFlickr、deliciousがメインで、あとは裏でWorld Community Gridは動かしてましたが、このたびネット活動を増やしてみることにしました。

もちろんTwitterじゃないですよ。

というわけで、今日はGPSを使って地図を作るという話です。

この話を始める前に、地図データというのはあまりオープンではなく…ということから話を始めないといけないはずなんだけど、その種の情報はよく知らない。Google mapもYahoo! mapもあるし国土地理院もあるけど、とにかく地図というのはいろいろな意味でフリーなものではない、としよう。だって自分で編集できないでしょ。

世間にはOpenStreetMapというものがありまして、これはみんなでCreative Commonsなライセンスの地図を作ろうというプロジェクトです。地図のWikipediaみたいなもん、と言えばいいんですかね(WikipediaもOpenStreetMapもCC BY-SA)。ユーザが提供したGPSのトラックログなりCCなデータを使って、地図を作る。ユーザはGarminとかのGPSデバイスを持って道路を歩き、そのログをトレースしていけば地図ができるよ、というものです。既存の地図の写しではなく、自前でデータを作って、それをもとにみんなで編集していく。

私にとってはファルコムのゲームと言うとロードモナークです。ゴチャキャラのシミュレーションゲーム。最高傑作と言ってもいいんじゃないか。PC-9801時代にはずいぶん楽しませてもらいました。

音楽フリー宣言で思いだして、検索してみたら、今は無料でダウンロードして遊べるんですね。ユーザが作ったマップでも遊べる。いい世の中になりました。というわけで、先週末は久々にロードモナークで遊んでました。そういえばこんなマップもあったなぁなんて。あの音楽も好きです。

PC-9801当時と比べると、画面の解像度が上がったのでマップの見渡せる範囲が広くなりました。中サイズのキャラでも、ほとんど全部のマップを見渡せます。快適快適。

うちのVistaでは、普通にやると終了時にエラーが出ますが、実行ファイルのプロパティからWindows 95互換モードに設定するとエラーが出なくなります。ただ、セーブがなぜか失敗します。セーブするには、SAVEという名前のディレクトリを掘る必要がありました。

フリーな動画フォーマット、Ogg Theora。こないだ晴れてバージョンが1.0になったので注目を浴びている。いまどきはだいたいMP4(H.264/AAC)が良いとは思うが、永続的に保存する場合はフリーなものという選択肢もある。H.264もいつまで主流か分からないしね。

TheoraはWindows用のコーデックを入れればメディアプレイヤーで再生できるようになる。H.264のMP4はffdshowを入れれば同様にメディアプレイヤーでの再生が可能(ffdshowの新しいのはTheoraにも対応してるのかな？)。デジカメのMotion JPEGのaviは何も入れなくても再生可能。

というわけで、圧縮率を比較してみよう。デジカメを買い替えて、時代によって動画の構成が変わるので、それぞれについて、全部エンコードしてみた。

theoraはffmpeg2theoraでオプションなしでエンコード。H.264は以下のようにエンコード。

## ffmpeg -i $input -f mp4 -vcodec libx264 -qscale 20 -acodec libfaac -ar 8000 -ab 32 $outp

ut

H.264の動画はこの設定では音声がかなり不自然になってしまうような…。実際に使うためにはオプションを調整することになるだろうけど、サイズの比較には使えるんじゃないかと思う。

GRD時代のファイルがやたらに大きいのは、子供をたまに撮るようになったということと、解像度とFPSが上がったため(320x240/15FPS → 640x480/30FPS)。目安的には、1分で100MBくらいになるという印象。

sqliteにもvacuumあるらしいですね。作り直してコピーするという内容らしいですが、作って消して…と繰り返しているDBはかなり小さくなるという噂。

sqliteは便利です。ほかのプログラムに組み込みやすいし、設定も少ないのにSQLを食えるので、いろんなところで使われています。blogのDBに使っている人もいるし、tracのDBなんかも普通はsqliteですよね。

sqliteはFirefoxにも組み込まれている。そこで、Firefoxのプロファイルディレクトリにあるsqliteファイルをvacuumするスクリプト。

パス名がWindows用です。Linuxで使う場合はbasedirに$HOME/.mozilla/firefoxを入れればよいと思われます。Firefoxを閉じてから実行しないとエラーになります。

#! /usr/bin/python

import os,sys
import sqlite3
import glob

basedir=os.path.join(os.environ["APPDATA"], "Mozilla", "Firefox", "Profiles")

for i in glob.glob(os.path.join(basedir, "*.*", "*.sqlite")):
    print i[len(basedir):]
    con=sqlite3.connect(i)
    c=con.cursor()
    c.execute("vacuum")
    con.close()

確かに、けっこう小さくなりますね。まあ、Firefoxのファイルに関しては気休め程度です。

Calcのテキストファイルのインポートは全く改善されていないような感じ。セルがリンク情報を持っていて(元ファイルの更新に追随できて)、それなりの自由度がないと使えないですよ。たまたまテキストファイルをオープンしたらそれなりの解釈をしてセルにデータを入れるだけというのは私としては受け入れられない。

実はExcel 2007でこのへんの機能は非常に不安定になって不便に思ってます(それでもOOoよりは格段にマシです)。リンクの関係を編集しようとするとExcelが落ちる。MSに情報を送信するかどうかのダイアログボックスで何度かMSに情報を送信してますが、いつか対応されるのかなぁ。

Writerはブログ投稿のxmlrpcのインタフェースがあれば使うかも。HTMLを生成してxmlrpcで送るだけだから、プラグインとかで作れるような気もする。OOoの日本のコミュニティにはあまりいい印象がないのだけど、バグレポートとかフォーラムとか、時間があったらのぞいてみようかな。

最近、IBMのWorldCommunityGrid(WCG)に参加しています。Riceというプロジェクトがお気に入り。Riceは栄養価の高い米を開発するプロジェクトです。始めてから1月くらいですが、累計ポイントは現在4万5千くらい。

地球で生存できる人口は、耕作地のサイズからだいたい計算できると思う。農耕に使える土地の面積から適正な人口が導き出せると。それからすると、日本は人口が多すぎるんではないかなぁ。

人口を増やすor増えた人口を養うには、耕作地を増やすか、海洋資源をもっとうまく使うか、耕作の効率を高めるくらいしか思い浮かばない。米や麦が主食の地域が多いが、米と麦の優劣に関しては米が勝つという認識でいる。米は連作できるし、単位面積あたりのカロリー生産が麦よりもだいぶ高かったはず。その効率の良い米の栄養価をさらに高められれば、世界の人口を増やせるはずだし、日本の人口も維持できたりするんでは？

人口を増やしてどうするかって？ それはわからないな。でも飢餓で死んでしまう人を減らせるなら、悪い話じゃないだろうと。

インストールは簡単で、ユーザ登録してWindowsならWCGのクライアントをダウンロードしてインストールするだけ。ユーザ登録時のユーザ名とパスワードが必要になる。

cinepaintでブラケット撮影の画像を読み込んで1つにできると聞き及び、やってみた。ずれを検出して補正する機能もついていた。Fedora8で

## yum install cinepaint

でインストール、cinepaintコマンドで起動できる。さっそくこのへんのチュートリアルを見ながら、「ファイル」-「New From」-「Bracketing to HDR」を選び、ずれ(offset)を検出、HDR画像を生成してみた。紫色のエリアがたくさんできるので、「画像」-「Colors」-「Gamma-Expose」で適当にチェックすると、それらしい画像になった。

ただ、手持ちだとさすがにずれはいかんともしがたいですね。cinepaintの補正は平行移動を仮定しているようだけど、それだけではずれがおさまらないです。非常に手ブレ感のある画像になってしまいます。あと、HDR画像をOpenEXRで保存できませんでした(gamma値が外れているとかいうエラーが出る)。xcfやtiff、hdrなどの形式では保存できましたが、cinepaintとgimpの世代が違うらしく、xcfをFedora8のgimpでは開けないという…まあ、32bit IEEE floatをやめてPNGあたりで保存するのがいいかなぁと思います。8bit unsigned intにしてもjpegで保存できませんでした…