くまりゅう日記

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

2016-06-13

日記

書いてる間に一週間過ぎてるっていう。

先々週の土曜にまたライブ行ってた。泥陀羅とMISHAORUの。これは楽。 泥陀羅のライブは初めて見たが、なるほどこんな感じなんだなーと。MISHAORUは相変わらず出来が良くて素敵だった。 日曜はごろごろしてたら終わった。

先週はごろごろしてたら終わった。まあたまにはな。ていうか外出ようとしても暑くてさー。

[PeerCastStation] MKVとか

MKV配信が従来のPeerCastでリレーできないという話があったのをIssue見てて思い出した。調べるか。

おそらくパケットサイズが細かすぎて64個しかパケット保持しないPeerCastではすぐ溢れるんだろう1。 とりあえず適当にMKV配信して確認してみると、秒間120パケットとかなってる。これだとよくて0.5秒分しかないから厳しそう。

ちょっと前にコンテンツの受け取り方をチャンネルに直接追加してくんじゃなくて、チャンネルに追加してくれるSinkオブジェクトにつっこんでく形にしたので、ここにバッファリングしてパケットをまとめるSinkフィルタみたいなのを追加してやればよかろう。

FLVで似たようなことはやってたのでそれをちょっと参考にしつつ、新しくコンテンツ追加すると15kB越えちゃうか、最後の追加から100ms以上経過してた場合はバッファ内を1パケットとしてチャンネルに追加してバッファをクリア、新しいコンテンツはバッファに溜めておく、とした2。これだと100ms程度の遅れが出る可能性があるんだけど仕方ないかな……。 あと次のコンテンツが100ms以上かかってからくるような場合にはその分遅れてしまってよくないんだが、これを解決するのは難しい(し、その状況はほとんどない)。

入れて計ってみたところ秒間20パケット前後になった。まあまあ。こんなもんか、ビットレートも2.5Mbpsだし。

WMVに問題出てると嫌だなと確認してみたが、WMVはそもそもパケットまとめこみの対象にならない?調べてみると、ASFの時点で8kB単位にまとまってるようだ。なので2パケット目が来たところで合計15kBを越えるから、まとめらんないなと判断してFlushしてしまい1パケットずつになる。なるほどなぁ。

しかしPeerCastでバッファ時間が1秒切るのって16kB/パケットが最大と仮定して8Mbpsと計算してたけど、ASF(WMV)の場合は8kB/パケットだから64パケット保持では4Mbpsで1秒かー。

  1. PeerCastStationだと個数じゃなくて受け取ってから5秒間保持してる。しかしちょっと長い気もするな。3秒でも良さそうな。 

  2. FLVの場合は閾値を7kBにしてたけどちょっと余裕見すぎだなこりゃ。FLVの方もでかくした方がいいかも。 


ページのトップへ | トップ «前の日記(2016-06-02) 最新 次の日記(2016-06-24)» | 編集 | kumaryu.net by kumaryu