やる気も復活したものの、イベントに出す物を作る気が起きない。
あと2週間切ってるわけだがやばいなぁ。気合入れるかー。
ffmpegで配信しようとすると落ちると報告があったので調べてみたいんだが、ffmpegでのエンコが上手く起動できなくて手をつけられずにいた。単に画像入力に指定してたデバイスが間違っていただけみたいで、再度やったら上手くいったので調べてみよう。
再現はすぐできたのでデバッグしてみると、どうもおかしなパケットが流れてきてる模様。今までパケットが流れていないチャンクストリームに対して、以前のパケットから継続というデータが流れてきている。そんなばかな……。
継続なのをなんとかごまかしてデコードしてみるとAckパケットだ。ある程度データ受信すると送ってくるやつだな。しかしその前にSetWindowSizeパケットでAckを送信までのバイト数をものすごく大きく設定してるはずなんだけど、なんでAck送ってきてるんだろう？
そのAckを適当にいなしてみると、しばらく進んだところで壊れたパケットを受信してしまうようになった。壊れ具合がよくわからんのでどこが悪いのか検討もつかんなぁ……。
OBSはlibrtmpで通信してたけど、動作が違うてことはffmpegのRTMPてlibrtmpじゃないんだろうか？ソースを見るとlibavformatに独自でRTMPを扱う機能が実装されてた。RTMPもでかい仕様じゃないし独自実装でも何もおかしくはないな。
ソースを見てみるもののよくわからんな。librtmpのソースでも思ったけど3000行とかあるソースはなんとかしようと思わないんだろうか。Cだとstatic変数使ってソースファイルをモジュールとして扱うからあんまり分割したくないんだろうか。
何がなんだかわからなくなったので最初に戻ろう。まずはAckが変なパケットで流れてくるのがおかしい。いや、それ以前にでかい値でSetWindowSizeにしてるのにAckがすぐ来るのがおかしい。SetWindowSizeが効いてないのか？
設定してるはずのでかい値を見ると0xFFFFFFFFだった。あっ……。 受け取る方のソースを見ると、最終的にintにつっこんである。ということは負値になっちゃうじゃないですか。こいつか。
設定する値を0x7FFFFFFFにしたら動くようになった。やったー。
でかい値にすると動くのはわかったが、結局Ack受け取ると壊れるようでは困るなぁ。まともな値でも動くように試しておくべきか、ということでやってみると、こっちからAck送信する処理に簡単な間違いが入ってた以外はちゃんと動いてくれた。しばらくするとパケットが壊れるのは変なWindowSize設定しちゃってたのが原因か……。
あとはFlashPlayer製の配信できるクライアントでも同じようなことになったという話だったので試してみたい。が、クライアント自体はもらったけど、まだ動かせてない。これたぶんhtmlに埋め込まないといけないんだよな。objectタグの書き方覚えてないわ。