Weitere ähnliche Inhalte
Ähnlich wie FRESH LIVEへのSRT導入 (20)
FRESH LIVEへのSRT導入
- 2. 自己紹介:松澤友弘
2000 - 2004 リアルタイム映像伝送装置IP-700IIの開発
2006 渡米
2007 - 2014 シアトルのスタートアップ会社でゲーム開発
2014 帰国
2015 - 2016 ゴルスタのライブ配信機能ゴルキャスの開発
2016 - FRESH LIVEの配信基盤の開発
- 4. SRTとRTMPの比較
RTMP SRT
開発者 Adobe Haivision
一般公開 2002年(Flash Player 6) 2013年(IBC 2013)
仕様またはソースの公開 2009年(仕様公開) 2017年(オープンソース化)
プロトコルベース TCP
・パケット再送遅延
・帯域制限
UDP
コンテナ FLV
・コーデックの制約
束縛なし(主にMPEG2-TS)
Hinweis der Redaktion
- まず自己紹介させていただきます。
私が初めて動画関連のプロジェクトに関わったのは2000年で、IP-700IIというリアルタイム映像伝送装置の開発を行なっていました。2006年に渡米して、2007年からシアトルのスタートアップ会社でゲームの開発を行っていました。2014年に帰国して、ゴルスタという中高生向けのソーシャルネットワークアプリの開発に携わり、後半は主にゴルキャスと呼ばれるライブストリーミング機能の開発を行っていました。2016年にサイバーエージェントに移り、現在はFRESH LIVEの配信基盤の開発を行っています。
- 次に、FRESH LIVEにSRTを導入することになった経緯を話させて頂きます。
FRESH LIVEは、誰でも動画の生中継を配信することができるライブ配信サービスで、2016年にサービスを開始しました。
サービス開始当初はRTMPとHLSといったオーソドックスなストリーミングプロトコルを使っていました。
HLSを使うことにより高画質の配信を実現できていましたが、10から30秒という大きな映像ラグが課題でした。
それを解決するために2017年にHLSを改良した低遅延のLHLSを導入して、映像ラグを3秒程度に縮めることに成功しました。
FRESH LIVEでは、比較的安定したネットワーク環境からPCで配信するユーザーが多かったため、このアプローチはうまくいっていました。しかし、ほぼ同じタイミングでiPhoneからFRESH LIVEに配信できるアプリをリリースしたところ、不安定なネットワーク環境からの配信が多くなってきました。
時々、RTMPで3秒以上の揺らぎが発生することがあり、全体としての映像ラグを3秒程度に収めることが難しくなってきました。
そこでRTMPの代わりになるプロトコルを探し始めたのが、SRTを導入するに至ったきっかけです。いくつかのチャレンジがありましたが、10月末にSRTを導入したiOSアプリをリリースして、現在FRESH LIVEではiOSでの配信にてSRTを使用しています。
- 次に、SRTとRTMPについて比較して見ましょう。
RTMPはAdobeが開発して、2002年にFLASH Player 6で導入されました。2009年にプロトコルの仕様が公開されています。対してSRTは、Haivisionのエンコーダー装置の伝送プロトコルとして開発され、2013年のIBCで一般公開されました。2017年にオープンソース化されています。
RTMPはTCPベースのプロトコルです。TCPにはパケットロス時の再送処理が遅く映像ラグの原因になるという問題があります。またTCPのコンジェスチョンコントロールの仕組み上、長距離配信にて帯域が制限されるという問題もあります。SRTはUDPをベースに、改善されたパケット再送とコンジェスチョンコントロールの仕組みが実装されており、これらの問題が緩和されています。
RTMPはコンテナがFLVに制限されています。FLVはH265のような最新のコーデックをサポートしていないため、RTMPでは最新のコーデックを使うことができないという問題があります。SRTではコンテナの制限がないため、どんなコーデックでも使用可能です。今は主にコンテナとしてMPEG2-TSが使われています。
- 次に、実装ステップにおいておきた2つの問題点について話させて頂きます。FRESH LIVEの配信サーバーでは同時に多数のユーザーのストリームを受信します。これらのストリームがどのユーザーからのものかを識別するためにRTMPのStream Nameを使用しています。しかしSRTには同等の仕組みがなかったため、配信者ごとに別々のポート番号を割り当てる必要がありました。そうすると多数のポート番号をインターネット上で開放する必要があり、セキュリティ上の問題が懸念されました。
しかし、SRT 1.3でStream IDというRTMPのStream Nameに相当する仕組みが導入されたため、これを利用することにしました。
しかしStream IDはまだ新しい機能で、サポートしているSRTプロダクトが少なく、FRESHLIVEで使用しているWowza Stream Engineでも、Stream IDをサポートしていません。
そこでWowzaの手前に独自に開発したSRT Proxyサーバーを置くことによりこの問題を解決しました。
例えば、SRT Proxyサーバーは、ポート5000で、ストリームを受信して、Stream AAAはWowzaのポート1234へ転送し、Stream BBBはWowzaのポート5678へ転送します。
- もう一つの問題がNetwork Adaptive Enodingを実装する際に発生しました。Network Adaptive Encodingは回線速度の変化に合わせて動的にエンコーダのビットレートを変更する機能です。これはHaivisionのMakito Xに実装されている機能で、これを参考にFRESH LIVEのiOSアプリにNetwork Adaptive Enodingを実装しました。
これは、SRT パケットを送信するたびに、受信側で回線速度を見積もり、その値が送信側へ転送され、エンコーダへフィードバックして出力ビットレートを常に最適なものにするという仕組みになっています。高ビットレートでは問題がなかったのですが、ネットワーク状況が悪化してエンコーダのビットレートが300kbps程度に落ちると、ネットワーク状況が回復しても回線速度の見積値が常に300kbps以下になり続け、ビットレートが元に戻らなくなるという奇妙な現象が発生しました。
- この問題を解決するためにSRTのソースを解読して、回線速度見積もりがどのように行われているか解析しました。動画を送信するときは、通常エンコードが完了するたびに1フレームずつ送信することになります。SRTパケットは標準では1316byteですが、これはビデオの1フレームより小さいため、複数のSRTパケットに分割されて送信されます。そのため図のように複数のSRTパケットが一気に送信され、しばらくしたら、次のSRTパケットが送信されるということが繰り返されます。パケットが一気に送られるときは回線をフルに使うため、この時の送信速度から回線速度を見積もることができます。SRTは次のようにしてこの値を計算します。SRTはそれぞれのパケットの送信間隔のサンプルを最新16個保持します。このサンプルの中間値を求め、この中間値から大きく外れた送信間隔のサンプルを除きます。この図ではd4とd8が外れることになります。残りのパケット送信間隔サンプルから平均値を求めて平均パケット送信間隔Dが求まります。SRTパケットサイズである1316byteをパケット送信間隔Dで割ることにより回線速度を見積もることができます。
- 低ビットレート配信時は、ビデオ1フレームが1つか2つのSRTパケットになります。この場合先ほどのアルゴリズムで図のd2とd3を除外することができないため、回線速度の見積もり値が、送信ビットレートに等しくなってしまいます。これを解決するために送信側で常に10個のSRTを溜めて、まとめて送るようにしました。低ビットレート配信時に最大10フレーム分の遅延が発生することになりますが、この変更で常に正しい回線速度見積もり値を得ることができるようになりました。
- SRTのインテグレーションは、他には大きな問題もなくスムーズに進みました。
Example Applicationであるstransmitの完成度が高く、再接続処理、SRTの通信ログ出力、統計情報出力などをサポートしているため、開発ツールとしても役に立ち、またSRT APIの使い方のサンプルプログラムとしても非常に役に立ちました。
今年になりiOSやAndroid用にSRTライブラリをビルドするスクリプトも追加されており、モバイルアプリへのSRTの組み込みは簡単にできるようになっています。
またWiresharkがSRTをサポートしたことにより、SRT関連のネットワーク問題を解析しやすくなりました。先月SRT対応がWiresharkのマスターブランチにマージされたため、Wiresharkの開発バージョンをダウンロードすれば、WiresharkのSRTサポートを利用することができます。
- SRTを導入して1ヶ月ほど立ちますが、大きな問題は起きておらず、以前に比べて外からの配信なども安定するようになりました。
SRTを導入してよかったことの一つとして、SRT通信の統計情報がサーバー上で見られるようになったということがあります。RTMP使用時は映像が止まったり、歪んだりしても配信者のネットワークで何が起きているのかがはっきり分かりませんでした。しかし、SRTの統計情報からパケットロス率やRTTなどが分かるため、何が起きているのかが推測しやすくなりました。
SRTを導入することにより、最新のコーデックであるHEVCやOpusも使えるようになったということも利点の一つです。現在FRESH LIVEではH264を使用していますが、プロトタイプではiOS端末からHEVCでの配信ができることを確認しています。
- FRESH LIVEは国内向けのサービスですが、稀に海外から配信するユーザーもいます。SRTは長距離の通信に対しても強いため、これらの配信も安定してくると思います。
配信者の配信ツールがSRTに対応していなくても、図のようにSRT Proxyサーバーをその配信者の近くに配置することにより解決することができると考えています。
- 最後に、FRESH LIVEへのSRT導入の過程で開発したオープンソースのライブラリを紹介させて頂きます。
まずiOSでカメラ、マイクからの入力をSRTで配信できるVideoCast-Swiftです。
これはHEVCにも対応しており、iPhone6S以上でHEVCでの4K配信も可能です。
また、先に紹介したNetwork Adaptive Encodingも搭載しています。
次にGoでSRTの送受信を行うgosrtです。FRESH LIVEのSRT Proxyサーバーで実際に使用しています。APIをGo標準のTCP/IP通信のAPIに似せて作っているため、Goプログラマーが簡単にSRTを組み込めるようになっています。
ご静聴ありがとうございました