本日のアレ.20070806-20070812 - Xia's
index
アレ
ぬぉぉ.ほしい……てかもう買っとくか.やむを得ず.
わりとヤフオクとかでも入手可能な気がしなくもないんだけど,こちらは新品ですし.ていうかヤフオクで買ってもクリエイタに金が入らない気がするし.やっぱ買いましょう.
というわけでお金ためとこう.うんうん.
なんか PC の置いてある方から「カコン! カラン!」とか音が聞こえた気がしたんだけど,その後特に異音があるでもないからちょっとそのまま PC 使ってたら,いきなり M/B の温度警告ビープが.
慌てて Tyan M/B Monitor を見てみると,CPU 温度が 54度.前に使ってた AthlonMP 2800+ ではアイドル時の温度だが,今の Athlon64X2 4600+ では異常事態だ.
とりあえずその時に再生していたニコニコ動画を停止したら温度が 40度くらいまで下がったが,再生開始したらまたすぐ 50度を超えてきた.CPU に近い箇所のファンの動作が不良っぽい.
ってことで机の下に潜り込んで机の裏側にある PC を開けて見てみると,CPU ファンが緩んで斜めになってた.あーこりゃダメだw
フックが外れただけかと思ったら,どうもフックを引っ掛ける箇所そのものが壊れて取れてるようだ.さっきの音はこれかー!
というのが昨日の夜.ひとまず朝イチで横浜のヨドバシに行って,AM2 用のリテンションってのを買ってきた.
ちなみに壊れたパーツはこんな感じ.
なんでこんなトコが壊れるんだろう……
「力をかけすぎなのでは」と言われたんだけど,サイズ製 AM2 フックを使ってみるとわかるがここは力がかかる場所ではない.テンションはここに縦方向にかかるのだけど,人間の力はフックを横方向に動かす時にかかるわけだから.
まぁ ANDY クーラが M/B 付属のリテンションガイドの想定より重かったってことなんだろうなぁ.でもショボいなぁ.Tyan さんはもーちょっと丈夫なパーツを使うべき.
なんかブロック塀で.
セミの幼虫は地中で木の根から樹液を吸って生きてるわけで,ということは羽化もそういう木のある場所で行なわれるのがスジってもんだが,この子は最寄の木から 3m 以上ある塀で羽化しておりました.けっこう移動すんのね.羽化の最中は完全に無防備なんで,逆に,ある程度そういう「敵の集まりそうな場所」から離れるようにしてるのかもしれん.
アップで.
アブラゼミなので羽に色が付きかけてます.透明な羽の種(ミンミンゼミとかクマゼミとか(クマゼミはうちの辺りにはいないけど))では,この羽の筋が青っぽく光ってすっごくキレイなんだけどねー.
なんか今年は梅雨が遅かったせいかセミが鳴くのも遅い気がするが,ここ数日でやっと一日中セミの声が聞こえるようになってきた.
夏だねぇ.
TMPGEnc4XP から VFW インタフェースで x264 + raw PCM の AVI を出力して, それを faac で AAC エンコして gpac の MP4Box で mux して .mp4 ファイルを作る日々.
先週はいつものモータスポーツに加えて NHK「失われた文明 インカ・マヤ・アステカ」とかも録画したもんで, 週間 23本,エンコ時間が合計で 40時間くらい? とかすごいことになってました. 今週は今週で BS-i でバレーボールワールドグランプリ予選があるんで, こいつを HD 画質に近くエンコすると 2時間番組 1本に 13時間かかる罠.
ここまで読んで「バカじゃね?」と思った方は,正常です.お帰りください(ぉ
というわけで,Core 2 Quad Q6600 がいい感じに値下がりしたわけですよ. 巷では「4コアなんて使い道ない」「2コアで充分」といった声も聞かれるわけですが, エンコ厨には何コアあっても使いきれないぜ! たぶん!
んが,ここで問題になるのが,上記の「VFW インタフェースで」の部分. こいつはエンコ時に「1フレーム読んで 1フレーム書く」という動作をするのだが, 複数コアの CPU を駆使するために複数スレッドを使ってエンコすると問題が発生する. 前後のフレームデータを参照しなければならないために入力フレームを同ターンで出力できないので, 最初の数ターンは何も出力しないでおいて,最期に帳尻を合わせるように動作するのだな. ところが VFW は入力が終わったら出力の読み取りも終えてしまうので, 結果その帳尻合わせができず,後ろの方のフレームが欠落してしまう.
で,4コア CPU を活用するためにスレッド数を増やせば,その分だけ多く欠落してしまう. ちなみに B フレームの連続数を増やすと同様に欠落が増えていってしまう. 圧縮率を上げつつ速度も向上させたい場合は,とにかく欠落が増える方向になってしまうわけだ. 今は「末尾のほんの数フレームが欠落してもまぁ仕方ない」と無対策でエンコしているのだが, 欠落量が増えてくるとそうも言ってられん.
というわけで,フレーム欠落対策をしっかりするために, まずはどのくらい欠落するのかをチェックしてみた.
フレーム欠落数 | スレッド数 | |||
---|---|---|---|---|
1 | 2 | 4 | ||
Bフレーム数 | 0 | 0 | 1 | 3 |
1 | 1 | 2 | 4 | |
3 | 3 | 4 | 6 | |
5 | 5 | 6 | 8 |
欠落数 = ( スレッド数 - 1 ) + ( Bフレ数 ),というとても明快な式が得られる模様. てことは 4コア CPU で 8 スレッド動かして B フレ 5 にすると 12 フレーム欠落, 時間にしておよそ 0.4 秒.とても無視できる量ではなくなるなぁ.
まぁそんなわけで,ビデオに関していえば,TMPGEnc でカットする時にあらかじめ 12 フレーム多くカットしておけばいいのだが, そうすると今度は音声が 0.4 秒くらい長く入ってしまうことになる. raw PCM を AAC にエンコする前に,2ch * 16bit * 48000Hz * 0.4 == 76800バイトくらい末尾から削り取る必要があるな.
話がどんどん複雑になっていくのは,ひとえに TMPGEnc の CM カット機能が優秀すぎる上にカット情報を単体で出力できねーからです. それができればなぁ,普通に AVISynth とかでコマンドラインだけでエンコできちゃうのに. のにのにの.