#fedimovie PeerTubeはファイル容量の大きい動画をホストするサービスということもあり、連合によって投稿を配送する際も、動画そのものを複製しません。
自身のコンテンツを管理しやすいプラットフォームです。
ここでは、動画を投稿したサーバをオリジンインスタンスと呼びます。
他のサーバの動画を再生する場合は、オリジンインスタンスの持っている動画データを直接参照します。
ただ、そのままだと人気のある動画をホストした場合に、みんなのアクセスが集中し、オリジンインスタンスに非常に高い負荷がかかります。
そこで、P2Pとミラーリングで負荷分散する仕組みがあります。
P2Pは、動画を同時視聴しているユーザー同士でデータをシェアしあうことで、オリジンインスタンスの負荷を軽くする仕組みです。
ブラウザ同士で通信しあう時にお互いのIPが割れるということがあるため、自分のブラウザをデータ提供に参加させるかどうかは任意です。
WebTorrentによって、WebRTCで動画データ（フラグメント）を融通しあいます。
参加しているブラウザはピアと呼ばれます。
#fedimovie ミラーリングは、余力のあるインスタンスが、他のインスタンスの負荷を引き受ける仕組みです。
自インスタンスのユーザーにとってリモートの動画をスムースに再生できることにもつながります。
自分にとってのメリットと、全体にとってのメリットがうまくマッチする仕組みで、よく出来ているなと思います。
ミラーリングは標準では有効になっていません。
有効にする場合、いくつかのミラーリング戦略に基づいて、自動的に実行されます。
自身のインスタンスでよく再生される動画を対象にしたり、新着動画を対象にしたり、トレンドになっている動画を対象にしたりします。サイズや再生数なども基準にします。
ある程度時間をおいて定期チェックし、不要と判断される基準を超えたら破棄します。
最大保持数も指定します。
管理者による手動ミラーも可能です。
#fedimovie あれ、ミラーリングの動作の部分、文字数調整してるあいだに消しちゃったな？？w
動画をWebで共有して再生する場合、全部ダウンロードしなくても、すぐに再生を開始できるようにしたいし、任意の位置にシーク（再生位置の変更）したいので、ストリーミング対応の動画データにあらかじめ加工しておきます。
具体的には、動画を細かなセグメントに分割しておき、そのインデックスを用意しておきます。
これで、必要なセグメントにすぐにアクセスでき、セグメント単位で再生できることを保証できます。
また、このセグメントを、P2Pでブラウザ間でやりとりしたり、ミラーリングした任意のサーバにアクセスして、負荷分散することを可能にしています。
帯域が厳しい時は、解像度を変えた動画を使って、セグメントごとに自動で切り替えることもできます。途中から解像度を下げたり、また元に戻したりすることが可能です。
#fedimovie 補足でちょっと画像つけとくね。
P2Pに参加する（ピアになる）かどうかは、自分の設定と、あと再生する時に画面下部に確認がでます。
ユーザーに断りなく行わないようになっています。
少しでもリスクを減らしたい場合や、帯域に余裕がない（転送量課金対象になっているなど）場合は参加しない方が良いです。
他方、参加することで再生が安定する場合もあるわけです。
何をしているのか理解した上で、活用してください。
#fedimovie ここまで書いたのでついでに。
動画配信者は、RTMPで動画をFediMovieインスタンスに配送します。動画のストリーミング配送プロトコルですね。
インスタンス側ではffmpegがこの受信側を担っており、HLSにトランスコードして、先程のような小間切れのTSファイルとその一覧のm3u8ファイルを吐き出しています。
ブラウザでこれを受け取って再生するコンポーネントがVideo.jsで、HLSによるストリーミング再生を実現しています。
#fedimovie このあいだのP2Pの実例。
いま、S.H.さんがやってるHALOのキャンペーン攻略のライブ動画配信を、
https://fedimovie.com/w/hcYWdEstnw3aPDhpEuAHz5
4視聴者が閲覧していて、2人がP2P（WebTorrent）に参加しています。
不参加の2人は、インスタンスから77MBを直接受け取っています。
参加している1人（私）は、添付画像のように、インスタンスから43MB、ピアから33MBというような割合で受け取っています。
また、他のピアに向けて36MBのデータを受け渡しています。
もう一人のピアの内訳はわかりませんが、概ね逆算できるハズです。
このように、たった2人のピアの参加ですら、インスタンスにかかる負荷を軽減する効果があります。
なお、通常の動画はオブジェクトストレージに移動し、そちらからデータを流していますが、ライブの場合はインスタンスのストレージから直接配送します。
小間切れの.tsファイルがあって、その一覧を.m3u8で渡してます。4秒ずつで、1分ちょっと保持してる感じかな。この小間切れを、インスタンスかピアから受け取っているわけです。