Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à FRESH LIVEへのSRT導入
Similaire à FRESH LIVEへのSRT導入 (20)
FRESH LIVEへのSRT導入
- 1. FRESH LIVEへのSRT導入 #StreamingConf #5 松澤 友弘 – Software Engineer at CyberAgent
- 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)
- 5. ストリームの識別 RTMP Stream Name SRT 1.2 ポート番号 SRT 1.3 Stream ID
- 6. Network Adaptive Encoding • 回線速度の変化に合わせて動的にビットレートを変更 • Haivision Makito Xに実装されている • 問題 : 300kbps以下の配信 回線速度見積値が常に低い値
- 7. SRT回線速度見積アルゴリズム 1.中間値から大きく外れたd4とd8を除外 2.平均パケット送信間隔 D = d1 + d2 + d3 + d5 + d6 + d7 / 6 3.回線速度見積値 = 1316 / D
- 8. 低ビットレート配信時の問題 • １フレームが１つか２つのSRTパケットに分解される -> d2とd3を除外できない • 10個のSRTパケットごとに送信するように改造
- 9. インテグレーションの容易さ • Example application - stransmitの完成度が高い • 再接続処理 • SRTログ収集 • 統計情報（帯域見積もり、RTT等） • iOSのビルドスクリプト • 他のSRT対応iOSアプリの開発者が追加 • WiresharkがSRTサポート • 現在は開発バージョンのみ
- 10. SRT導入による恩恵 • 野外からの配信が安定 • 統計情報が見れる 配信問題の可視化 • HEVC、Opusも使える • 海外対応のサーバー構成がシンプルに
- 11. 海外展開
- 12. OSSライブラリの紹介 • VideoCast-Swift • https://github.com/openfresh/VideoCast-Swift • iOSでカメラ、マイクからの入力をSRT配信 • H264、HEVC対応 • Network Adaptive Encoding • gosrt • https://github.com/openfresh/gosrt • GoでSRTの送受信 • GoのTCP 通信APIとほぼ同じAPI
Notes de l'éditeur
- まず自己紹介させていただきます。 私が初めて動画関連のプロジェクトに関わったのは２０００年で、IP-700IIというリアルタイム映像伝送装置の開発を行なっていました。２００６年に渡米して、２００７年からシアトルのスタートアップ会社でゲームの開発を行っていました。２０１４年に帰国して、ゴルスタという中高生向けのソーシャルネットワークアプリの開発に携わり、後半は主にゴルキャスと呼ばれるライブストリーミング機能の開発を行っていました。２０１６年にサイバーエージェントに移り、現在はFRESH LIVEの配信基盤の開発を行っています。
- 次に、FRESH LIVEにSRTを導入することになった経緯を話させて頂きます。 FRESH LIVEは、誰でも動画の生中継を配信することができるライブ配信サービスで、2016年にサービスを開始しました。 サービス開始当初はRTMPとHLSといったオーソドックスなストリーミングプロトコルを使っていました。 HLSを使うことにより高画質の配信を実現できていましたが、１０から３０秒という大きな映像ラグが課題でした。 それを解決するために2017年にHLSを改良した低遅延のLHLSを導入して、映像ラグを３秒程度に縮めることに成功しました。 FRESH LIVEでは、比較的安定したネットワーク環境からPCで配信するユーザーが多かったため、このアプローチはうまくいっていました。しかし、ほぼ同じタイミングでiPhoneからFRESH LIVEに配信できるアプリをリリースしたところ、不安定なネットワーク環境からの配信が多くなってきました。 時々、RTMPで３秒以上の揺らぎが発生することがあり、全体としての映像ラグを３秒程度に収めることが難しくなってきました。 そこでRTMPの代わりになるプロトコルを探し始めたのが、SRTを導入するに至ったきっかけです。いくつかのチャレンジがありましたが、１０月末にSRTを導入したiOSアプリをリリースして、現在FRESH LIVEではiOSでの配信にてSRTを使用しています。
- 次に、SRTとRTMPについて比較して見ましょう。 RTMPはAdobeが開発して、2002年にFLASH Player 6で導入されました。２００９年にプロトコルの仕様が公開されています。対してSRTは、Haivisionのエンコーダー装置の伝送プロトコルとして開発され、２０１３年のIBCで一般公開されました。２０１７年にオープンソース化されています。 RTMPはTCPベースのプロトコルです。TCPにはパケットロス時の再送処理が遅く映像ラグの原因になるという問題があります。またTCPのコンジェスチョンコントロールの仕組み上、長距離配信にて帯域が制限されるという問題もあります。SRTはUDPをベースに、改善されたパケット再送とコンジェスチョンコントロールの仕組みが実装されており、これらの問題が緩和されています。 RTMPはコンテナがFLVに制限されています。FLVはH265のような最新のコーデックをサポートしていないため、RTMPでは最新のコーデックを使うことができないという問題があります。SRTではコンテナの制限がないため、どんなコーデックでも使用可能です。今は主にコンテナとしてMPEG2-TSが使われています。
- 次に、実装ステップにおいておきた２つの問題点について話させて頂きます。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のソースを解読して、回線速度見積もりがどのように行われているか解析しました。動画を送信するときは、通常エンコードが完了するたびに１フレームずつ送信することになります。SRTパケットは標準では1316byteですが、これはビデオの１フレームより小さいため、複数のSRTパケットに分割されて送信されます。そのため図のように複数のSRTパケットが一気に送信され、しばらくしたら、次のSRTパケットが送信されるということが繰り返されます。パケットが一気に送られるときは回線をフルに使うため、この時の送信速度から回線速度を見積もることができます。SRTは次のようにしてこの値を計算します。SRTはそれぞれのパケットの送信間隔のサンプルを最新１６個保持します。このサンプルの中間値を求め、この中間値から大きく外れた送信間隔のサンプルを除きます。この図ではd4とd8が外れることになります。残りのパケット送信間隔サンプルから平均値を求めて平均パケット送信間隔Dが求まります。SRTパケットサイズである1316byteをパケット送信間隔Dで割ることにより回線速度を見積もることができます。
- 低ビットレート配信時は、ビデオ１フレームが１つか２つのSRTパケットになります。この場合先ほどのアルゴリズムで図のd2とd3を除外することができないため、回線速度の見積もり値が、送信ビットレートに等しくなってしまいます。これを解決するために送信側で常に１０個のSRTを溜めて、まとめて送るようにしました。低ビットレート配信時に最大１０フレーム分の遅延が発生することになりますが、この変更で常に正しい回線速度見積もり値を得ることができるようになりました。
- SRTのインテグレーションは、他には大きな問題もなくスムーズに進みました。 Example Applicationであるstransmitの完成度が高く、再接続処理、SRTの通信ログ出力、統計情報出力などをサポートしているため、開発ツールとしても役に立ち、またSRT APIの使い方のサンプルプログラムとしても非常に役に立ちました。 今年になりiOSやAndroid用にSRTライブラリをビルドするスクリプトも追加されており、モバイルアプリへのSRTの組み込みは簡単にできるようになっています。 またWiresharkがSRTをサポートしたことにより、SRT関連のネットワーク問題を解析しやすくなりました。先月SRT対応がWiresharkのマスターブランチにマージされたため、Wiresharkの開発バージョンをダウンロードすれば、WiresharkのSRTサポートを利用することができます。
- SRTを導入して１ヶ月ほど立ちますが、大きな問題は起きておらず、以前に比べて外からの配信なども安定するようになりました。 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を組み込めるようになっています。 ご静聴ありがとうございました