リアルタイム映像配信サーバ開発者からみた STADIA
まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10
コードを書き続ける
「開発者は経営者になったらコードを書くのやめて、経営に集中すべき」という考え方を聞いたことがある人はいるだろうか？ 自分はこの考えを持っていた経営者の元で働いていたことがあるので、強く印象に残っている。そして優秀な開発者たちが無理やりコードを書く時間を取り上げられ、経営者とされていったのを何度か見ている。 ここに書くのは自分の経験談であり、こうすべきとかではない。そしてなにより自分は死ぬまでコードを書き続けたいと考えているタイプであるということだ。 伝えたいことは一つだけでコードを書き続けたい経営者からコードを書くのを取り上げるのが良い方法だと思わないということだ。 また、経営者だから偉そうにコードを書くとかは当たり前だがなしだ。経営者関係なく、ただの開発者としてコードを書くという前提のお話。 開発者と経営者起業して 5 年が過ぎた。経営者としても 5 年、開発者としても 5 年。社員をし
Elastic Cloud を採用する事にした
検討した結果、採用することにしたので、その過程の理由を。 Elastic Stack を使うことにしたのはいいが、サーバをどう構築するかは決め兼ねていた。 普段から使っている Vultr という VPS サービス上に構築する予定だったのだが、そこそこめんどくさい。落ちた時、ディスク不足などを考える必要がある。 そこで次は AWS の CloudSearch を検討することにしたが、いまいち使いづらい。こちらとしては運用を丸投げしたいだけなのだが、しっくり来ない。転送量課金もある。これは仕方がないが。 そこで Elastic が提供している Elastic Cloud を試してみることにした。 自分が思いつく要求をまとめる。 運用に手間がかからないあまり高くない予算は月 2 万円程度使う側は Beats だけを意識していればいいKibana も運用してほしいサーバは東京にあって欲しい転送量で
自分の発表スタイル
ここ数年、自分の発表スタイルが固まってきたのでまとめてみることにした。 色々発表をしてきたが、今のスタイルが自分にはあっているので当面はこのスタイルで行こうと思っている。 方針資料は事前に公開する資料は発表を見ていなくても理解できるようにする発表資料ではなく発表者向けの資料にする資料は詳細に、発表はシンプルにする資料は Gist で作る発表時間は守る発表は全てアドリブで行う調べないと発表できない内容の発表依頼は受けない写真撮影は拒否、配信や動画は許可短縮 URL サービスを利用して資料の URL はわかりやすくしておく自己紹介は最小限にする事前公開そもそも何か秘密の発表をするわけでもないので、資料は事前に公開するようにしている。そうするとインターネッツの人たちが Typo を指摘してくれたりするので大変ありがたい。 これ、なぜみなさんやらないのかよくわからない。さっさと公開してしまうと良い
Mixer の技術的視点での凄さ
ところてんが Mixer について書いていたので、技術的な話をしようとおもう。 Mixer はマイクロソフトが買収した会社でもともとは Beam.pro というサービスだった。仕組み自体は今と変わらず、ゲーム配信をするという仕組み。 Mixer が他のゲーム配信サービスと違うのは HLS/MPEG-DASH といったストリーミング配信技術を採用せずに WebRTC というリアルタイム配信技術を採用したことだろう。 彼らは Janus という WebRTC Gateway を基盤として採用した。使うだけでなくフォークして、色々自前で改良を進めている。 Mixer が凄い点を上げてみる。 フル HD 、60 fps 、5Mbps での配信が実現可能ほとんど遅延がない、あっても 1 秒あるかないかクライアントを独自で作り込んでいる5Mpbs という高いビットレートでの配信を大規模に実現しているリ
CPU の AES 高速化
Intel と AMD の CPU には AES-NI という CPU 命令拡張が搭載されています。詳細は Wikipedia を読んでください。ちなみに ARM にも AES 拡張が搭載されているものがあります。 ちなみに 私自身はハードがわからないので AES-NI の知識はまったくありません。AES がハードウェアによって高速化される程度の知識です。 ただ、AES といっても暗号の種類は CBC 以外にも、最近良く使われている AES-GCM (TLS 1.2 で利用) や、 WebRTC の SRTP で利用されている AES-CTR があり、実は CPU ごとに AES-GCM や AES-CTR はかなりの差があるというのを最近調べていて気づきました。 ということでインターネッツのちからを使って募集してみることにしました。この記事を読んだ人も是非お時間あれば、気軽にコメントして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
