Posted by yusuke on 5 月 5, 2010 in
Review 貴志祐介の第三作目「クリムゾンの迷宮」
—
主人公の藤木は、目を覚ますと今まで観たことのない風景が目の前に広がっていた。
辺り一面は深紅色。傍らに置かれた一つの携帯ゲーム機。
「火星の迷宮へようこそ」
血で血を洗う凄惨なゲームが始まった
—
何年ぶりに読んだのだろう。１０回は読んでるはずだと思うのだけど、
色褪せることなく楽しませてくれる。
読んでいて先の展開はわかったけれど、その分いろいろと考察しながら読めた。
物語としては生き残りゲームということになるのだけれど、所謂サバイバルゲーム（BB弾使うやつ）
やサバイバルホラーに代表されるバイオハザード等などのゲームと違い、本作での武器は情報と知恵
という所が面白い。
なによりこの本がでたのは1999年。丁度ISDNからケーブルが出始めて首都圏ではADSLが始まったころだろうか。
まだ無線LANやブロードバンドと言った言葉なく、情報化社会などと言った言葉もなかった時だ。
一般まで情報の価値、概念が普及していなかったころにこのようなテーマを扱うのも先見の明があるように思える。
元証券マンという主人公が情報の価値について顕在的に理解しているのも上手い運びだと思う。
何度読んでも面白いのが物語の運びがRPGゲーム風であるところ。レベルこそないもののそれぞれのルートで
手に入る道具（アイテム）が異なり、それぞれに価値がランク付けされているところや指示された目的地へ向かうことなど、
ワクワクする要素だ。
さらにサバイバル術としてトラップや草木実を食べたり、狩猟をしたりとボーイスカウト的な話も魅力の一つ。
ホラーとしては前作の黒の家もそうだったのだけど、「隠れる」ということに対して描写が
ひどくリアルで不安や恐怖への描写がすばらしい。こういったものに興味があるのであれば
是非読んでほしい一冊。
一点だけネタバレ含んだ考察
Read more…
Posted by yusuke on 5 月 4, 2010 in
Review 1Q84 Book1を読んでみて。
ふかえりの可愛さが異常。
おわり
Read more…
Posted by yusuke on 10 月 27, 2009 in
Life,
Photo,
Trip 京都出張どす〜
10年ぶり中学生の時の修学旅行以来！
カメラ持ってきてたから、iPhoneではり撮ってない…
Tags: 京都
Posted by yusuke on 10 月 23, 2009 in
Life,
Photo 高架橋からのショット。
ただ、なんとなくで撮った方が加工に熱が入るの図。
ミニチュア化として、少しいい感じ。元の写真のバランスがわるいほうが加工した時に映えるのだろうか
Tags: iPhone
Posted by yusuke on 10 月 20, 2009 in
Life,
Photo 書いてることはTwitterからなんだけど
品川駅、スタバからショットをチルトシフト。
面白い。
Tags: iPhone, チルトシフト, 品川
Posted by yusuke on 10 月 20, 2009 in
Life,
Photo 半年以上ぶりによく寝てる（二日目）ので、朝からパシャパシャした。
iPhoneからポストできるとついったー感覚でブログ書けるな
Posted by yusuke on 10 月 19, 2009 in
Life iPhone を買ったけど、結局iPodとtwitterとWebしかしてない！
という訳で二年近く放置してたブログへポストしてみる
Tags: iPhone, legacy
Posted by yusuke on 1 月 5, 2009 in
Life ひとつ前の記事があけましておめでとうだなんて・・・
仕事で日報というものがあるせいか、あまり日記を上げる気がしなくなったのだけど、
写真や読んだ本についてを書きたいから改めてはじめようと思う。
最近、いろいろと見えない何かが積まれていっている感覚がある。
この感覚がいつか取り返しのつかなくなる何かに変わるんだろう。
それはたぶん、何かを境にふっと消えて、
知らずのうちに過去のになり、小さな後悔へと変わるのだろう
それは後悔してもしきれない。
そうならないようにできることをやっていかないといけない。
Posted by yusuke on 1 月 4, 2008 in
Life あらゆるコンピュータの心臓部となるＣＰＵは
こと、一つ一つの命令は至極単純なもの
その命令郡（命令セット）を組み合わせて利用することにより、
生き物のような機構、機械、システム、サービスを生み出してくれる
そういえば村上春樹も、とあるインタビューで
「できるだけシンプルな文章で、 できるだけ複雑な物語をつくりたい」
という言葉を残している。
人も、生きるという行動の本質は、とても単純なものの組み合わせでしかないのだと思う
それが社会という舞台に上がるだけで、複雑にしてしまう
複雑なものを複雑のまま考えるから、実際単純なものまで複雑に考えてしまっている
というわけで今年の抱負は「フットワークの軽さ」「過程の中の結果」と行きたい
諺で言えば、千里の道も一歩から
明けましておめでとうございます
Posted by yusuke on 12 月 29, 2007 in
Diary 初めて触ったWindows以外のOSがSolarisでその時のブラウザがNetscapeだった。
文字化け、言語対応、かなりお粗末だったという記憶しかない（汗
その後、Ｉ研究室に寄生して、FreeBSD,Linuxと関わる中Mozilla,Firefox,Operaと利用して
結局Operaを使い続けている。
こうして開発終了を知ると、感慨を覚え、時の流れ―諸行無常を感じるね
この6年でＷｅｂ界隈も便利になったよなぁ
Posted by yusuke on 12 月 28, 2007 in
Study
kill PID
でプロセスを殺せない場合
kill -QUIT PID
とすると殺せる
Posted by yusuke on 12 月 28, 2007 in
Study プロセスがロックされて、シグナルをもらうことができない！！
なんていう時の解決方法はいくつかあるのだけど
メモリ管理が分からないのでforkを使って子プロセスから監視してみた
けれども親プロセスがTVorIP電話、ストリーミングだったりすると、waitで待って同期するわけにはいかない
そういう時はwaitpid()を使う
pid_t cid = fork();
if(cid == 0) { //子プロセス
struct sigaction sa;
sa.sa_handler = sight_handler;
sa.sa_handler = SA_RESTART;
while(1){
if(sigaction(もらいたいシグナル,&sa,NULL) < 0){
/* error */
}
if ( /* handler が 起動したら */){
break;
}
}
exit(1)
}
... /* 親プロセス elseで続けても良い */
int status;
waitpid(cid,&status,WNOHANG); // 子プロセスが終了してなけれ処理が継続する
if(WIFEXITED(status)){ //子プロセスの終了 == シグナル受信
子プロセスがシグナル受信した後の処理
}
他に共有メモリを使う方法あるのだけど、おそらくこちらの方がエレガントに書けそうな気がする
Posted by yusuke on 12 月 26, 2007 in
Diary 2003年からやっていて、mixiに移ったものの、ログという意味ではこちらも続きつつ思う。
最近ブロガーと呼ばれる人たちが書いてるのはログじゃねーヽ(`Д´)ﾉ
なんで、Ｂｌｏｇというカテゴリーは飽くまでこういった読む必要のないログを収めるカテゴリーである
ログであるからこそ、今まで続けてこれたのもあるのだけれどね
Posted by yusuke on 12 月 26, 2007 in
Study Debian/GNU Linuxでffmpegをhackしようとした時、ffmpegをsvnでcheckoutしてtrunkのソースをごにょごにょしてコンパイル！っていうことを考える
だけど、それでlinphoneを使ってみようとするとlibavcodec.soが無いんだよボケ！とあまり見たくないundefined referenceやらがわらわらでてくる。アプリケーションでffmpegの利用にffmpeg自体はあまり意味をなさない。必要なのはライブラリであるlibavcodecだ。
同じようなもの、というか、ffmpegとアプリケーションの仲介でもしてるのかと思ったら、そのままlibavcodecがffmpegと同じことをやっていた。アプリとして存在するか、ライブラリとして存在するかの違いっぽい。
そんなわけで最初の設定がまずかったかもしれないのだけど、Debianでlibavcodecを利用しようとするとlibavcodecのdebパッケージを用意する必要があるわけだ。純ソースからのコンパイルが結局わからんかった。
Read more…
Posted by yusuke on 12 月 25, 2007 in
Study intra_onlyとはIntra-coded FrameつまりIフレームのみの通信にするffmpegのオプション
GOPとはGroup Of Picturesの略でIフレームから次のIフレームの前のフレームまでの一くくりを指す。
ffmpegのheaderからgop_sizeを0にすることでintra_onlyになる
the number of pictures in a group of pictures, or 0 for intra_only.
そのため、intra_onlyとgop_size=1との比較検証をしていたのだけど、全く差がでなくて困っていた
ffmpegのソースコード(libavcodec/mpegvideo.c)を読んでみると
if (s->gop_size < = 1){
s->intra_only = 1;
s->gop_size = 12;
}
となっており、1でもintra_onlyになっていた！最初はこの値はIフレーム後のフレーム数でも指していると考えていたのだけど、考えてみればgop_sizeなわけで、全体のフレーム数が1なわけだ。
しかし、intra_onlyにした時に何故GOPを12になるのかは分からない。
gopヘッダーのオーバーヘッドの問題だとして12が一番効率良いのだろうか？
結果として
CIFサイズ、unsigned int maxのbitrateのintraで2Mbpsまで上げることができ、gop_size=2では1.2Mbpsと差が出た。
これを動的にできれば実験も折り返しにくる。もう少しだ
Posted by yusuke on 10 月 22, 2007 in
Logic ・やりたいことが多すぎて収集がつかない
・やるべきことが期日までに終らない
・もっとゆっくり、噛み締めて過ごしたい、吟味したい、今が惜しい
基本的にこれらの組み合わせだろうか…
これらを発展して、「ある時期にある高みまで成長したいという欲求、または焦り」が一番強い
これは取り返しが付かないから･･･
そういう意味で何を学ぶべきかと何を捨てて何を得るかはいつもボクを悩ませます。
Posted by yusuke on 10 月 1, 2007 in
Study 入力で利用されるピクセルフォーマットとエンコーディング、デコーディングで使われるコーデックがごっちゃになっていた。
実験で使っているQCAM、QVR13-Rで使われるピクセルフォーマットはMJPEGとYUYVの２つで、もう一つのQCAM （おそらく）QVR12か13がYUV420Pを使っているみたい。
これからフレーム間引きを実装する必要がでてくるのだけど、MPEGはフレーム間圧縮で簡単に間引きすることは出来ない。MJPEGかDVのフレーム内圧縮だと間引きしやすいので、後者を使いたいのだけど例のlinphoneにはMJPEGを使いたかった。
だけど、これらはあくまで入力フォーマットであってエンコするときには選択されたものを使っちゃうのね。MJPEGのつもりで進めていて実験してみたら、ペイロードタイプが違うのだもの。泣いた(>_<);
input→encoding→send→//→recv→decoding→output！
んん･･･入力がMJPEGならエンコードもデコードもしなくていいよくね？
input→send→recv→output!
こうしてMJPEGで伝送のミチを探るのでした
Posted by yusuke on 7 月 12, 2007 in
Diary 大学二年から自宅でサーバーを作っていろいろやっていたけれど、去年の春にマザーボードが壊れて以来、Value domainで年間2400円で借りてるのだけど、いろいろと不便。
サーバーが欲しい。超静音、むしろ無音なサーバーが欲しい。サーバーは便利だったけどかなりウザかった。
研究でも使っているDELLのサーバー、Power Edgeシリーズが良さそう、というかコスト的に3万から買えるのは素晴らしい。
うーん、バイトすることを視野にいれよう。
Posted by yusuke on 7 月 11, 2007 in
Study 結局、set_non_blocking_socketがvideo側のrecvでも引っかかっていたというオチで、無事、DCCP TFRCプロトコルでlinphoneを作動させることが出来た。
ようやく次の段階。に移る前に検証を行って行きたい。が、そもそも検証って何をするんだ。
もともとのプラットフォームの検証
・DCCPの上位レイヤーとしてRTPが動作するのかどうか
・SIPとDCCP-RTPが実装レベルで独立してくれているのかどうか
次にFreeBSDからLinuxにプラットフォームを変えたので
・LinuxでDCCPが同様の動作をするのか
等など。･･･検証できてるじゃん！
Posted by yusuke on 7 月 3, 2007 in
Study なぜ、音声データしか送信されないのかの原因がようやくわかった。
当初、デバッグのしている時に見えてわかる違いが送信スレッドの呼出が違う時期に行われていることだった。これに着目してしまったのが泥沼のはじまり。
Read more…