ワンセグを http live streaming して iphone で見る
って、試してるのはipod touch (1st gen)なんだけどw。
iphone 4g買う気でいるのでその準備と言うか。
寝てる部屋でもテレビ見たいというか。
要るもの（ハード）：
- OSX(雪豹が望ましい)
- Friio等（生TSが抜ける地デジチューナー）
ってここまでで敷居高杉ですが。
要るもの（ソフト）：
- recfriio改
- tssplitter_lite改
- mediastreamsegmenter
recfriioは終了まわり、tssplitter_liteはパイプ対応など修正。
mediastreamsegmenterはsnow leopard標準で入ってるコマンド。
iphone側はQuicktime playerで見るので特にソフトは不要です。
あ、あとWebのUIをgolangで作ってて、iphoneからはsafariで操作する感じ。
mediastreamsegmenterはオープンソースのsegmenterでも行けそうなんだけど、
AACとの相性が悪いのか成功せず。
トランスコードしてる訳じゃないので、
これさえ動けばlinuxとかbeagleboardでOKなんだけど。
と、需要あるのかないのかなのでとりあえず。
WebSocket Draft76
１周半ぐらい周回遅れですが、WebSocketのDraftが更新されていて76に成っています。
Handshake周りが変わっていて前バージョンとの互換性が実装次第なので注意が必要。
って、WebSocket Draft75 « ケンタテクブロで先を越されてエントリしていませんでしたが一応記事にしておきます。
websockets を proxy 環境でも利用する場合の注意点
ええとコメント頂いたのでまじめに書くことにします。
（ちょっとアングラな世界でドライバ作ってました）
現在のwebsocketsのクライアント側の実装でproxy越えをしようとする場合、サーバ側で特殊な考慮をしておかないと繋がらない環境が多いと思います。
ちょっとややこしいので順を追って説明します。
・クライアント側の実装でproxy越えする際にはProxyに対し CONNECT を発行する
・proxyでCONNECTできるのは接続先ポートがhttps(443)に制限されている場合が多い
（squidはデフォルト。443以外のSSLポートをSquidでプロキシするには辺り参考）
・一方、サーバ側はというとhttps使ってるならhttpsの場合が多い。
・websocketsで443に繋いだとしてもSSLのハンドシェークは行われない
以上から、proxy経由でのwebsocketsをなるべく利用可能にするならrawな（SSLでない）websocketsの口をポート443であけて置く必要があります。このblogに張ったwebsockets chatはこの対応をやってます。(httpsは潰してますｗ）
ま、現状の実装（websockets, proxy）での話しなのでこの先は分かりませんが…。
golangリリースニュース（w
2010-03-04のリリースで言語仕様に変更が有った模様。
http://go.googlecode.com/hg/doc/devel/release.html
strings.Bytes(x) -> []byte(x)
strings.Runes(x) -> []int(x)
って、結構当たり大きいような。
websocketsのpipeline
またもEmerge Technologyからのネタ。
この、websocket pipelineのサンプルが意味するところら辺の話。
# ちなみにHTML5のドラフト上、「websocket」ではなく「websockets」が正解・・・だったと思うw
websocketsの利用シーンとしては現状httpでは出来ないサーバ側からの通知とか、
非同期通信ばかりを思い浮かべていたけど、ajaxで出来る事もwebsockets化する！って
言うのはなんと言うか着眼点が面白いというかちょっと思いつかなかったなぁと言う感じ。
ただ、なんと言うか記事読んでいて思ったのは、
「websockets+pipelineが凄い！」っていう結論に成るような論旨展開に成っているんじゃない？！という事。
pipelineにするとシーケンシャルにしか処理できません。
例えば、１件処理するのに３秒かかるリクエストを３件行うとします。
３並列で実行すれば３秒、シーケンシャルに処理すれば３秒x３＝９秒かかるのは当たり前です。
ただ、この話は３並列で処理を実行した場合のオーバーヘッドが０という前提が必要です。
それをふまえ、何故、「websocket+pipeline」のサンプルがajaxでの処理が遅いのか考えてみると、
サーバ側でリクエスト１件に対するオーバーヘッドが大きいからに他成りません。
mod_python使っていても、handlerがpublisherの場合のTPSはそんなに良くないはずです。
またサーバ側のCPUのスレッド数も分かりませんし、
apacheのpreforkがいくつに成っているのかも分かりません。
websockets版はスレッドとしてpython上でread/writeをループしているだけで、
pythonの初期化とかしてないので早くて当たり前ですね。
上記のような事を考察せずNWの遅延とかターンアラウンドの話ばかりを引き合いに出しているあたり、
微妙に突っ込まれる事も有るかも知れません。
その上WebSocketsの方はページを開いたときにコネクションを張ってしまっています。
なんと言うか、インフラとかapacheとかajaxに詳しくない人って印象を受けてしまうのは気のせいでしょうか。
穿って考えると、websocket+pipelineが早い、という事ではなく、
「自分のサーバとかJSだとwebsockets+pipelineの方が早いみたい。」
と、言う話で一般的にAjaxよりもwebsockets+pipelineが早いという話では無いような気がしてきます。
と、色々書きましたがやっぱりWebSocketsは現状httpでは出来ない事を実装するためのものと、
思った方が良いのかも。
http(s)なら今までの資産として、javascriptのライブラリも使えるし、
cookieとか認証とか文字コード変換とかjsonとかproxyでのキャッシュとか
今まで蓄積してきたモノが使えます。
websockets上で独自プロトコル作るのがデファクトとは思えず。
まー、apache + mod_pythonなんてケチな環境じゃなく、
golangで専用プロセス上げてればもうちょっと違う結果になったのかもw