2週間くらいだと思ってたけど3週間くらい書いてなかった？
ちまちま作業してるからあんま日記書く暇なくてな。書くこともないんだけど。
11月末にはM3行ってお金なくなったくらい。
GPD Pocketが蓋閉じると10秒毎に起きて寝るをくりかえしてて電池食い潰すようになってたんだが、蓋を開けた時に起きる設定はOFFにしてあるし、起きた直後に寝るっていうログが出てて困ってた。蓋が原因で寝起きしてるログは出てるので、蓋を殺すつもりでデバイスマネージャからACPI Lidのドライバをアンインストールしたが再起動したら普通にまた復活してて、しかし症状は収まってくれた。なんだったんだろう……。
あとGPD Pocketは簡単操作で固定キーを有効にすると便利ってのに今更気付いた。普段両手で本体持って持ってキー打ってるんだけど、Shift押しながら他のキーてのが難しかったりしたのよね。
XSplit対策を一応完成させた。
XSplitはRTMP接続してきたあとにもう一本ポートチェックと称して別なRTMP接続をしてきて、それがつながらないと既につながってビデオデータを流している接続も切ってしまうという意味不明な動作をするソフトだった。
対策のために、RTMP接続を受け付けたあとも、そのまま接続受け付けを続けるようにして上手く動くようになった。 と、思いきや、一度接続を切るとそのあとの再接続がうまくいかないようだ。なんで？
再接続の時にポートチェックの接続が優先されてつながってんのかと思って試行錯誤してみたんだが、どうもおかしい。 ぶっこわれたデータをひたすら受信するのでこれがポートチェックの接続かと思ったけど違うんじゃねえかな。 XSplitは普通に動画を送ってきてるけどPeerCastStation側でちゃんと受け取れてないように見える。
何が悪いのかわからんなぁと悩んでたら、拡張タイムスタンプが入ってない場所があるとの有力情報がもたらされた。まじでー？
調べてみるとその通り。RTMPのパケットでタイムスタンプは3バイトなんだけど、3バイトで足りない場合は0xFFFFFFを入れるとヘッダの後に4バイトが拡張タイムスタンプがくっつく。 しかしXSplitはなぜか0xFFFFFFを入れてくるわりに拡張タイムスタンプは送ってこないので、そこでデータがずれて正しく受信できなくなってしまうようだ。 そんなんできる仕様だっけとRTMPの仕様見たけど拡張タイムスタンプ入ってくるのがやっぱ正しいな。バグってんじゃんこいつ。
直すだけなら、0xFFFFFFが来ても拡張タイムスタンプは無いことにすればいいんだけど、それだとXSplit以外のエンコーダが正しいデータを送ってきた場合に困る。XSplitであることを判別して特別な処理しないとだめか……。
しかしハンドシェイクの段階ではXSplitだと分かるデータは送られてこないのでどうしたもんか。と困ってたら、おかしいタイムスタンプより前にメタデータが先に来れば判別できるのではとのこと。それはあるなーと調べるとその通りだったので、メタデータで判別してXSplitだったらXSplitモードに落ちて拡張タイムスタンプを読み込まないようにした。
これで完成！XSplitでも配信できるようになった！やったー！捨てよう！
いやー、対応はできたけど、これ今のところ普通のリリースに入れたくはないな。 今まで一本RTMPつながったら行儀良く待ち受け解放してたのが待ち受け続けるようになってるし、XSplitとかいうバグってるアプリの尻拭いをこっちでやるのおかしいし。 Pull Requestとしてマージできる用意だけはしといて、要望あるまで入れないようにしよう。
PeerCastでXSplit使いたいって話は今まで聞かなかったし、正直XSplitは出来が悪いアプリなのでPeerCastに限らずどんなサイトで配信するにしてもおすすめできん。 無駄に常時管理者特権じゃねえと動かねえアプリとか存在自体が脆弱性みたいなもんだし。