CPUファンやばい。
最近あったかく、というよりちょっと暑くなってきてPCのファンが素敵な音でぶんまわるようになってきた。空も飛びそうなくらいの素敵な音がしてやがる。 ケースファンとCPUファンを確認したらケースファンは980rpmくらいで安定してるのに対してCPUファンが4500rpmとかひどいと6500rpmとか77℃とかいってくる。すごい、6500rpmもでるんだ！ おいおい気温高めだったとはいえまだ25℃程度だし、A8-3850がTDP100Wでちょっと熱めとしても定格で動かしてんだぞ。 リテールファンが最高速で回るとかおかしいだろ！
ケース内の温度は40℃くらい。高めだけどMini-ITXですし。エンコ止めたらCPU温度も40℃後半まですんなり下がったのでCPUが冷えてないような気がする。CPUクーラーの接触が悪くなったのかとも思えるが、最初に組んでからそんなところいじってない。最近いじったのは旧マシンからHDDをひっぺがしてつけたくらい。そのときに何か変なところ触ったのかなぁ。
メインマシンは週末くらいしか使えてないので、そこまで急ぎではない。どうせいじるならリテールCPUクーラーよりは静かに冷える物に取り替えてみようとしたんだが、Mini-ITXにしてはでかいケースとはいえやはり狭いことにはかわりなく、一回開けてみないとどの程度のモノが付くかわからんわ。
最近流行りっぽいメンテナンスフリー水冷とかよさげーと思ったんだけど1120mm角のケースファン+ラジエータが付く場所あっただろうか。 うーん、ケースのマニュアルを見る限りでは140mmのケースファンしか付かないようだ。CPUクーラー取り替えだから場所はなんとかなるかもだけど、140mmファンのところに120mmファンを付けるアダプタなんて変なものはそうそう売ってなさそうだ。120mmのところに140mmファンを付けるアダプタはあるっぽいんだが、逆に付けるのは難しそうな気が。140mm角ラジエータのメンテナンスフリー水冷とか出ないもんかな。
ひとまずは無理せずCPUクーラーを一回つけなおしてみるのが一番かなぁ。
ポンプがけっこううるさいらしいだけど、べつに爆音でさえなければいいからな。それより水冷は浪漫だし。 ↩
RTMPの仕様って公開されてんだな。と読んでみると意外と簡単そうだったのでサーバを書いてみようかと。
やりたいのはFlashMediaLiveEncoderやFlash内蔵のエンコーダからエンコードされた映像・音声データを受け取ったら適当に何かのコンテナにmuxしてhttpでプログレッシブダウンロード的にストリーミングするってこと。いやストリーミングなら普通にRTMPで配信しろよ言われればその通りなんだが、最終的にはPeerCastで簡単に扱える形にしたいので。
仕様を参考にデータやりとりするプログラムを書き始めたんだが、そこはさすが独自プロトコル、さすが旧マクロメディア、仕様がおかしい。 チャンクとメッセージの関係がよくわからんのだよな。特にチャンクストリームとメッセージストリームが。
基本的な通信単位がチャンクでその中のメッセージが論理的なデータ構造だというのはわかる。
チャンクはチャンクストリームID+メッセージヘッダ+メッセージボディみたいな感じ。 チャンクにはメッセージが分割されて入ることがあるので、受信したらチャンクストリームIDが同じパケットを組み上げてメッセージを作る。
メッセージヘッダには何種類かある。
こんな感じ。基本的にメッセージを送る時にはタイプ0のチャンクを送って、分割されるならば1メッセージのバイト数がいっぱいになるまでタイプ3を送りまくる。 次のメッセージを始めるにはどこまで省略できるかによってタイプ0～3を送ればよい。 仕様的には新しいメッセージを始めるにもタイプ3が使えるので、どこでメッセージの区切りがメッセージ長さを見るしかなくてわかりづらいのは難点じゃねぇかな。
ここでちょっと困るのがメッセージストリームIDだ。これが何に使うのかわからん。違うメッセージを同時に送りたい場合はチャンクストリームIDを変えれば十分なんだが、仕様によると一つのチャンクストリームに複数のメッセージストリームをつっこんでもいいよ、メッセージヘッダがタイプ0になっちゃうのでヘッダがでかくなりがちだけどな！ということになっている。 なってはいるんだが、チャンクストリームがあるのでそんな必要ないし、タイプ0を送るとメッセージのメッセージのバイト数とかメッセージタイプも含まれてしまって、メッセージの途中でもしそれらが違うパケット来ちゃったらどうすんのよ、というところが謎である。 タイプ1～3も省略されてるだけで同じ値のメッセージバイト数やメッセージタイプが含まれてるんだよ、と言われたらその通りな気もするが。 おそらくメッセージストリームIDが有意に使われることはないんじゃねぇかという気がするなぁ。
よくわからない仕様はどうせ一番単純な方法でしか使われないだろうということにして先に進む。 メッセージが受信できたらその中身を処理していこう。
通信コントロール用のメッセージはまあそんなに難しくないので適当に処理する。
大事なのはコマンド実行用の物。ここで録画とかビデオパケットとかオーディオパケットが流れてくる。中身は何かなーと思ったらNumberとかStringとかいうデータ型が書かれてるがこれは知らないなぁ。よく読むとAMF0とAMF3の仕様を読めと書いてあるので示されたURLからPDFを落としてき……あれ、ファイル無いよ。 なんだかSourceForceにあるAdobe Open Source内のどっかのWikiに添付されてたようだが、サイト構造が変わってなくなったようだ。 しばらく探してみたが無い。本当になくなってしまったようだ。 仕様書がWikiの添付ファイルとして上がってるだけってどうなのよ。サイトの構造変えるならちゃんとチェックくらいしなさいよ。
とはいえ無いものはないので、仕様書が足りない。おしまい。
……ええ、まあ探しましたよ。探したら古いダウンロードサイトらしき場所からちょっと古い仕様書が落とせた。
AMF3は最新より一個前のっぽいけど無いよりはずいぶんマシだろう。これ読むか……。
1つのチャンクにはデフォルトでは128バイトまでのメッセージボディしか付けないのでそれより長ければ分割する。 ↩
MKVをストリームするのに必要なヘッダとボディの分割はなんとなくできそうなのでPeerCastStationに組み込んでいこう。
ASFContentReaderのソースをパクろうとしたら、ヘッダからビットレート情報の抽出をしているところがあった。あ、これやらなきゃならないのか……。
めんどうだけどもうちょっとちゃんと中身見ないとなぁとMKVの仕様を読んでいくが……無いじゃん。最大ビットレートとか平均ビットレートとかどっちでもいいから欲しいんだけど入ってないよこれ。もうちょい調べてみると、タグのところに文字列で入れるといいんじゃねぇかなぁ的なことが書いてあった。でもライブストリーミングの時にタグなんか付かないっすよね。
手動指定は出来るのでビットレート自動判別は無いと無理というわけでもないんだが、現状ほぼ唯一使われてるコンテナであるWMVの場合は自動判別できるので誰も手動入力なんざしない。 やるならちゃんとパケットのタイムスタンプとサイズを見て平均ビットレート計算かな。すっごいめんどくさい。 実際ライブストリーミング用のファイルではタグは付かないようだ。あとで対応しようとしてるFLVでもビットレート情報は入ってないので結局いつかは計算はしないといけないか。ちょっと頑張ってみよう。