Transiruの音声配信技術についての講評

てるろー @terurou

Transiru、技術面はわかる人が見たらすぐに判っちゃうので先に書いておくと、Haxe/JavaScript, Scala, WebAudio, MQTT orver WebSocket, VerneMQみたいな感じです transiru.net

V @voluntas

Transiru transiru.net 音声配信を TCP に乗せたのか。輻輳あったときどうなるのか凄い気になる。

てるろー @terurou

@voluntas 将来的にはWebRTCも含めプロトコルの置き換えは検討してます。現時点ではかなり素朴な実装ですね。とりあえず公開することを優先して、だいぶ割り切ってます

V @voluntas

@terurou WebRTC で音声だけはかなりおすすめです。P2P でも相当な数裁けるので。映像絡むと死が待ってます。

V @voluntas

音声は何も難しくないんだよなーパケロスしてもどうでもいいし。ばんばん投げればいいだけ。問題は映像なんだよな。。

てるろー @terurou

@voluntas うちはあまり知見がないので、御社に技術相談すればよさそうですね。実際、MQTTで作ったはいいんですが、他にも問題は見えてるので、近いうちにご相談することになるかもしれないです

V @voluntas

@terurou いや、音声配信だけは凄い簡単です。js でさくっと出来ますよ。うちのはサーバ経由という面倒なことをやってるだけなので。それも映像がーってだけなので。音声だけであれば転送量問題とかも全部解決します。イイ選択だと思います。

てるろー @terurou

@voluntas なるほど、面倒だという印象があったので後回しになってたんですが、優先度上げて調査してみます

V @voluntas

@terurou SkyWay とかで逃げちゃえば凄い楽ですよ。P2P であればサーバコストもかからないですし。まさにこのための WebRTC って感じですね。うちは真逆で P2P では無理なところやってる感じです。

V @voluntas

@terurou ちなみに P2P だと 1:20 くらいが最大だとおもいます。CPU 的に。

てるろー @terurou

@voluntas やっぱ、1:20ぐらいになんですね。それだと全然規模が足りなくて、1:10Kぐらいの配信は最低限の目標としてるので、このあたりの配信制御が簡単にいくならWebRTCで良いのですが

V @voluntas

@terurou 1:1000 だと WebRTC だとサーバ経由しないとダメですね。もしくはFlash Media Server を用意するしかないですね。遅延なし（RTC) 系の配信は鬼門しかないです。

V @voluntas

@terurou 遅延ほぼなしリアルタイム配信は技術的に今のところニコニコ動画が最先端ですね … 。ほとんどの場合は遅延ありでやってるとおもいます。うちは映像込みだと 1:600 が限界ですね。

てるろー @terurou

@voluntas FMSを使いたくない→WebRTCで配信制御大変そう→とりあえずMQTTでリレーさせるかみたいな状況になってます。あと、遅延なしまでやるとコストが跳ね上がっちゃうので、10秒程度の遅延が実現できれば十分でしょという考え方をしてます

てるろー @terurou

@voluntas 映像込みで1:600はすごいですね…

V @voluntas

@terurou MQTT でリレーで十分かもしれないですね。ただ TCP + 音声はあまり現実的では無いとは思います。10 秒程度許容できるなら play list 方式でサーバにアップロードしてそれをポーリングしてダウンロードする HLS っぽいほうがイイと思います。

V @voluntas

@terurou broker いらなくなりますよ。遅延おｋの大規模配信はほとんど HLS (サーバに一度置いてプレイリストによる分割）方式が基本です。配信はセッションがボトルネックになっていくので難しいと思います。

V @voluntas

@terurou 完全に CPU 問題です。暗号化するので、そこがボトルネックですね。ただどうしようもないので、なんともｗ

V @voluntas

@terurou WebRTC は RTC(遅延を 1 秒以内に)が目的なので、用途が特殊なんですよね。遅延許容できるなら配信をダウンロード形式にすべきだと思います。そうすれば 1:10000 も可能かと。スケール考えなくて良くなります。

V @voluntas

@terurou うちの製品は、音声はテストが難しいのでやったことないですが、転送量的に 1:1000 は可能だとは思います。ただ、その魅力が遅延許されるならないかなーと。遅延が許されないシステムにしか使えない感じですね … ニッチです、ニッチ。

てるろー @terurou

@voluntas たしかにMQTTで作っちゃってから、実質それとやってることが大差ないみたいな感じにはなってますね。Pushされてくるか否かの違いぐらいのもので。

V @voluntas

@terurou だと思います。なので、 PUSH される必要はなくて、保存したデータを Opus で配信してしまった方がいいなと。ブローカー減らせて、Nginx だけでよくなりますね。

てるろー @terurou

@voluntas 配信周りにあまり詳しくないまま突っ込んできてるので、大変参考になります

てるろー @terurou

もともと低遅延を目指してはいたのだけど、ユースケースを整理してたら、shouldではあるけどmustではないという感じになった

てるろー @terurou

とりあえずモノを出すと詳しい人から知見を得られて便利