ストリーミングサーバを自前で構築する前編(考察編)

こんにちはszkです。
配信系の記事が多い今日この頃。

今までのミラー配信の手順で公開していたのは手っ取り早く配信を開始できる「配信サイトを中継し、ブラウザで開く」という方法でした。

しかしこの方法にはいくつかの問題があります。
1．YoutubeLiveなどの配信サイト側の問題や事情により配信が中断れてる可能性がある。
2．一旦遠隔地のサーバを中継するためタイムラグが大きくなる．

そこで、今回は中継する配信サイトに位置するサーバを自前で用意して利用するという方法を紹介しようと思います。
やっとszkの本業の話っぽくなってきたな！

この記事について

今回紹介する方法は過去に紹介した方法に比べるとかなり難しい、いわゆる「上級編&応用編」というべき内容となっています。
実施にはIT及びそのネットワークと、映像配信にについての基本的な知識を必要とします。

なるべく、初心者の人にわかりやすく説明するため今回は前半と後半の2部に分けて紹介を行います。
また、IT用語については「全く知らない人向け」に説明を行いますので、IT業界的不適切表現がいくつか出てくると思いますがご了承いただければ幸いです。

前半(この記事)

・今回使う手法と通信規約についての説明。(RTP/RTMP/HSL当たりの説明)
・今回の手法について全体的な説明
・全体構成の設計についての考察

後半(方法別に紹介)

・サーバの構築方法と実際の使用方法について

では初めて行きましょう。

通信規約について

さて、配信を中継するにあたって映像系統の通信規約(プロトコル)についておさらいしておきましょう。
プロトコルはネットワーク上で通信を行う際の「決まり事」のようなもので、例えばAさんが英語しかわからないのにBさんが日本語で話しかけても話が成立しないように、ネットワーク上の通信も「決まった方式」で送信/受信しなければ成立しない、というものになります。(雑説明)

ちなみに普段このブログで度々話している「NDI」も通信規約の一つです。
この記事にたどり着いた人はおそらく色々なプロトコルを見てきて「結局どれがいいの？」という感覚を持っているはず。

ググると出てくるプロトコルについてここで一旦まとめておきましょう。
興味ない人は読み飛ばしてOKです。

TCP(Transmission Control Protocol)

現代のインターネットにおける主流な通信規約。
Web徘徊で皆さんが毎回使っているHTTPもこの「TCPに属する通信規約」です。
特徴としては詳しくはググってどうぞ、ですが簡単に言うと送信側と受信側で通信の成功可否を確認する為パケットの欠損が発生せず品質が良いということ。
まぁ、最近のHTTPやその上で動くHSLさんはTCP使いつつバンバンパケット送りつけたりしてしっちゃかめっちゃかなんですが、その話はまた今度で

UDP(User Datagram Protoco)

TCPのように通信の成功可否や通信の開始の手続き(ネゴシエーションという)を行わずにとりあえずデータを送りつける通信方式。
手続きをしない分送信が早い。
しかし、失敗してようが成功してようがデータを送信し続ける為データに欠損が発生する可能性がある。という方式です。
RTPをはじめとするプッシュ配信はこの方式を使っており、かつてはインターネット上の動画像送出はこの方式を使うのが主流でした。

HTTP

Webサイトを閲覧するときに使用するプロトコル。恐らく現代社会で最も利用されているプロトコルだと思います。
TCPに属する通信規約で誕生してから30年余り、その便利さと普及率の高さでHTTPの中でも様々な通信方法が実装されている沼プロトコル。

RTP/RTSP

通信の品質担保は確実にしたいのでTCP。通信自体は早いほうがいいのでUDPで行う通信方式。
名前の通り遅延が少なく映像と音声もどっちも遅れて優秀なプロトコル。
正し、性質上グローバルで使用されることは想定されてなくローカル向け(カメラとサーバを接続する用途)の通信で、NDIが映像畑から出てきたプロトコルならこちらはIT畑から生まれたプロトコルという感じ。
競合はNDIですかね。

NDI

TCPのプロトコルの一つ。
映像系の通信方式である「SDI」をそのままITの世界に持ってきちゃおう！という趣旨で生まれたプロトコル。
そのため映像や音声のほかブラックバースト信号やタイムコードまで乗ってくる。
ITでネットワークやってる人からするとむしろ「専門外」な通信規約。
その用途の通り、ターゲットはローカルでの使用の為グローバルでの使用には不向き。

RTMP

Adobe(旧Macromedia)が作った通信規約でFlashでストリーミング映像を流すために開発された通信規約。
主にWeb上で使用され2015年くらいまでの主流はこれでした。

ただし、2020年にサポートがついに終了するのでこれから過去のプロトコルとなる。

HSL

RTMPをリファインしつつ、FLASHに依存せずHTTPの仕組みを用いて通信を行う方式。
元々高速通信やストリーミングを想定していなかったHTTPで今やここまでしちゃうから凄いですよね。
現在の配信系サイトもこの方式を採用しており、今回紹介するのもこの方式となります。

2020/04/28追記

なんかサーバ組んでたら知ったんですけど最近はMPEN-DASHなる新規格があるそうで、コイツの方が高品質&低遅延だそう。
もしかするとこっちで構築記事書くかも？

2020/04/28さらに追記

界隈先駆者のFAIO氏からツイート頂いて「SRT」なるさらに新しいプロトコルがあるそう。
どうやらNginxを使用しない別のプロダクトもあるらしく、こちらも併せて調べてます

まとめ

RTP/NDI=ローカル向けで主旨が違う
RTMP＝FLASHのサポートが終わることでポジション上古いとされる規格。遅延は最小)
HSL＝最もメジャー(遅延は大きい)
MPEG-DASH=新規格(高品質でRTMPより遅延はあれどHSLより低遅延)
SRT＝さらに次世代の新規客(RTMP並みの低遅延)

TCPとUDP＝各プロトコルのさらにベーシックな部分を司る通信規約。TCPは安定だが遅い、UDPは不安定で早い。

概念(通信)

過去に紹介した方法との差

概要は以下のような形になります。

左が配信元(DJ配信)で右が配信中継者(VJやミラー配信する人)です。
実際の配信では右のVJ/配信中継者がさらにYoutubeライブなどに配信を行う仕組みとなります。

今までの記事で紹介していたOBSソース「ブラウザ」を用いた方法は下の図の下の矢印。
今回紹介する方法が上の矢印の経路を取ることになります。

RTMP/HSLサーバについて

RTMP/HSLサーバ、と名前は言っていますが利用されるコンポーネンツはNginx(＋RTMPモジュール)というサービスのみ。
これはWebサーバで広く利用されているもので、いわば「Webサーバが立てられればHSLサーバの実装は可能」ということになります。
「HSLサーバ」「Nginx」と難しい言葉が連続していますが、やってることはいわば「僕だけのYoutubeLiveを組み立てる」といった具合。
各配信サイトは世界各国のインターネット上にサーバが存在しますが、今回の方法では自分の好きな所にサーバを立てられる為一定の遅延や同期をサーバ側で吸収できます。

では、実際にどのようにサーバを構築・設置するのが良いか以下で考察してみます。

設計について/どんな方法があるのか整理する

HSLサーバを立てる時の設計について考察してみます。
尚、これはITシステム全般に言えますが「最強の構成」なんてものは存在しません。
あるのは「俺にとっての最強構成」のみ。
各自がやりやすい方法で実施頂くのが良いかなと思います。
尚基本的に「Internet」を中継する際は大きなラグが発生すると考えていだたいた方が良いと思います。

配信サイトを利用する場合（おさらい）

まず、過去に紹介した形式をおさらいしてみます。
各配信元は個別のアカウントから配信サイトに出力を行います。

経路としては「配信元」→「配信サイト」→「配信ミラー」→「配信サイト」となります。

配信元のLAN内にサーバを構築する

この方法では配信元のLAN環境にサーバを立てます。
配信元と配信サイトの間のラグは限りなく少なくなりますが、サーバの管理は配信元毎に行う必要があり
配信元に一定のITリテラシーを要する方法になります。

配信集約PCのLAN内にサーバを構築する

この方法は配信集計元のLAN環境にサーバを立てます。
配信元とサーバのラグはありますが、サーバと最終的に配信を個なうミラー配信PCのラグは少なくなります。
配信元の負担も配信サイトに対して配信する方法と差異がありません。
サーバを管理する人の負担が多く、ITリテラシーも必要としますが、構成としては最も効率的かつ理想的な構成と言えます。

外部インターネット上にサーバを構築する

インターネット上の別ネットワークにサーバを立ち上げます。
主に利用するのは「パブリッククラウド」と呼ばれるようなサービスでしょう。

この方法ではラグの問題については大きな解決にはなりません。
外部にサーバを持っているため、配信サイトを利用するパターンと比較して差は無し～多少マシ程度になると思われます。
しかし、自宅にサーバを立てれない方にとっては有効かつ、自宅のセキュリティ等を無視して構築できる点で優れています。

そうですね。私もテスト配信では画像のようにローカルにRTMPサーバ立ててやってますね。
記事の公開ツイートお待ちしております〜 pic.twitter.com/ULKvyflXvk

— xcorp?予後不良 (@_xcorp_) April 24, 2020

ちなみにTwitterでxcorpさんもこの構成で考察しているようです。
この場を借りて紹介とさせて頂きます。

余談：上記で記載されている「ITリテラシー」について

一般的に「サーバ」とは専用の機器は必要無く、PCと手法さえ確率されていれば簡単に構築が可能です。
ただし、「それを外部に公開できるか」は各自の環境に大きく左右されます。
例えば自宅のネットワークを外部に公開する際は一般的に「ポート開放/NAT変換」と呼ばれる作業が必要になります。
これは現実世界における「東京都北区△町〇番地-〇‐〇」までわかっていても、「どの部屋の誰か」がわかっていなければ荷物の配達が難しいのと考え方が似ており、ポート開放では「アクセスがあった場合、IPアドレスのこの機器のこのポート番号に向けて通信してくれ」という宣言をルータに行うことで通信を可能にしています。

例えばこのszkhaven.comはグローバルIPアドレスが「113.150.11.76」ですが、szkの管理しているこのIPアドレスのルータに対して「113.150.11.76のポート443にアクセスがあったら192.168.x.xの443ポートとして通信してくれ」という設定を行っています。

また、外部にIPを公開する以上はセキュリティの問題も孕んできます。
知識なしにうかつに外部にIPを公開するとbotによるスキャニングやら攻撃やらで色々大変だったりします。

ですので、サーバを立てて外部公開するときは一定のITリテラシーを持った人が行うことを強く推奨します。