なぜ WebAssembly 生成を Go にしたのか
オンラインイベントで聞かれて、ツイッターにつぶやいたら思った以上に反響があったので、もう少し詳細に書いてみます。 思ったより反響があったまとめ信頼できる暗号ライブラリがある自分が TypeScript より Go のほうが書けるGo の Wasm バイナリサイズを気にする必要がないWebCrypto にない暗号が必要自社の WebRTC SFU において End to End Encryption (E2EE) をブラウザ上で実現するためにはいくつかの壁がありました。 一つは WebCrypto が提供していない暗号を利用したいというものです。 今回 E2EE を実装するにあたり採用した Signal プロトコルでは公開鍵暗号に Curve25519 を採用しています。残念ながら WebCrypto では Curve25519 に対応していません。この時点で「暗号ライブラリをどこからもって
Chrome リモートデスクトップ – V – Medium
ブラウザだけで利用できるリモートデスクトップ機能。使う側のマシンにセットアップするだけですぐに使えるようになる。 Chrome 拡張と、専用のアプリをいくつかインストールするだけ。とてもインストールは簡単。ほぼほぼマウスクリックするだけで終わり。 あとはマシンの名前とピンコードを登録さえすればピンコードがわかっていればアクセスできる。 この Chrome リモートデスクトップが今までのリモートデスクトップと大きく違うのはブラウザで実現していることだろう。 そしてこの Chrome リモートデスクトップはがっつり WebRTC を利用した仕組みだ。WebRTC P2P で実現している。 VP8 でリモート先のマシンの全画面を WebRTC MediaChannel を利用して P2P 経由で送っているリモート側のマウスやキーボード情報を WebRTC DataChannel を利用して P2
リファクタリング
自分はリファクタリングが好きなので、リファクタリングに対する考えとかを書いてみる事にした。 前提としては自社製品、さらにパッケージソフトウェアのためデプロイは存在しない。リリースは一ヶ月に一回程度。ソースコードは 10 万行未満。 自分がリファクタリングするのは機能追加に飽きた時。ペーストしては月１回程度で、多い方だと思う。よく飽きる。 リファクタリングをする時はまず、コードを端から端まで読みながらコメントをしていくところから始める。その後、またコードを端から端まで読みながらコメントを読みつつ、どんなリファクタリングをするか決めていく。そして、決めたらブランチを切って作業。 とにかく、手を付けるコードを読むことが重要だと思っている。人間は適当なものでコードを適当に理解している事が多いので、一度頭を空っぽにしてコードを読むと「この辺は大丈夫」と思っていた部分も全然大丈夫じゃないことがある。
AV1 の未来が開いた – V – Medium
今、よく使われているビデオコーデックといえば H.264 でしょう。ただ H.264 は最先端の技術とはいえません。今後は H.265 に切り替わっていくかと思われましたが、H.265 はパテントがとても複雑です。そのため広がっていくとは思いにくいです。 そんな中、H.265 のパテントの闇に取り込まれないようにするための光が AV1 です。
WebRTC を利用した配信の現実
超低遅延、高画質な配信を実現するための選択肢の一つとして WebRTC があります。 ただ WebRTC はもともと少人数で双方向の配信を前提としているため、スケールしないというのが一般的な認識です。 せっかくなので WebRTC サーバを開発・販売している立場から WebRTC を利用した配信の現実がどの程度なのかを書いていこうと思います。 P2P モデルまずは WebRTC といえば P2P なので、WebRTC の P2P 利用についてお話する必要があります。 WebRTC の P2P 利用は、配信者が視聴者分の変換を行うという負担があることから、最大でも 10 名程度までしか配信できません。 さらに、何より配信者の PC 負荷がとても高くなるため、採用は趣味のページまででしょう。 ビジネスで P2P を配信に利用するのはとても現実的ではありません。
カスタマイズをしない
自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して＋アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう
WebRTC の Gateway と SFU による 1:N 配信
まずは Firefox または Chrome Canary で以下の URL を見てみて欲しい http://sora-demo.shiguredo.jp/down.html LED Cube がチカチカ光ってるのが見えたら、それは NAT 越えが無事できて、WebRTC SFU があなたのブラウザに映像を配信しているということだ。 これは USB 経由の Web カメラを Raspberry Pi 経由で WebRTC Gateway が WebRTC SFU に配信している映像だ。配信側はブラウザではない。 社内においてある LED Cube を USB 経由で Raspberry Pi に接続している Web カメラで映像を取得する。その映像を WebRTC Gateway が WebRTC 形式で さくら VPS 上にある WebRTC SFU 配信する。WebRTC SFU は受
WebRTC SFU の API 連携
WebRTC SFU 単独ではサービスが作れるわけではない。もちろんアプリが必要だ。そのアプリとの連携は必須になる。 ただ、 WebRTC SFU 側に判断機能をできるだけ入れたくない。つまり委譲機能を積極的に積んでいきたい。 アプリとの連携のために WebRTC SFU は Stream API と Action API そして Event API を提供する。 Stream API は簡単にいってしまえば WebSocket の口だ。つまりアプリは WebSocket を WebRTC SFU に対して接続しにいく。その後は WebRTC SFU で管理している状態が変化するタイミングでストリームデータが流れてくる。 Action API はアプリから WebRTC SFU に対して処理を依頼する。たとえば特定の接続ユーザを切断させたい場合に使う。 Event API は Stream
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebRTC スタック Python 実装の紹介
Discord の採用している技術
HTTP API の設計方向