くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | ]

2012-10-09

日記

9月で消えると思ってた代休が10月までだったよ。余裕はあるはずなのでぼちぼち休んでいくか。

3連休は帰省してだらだらしてた。だけ。

SIGGRAPH ASIA行こうと思ってたけどその次週に仕事の締めがあるので厳しい気がする。 行くならもう決めないとまずいんだが。

[Ruby][OpenGL] 今週のゲーム作り続き

進展無いのでスクリーンショットもなし。PeerCastStation作ってた。

衝突検出作ろうかと思ったんだけど落ち着いたらめんどくさくなった。本読んだら作りたくなったのは確かなんだが、よく考えたら物理エンジン作るのってそんなに興味ないんだよねー。

なのでBox2D移植しようかなぁという気になってきた。というか調べたらC#移植版もJava移植版もあったのでRubyに移植する必要すらないんじゃないかと思うが。

しかしBox2DをRubyに移植しようとちまちま書き始めてみたがやっぱりめんどい。めんどいっつーかつまらん。1行ずつ置き換えていくとほんとつまらんな。やっぱり一回ちゃんとコード読んで理解してから書いた方がいいと思うんだがどうしたもんかな。

[PeerCastStation] 送受信ビットレートの表示

最近配信してるときに一度リレー崩壊すると上手く復帰できないことがあって困っていた。 当然直したいんだが原因が思い当たらないので何かデータを取って調べないといけない。

現象からどうもちゃんとリレーが流れなくなるんじゃないかという感じなので、まず秒間の送信バイト数を計測して表示してみたい。 以前からやりたかったことではあるのでやろう。

やるのは簡単でソケットからの送受信ができたら、それを記録しておいて時間で割るだけ。しかし延々と記録してしまうとすごい長時間での平均になってしまうのでもう少し短い間隔でリセットしてやる。最初10秒くらいかなぁとやってみたが長かったので結局1秒だ。値を取りにいった時点で時間計って計算するので正確に1秒ではないんだが目安だから問題はない。

計測できたらGUIにてきとうに表示してやるだけ……ってちょっと手を抜いててきとーすぎる方法で表示したがまあいいか。ついでに受信側も作ったので受信ビットレートも表示できるようにした。

まだ配信はしてないのだが視聴に使いながら動きを見てると、どうもリレー接続要求が来た時に既に接続されてる出力ストリームの送信が一時的に止まってしまうみたいだ。なんでだろうなぁ。確かにこの動作だと沢山リレー要求来ちゃった時に安定しないので現象には合ってるな。しかしどこかで送信スレッドがブロックしてるっぽい動きなんだが他を待ってブロックしちゃうようなところはあっただろうか……。引き続き調べるしかないか。

受信ビットレートの計測をするようにしたのでついでに受信中かどうかのフラグをちゃんと出力するようにした。今までは常に受信中扱いだったんだ。とりあえず受信ビットレートが0だったら未受信ということにしておいた。1秒間全く受信できなかったら未受信なんだが……うーん、これでいいんかな?まずそうならまたあとで直せばいいか。

[PeerCastStation] PeerCastのパケットスキップ

PeerCastStationで実装してなくて気になっていたパケットのSkipを実装しようかとPeerCastのソースを結局読んでみた……が、思ったのと違う動作だった。

受信したコンテンツパケットは最大64個だかのキュー(というかリングバッファ)につっこまれて送信されるんだが、送信が追い付かないとキューが溢れてしまう。溢れると古いのが未送信のまま消えるので、そのパケットは送信スキップ扱いになる。というのが送信のスキップらしい。

ただのキュー溢れかよ。だったらPeerCastStationでもだいたい同じ実装なので既に溢れはするんだが、あとはスキップしたかどうか判別するだけか。いやめんどいなこれ。ちょっと保留にしといていいですかね。

やるならちゃんと受信した時刻を計測してそれとだいたい同じ間隔で送信できてるかどうかでスキップ判定するべきだと思うんですよ。てかそのくらいしてるもんだと思ってたぜ。PeerCastの実装だと問題があって、パケット数がやけに多いコンテンツが流れた場合に送信できなくなっちゃうんだよな。PeerCastの実装的に1パケット16KiB以上のデータは受信できないのと相俟って高ビットレートだとどんどん時間的余裕が厳しくなるんじゃないだろうか。計算すると8Mbps以上だと1秒切るようだ。無理じゃん。逆に言うと2Mbpsならまだ4秒もあるのか。このくらいなら充分かもしれん。

あ、よく読んでたら受信側のスキップもあった。こっちはより簡単で、次に受信を期待していたパケットより先の位置のパケットを受信したら受信スキップが起きた扱い。特におかしいところもない、至って普通だ。

スキップ時の動作も調べてみたが、送信側のスキップはちゃんと送信できてないので強制切断、受信側のスキップは50回検出したら再接続を試行する。再接続は自動Bumpが設定で有効になってる場合のみだが、OFFにする理由も思い当たらないので常に有効でいいんじゃないだろうか。JP-EXとコメントが入った仕様……つまり日本でのフォーク版が拡張したところのようなので保守的になるのはわかるが、どうも保守的すぎる気がするんだよな。

まあどっちも実装してもいいけど、送信側のスキップ検出はどうすんかな。受信側のスキップ&自動Bumpがあればいらない気もするんだよなぁ。

とりあえず、Skipはともかくとしてまずはリレー要求が来た時に送信がブロックされる方をなんとかしないとな。


ページのトップへ | トップ «前の日記(2012-10-01) 最新 次の日記(2012-10-13)» | 編集 | kumaryu.net by kumaryu