WebRTCでやれよ!と言われそうなところですが、 WebSocket+WebAudioの組み合わせで音声ストリーミングをシンプルに構成する方法を紹介してみます。
サーバーサイドは何でも良いのですが、
とりあえずNode.jsでtest.mp3
というサンプルファイルをpcmモジュールでデコードし、
wsでクライアントに垂れ流す作りにしておきます。
(WIP)
#イベント駆動アーキテクチャ心得集
イベントを設計するのではなく、責任分界点を設計せよ
命令形ではなく過去形を使用せよ
ディスパッチャーはリスナーの存在を想定してはならない
ディスパッチャーはリスナーの数を想定してはならない
テスト用に自己証明書を用いてローカルhttpsサーバーを立てるなどの際に、クライアントから危険な接続として扱われないように証明書を設定をする方法について説明する。
通常ホストの真正性を確認するためにはドメイン名を使用するが、環境の都合上ローカルにDNSを立てるのが難しい場合がある。クライアントへの介入が難しい場合は/etc/host
による書き換えも出来ない。
そこで、x509.v3のsubjectAltName拡張を用いてIPをホスト名の代わりに使用し、任意のIPアドレスに立てたサーバーを真正なものとして扱えるようにする。
httpプロクシによるペネトレーションテストを行う際に、対象となるアドレスが不定であったりOSのプロクシ設定に従わないようなクライアントがあるとする。 この場合でも全ての対象ドメインが数え上げられる場合はDNSスプーフィングによって介入することが出来るが、透過型プロクシを使うのがより確実な方法である。 ここではOSX上のmitmproxyをプロクシサーバーとして使用し、任意のドメインとポートを対象としたhttp(s)通信へ介入する手法について説明する。 前提として、対象クライアントは既にプロクシの証明書を信用済みであるとする。
OpenGLにコンパイルしてもらう時点でシェーダにはある程度最適化が行われるようですが、 モバイルデバイスではあまりコストの掛かる最適化は行われないだろうという事で、 オフラインでGLSLの最適化をしてくれるフレームワークとしてglsl-optimizerがあります。 サポートされているGLSLバージョンはES2.0とES3.0もカバーしていますが、未対応の拡張もあります。
元々はUnityが機械生成した冗長なGLSLを最適化するために作られたようですが、 一応手書きのシェーダの最適化に使うこともできます。 ただし、組み込みを前提としているようでコマンドラインからキックするバイナリは提供されていません。
webrtcのObj-Cポーティングもそろそろ落ち着いてきた(?)頃合いなので、iOSの実機にWebRTCを組み込んでみます。 本記事中でSVNのバージョンは http://webrtc.googlecode.com/svn/trunk のr7864を使用しています。
この記事でも書きましたが、webrtcのiOSビルドは、 How to get started with WebRTC and iOS without wasting 10 hours of your life ↑この記事が親切かつ、まめにアップデートされているのでオススメです。