ブラウザだけで超低遅延&大規模配信を実現! ImageFlux Live Streamingの真髄に迫る! ImageFlux meetup #2 レポート (後編)
さくらインターネットとピクシブが共同開発している画像変換サービス「ImageFlux」。1枚の画像をもとに画像の拡大縮小、切り抜き、合成などにより、デバイスに最適化された画像を簡単に生成し、高速かつ高品質で配信するクラウドサービスです。
さくらインターネットとピクシブは、このImageFluxをより多くの方に知っていただくとともに、最新情報をお届けすることを目的としてミートアップを開催しています。9月25日(火)の夜、さくらインターネット大阪本社にて2回目のイベントとなる「ImageFlux meetup #2」を行いました。レポートの前編では、ImageFluxの使い方やユーザーの声をお伝えしました。続くこの記事ではイベントの後半の模様をお伝えします。
目次
低遅延かつ大規模配信を実現したImageFlux Live Streaming
イベントの後半は、ImageFluxと同じくさくらインターネットとピクシブが共同開発している動画配信サービス・ImageFlux Live Streamingの特集です。まず本サービスの開発に携わるピクシブの茂木勇さんから、サービスの概要や内部処理の解説がありました。
※以降、本記事内においては、ImageFlux Live Streamingを便宜上「IFLS」と表記します。
IFLSは、PCやスマートフォンのブラウザなどからライブ動画を配信し、低遅延かつ大規模に配信を行えるサービスです。配信の仕組みは、配信者からWebRTC(Web Real-Time Communication)というAPIを用いてIFLSに動画を送信し、IFLSからはHLS(HTTP Live Streaming)というプロトコルで視聴者のブラウザ/アプリに動画を配信します(下記写真参照)。WebRTCを利用することにより低遅延かつプラグイン不要の配信が可能で、HLSを使うことで遅延はやや増えますが大規模な配信を可能としています。サービスとしてはまだα版ですが、すでにpixiv Sketch LIVEなど利用事例も生まれつつあります。
IFLSによるライブ配信の手順は以下の通りです。
- 配信者
- IFLSに対して配信チャンネル作成APIを実行し、配信管理用URL/チャンネルID/視聴用URLを取得
- 配信開始用URLとチャンネルIDを使ってWebRTCの動画配信を開始
- 視聴者に視聴用URLをアナウンス
- 視聴者
- 視聴用URLにアクセスして動画を視聴
続いて、IFLSにおける内部処理、特にWebRTCからHLSへの変換について解説がありました。詳細は割愛しますが、変換手順は以下の通りです。
- WebRTCで送られたデータを復号化し、RTPストリームを取り出す
- RTPストリームから音声と映像を取り出す
- 映像と音声の同期
- バッファリング
- 映像と音声をAPIで指定されたスペックに変換(トランスコード)
- 映像/音声ストリームを指定されたサイズのMPEG-TSファイルに分割(HLSセグメント化)
- MPEG-TSファイルをHLSのプロトコルで視聴者に送信
発表の最後に、ピクシブの中村宇作さんによるデモがありました。ピクシブでは、時刻表示と音声による時刻アナウンスを同期して流すアプリを作成し、同期テストや遅延測定に活用しています。今回もそれを使ってデモをしていました。社内でも1か月ほど連続配信していますが安定した動作を示しているとのことです。
なお、当日は、このイベント自体をIFLSを使って配信しました。東京、福岡、札幌にはサテライト会場を設け、各地で参加された方々はIFLSにて配信された動画をスクリーンにて視聴していました。2時間以上にわたる長時間配信でしたが、各会場ともトラブルなく視聴できていたようです。
このセッションの資料も公開しています。特にWebRTCからHLSへの変換手順の詳細などは、こちらをご参照ください。
こんなときImageFlux Live Streamingがあったら…!
続いてはピックアップの赤塚浩一さんから「ImageFlux Live Streamingで開発に集中する」と題する発表がありました。ピックアップでは、女性のコミュニケーションを活性化するためのライブ配信アプリ「CHIPS」を提供していました(2018年5月サービス終了)。その開発過程と、それを踏まえてIFLSの試用感をお話しいただきました。
CHIPSの配信/視聴シーケンスは以下の通りです。
- 配信者はサーバに対して空きチャンネルをリクエスト
- サーバは配信用URLを返す
- 配信用URLにアクセスすると配信開始
- 視聴者はサーバに対して配信一覧をリクエスト
- サーバは配信一覧を返す
- 視聴者は配信一覧から見たいものを選び、視聴要求をリクエスト
- サーバから映像が送出され視聴開始
- 配信が終了したら映像をサーバにアーカイブ
CHIPSのシステムはGCE(Google Cloud Engine)で構築しました。初期は1台のサーバですべてを処理していましたが、ユーザーが増えるとアーカイブ作成中に他の配信が乱れるので、アーカイブ作成をCoconutsというSaaSで行うようにしたのが中期の構成です。しかしそれでも安定しなかったので、後期はWowzaという配信ソフトウェアを利用しました。これでサービスは安定しましたが、さらなる品質の向上を求めて配信SaaSの利用を検討しました。このときに挙げていた要件としては、遅延がEnd-to-Endで5秒以内、配信の開始/終了が簡単にできる、APIをたたけばアーカイブしてくれる、といったものですが、検討した当時(2017年12月ごろ)は、残念ながら要件を満たすサービスはなかったそうです。
そんな赤塚さんによるIFLS試用の感想は「今までの苦労は何だったのかと思うぐらい楽だった」でした。特に重要な要件である遅延については、Andoroid端末からストップウォッチの画面を配信し、別のAndoroid端末で受信したものを並べて時刻を比較するという方法で測定しました。写真を見てわかるように、遅延は5秒程度で収まっています。
最後に赤塚さんは「私達はただサービスを作りたかっただけで、配信システムを開発したかったわけではない。ImageFlux Live Streamingのような良い配信システムがあれば、我々はサービスの開発に集中できる」とコメントしました。発表資料はこちらです。
ImageFlux Live Streamingを支える低遅延通信・WebRTC
最後のセッションは、時雨堂のvoluntasさんによる「WebRTCの優位性」という発表でした。IFLSでは、配信者からIFLSに動画を送る部分でWebRTCを使っていますが、このWebRTCに関する技術解説をしていただきました。
WebRTCはWebでリアルタイムコミュニケーションをするために作られたもので、ブラウザ同士で直接、音声や映像、バイナリや文字列をUDPでやり取りする仕組みです。内部では、音声や映像を扱うRTP、バイナリや文字列を扱うSCTP、暗号化を担うDTLSなど数多くのプロトコルが使われていて、それらを駆使することにより、ブラウザ同士での超低遅延の通信を実現しています。
WebRTCは本来、P2Pで通信するように作られていますが、P2Pは1対多の配信には向いていません。例えば100台に向けて配信しようとすると自端末から100本同時に送信する必要があり、帯域も負荷も膨大になってしまいます。そこで、送信者からWebRTCで受け取ったストリームをサーバ経由で多くの受信者に配信する仕組みが考案されました。これがWebRTC SFU(Selective Forwarding Unit)であり、それを時雨堂で実装したものがWebRTC SFU Soraです。IFLSにおいても、茂木さんから説明のあったWebRTCからHLSへの変換手順における「1. WebRTCで送られたデータを復号化し、RTPストリームを取り出す」という処理を、Soraを使って実現しています。
WebRTCが優れている点として、voluntasさんは「全部入り」「超低遅延」の2つを挙げました。「全部入り」は、ブラウザが、デバイス(カメラや画面)の認識、映像の取り出し、圧縮と配信という、動画配信に必要な作業をすべてやってくれることを指します。従来の動画配信は専用の配信ツールが必要でしたが、WebRTCではそのようなものが必要なく、ブラウザだけですべてが実現できるのでとても便利です。「超低遅延」は、voluntasさんの見解では1秒未満の遅延で配信できることを指します。WebRTC自体はサーバ経由でも200-300ミリ秒程度の遅延で配信できるようです。
最近は1対多の配信で低遅延のものが欲しいという需要が増えているのですが、大規模配信と低遅延の両立は難しい課題です。そこに挑戦しているのがIFLSで、ブラウザから簡単に配信できて超低遅延のWebRTCと、数万台でも配信できるHLSを組み合わせることにより、大規模かつ低遅延の配信を実現しています。現在、このようなことができるサービスはほとんどなく、そこがIFLSの優位性であると言えます。
voluntasさんの発表資料はご自身により公開されています。そちらもぜひご覧ください。
おわりに
ImageFlux Live Streamingはまだ開発中ですが、これまでの動画配信ツールにない特長を備えた、技術的にも見どころの多いシステムだと思います。今後の開発に期待が持てますし、次回以降のミートアップで新たな情報が聞けることを楽しみにしています!
それではまた、次回のイベントでお会いしましょう!