普通の手順は，まず Alt + PrintScreen キーでクリップボードに画像を取得し，ペイントブラシなり何なりを起動してから画像を貼り付けて，ファイル形式（SS 用なら PNG 形式が好み）を選択して，外部から見れる場所（ディレクトリ）を選択してファイル保存．

手間がめんどい．もっと楽にやる方法はないのか．

よくあるスクリーンキャプチャ系ソフトはどうかと思ったが，実際に使うシチュエーションを考えてみると，「撮ろうと思う → キャプチャソフト起動 → 撮ろうと思ったソフトで撮影 → キャプチャソフトで保存」と，対象があっちこっちを往復するので，気分的にかなりウザい．面倒．

理想のパターンとしては，「まず撮る → 目的ディレクトリを選択 → クリップボード画像をファイル保存」というのが思考の流れに沿っていて無駄がない．さらに，「目的ディレクトリを選択」というのが，よくある「ファイルを保存ダイアログ」だと面倒くさいってのが，ファイラを使い慣れちゃってる弊害というか．

というわけで，そういうソフトを探してみる．理想は，シェル拡張みたいにコンテキストメニューで「ここにクリップボードの画像をファイル化」みたいにできたらいいね．

……と思ってかなーーーーり探したんだけど．なんでそういうソフトないんだ？ 誰も欲しがらないものですかねー？

仕方ないから自分で作る？ シェル拡張のコードとか書いたことないけど……とか思ってたら，シェル拡張コンポーネントをマネージコードで作るな！？ という耳寄りなガッカリ情報をゲットしましたよ．うぇー……今さら C++ とかで書きたくないよう．C# がいいのー．しーしゃーぷー．

次の策．「クリップボードから画像をファイル化して，引数で指定された場所に保存するソフト」を自分で作って，なんかのソフト使ってコンテキストメニューからそれを呼び出すってのはどうでしょうかね？おおう，これはイケそうな気がしますよ！？

……と思ってかなーーーり探したんだけど（またか），あのね，フォルダのコンテキストメニューに機能を割り振れるのはいっぱいあるんだけどね，なんとゆーか，エクスプローラでいうとツリーじゃなくて右側の方，ディレクトリの中身の方ね，ここの余白で右クリックしてメニュー出す時のアレ，あそこにコマンドを追加できるものが何一つないわけですよ．

なんでかなー．TortoiseSVN とかだとそこにもメニュー出るから，そこに出すことが原理的に不可能ってわけじゃないと思うんだけど……もっと内部に突っ込んで勉強しないと原因は判りそうにないな……

そんなわけで，理想のプログラムはひとまず断念して，GetWinShot とか利用することにしますた．ランチャに仕込んでおいて，ファイラでファイル保存場所に一発で飛べるようにしておけば，こういう使い方ってことでこれは便利．作者さまありがとう．

なんか最近，サブマシンで H264 エンコしてると，ファンの回転数ががっつり上がって通常 3300rpm くらいだったのが 4600rpm になって，とんでもねー騒音というか不快なノイズを発するわけですよ．

メインマシンのクーラを交換したらよく冷えるし音も静かだしでにこにこなので，ここはひとつサブマシンのクーラも変更しようと思い立ったわけで．

でね，サブマシンは A8S-X なのだが，メインマシンに付けてるのと同じクーラ ANDY SAMURAI MASTER だと，デカすぎてレイアウト的に周囲のパーツに厳しいかなと．

というわけでちょっと小さいサイズのを探しに秋葉に行ってきた．横浜で探しもしたんだけど，どうも LGA775 用ばかりというか，品揃え自体がイマイチで……というのは言い訳で単に秋葉に行きたかったんですハイ．

で秋葉で SLC-747 とゆーのを買ってきた．サイズはあまり大きくないし，ヒートシンクの部分は斜めにカットされてるから，A8S-X のノースのヒートシンク（青笊）とも干渉しないだろう．おｋおｋ．

……と思って付けてみたら，取付け金具がデカすぎてヒートシンクと干渉しまくりｲｴｰｲ ってどういうことよ！あと干渉してなくてもさー，取り付けの説明書にある「ここ押してフック」っていう押す場所が，もろにヒートシンクに隠されてて普通に押せなくなるのってどうよ！

結局，近所の PC-DEPOT で 峰COOLER 買ってきて付けた．泣きたい．SLC-747 余ったんで誰か欲しい人にやる．ちくしょうちくしょう．

まぁそんなわけで，実は 峰COOLER の取付け金具も，サイズ自体は小さいんだけど固定時にフックピンを回そうとすると青笊と干渉したわけだが，これは青笊の方のピンを少し曲げて対処可能だった．

結果，CPU 温度はアイドリング時で 2度ほどダウン，回転数は FAN 径デカいので 3300rpm → 1100rpm くらいになった．まだ高負荷状態は確認してないが．

まぁめでたしめでたしってことで……

なんだかんだで正月ずっと動画いじりやってて家から出なかったので（箱根駅伝の影響で道路事情が悪いから出たくないという理由もあったのだが），今日は久しぶりに家から出てみる．

本来の計画では，銀行にちょっと寄ってからマジスパで食事して，その後に NEXT でオイル交換でもしようか……ってところだったのだけど，すごい混雑で銀行に時間を取られすぎて中休みの時間帯になってしまった．ので，先に NEXT に行ってからマジスパに行くことに．

というわけで NEXT でエンジンオイル交換をしようと思ったら，なんかそろそろ色々な液体系が交換時期だよねーってことで，いつの間にかミッションオイルとデフオイルとブレーキフルードとクラッチフルードとLLCを交換しておりましたｗ

まぁ年に 1回くらいはこういう大掃除を……ってもう 1年たってるのか．去年はほんと後半あたり仕事仕事でぜんぜん車に乗れてなかったからなぁ．今年はもっと走行会だの練習会だのに行きたいなーと思いつつ．

あぁそうそう，なんか右ウィンカを出した瞬間にヘッドライトが瞬くという謎現象が発生していたのだけど，これはレバー Assy の交換だろうってことで，実害は少ないけど不快なので交換することに．

あと帰り道で，またもやブースト計が止まってたのを確認．ホントこのブースト計はトラブル多いなぁ……

さてさて昨日は「ファイルを正常に抽出できないのは AVI ファイルが悪いのでは」 ってことでエンコ仕込んで寝たわけだが， 起きてみてパラメタ変更した AVI を食わせてもやっぱしダメだった． 昔作った DivX の AVI を食わせてもやっぱし正常に動かない， けどこれは本当に AVI がダメなのかもしれなくてあまり参考にならない．

それにしてもコケてるサイズが「だいたい 2GB くらい」なのが気になる． AVI1.0 は 2GB ファイル制限とかあるけど， 2GB 以上でも正常に抽出できる AVI もあるし， だいたい抽出後のファイルが 2GB ってことは AVI 的には 2GB を超えてるはずだから， MP4Box が AVI2.0 っつか OpenDML に対応してないってこたーあるまい．

で，試しに Windows の MP4Box でやってみたら……おいおい正常に抽出できるじゃんよー． Windows で動いて FreeBSD で動かない？ なんでやー． とりあえず AVI 自体は問題ない，と思われる．

となると MP4Box が FreeBSD で 2GB まわりでバグってる？ ということで検索してたら， なんかすげー似た症状を訴えてるひとを発見． AVI ファイルから H264 を抽出しようとしたら， 3.2GB あるはずなのに 2024MB しか出てきませんよーって，おおう全く同じ症状だ．

別のエンコーダだとどうよ？ とか，そもそも AVI 使わなければいんじゃね？ とか， 周囲の雑音に紛れて MP4Box 作者が登場． 結局「バグレポート登録してくんね？」「わーったよ作っとくよ」ってことになったようだ．

さて MP4Box というか GPAC のバグトラック． って，さっきの R!tman 氏のバグがまだ生きてる件ｗ 登録されたの 3月とかだよ！？ｗ で，そこには何やらヒントというか回答めいたものが．

 Can you try if it help if you 
 use "./configure --extra-cflags=-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
 -D_LARGEFILE_SOURCE=1" 
 should only be needed if you use a 32bit installation.

ファイルまわりの 64bit 対応をさせるコードなんですかね． さらに検索して調べると，Solaris とかある種のシステムの 32bit 版で， fseek() と ftell() を 64bit 対応（というか 32bit 非依存化）させるのに使う定数らしい． そんでよくよく調べると，FreeBSD では fopen() とかは素で 64bit 対応なんだけど， fseek() と ftell() だけは 64bit 版が別の関数（ fseeko() と ftello() ）があるみたいだ． へぇー……生の C なんて 16bit の頃からこっち使ってなかったから全然知らなかったぜいｗ

となると，昨日ソースコードをごりごり解析していて見つけた中に怪しい箇所がある．

 src/util/os_divers.c
u64 gf_f64_tell(FILE *fp)
{
#if defined(_WIN32_WCE)
    return (u64) ftell(fp);
#elif defined(WIN32)
    fpos_t pos;
    if (fgetpos(fp, &pos))
        return (u64) -1;
    else
        return ((u64) pos);
#elif defined(CONFIG_LINUX)
    return (u64) ftello64(fp);
#elif defined(CONFIG_FREEBSD)
    return (u64) ftell(fp);
#else
    return (u64) ftell(fp);
#endif
}

ちょ…… CONFIG_FREEBSD とか名指ししといて ftello() 使ってないじゃん！ｗｗ さらにコードを grep してみると， せっかく gf_f64_tell() とか定義してるのに ftell() を直接使ってる箇所が山ほどあったりして， なんだかなぁもう……

そんなわけで，ftello() とか fseeko() を使うように os_divers.c を書換え． さらに MP4Box のコードで ftell() を直接使ってる箇所があったんでそこは gf_f64_tell() に書換え． さらにさらに，なぜか CONFIG_FREEBSD が認識されてなくて最後の else に来てるみたいなんで， ports の Makefile の CONFIGURE_ARGS に --extra-cflags="-DCONFIG_FREEBSD=yes" を追加． そしたら改めて ports でコンパイルっと．

と！ いうわけで！ やっと期待通りに動いたー！！！！ヽ( ´∀｀)ノ

さて次の問題は，HD 画質を H.264 でエンコードすると， 1280x720 サイズでもカクカクで再生できない件ですが． こればっかりはどうしようもないから CPU と GPU の進化を待とう……ｗ

さて avi の問題点も把握したところで， やっと mkvtoolnix に 「allow_avc_in_vfw_mode」なんてモードがある理由も把握できたような気がする昨今． 「1フレームに 2個押し込めつつヌルのフレームを挿入」とか 「必ず 1フレームずつずれる」とか， ちょっと齧っただけでもとてつもなく美しくない策を弄するしかないあたり， きっと avi フォーマットってのは世界の各地でこよなく憎まれていることであろう．

ただ上記の mkvtoolnix の出力によると， 「VFW モードの AVC を Matroska コンテナに押し込めるのは未定義． いったん MP4Box で洗ってから native モードで入れなおしな」と出るので， まぁこちらとしては初めから mp4 にしようとしてるわけだが， するってーと MP4Box ってのは「きれいな」H.264 ファイルにして格納してくれるのかしらね？

早速 MP4Box を使ってみるわけだが， まぁ Windows 上だと GUI とかもちろん存在するわけで， YAMB という MP4Box のフロントエンドがしっかりあるわけですな．

ちなみに以下のような手順になる．

1. PV3 で録画．→ .dv （EARTH DV 形式）
2. TMPGEnc4XP で CM カット＆ x264 出力 → .avi （H.264/VFW + MP3）
3. MP4Box で raw video と raw audio を extract → .h264 + .mp3
4. MP3 を AAC に変換 → .aac
5. MP4Box で .h264 + .aac を .mp4 にエンコード → .mp4

うわぁ面倒くさいｗ

こういう面倒なのはバッチファイルにしてコマンドラインでやってしまうに限るわけだが， うちの環境の場合これらを行なう場所がネットワークドライブ上なので， 数 GB のファイルをいちいちネットワーク横断させないといけなくて， 大変に遅くなってしまう． そこで，どうせならこれらの作業すべてファイルサーバ上でやってしまおう，と．

用意するものは以下の通り．

• MP4Box ( ports: multimedia/gpac-libgpac )
• FAAC ( ports: audio/faac )
• mpg123 ( ports: audio/mpg123 )

作業はこんな手順で．

 MP4Box -aviraw audio infile.avi
 MP4Box -aviraw video infile.avi
 mpg123 -w infile_audio.wav infile_audio.mp3
 faac -q 100 -b 160 -c 48000 --mpeg-vers 4 --obj-type Main infile_audio.wav
 MP4Box -fps 29.97 -add infile_video.h264 -add infile_audio.aac infile.mp4

うーん……TMPGEnc4XP の avi 出力の時点で AAC にエンコードできれば手順がひとつなくせるのだけどなぁ． あと MP4Box の入力ファイル名に日本語（UTF8）が使えないぞ．どーなってんだ．

とまぁ，ここまでやって， なんか途中の MP4Box -aviraw video で抽出する H.264 データのファイルサイズがおかしいことに気づいた． 元の AVI ファイルを作る際のパラメタが悪くて変なデータになって途中で切れているのでは， とか予想して，パラメタ変更してエンコ仕込んで寝よう．

動画ファイルいじってたらまる 1日潰してしまったが， いろいろと知識が増えたからまぁよしとしよう……

詳しくはココ．

……後でぜったい内容忘れるから書いてあることをメモっておこう．

そもそもの問題点

VFW インタフェースと AVI コンテナは基本的に「Bフレーム」を扱えない． 古臭いテクノロジなので「Bフレーム」みたいな最新テクノロジには対応できないのだ．

「Bフレーム」を使いたかったら，できることといったらふたつくらい．

1. んな古いテクノロジはさっさと捨てて，.MP4 を DirectShow 経由で使うとかする．
2. 何とかして対応できるためにハックと開発をする．

ふたつのハックの方法

ハックとしては 2種類ありうる．

1. エンコーダがうまいこと処理する（XviD で packed bitstream を使った場合，あと DivX5 も）
2. デコーダで頑張る（packed bitstream を使ってない時の XviD）

基本的なトコ

まず，vfw/avi で Bフレームがどういう風に扱われてるのか理解しとこう．

通常，コンテナには「I P B B」の順でフレームが格納され，表示の際には「I B B P」の順で出力される．

vfw/avi は「1フレーム読んで 1フレーム出す（1 in, 1 out）」という仕組みになっていて， 1フレーム読み込んだら必ず 1フレーム出力しなきゃならない （エンコードもデコードも両方そう）． Bフレームというのは前後ふたつのフレームの情報から間のひとつのフレームを作り出す技術なので， 「2 in, 1 out」という風に動けない vfw/avi ではうまくいかない．

今時の普通のデコーダの挙動を示す．

1. まず Iフレームを普通に読んで出力する．
2. 次に Bフレームを出力したいところだが，それには I/P のフレームが必要だ． I は既にデコード済みなので P までのフレームを読んできて Bフレームをデコードし出力． つまり「3 in, 1 out」となる．
3. 同じように次の Bフレームを出力．
4. 最後に Pフレームを出力する．

デコード時のハック

まず，やりかたその1．

avi/vfw の「1 in, 1 out」の法則があるので，まずはエンコーダ側で対応しとかなきゃならない． packed bitstream とか呼ばれる手法がこれだ． すなわち，最初の Bフレームが Pフレームと同じ 1フレームに入って， 「I P B B」が「I P+B B N」になるのだ． N というのはフレーム番号だけ持ってる空フレームだ．

その上で，デコーダの挙動はこうなる．

1. まず Iフレームをデコード
2. 次に Bフレームをデコード．これは I と P を必要とするが， P は B と一緒に入ってくるのでデコードできる． AVI的には両方で 1フレーム扱いとなっている．
3. I と P は既に読み込んでるので 2番目の B もデコードできる
4. 最後に P を出力．

このハックは，1 フレームに 2フレーム分の情報を送ることで， avi/vfw の「1 in, 1 out」の法則をうまく回避できる． が，普通の MPEG4 標準に従って書かれたデコーダは， この packed bitsream を扱うことができない．

やりかたその2．

コンテナには正しく「I P B B」の順にフレームが格納され，デコーダ側でこれを何とかする．

1. デコーダはまず Iフレームを読み込むが，ここでは空フレームだけを出力する．
2. 次に Pフレームが入力されるが，ここで最初の Iフレームを出力する． 「1 in, 1 out」の法則は，初回の空フレームも込みで維持されている．
3. 次に Bフレームが入力されると，ここで I + B + P が揃うので，Bフレームをデコードできる．
4. 2番目の Bフレームも同様にデコードできる．
5. 最後に Pフレームを出力．

このハックだと，空フレームを作ることで「1 in, 1 out」のルールに対応できるが， デコーダは入力されたフレームと違うフレームを出力していることになる． が，packed bitsream と違って，MPEG4 標準ではこれを使用するよう定義している．

エンコード時のハック

というわけで，avi/vfw で Bフレームを扱うためのデコード時のハックは 2通りある． さらにエンコード時にもハックがある．

Bフレームをエンコードするには普通は以下の手順が必要となる．

1. 最初のフレームを Iフレームにエンコードする．
2. 2番目の，Bフレームとなるべきフレームが入力されるが， Pフレームが来るまでは Bフレームをエンコードすることができない．
3. 3番目のフレームも同じようにエンコードできない．
4. 4番目のフレームを Pフレームとしてエンコードする．
5. I と P が揃ったので，Bフレームをエンコードできる．
6. 同じように 2番目の Bフレームをエンコードできる．

もちろん，avi/vfw の「1 in, 1 out」の法則により， ステップ 2 と 3 の「何も出力しない」は不可能だ． そこで，エンコーダは「ディレイフレーム（delay frame）」と呼ばれる空フレーム（1バイトの 0x7F のみから成る）を出力する． このディレイフレームは，単に「1 in, 1 out」に従うためだけに出力されるもので， これが MPEG4 標準への準拠を不可能にする．

そこでどんな手段があるだろうか． Virtualdub(mod) は，エンコード中に得たディレイフレームをすべて捨てるという対処をしている． これにより，出力された AVI ファイルにはディレイフレームがなくなる． が，VFW が必ずしもこういうディレイフレームを捨てるフロントエンドで使われるとは限らない．

……AVI とか VFW，これマジどうよｗ

……けっきょく全部翻訳してしまったｗ

略して「のをでなに」（黙れ

というわけで何の話かというと，保存用の動画エンコードのことで．

今までは MTV2000 で MPEG2 形式で録画し，これを TMPGEnc4XP の内蔵 DivX で AVI ファイルにして保存していたわけだが．DivX 形式は家電化のための標準化だか何か知らないがやたらと制限を増やそうとしていて，TMPGEnc4XP がそれに追従しちゃうもんだから，最近のバージョンではとうとう 2GB 以上のファイルを作れないという役にたたんものになってしまった．

でもって解像度．今までは 720 * 480 で録画したものを左右削って 704 * 480 にし，これを 640 * 480 にサイズ変換して DivX にしてたのだけど，HDD もでかくなってきたことだし，せっかくだから 704 * 480 の解像度を維持したい．が，AVI ファイルはピクセルの縦横比が 1:1 固定なので，704 * 480 の 10:11 ピクセルを使えない．

となると方法は 2通りあって，(1) AVI 以外のコンテナを使う，(2) AVI でもデータが縦横比を保持してくれるコーデックを使う．後者は XviD 辺りが相当するんだけど，昔ちょっと試したら，ある程度の画質を維持しようとすると異様にエンコ遅かったんでこれはパス．

んじゃ AVI 以外のコンテナはというと，mkv とか ogg とか mp4 とかあるわけだが，TMPGEnc4XP の超便利な CM カット UI を捨てたくないので，TMPGEnc4XP がネイティヴで出力できるやつで．となると mp4 か，これなら H264 エンコーダも内蔵されてるし．

ということでここんとこしばらく H264 で mp4 エンコードしてたわけだが，内蔵エンコーダの欠点は 720 * 480 までしか対応していないこと．MTV2000 で使ってればこれは問題にならなかったのだけど，10月末に PV3 を入手してハイビジョン番組も録画するようになったら，これは大問題になってきた．

仕方ないから，いったん AVI 用の VFW コーデックで出力して，後から mp4 だの mkv だのに変換するってのはどうかなーと．色々と試すとやはり H264 がビットレートあたりの画質が良い感じなので，フリーで VFW として使える x264 とか使ってみる．そんで出力の AVI を MP4Box で mp4 に変換とかどうよ．TMPGEnc4XP は AVI 出力時に音声を AAC 出力できないので，FAAC で MP3 を AAC に変換したりとかしてさ．

……というわけで，色々やり中．x264 の B フレームが AVI でアレコレとか，面倒だからファイルサーバ側で変換できないかとか……

さて大晦日は例年通りみっち邸でぐだぐだと．すき焼きとか食べながらビデオ見たり酒飲んだりっと．

いつもはゲームとかしてたんだけど，今年は Wii のゲームが大して面白そうなのなかったので，ビデオを……と思ったらなんか仮面ライダーとかみたいのだったのでﾋﾞﾐｮｰに退屈ですた(´･ω･`)

つか Wii．結局なんだか一度も起動すらしなかった気がするんだけど，ライトゲーマ層どころか非ゲーマ層を取り込むって目標で作られたアレは，やっぱしちょっと既存ゲーマ層には訴求力低いんじゃないですかね．

コントローラの特殊性自体はゲームコンソールの売りにはならないのだが，とにかくもあの任天堂の方針，ゲームハードウェアの進化はストップしてソフトウェアで客層の拡大を図るってやつ．アレがいつまで続くものかって点がとても気になる．

ゲームコンソールというものはほぼ確実に「ひとり勝ち + その他」になっちゃうわけで，Wii がそのひとり勝ちになっちゃうと，今後数年間はこういう「非ゲーマ層向けゲーム」ばっか出て，既存ゲーマ層向けゲームは質的な向上が出来ないのではなかろーか．

しかも，非ゲーマ層を拡大といっても，世界の全員がゲームをやるようになるわけじゃない．新しいネタはそこまで頻繁には出ないから，受けたゲームの続編ばかりになってくるだろう．DS が脳トレ天国になっちゃってるみたいに．

とりあえずアレだ，Wii で「HD画質の超キレイでリアルなゲーム」は作れないけど，PS3 や Xbox360 で「アイデア重視のライトゲーム」は作れるわけだから，まずは「PS3 リモコン」や「Xbox360 リモコン」を出せば OK だ．ゲーム開発費の方はミドルをもっと充実させないと大変だろうけどなー．